Здравствуйте, Хон Гиль Дон, Вы писали:

ХГД>Напомню — я изначально говорил лишь о применимости С++ для некоторых конкретных условий, ничего не утверждая о масштабности приложения. Но вообще у нас GWTшных и флэшевских исходников мегабайт 30-40, если это кому-то интересно.

А с применимостью никто и не спорит. Разногласия в целесообразности.

PS. вы же вон тоже флеш и гвт заюзали

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, artelk, Вы писали:

A>>Когда не требуется большое число одновременных задач?
_>Например при организации фоновых процессов не серверных приложений.
Это я повторил, убрав лишнее "не".

A>>Без поддержки языка работать с продолжениями неудобно — будет лапша.

_>Что подразумевается под поддержкой языком? К пример в boost.thread продолжения давно есть и вполне себе нормально работают...
Что-нибудь, что позволяет выпрямить такой код:

F1(..., a=>{
  ...
  F2(..., b=>{
    ...
    F3(..., c=>{
      //use a, b and c
    });
  });
});

А в идеале, чтоб, если захочется, еще можно было, например, завернуть все в try/catch:

try
{
   var a = await F1(...);
   var b = await F2(...);
   var c = await F3(...);
   //use a, b and c
}
catch(Exception ex)
{
  //...
}

A>>Интересует не "полностью аналогичная реализация", а аналогичная возможность — чтоб лапши небыло, но с масштабируемостью из коробки.
_>Ээээ, какая ещё масштабируемость в данном разделе? С этим обращаться ко второй части того моего сообщения... )
Нуу.. если приложение серверное, то почему бы и нет? Ну ок, оставим только "чтоб лапши небыло".

A>>А чем с акторами проще?

_>Ну это собственно дело вкуса. Т.е. лично мне больше нравится такая архитектура, исключительно по эстетическим признакам. И естественно подобное нельзя пытаться кому-то навязывать. Однако могу просто показать упрощённый пример, демонстрирующий разницу в этих стилях. Весь код на C++.

_>Значит с сопрограммами мы можем написать так:
_>

_>void OnClick() async_code
_>(
_>    textbox+=await_async([]{return download("http://...");});//download - блокирующая функция, запускается в отдельном потоке
_>)
_>

_>А в стиле акторов будет что-то вроде:
_>

_>void OnClick()
_>{
_>    thread([]{PostData(download("http://..."));}).detach();
_>}
_>void OnData(string data)
_>{
_>    textbox+=data;
_>}
_>

_>Оно конечно длиннее, но лично мне больше нравится по ряду причин.

Кто и как вызывает OnData? Что за ряд причин?


_>>2. Когда требуется не большое число одновременных задач.
A>>Когда требуется большое число одновременных задач?
_>В основном при реализации высоконагруженных серверов.
Это я повторил, убрав лишнее "не".

A>>Еще раз, меня в этой ветке интересует, чтоб масштабируемость по ядрам была и чтоб при этом код в лапшу не превращался. И да, я имею ввиду сервис, не UI.

_>Если критична производительность, то я пожалуй не стал бы увлекаться всяческими архитектурными изяществами (типа сопрограмм, причём как в сомнительной .net реализации, так и даже C++ реализации), а решил бы проблему в лоб стандартными средствами. Причём в C/C++ их выбор тоже не маленький с разным уровнем продуманности программного интерфейса. Если в C++ стиле, то это Boost.Asio, а если в C стиле, то это libevent, libev, libuv. Все они достаточно вылизанные и заточенные на производительность.
Блин, ты пойми, я не только такты считаю, я хочу, чтоб все ядра использовались и IO асинхронный был, но, при этом, код в спагетти не размотало.
Вот, например, сделаешь ты зеленые потоки в одном системном потоке — остальные ядра будут проставивать, даже когда работа есть, запросы новые идут.

_>>>а для просто реализации зелёных потоков поверх пула системных ничего дописывать и не надо — оно просто работает
A>>Покажи?

_>Так я же говорю, если без семафора, то Евгений уже показал что всё работает. Ну т.е. он не показал собственно организацию пула потоков (это отдельное реализуется или берётся готовое из того же boost'a), а продемонстрировал, что boost.coroutine вполне дружат с многопоточностью. Кстати, что самое интересное, boost.asio дружит с многопоточностью по точно такой же модели (http://www.boost.org/doc/libs/1_56_0/doc/html/boost_asio/overview/core/threads.html), так что все 3 компоненты (пул потоков, сопрограммы, асинхронный ввод/вывод) без всяких напрягов собираются в единую системку.

Asynchronous completion handlers will only be called from threads that are currently calling io_service::run()

Подозреваю, что тут лишний перескок из IOCP thread, не?

_>Но опять же надо понимать, что даже такая крайне эффективная реализации сопрограмм всё равно имеет определённые накладные расходы. Так что если уж производительность уж совсем критична, то лучше забыть про сопрограммы. И кстати не такой уж и страшный код без них выходит. )))
От boost.asio тоже придется отказаться?

A>>Имхо, акторы хороши, когда модель приложения в виде асинхронно общающихся объектов, посылающих друг другу сообщения, является естественной для решаемой задачи. Неясно, нафиг они нужны для вышеупомянутого сервиса и для UI с кнопкой, по которой что-то асинхронно выкачивается. Можешь объяснить?

_>Для сервиса я их и не предлагаю. Хотя скажем Theron может и не плохо справился бы (http://www.theron-library.com/index.php?t=page&p=performance) в смысле производительности, но не вижу особого смысла тащить его для таких целей.

_>А вот скажем на асинхронное скачивание по кнопке в UI акторы очень даже не плохо ложатся. Правда для такой задачи не нужна мощная библиотека типа Theron, а достаточно тривиальной реализации (см. пример выше).

Здравствуйте, _Raz_, Вы писали:

_R_>modelBuilder.Entity<Person>().Ignore(t => t.Runtime);

А в каком месте подобное можно вызывать?

_R_>Нет, не обязательный. См. выделенное. Мне было так удобней, но можно и как у тебя. Добавиться только строка db.SaveChanges().

Так и думал. )

_R_>Ну а ты чего хотел? Разные фреймворки все-же, на разных языках. Хочешь строчки считать? Это не ко мне. Я ясно показал, что есть штатная возможность легко ислючить свойство из маппинга.

Как раз посчитать строчки (грубо говоря) и было целью. ))) Ну и кстати с твоей помощью вполне вышло. В результате я бы оценил что удобство/размер кода/надёжность (я надеюсь что в твоём примере за соблюдением полей и их типов тоже статически следит компилятор?) приблизительно одинаковые, хотя стиль реализации немного разный.

P.S. Странно с чего это Ikemefula и Ночной Смотрящий не осилили показать подобный код.

Здравствуйте, artelk, Вы писали:

A>Что-нибудь, что позволяет выпрямить такой код:
A>...
A>А в идеале, чтоб, если захочется, еще можно было, например, завернуть все в try/catch:
A>...

Если цель именно "выпрямлять", то по идее ничего кроме какой-то разновидности сопрограмм и не поможет. Моя же мысль была в том, что кроме "лапшевидного" и "выпрямленного" кода, могут быть и другие удобные варианты. Кроме уже упомянутых акторов можно вспомнить ещё и организацию обработки сообщений в классических ООП фреймворках (когда весь управляющий код скрыт где-то внутри, а пользователь библиотеки просто переопределяет пару нужных функций у наследуемого класса, которые будут сами вызваны фреймворком в нужный момент). Или например если взять машину состояний с нетривиальной реализацией (типа такого http://www.boost.org/doc/libs/1_56_0/libs/msm/doc/HTML/ch03s04.html#d0e1462 например). Да мало ли ещё вариантов. Не вижу особой потребности именно в линеаризации параллельного кода.

_>>Оно конечно длиннее, но лично мне больше нравится по ряду причин.
A>Кто и как вызывает OnData? Что за ряд причин?

Главный цикл обработки сообщений UI потока. Т.е. это универсальный код, реализованный даже не под приложение, а вообще на уровне фреймворка.

А причины, как я уже сказал, исключительно субъективные и эстетические — мне не нравится, что на самом деле нелинейный код (в реальности там возникает "разрыв", в котором может происходить что угодно) визуально старается притвориться линейным. На мой вкус подобное затрудняет полноценное понимание кода. Вообще у меня есть подозрение, что например многие пользователи await из .Net очень слабо представляют себе процессы, происходящие при этом внутри.

A>Блин, ты пойми, я не только такты считаю, я хочу, чтоб все ядра использовались и IO асинхронный был, но, при этом, код в спагетти не размотало.

Ну так и какие проблемы с многоядерностью у вышеуказанных инструментов? )

A>Вот, например, сделаешь ты зеленые потоки в одном системном потоке — остальные ядра будут проставивать, даже когда работа есть, запросы новые идут.

Так почему я в одном то сделаю, а не на пуле? )

A>

Asynchronous completion handlers will only be called from threads that are currently calling io_service::run()

A>Подозреваю, что тут лишний перескок из IOCP thread, не?

Вот тут http://www.boost.org/doc/libs/1_56_0/doc/html/boost_asio/overview/core/async.html есть картинка, которая очень хорошо всё поясняет. )

_>>Но опять же надо понимать, что даже такая крайне эффективная реализации сопрограмм всё равно имеет определённые накладные расходы. Так что если уж производительность уж совсем критична, то лучше забыть про сопрограммы. И кстати не такой уж и страшный код без них выходит. )))
A>От boost.asio тоже придется отказаться?

Нет, в boost.asio сразу много разных вариантов использования заложено. И кстати вариант на базе Boost.Coroutine вроде не так давно появился.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, artelk, Вы писали:

A>>Что-нибудь, что позволяет выпрямить такой код:
A>>...
A>>А в идеале, чтоб, если захочется, еще можно было, например, завернуть все в try/catch:
A>>...

_>Если цель именно "выпрямлять", то по идее ничего кроме какой-то разновидности сопрограмм и не поможет. Моя же мысль была в том, что кроме "лапшевидного" и "выпрямленного" кода, могут быть и другие удобные варианты. Кроме уже упомянутых акторов можно вспомнить ещё и организацию обработки сообщений в классических ООП фреймворках (когда весь управляющий код скрыт где-то внутри, а пользователь библиотеки просто переопределяет пару нужных функций у наследуемого класса, которые будут сами вызваны фреймворком в нужный момент).
Да, но если в этих переопределенных функциях делать вызовы async IO...

_>Или например если взять машину состояний с нетривиальной реализацией (типа такого http://www.boost.org/doc/libs/1_56_0/libs/msm/doc/HTML/ch03s04.html#d0e1462 например). Да мало ли ещё вариантов. Не вижу особой потребности именно в линеаризации параллельного кода.
Так он не параллельный, а именно последовательный! Просто в местах, где стоит await может быть перескок в другой поток. Параллельным он может быть, разве что, для вызывающего метода, если тот не делает await на нашем, когда его вызывает (но async у нашего метода как раз намекает, что такое может случится). Типичный пример:

void async Button_Click()
{
  var s = await DownloadAsync();
  txt.Text = s;
}

Тут надо учесть, что Button_Click вернет управление сразу и нужно задизэйблить кнопку, чтоб повторный запрос нельзя было сделать — UI не блокируется же.

_>>>Оно конечно длиннее, но лично мне больше нравится по ряду причин.
A>>Кто и как вызывает OnData? Что за ряд причин?
_>Главный цикл обработки сообщений UI потока. Т.е. это универсальный код, реализованный даже не под приложение, а вообще на уровне фреймворка.
Понятно, что цикл обработки сообщений UI потока. Интересуют детали.

_>А причины, как я уже сказал, исключительно субъективные и эстетические — мне не нравится, что на самом деле нелинейный код (в реальности там возникает "разрыв", в котором может происходить что угодно) визуально старается притвориться линейным. На мой вкус подобное затрудняет полноценное понимание кода.
И без разрыва может произойти что угодно, если у нас больше одного потока. И таки код не притворяется линейным, а таким и является, до тех пор пока мы параллельность явно делать не начнем (массивы тасков с WhenAny и т.п.).

_>Вообще у меня есть подозрение, что например многие пользователи await из .Net очень слабо представляют себе процессы, происходящие при этом внутри.
Это правда. Для многих async означает, что при вызове метода будет делаться new Thread(...).Start() или ThreadPool.QueueWorkItem(...), а то, что до первого await код будет выполняться синхронно, не знают;
а await — это то, что модно писать вместо ".Wait()" в новом фреймворке. ))

А у меня есть подозрение, что подавляющее большинство программистов, у которых в графе профессии стоит "C++", пишут код так, что ты это, мягко говоря, не назовешь идеоматичным кодом на C++.)
Т.е. не только boost, но и часто STL не знают, а пишут с стиле "C++ 80х".
И еще подозреваю, что самый тормозной код — это код на C++, написанный "индусами".))
А если взять среднестатистических C++ и C# программистов, то на типичном проекте с типичными ограничениями ресурсов (время, деньги) продукт на C++ будет содержать больше багов и (о ужас!) будет тормозить, по сравнению с написанным на C#.

A>>Блин, ты пойми, я не только такты считаю, я хочу, чтоб все ядра использовались и IO асинхронный был, но, при этом, код в спагетти не размотало.
_>Ну так и какие проблемы с многоядерностью у вышеуказанных инструментов? )
A>>Вот, например, сделаешь ты зеленые потоки в одном системном потоке — остальные ядра будут проставивать, даже когда работа есть, запросы новые идут.
_>Так почему я в одном то сделаю, а не на пуле? )
Если на пуле, то +1. Заблуждался на счет этого, Евгений меня переубедил.

A>>

Asynchronous completion handlers will only be called from threads that are currently calling io_service::run()

A>>Подозреваю, что тут лишний перескок из IOCP thread, не?
_>Вот тут http://www.boost.org/doc/libs/1_56_0/doc/html/boost_asio/overview/core/async.html есть картинка, которая очень хорошо всё поясняет. )

_>>>Но опять же надо понимать, что даже такая крайне эффективная реализации сопрограмм всё равно имеет определённые накладные расходы. Так что если уж производительность уж совсем критична, то лучше забыть про сопрограммы. И кстати не такой уж и страшный код без них выходит. )))
A>>От boost.asio тоже придется отказаться?
_>Нет, в boost.asio сразу много разных вариантов использования заложено. И кстати вариант на базе Boost.Coroutine вроде не так давно появился.
Inspired by async\await from C#?

Здравствуйте, Evgeny.Panasyuk, Вы писали:

Ок, убедил, можно, причем с даже почти с тем же синтаксисом.
Претензия в том, что вот опечатался ты где-нибудь и компилятор в аутпут выдает портянку со всеми потрохами и ошибка описывается в терминах этих потрохов. Потроха знать, конечно, полезно, но то, что они все время вылезают отнимает время, которое можно было бы потратить с пользой (например, на оптимизации ). Но это претензия общая для метакода на шаблонах и сишных макросов...

Здравствуйте, artelk, Вы писали:

A>Претензия в том, что вот опечатался ты где-нибудь и компилятор в аутпут выдает портянку со всеми потрохами и ошибка описывается в терминах этих потрохов. Потроха знать, конечно, полезно, но то, что они все время вылезают отнимает время, которое можно было бы потратить с пользой (например, на оптимизации ). Но это претензия общая для метакода на шаблонах и сишных макросов...

Сейчас есть конечно некоторые приёмы для улучшения этой ситуации (типа boost::concept_check). Но всё-таки нормальным решением будут концепции, которые надеюсь появятся в C++17.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, artelk, Вы писали:

A>>Претензия в том, что вот опечатался ты где-нибудь и компилятор в аутпут выдает портянку со всеми потрохами и ошибка описывается в терминах этих потрохов. Потроха знать, конечно, полезно, но то, что они все время вылезают отнимает время, которое можно было бы потратить с пользой (например, на оптимизации ). Но это претензия общая для метакода на шаблонах и сишных макросов...

EP>Сейчас есть конечно некоторые приёмы для улучшения этой ситуации (типа boost::concept_check). Но всё-таки нормальным решением будут концепции, которые надеюсь появятся в C++17.

Когда еще появятся.. я все компьютерные ОС решила выкинуть!

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, artelk, Вы писали:

A>>Претензия в том, что вот опечатался ты где-нибудь и компилятор в аутпут выдает портянку со всеми потрохами и ошибка описывается в терминах этих потрохов. Потроха знать, конечно, полезно, но то, что они все время вылезают отнимает время, которое можно было бы потратить с пользой (например, на оптимизации ). Но это претензия общая для метакода на шаблонах и сишных макросов...

EP>Сейчас есть конечно некоторые приёмы для улучшения этой ситуации (типа boost::concept_check). Но всё-таки нормальным решением будут концепции, которые надеюсь появятся в C++17.

когда только

Здравствуйте, Snezhanka, Вы писали:

EP>>Сейчас есть конечно некоторые приёмы для улучшения этой ситуации (типа boost::concept_check). Но всё-таки нормальным решением будут концепции, которые надеюсь появятся в C++17.
S>Когда еще появятся.. только разговоры одни!

Стандарта нет, а пробные реализации давно уже есть — например

Автор: Evgeny.Panasyuk
Дата: 27.03.13

.

Здравствуйте, alex_public, Вы писали:

_>А в каком месте подобное можно вызывать?

The code first fluent API is most commonly accessed by overriding the OnModelCreating method on your derived DbContext. The following samples are designed to show how to do various tasks with the fluent api and allow you to copy the code out and customize it to suit your model, if you wish to see the model that they can be used with as-is then it is provided at the end of this article.

Configuring/Mapping Properties and Types with the Fluent API

Здравствуйте, artelk, Вы писали:

A>Так он не параллельный, а именно последовательный! Просто в местах, где стоит await может быть перескок в другой поток. Параллельным он может быть, разве что, для вызывающего метода, если тот не делает await на нашем, когда его вызывает (но async у нашего метода как раз намекает, что такое может случится). Типичный пример:
A>...
A>Тут надо учесть, что Button_Click вернет управление сразу и нужно задизэйблить кнопку, чтоб повторный запрос нельзя было сделать — UI не блокируется же.

Лучше этот пример переписать вот так:

void async Button_Click()
{
    txt.Text=await DownloadAsync();
}

для одновременно большей красоты и непонятности (при условии, что мы хотим вообще понимать суть происходящего, а не рассчитывать на таинственную магию .net'a). Т.е. в таком коде надо чётко понимать, что между вычислением правой части (причём не важно в отдельном потоке или нет) и самим приравниванием может быть выполнен (в том же потоке) произвольный объём кода.

A>Понятно, что цикл обработки сообщений UI потока. Интересуют детали.

В каком смысле детали? ) Показать как подключаются обработчики сообщений в каком-то фреймворке или что? ) Или вытащить из исходников библиотеки код самого цикла? )

A>И без разрыва может произойти что угодно, если у нас больше одного потока. И таки код не притворяется линейным, а таким и является, до тех пор пока мы параллельность явно делать не начнем (массивы тасков с WhenAny и т.п.).

Я бы сказал что код на C# является линейным. А компилируется это (и соответственно выполняется) в совсем другие сущности. Вот эта "подделка" мне и не нравится.

Если что, это придирка не к C#, а к сопрограммам по каждому поводу вообще (т.е. включая Boost.Coroutine). Единственное отличие у C# тут в том, что в нём использование await рекомендуется везде, как повседневный инструмент. Вот это уже фигово. В C++ такого естественно нет и Boost.Coroutine используется в весьма специфических случаях, когда использование сопрограмм действительно оправдано.

A>Это правда. Для многих async означает, что при вызове метода будет делаться new Thread(...).Start() или ThreadPool.QueueWorkItem(...), а то, что до первого await код будет выполняться синхронно, не знают;
A>а await — это то, что модно писать вместо ".Wait()" в новом фреймворке. ))

A>А у меня есть подозрение, что подавляющее большинство программистов, у которых в графе профессии стоит "C++", пишут код так, что ты это, мягко говоря, не назовешь идеоматичным кодом на C++.)
A>Т.е. не только boost, но и часто STL не знают, а пишут с стиле "C++ 80х".
A>И еще подозреваю, что самый тормозной код — это код на C++, написанный "индусами".))
A>А если взять среднестатистических C++ и C# программистов, то на типичном проекте с типичными ограничениями ресурсов (время, деньги) продукт на C++ будет содержать больше багов и (о ужас!) будет тормозить, по сравнению с написанным на C#.

Ну я в общем то со всем эти согласен. Я тут уже не раз говорил, что у C++ и C# есть свои ниши, где они однозначно царят, ну и плюс большое промежуточное поле, в котором можно использовать с пользой оба инструмента. По моему мнению Java/C# отлично подходит для не IT компаний (кстати, надо понимать, что таких большинство), а соответственно C++ хорош для высокотехнологичных IT компаний, которые могут позволить себе нанимать не рядовых программистов.

_>>Нет, в boost.asio сразу много разных вариантов использования заложено. И кстати вариант на базе Boost.Coroutine вроде не так давно появился.
A>Inspired by async\await from C#?

Нуу несколько сложнее. Для начала сами Boost.Coroutine явно сделаны не под влиянием async\await, т.к. являются stackfull реализацией, а отличие от менее интересной реализации в .net. Тут прототипом скорее можно назвать какие-нибудь fibers из win32 (кстати, мы вот ещё про них забыли, когда перечисляли возможные варианты зелёных потоков). Далее, сами Coroutines появились в Boost'е относительно недавно, а Asio уже давно. Соответственно почти сразу как они появились, так и добавили в Asio вариант архитектуры с их использованием. Более того, помнится в примерах Asio давным давно встречались реализации наколенных не stackfull сопрограмм, но т.к. там всё надо было писать руками (в .net это генерирует компилятор), то особого смысла в этом не было. Т.е. там был уход от "лапши", но слишком дорогой ценой. )

Здравствуйте, Privalov, Вы писали:


P>P. S. Когда-то давно ассемблерщики выдвигали против фортранщиков примерно те же аргументы, что ты выдвигаешь против тех, кто работает на языках, отличных от С++ . Но скажи, где сейчас Фортран и где — Ассемблер?

Ну ассемблер вроде как живее фортрана...

Здравствуйте, genre, Вы писали:

G>А кому нынче нужна эта шустрость? Ну срендерится твой html не за 10мс а за 5. и?

Ну поставишь вместо пяти серверов два и?

Здравствуйте, Sheridan, Вы писали:

S>Володь, а можешь на скорую руку пробежаться каким нибудь сканером по http://www-test.sergos.ru/ ?

У тебя же там вего 4 точки входа с 12 входными группами. Тестировать особо и нечего-то, все ок В cppcms же, навскидку, при формировании сессионного токена используется странным образом реализованная криптография — вот там да, возможно есть где развернуться. Но я хз, когда получится выкроить достаточно времени, чтобы по-серьезному посмотртеь ее код

Здравствуйте, Erop, Вы писали:

G>>А кому нынче нужна эта шустрость? Ну срендерится твой html не за 10мс а за 5. и?
E>Ну поставишь вместо пяти серверов два и?

И? Ну например четверть разницы через директора и бухгалтерию в карман в виде премии
Или разницу добавить к деньгам на сервера БД

Здравствуйте, Sheridan, Вы писали:

S>И? Ну например четверть разницы через директора и бухгалтерию в карман в виде премии
S>Или разницу добавить к деньгам на сервера БД

Так я про то же, что пока одного любого сервака хватает -- это одна история, а как хватать перестаёт, так производительность сразу начинает стоить денег...

Другое дело, что столь высоконагруженные решения -- редкость, и на таких системах среды с JIT'ом не должны катастрофически сливать компилируемым языкам...

Здравствуйте, Erop, Вы писали:

G>>А кому нынче нужна эта шустрость? Ну срендерится твой html не за 10мс а за 5. и?
E>Ну поставишь вместо пяти серверов два и?

и заплачу за разработку стоимость еще 10. и?

Здравствуйте, genre, Вы писали:

G>>>А кому нынче нужна эта шустрость? Ну срендерится твой html не за 10мс а за 5. и?
E>>Ну поставишь вместо пяти серверов два и?
G>и заплачу за разработку стоимость еще 10. и?
Пятьдесят, ага.

Здравствуйте, Sheridan, Вы писали:

G>>и заплачу за разработку стоимость еще 10. и?
S>Пятьдесят, ага.

вполне возможно и пятьдесят.

тебе вообще не пристало бы шутить на эту тему, учитывая, сколько ты знаешь о разработке высоконагруженных систем. Одно дело сайт на 10 страничек на с++ написать и утверждать, что сэкономил на железе, другое серьезно говорить о экономии на железе в нагруженных платформах.