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

_>Я же вроде там чётко написал что "не в исходнике". Так что речь грубо говоря о количестве процессорных инструкций затраченных на достижение одной и той же цели.

Это ни о чем. Нужна конкретная задача. Скажем тормозного джаваскрипта хватает для задач UI. Все твои эффективности в С++ дают нулевой выхлоп, если говорить про эту задачу. Или так — ядро проца выполняет около 5 млрд инструкций, а nginx почему то работает всего с 1024 коннектам на один поток.
Скажем в реалтайм процессинге проблемы уже давно не в скорости линейного кода, ибо полно реалтаймных приложений для всяких фондовых бирж которые работают джаве.
Вопрос так и остался открытым — где же будет та самая эффективность про которую ты говоришь.

I>>Для каких операций он не самый удобный ? для relational-like он практически самое лучше из того, что есть. ДЛя noSql он естесвенно не будет таким удобным, скажем для graph database нужна поддержка математики навроде bfs, dfs и тд.
I>>Ты ошибочно понимаешь linq как мега универсальный подход. Он нужен для relational-like операций, данных и тд.

_>Нуу про нетабличные данные то я вообще молчу. ))) Но и для табличных "самое лучше что есть" звучит очень забавно, особенно с учётом того, что SQL создавался не для программистов.

Ну стало быть ты знаешь хороший способ, который гораздо лучше с этим справляется и при этом доступен как минимум всей аудитории C# девелоперов.
Теоретичеки можно заставить людей знать на раз теорию категорий и на этой основе строить апи для обработки данных. Реально это утопия, ибо теорию категорий знают единицы и следовательно такой способ недоступен всей аудитории.

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

I>Обработка IO completion уже займет порядка на три-четыре больше затрат.

Тебя обманули. Унутре там lock-free структуры, поэтому постановка задач в очередь в ядре почти бесплатная, а выгребать можно через GetQueuedCompletionStatusEx все накопившиеся задачи за раз и диспетчить их тоже забесплатно фактически. ТАм основная нагрузка собсно вызов ядерных ф-ий, поэтому уменьшение этих вызовов в пересчете на операцию дает буст.

I>Для сравнения, один поток в nginx обрабатывает всего 1024 соединения.

Сравнения с чем?

I>Обслуживание на async-await займет в худшем случае 1000-2000 тактов процессора. Это вообще ни о чем.

Это зависит от частоты событий. Раз в секунду — ни о чем... Под сотню тыщ раз в секунду — уже что-то.

I>Потому даже если С++ версия будет отрабатывать за 1 такт, то экономии нет и быть не может.

Смешно.


I>>>Кривая архитектура, это когда переходы непойми где делаются. А когда код легко майнтейнить, это хорошая архитектура. async упрощает майнтенанс.
V>>Ну ты же как-то поддерживаешь обычный код? Тебя же не смущает, что переключение потоков в многопоточной ОС происходит "где-то" за пределами твоей программы? Тут аналогично.
I>Да вот как то смущает ибо надо использовать всевозможные схемы синхронизации. А теперь ты хочешь получить на ровном месте еще одну такую же по сложности проблему.

Проще намного. Если несколько твоих фиберов лезут в одну и ту же переменную из одного и того же аппаратного потока, то никакая синхронизация не нужна. Ведь у нас на самом деле не неуправляемое переключение "потоков", а детерминированное. Получить такие же гарантии на async/await нереально. )) В общем случае нет гарантии, из какого потока что вызывается.

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

V>>Без проблем использовать await без всякой надуманной асинхронщины по прямому назначению — для того, чтобы наплодить легковесных безстековых короутин для той самой кооперативной многозадачности.
I>Можно и это неосновное назначение.

У трюка не может быть другого назначения, кроме его принципа действия. ))
Характерно, что в дотнете, из-за привязки к "назначению", один и тот же трюк сделали дважды: yield для коллекций и await для короутин. И то и то идентичные короутины на генерируемом автомате с той разницей, что в последнем случае await равен yield, возвращающему void.

Ну и с вложением енумераторов у исходного yield не ахти, зато await это умеет изкаробки. Вот и вся разница. Тупо, не правда ли? Как я вижу на этом форуме, вводит хомячков в дикое заблуждение.


V>>Ну и названия ключевых слов вводят тебя в заблуждение настолько, что такое заблуждение преодолеть фактически нереально. )))
I>Я собтсвенно говорил про разницу между двумя вещами.

Если ты действительно это говорил, то ты споришь сам с собой уже. Короутины из буста и async/await — это похожие инструменты, даже работают практически одинаково за тем исключением, что в async/await потоки исполнения не настоящие, а эмулируемые через конечные автоматы.


V>>Ну так ты хвалишь заведомо более слабый инструмент, обвиняя более сильный в том, что это "просто кооперативная многозадачность". На C# async/await можно сэмулировать почти такую же. Только хуже. )))
I>Кооперативная многозадачность в чистом виде нужна чуть менее чем никогда.

Разве? )))
Как раз диспетчеризация событий в одном потоке на некоем completion port — это кооперативная многозадачность в незамутненном чистом виде. Про GUI loop даже и упоминать нелепо, ты сам его раз 100 упомянул уже.

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

V>Тебя обманули. Унутре там lock-free структуры, поэтому постановка задач в очередь в ядре почти бесплатная, а выгребать можно через GetQueuedCompletionStatusEx все накопившиеся задачи за раз и диспетчить их тоже забесплатно фактически. ТАм основная нагрузка собсно вызов ядерных ф-ий, поэтому уменьшение этих вызовов в пересчете на операцию дает буст.

И все это бесплатное почемуто может выдать только 1024 коннекта, ага.

I>>Для сравнения, один поток в nginx обрабатывает всего 1024 соединения.
V>Сравнения с чем?

С издержками на async/await.

I>>Обслуживание на async-await займет в худшем случае 1000-2000 тактов процессора. Это вообще ни о чем.
V>Это зависит от частоты событий. Раз в секунду — ни о чем... Под сотню тыщ раз в секунду — уже что-то.

Даже так это <5% от того, что может одно ядро.

I>>Потому даже если С++ версия будет отрабатывать за 1 такт, то экономии нет и быть не может.
V>Смешно.

V>Проще намного. Если несколько твоих фиберов лезут в одну и ту же переменную из одного и того же аппаратного потока, то никакая синхронизация не нужна. Ведь у нас на самом деле не неуправляемое переключение "потоков", а детерминированное.

Гонки, голодание никуда не деваются. Все как было, так и осталось. Не ясно, как ты дашь какие то гарантии.

>Получить такие же гарантии на async/await нереально. )) В общем случае нет гарантии, из какого потока что вызывается.

Как и в С++

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

V>>>Без проблем использовать await без всякой надуманной асинхронщины по прямому назначению — для того, чтобы наплодить легковесных безстековых короутин для той самой кооперативной многозадачности.
I>>Можно и это неосновное назначение.

V>У трюка не может быть другого назначения, кроме его принципа действия. ))

Ты путаешь короутину с конкретным вариантом её использования. Скажем унутре это гораздо больше похоже на continuation.

V>Характерно, что в дотнете, из-за привязки к "назначению", один и тот же трюк сделали дважды: yield для коллекций и await для короутин. И то и то идентичные короутины на генерируемом автомате с той разницей, что в последнем случае await равен yield, возвращающему void.

yield и есть короутины, это никакие не коллекции. await — это уже решение для асинхронщины.

V>Если ты действительно это говорил, то ты споришь сам с собой уже. Короутины из буста и async/await — это похожие инструменты, даже работают практически одинаково за тем исключением, что в async/await потоки исполнения не настоящие, а эмулируемые через конечные автоматы.

Спасибо, капитан, скажи наконец уже хоть что нибудь, чего я до твоего пришествия не повторил хотя бы дважды.

I>>Кооперативная многозадачность в чистом виде нужна чуть менее чем никогда.

V>Разве? )))
V>Как раз диспетчеризация событий в одном потоке на некоем completion port — это кооперативная многозадачность в незамутненном чистом виде. Про GUI loop даже и упоминать нелепо, ты сам его раз 100 упомянул уже.

И практически все нативные реализации которые используют completion port не используют короутины.

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

V>>Входит, ес-но, но поддержка её ср-вами языка — нет.
I>И в С++, что характерно, точно так же — скажем те же короутины буста сделаны самым честным хаком.

Язык позволяет. ))


V>>Да никак. Обычно вызывай и все. Это именно настоящее "выпрямление" кода. Легковесная многозадачность, где ВНУТРИ метода стоят хинты, когда переключать задачу, как в виндах 3.x.
I>Ну ка, подробнее, что же за фокус такой, ты ни много ни мало утверждаешь, функция вдруг сама узнает, ожидаю ли я её результат и в зависимости от этого решит как делать процессинг ?

Какая ф-ий что узнает? Там просто в теле ф-ии есть хинты, когда забирать у фибера ресурсы и отдавать следующему. Или у тебя вопрос про шедуллинг, т.е. вопрос про управление очередью фиберов? Шедуллинг делается на уровне задач, требующих ожидания, т.е. на уровне поддержки задач ввода-вывода. Остальное пляшет оттуда. Собсно, кооперативная многозадачность на операция ввода-вывода в Win 3.x тому пример.


V>>С т.з. вызывающего метода это обычный синхронный код, а вся асинхронность сугубо внешняя, как внешим является переключение потоков ОС по отношению к обычному коду на C#.
I>То есть, все функции будут синхронными с т.з. вызывающего кода, что внезапно останавливает message pump.

Оп-па...
Твой message pump вызывает не ф-ии, а короутины, т.е. передает управление потокам. Это не есть вызов ф-ии.

V>>Да. Программы для виндов 3.х прекрасно работали на win95, но уже с нормальной многозадачностью.
I>Не понял идею. Речь про изменения в языке и использование этих изменений во фремворках. Или винда вдруг стала каким то языком ?

Да нет. Просто те же самые проги, которые раньше работали на основе кооперативной ОС, прекрасно работают в многозадачной. Сейчас ты работаешь в многозадачной, и у тебя проблем с поддержкой обычного кода нет. Вот и в "многозадачной ОС" проблем не было, если не делать 10 GOTO 10.


I>см "функция вдруг сама узнает, ожидаю ли я её результат"

Смотрел. Улыбнуло. Ф-ия должна делать некий yield next (твой await), если текущее состояние внешнего мира вынуждает её крутиться в 10 GOTO 10. А подробности этого "кручения" зависят от низлежащей ОС, от предоставляемых ср-в сигнализации готовности ввода/вывода.

Т.е., конечно должен быть набор библиотек IO, на основекоторых написан твой код. Все эти подробности с yield next должны быть упрятаны в эти либы, а твой прикладной код будет уже как простой линейный код.


V>>Дык, async еще более не нужен хотя бы потому, что на порядки менее удобный.
I>"функция вдруг сама узнает, ожидаю ли я её результат"

Я уже понял, что ты ничего не понял.)

V>>Но с ней в С++ всегда было лучше, чем в других ООП языках, именно из-за многообразия функциональных типов и именно из-за того, что вся асинхронщина, которая "в лоб" (без asyc), идет как IoC, в котором функциональный подход заруливает ООП. А с короутинами еще проще...

I>Надо понимать async/await появились как ответ на одскульную асинхронщину.

Ес-но. Так же как подобные либы на плюсах задолго до. (а их полно)
Просто язык позволяет делать многое в рамках всё того же самого языка.

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

I>>>Для сравнения, один поток в nginx обрабатывает всего 1024 соединения.
V>>Сравнения с чем?
I>С издержками на async/await.

Нашел с чем сравнить.


I>>>Обслуживание на async-await займет в худшем случае 1000-2000 тактов процессора. Это вообще ни о чем.
V>>Это зависит от частоты событий. Раз в секунду — ни о чем... Под сотню тыщ раз в секунду — уже что-то.

I>Даже так это <5% от того, что может одно ядро.

Да не все так просто. Дело не только в кол-ве тактов, но и в проходах по памяти. В async/await мы имеем графы наверченных друг на друга автоматов в куче и проход по этому графу при каждом шаге. Лишние косвенности каждый раз, а косвенность по внешней памяти обычно стоит намного больше тактов.


V>>Проще намного. Если несколько твоих фиберов лезут в одну и ту же переменную из одного и того же аппаратного потока, то никакая синхронизация не нужна. Ведь у нас на самом деле не неуправляемое переключение "потоков", а детерминированное.
I>Гонки, голодание никуда не деваются. Все как было, так и осталось. Не ясно, как ты дашь какие то гарантии.

При отсутствии конкуренции за ресурсы нет ни гонок, ни голоданий.


>>Получить такие же гарантии на async/await нереально. )) В общем случае нет гарантии, из какого потока что вызывается.
I>Как и в С++

Дудки. В С++ ты управляешь ситуацией — располагай легкие потоки в аппаратных как угодно. Т.е. ты имеешь возможность решать прикладные задачи через свою диспетчеризацию.

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

I>Это ни о чем. Нужна конкретная задача. Скажем тормозного джаваскрипта хватает для задач UI. Все твои эффективности в С++ дают нулевой выхлоп, если говорить про эту задачу. Или так — ядро проца выполняет около 5 млрд инструкций, а nginx почему то работает всего с 1024 коннектам на один поток.
I>Скажем в реалтайм процессинге проблемы уже давно не в скорости линейного кода, ибо полно реалтаймных приложений для всяких фондовых бирж которые работают джаве.
I>Вопрос так и остался открытым — где же будет та самая эффективность про которую ты говоришь.

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

Но если мы получаем отсутствие накладных расходов на халяву (просто работая в обычном стиле) то это в любом случае и есть настоящая эффективность. )))

I>Ну стало быть ты знаешь хороший способ, который гораздо лучше с этим справляется и при этом доступен как минимум всей аудитории C# девелоперов.
I>Теоретичеки можно заставить людей знать на раз теорию категорий и на этой основе строить апи для обработки данных. Реально это утопия, ибо теорию категорий знают единицы и следовательно такой способ недоступен всей аудитории.

Ээээ ну с таким подходом то я не буду спорить... Тут всё правильно. Но изначально у нас же был тезис об абсолютной "крутизне" linq, без привязки к C#, анализа уровня разработчиков и т.п.

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

_>Так я же тебе уже говорил, что если бы эта эффективность чего-то нам стоила (например каких-то дополнительных усилий при написание кода), то тогда имело бы смысл рассматривать конкретные задачи и в каждом частном случае считать есть ли смысл для подобной оптимизации или нет.

Халява в данном случае это ручная диспетчеризация и ручной контроль. Когда это нужно для оптимизации — это нормально. А как правило проблемы создает 10-20% кода, за это надо платить тем, что остальные 80-90% кода будет контролировать руками, даже если тебе это не хочется.

_>Но если мы получаем отсутствие накладных расходов на халяву (просто работая в обычном стиле) то это в любом случае и есть настоящая эффективность. )))

Это не эффективность а баловство. Любые оптимизации вне узкого места как минимум лишние, как максимум — создают проблемы на ровном месте.

_>Ээээ ну с таким подходом то я не буду спорить... Тут всё правильно.

!!!

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

V>>>Сравнения с чем?
I>>С издержками на async/await.

V>Нашел с чем сравнить.

А что, сравнивать с синтетикой, навроде getline ?

I>>Даже так это <5% от того, что может одно ядро.

V>Да не все так просто. Дело не только в кол-ве тактов, но и в проходах по памяти. В async/await мы имеем графы наверченных друг на друга автоматов в куче и проход по этому графу при каждом шаге. Лишние косвенности каждый раз, а косвенность по внешней памяти обычно стоит намного больше тактов.

Это все теория. А на практике один лишь переход в ядро и обратно даст столько такто, что покроет минимум десять таких проходв.

I>>Гонки, голодание никуда не деваются. Все как было, так и осталось. Не ясно, как ты дашь какие то гарантии.

V>При отсутствии конкуренции за ресурсы нет ни гонок, ни голоданий.

Спасибо, капитан ! Похоже это новая концепция в многозадачном программировании.
А вот мне кажется, что проблемы уже могут быть в случае с тремя короутинами, каждая из которых готовит данные для другой.

I>>Как и в С++

V>Дудки. В С++ ты управляешь ситуацией — располагай легкие потоки в аппаратных как угодно. Т.е. ты имеешь возможность решать прикладные задачи через свою диспетчеризацию.

И это гарантирует что проблем с многозадачностью не будет ? Это слишком сильно сказано, что бы принимать без доказательства. Вот простой пример — три короутины, каждая готовит данные для одной из двух других, эдакое колечко. Нарушаешь порядок — получаешь проблемы. Но похоже твоя концепция как то гарантирует невозможность такой ситуации.

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

I>>Ну ка, подробнее, что же за фокус такой, ты ни много ни мало утверждаешь, функция вдруг сама узнает, ожидаю ли я её результат и в зависимости от этого решит как делать процессинг ?

V>Какая ф-ий что узнает? Там просто в теле ф-ии есть хинты, когда забирать у фибера ресурсы и отдавать следующему. Или у тебя вопрос про шедуллинг, т.е. вопрос про управление очередью фиберов? Шедуллинг делается на уровне задач, требующих ожидания, т.е. на уровне поддержки задач ввода-вывода. Остальное пляшет оттуда. Собсно, кооперативная многозадачность на операция ввода-вывода в Win 3.x тому пример.

И что же это за хинты унутре такие, которые подскажут функции, как она вызвана ? Не иначе сканирование назад по стеку и анализ на предмет вызова функции ожидания.

С async все ясно — можно вызывать с ожиданием, можно без ожидания. А как быть с твоими мега-функциями ?

V>>>С т.з. вызывающего метода это обычный синхронный код, а вся асинхронность сугубо внешняя, как внешим является переключение потоков ОС по отношению к обычному коду на C#.
I>>То есть, все функции будут синхронными с т.з. вызывающего кода, что внезапно останавливает message pump.

V>Оп-па...
V>Твой message pump вызывает не ф-ии, а короутины, т.е. передает управление потокам. Это не есть вызов ф-ии.

V>>>Да. Программы для виндов 3.х прекрасно работали на win95, но уже с нормальной многозадачностью.
I>>Не понял идею. Речь про изменения в языке и использование этих изменений во фремворках. Или винда вдруг стала каким то языком ?

V>Да нет. Просто те же самые проги, которые раньше работали на основе кооперативной ОС, прекрасно работают в многозадачной. Сейчас ты работаешь в многозадачной, и у тебя проблем с поддержкой обычного кода нет. Вот и в "многозадачной ОС" проблем не было, если не делать 10 GOTO 10.


I>>см "функция вдруг сама узнает, ожидаю ли я её результат"

V>Смотрел. Улыбнуло. Ф-ия должна делать некий yield next (твой await), если текущее состояние внешнего мира вынуждает её крутиться в 10 GOTO 10. А подробности этого "кручения" зависят от низлежащей ОС, от предоставляемых ср-в сигнализации готовности ввода/вывода.

V>Т.е., конечно должен быть набор библиотек IO, на основекоторых написан твой код. Все эти подробности с yield next должны быть упрятаны в эти либы, а твой прикладной код будет уже как простой линейный код.


V>>>Дык, async еще более не нужен хотя бы потому, что на порядки менее удобный.
I>>"функция вдруг сама узнает, ожидаю ли я её результат"

V>Я уже понял, что ты ничего не понял.)

V>>>Но с ней в С++ всегда было лучше, чем в других ООП языках, именно из-за многообразия функциональных типов и именно из-за того, что вся асинхронщина, которая "в лоб" (без asyc), идет как IoC, в котором функциональный подход заруливает ООП. А с короутинами еще проще...

I>>Надо понимать async/await появились как ответ на одскульную асинхронщину.

V>Ес-но. Так же как подобные либы на плюсах задолго до. (а их полно)
V>Просто язык позволяет делать многое в рамках всё того же самого языка.

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

V>>Нашел с чем сравнить.
I>А что, сравнивать с синтетикой, навроде getline ?

Вообще-то, да, с синтетикой. Если сравниваются голые затраты механизма диспетчеризации событий.


V>>Да не все так просто. Дело не только в кол-ве тактов, но и в проходах по памяти. В async/await мы имеем графы наверченных друг на друга автоматов в куче и проход по этому графу при каждом шаге. Лишние косвенности каждый раз, а косвенность по внешней памяти обычно стоит намного больше тактов.
I>Это все теория. А на практике один лишь переход в ядро и обратно даст столько такто, что покроет минимум десять таких проходв.

Не каждый ядерный вызов тяжел. Стоимость голой SYSENTER не так уж высока.


V>>При отсутствии конкуренции за ресурсы нет ни гонок, ни голоданий.
I>Спасибо, капитан ! Похоже это новая концепция в многозадачном программировании.

Ну гонок при описанном сценарии избегаем в любом случае. А голодание лечится завязкой шедуллинга на состояние прикладных данных.

I>А вот мне кажется, что проблемы уже могут быть в случае с тремя короутинами, каждая из которых готовит данные для другой.

Простейшая автовыравнивание нагрузки — взаимная очередь фиксированного сверху размера, блокируемая для кода короутины, если очередь полна при записи или пуста при чтении. Но есть и еще более динамичные варианты, например, на основе некоей информации по обратной связи. Можно сэмулировать простейший фильтр 1-го порядка по обратной связи по информации о текущей длине очереди, по его показаниям фибер-производитель может назначать себе "штрафы".


I>И это гарантирует что проблем с многозадачностью не будет ? Это слишком сильно сказано, что бы принимать без доказательства. Вот простой пример — три короутины, каждая готовит данные для одной из двух других, эдакое колечко. Нарушаешь порядок — получаешь проблемы. Но похоже твоя концепция как то гарантирует невозможность такой ситуации.

У каждой короутины доложен быть некий сигнал готовности, чтобы она не получала управление для "холостого" оборота. В чем будет заключаться этот сигнал — сугубо прикладная хрень.

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


I>>>Ну ка, подробнее, что же за фокус такой, ты ни много ни мало утверждаешь, функция вдруг сама узнает, ожидаю ли я её результат и в зависимости от этого решит как делать процессинг ?

V>>Какая ф-ий что узнает? Там просто в теле ф-ии есть хинты, когда забирать у фибера ресурсы и отдавать следующему. Или у тебя вопрос про шедуллинг, т.е. вопрос про управление очередью фиберов? Шедуллинг делается на уровне задач, требующих ожидания, т.е. на уровне поддержки задач ввода-вывода. Остальное пляшет оттуда. Собсно, кооперативная многозадачность на операция ввода-вывода в Win 3.x тому пример.

I>И что же это за хинты унутре такие, которые подскажут функции, как она вызвана ? Не иначе сканирование назад по стеку и анализ на предмет вызова функции ожидания.

Ты опять путаешь вызов ф-ии внутри короутины и передачу управления самой короутине.


I>С async все ясно — можно вызывать с ожиданием, можно без ожидания. А как быть с твоими мега-функциями ?

Должен быть сформирован сам фибер изначально, который будет запущен на исполнение. Код внутри него всегда с ожиданием, т.е. синхронный.

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

I>>И что же это за хинты унутре такие, которые подскажут функции, как она вызвана ? Не иначе сканирование назад по стеку и анализ на предмет вызова функции ожидания.

V>Ты опять путаешь вызов ф-ии внутри короутины и передачу управления самой короутине.

Не я, а ты. Ожидание возникает не от того, какие у тебя функции, а от того, когда нужно делать вызов и когда ожидать данных. Как ты чего вызываешь не имеет никакого значения. Если задача требует блокировки — надо делать ожидание. Если задача требует неблокирующий вызов — надо делать именно такой.

Покажи аналог для каждой из строчек

await X();

X();

>>С async все ясно — можно вызывать с ожиданием, можно без ожидания. А как быть с твоими мега-функциями ?

V>Должен быть сформирован сам фибер изначально, который будет запущен на исполнение. Код внутри него всегда с ожиданием, т.е. синхронный.

Код покажи.

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

I>Халява в данном случае это ручная диспетчеризация и ручной контроль. Когда это нужно для оптимизации — это нормально. А как правило проблемы создает 10-20% кода, за это надо платить тем, что остальные 80-90% кода будет контролировать руками, даже если тебе это не хочется.

Какая ещё ручная диспетчеризация и ручной контроль? ) Мы же вроде бы уже давно договорились что C++ вариант внешне отличается от C# варианта только тем что там макросы (которые пишутся один раз вообще).

I>Это не эффективность а баловство. Любые оптимизации вне узкого места как минимум лишние, как максимум — создают проблемы на ровном месте.

Т.е. если завтра компилятор C# каким-то чудом ускорят раза в два, то ты скажешь "извините, но я возможно не буду этим пользоваться, т.к. я ещё не замерил есть ли у меня узкие места в моём ПО или нет"? )))

I>!!!

Ну так никто и не спорил что linq — это прорыв внутри C#. Это факт естественно. Просто некоторые странные личности иногда начинают говорить что это прорыв не внутри C#, а вообще в программирование (типа как концепция) — вот это конечно вызывает только смех. )))

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

V>>>Нашел с чем сравнить.
I>>А что, сравнивать с синтетикой, навроде getline ?

V>Вообще-то, да, с синтетикой. Если сравниваются голые затраты механизма диспетчеризации событий.

Это никому не интересно. Скажем, это не дает объяснения, почему веб-приложения массово пишутся на менеджед платформах, хотя казалось бы, они вечно испытывают нехватку ресусорв, памяти, процессора и тд и тд.
Если смотреть синтетику, то веб-приложения должны писаться на С++. А вот десктоп приложения, где вагон ресурсов, почему то до сих пор частенько пишутся на С++, хотя я бы не сказал что в большинстве случаев. Казалось бы — должно быть наоборот. Ан нет.
А если глянуть на реальные задачи, стновится понятно, где чего экономится. Скажем ручное управление памятью в веб-приложении задача адски сложная и неудивительно, что GC справляется гораздо лучше -> managed. Цена низкоуровневой оптимизации в таких задачах слишком высока, потому весь функционал предельно упрощен. А в десктопе все проще — ресурсов в пересчете на задачу больше + есть вещи, которые требуют перформанс. Вот здесь ручные оптимизации вводить достаточно легко и цена таких изменений сравнительно мала, отсюда ясно, что для десктопа все еще актуально писать на С++.
Реалтайм приложения, что характерно, требуют в первую очередь корретной работы с ресурсами, низкоуровневый перформанс дело второстепенное. Отсюда понятно, почему приложения для биржи и тд, пишутся в т.ч. на Джаве той же.
Есть другие случаи, скажем серверные приложения которые требуют достаточно высокий перформанс в задачах, которые упираются в низкоуровневый перформанс, такие невозможно решить в менеджед — обработка звука, видео, изображений. Менеджед применяется очень осторожно и всегда вместе с нативными библиотеками. Скажем, никто в своем уме не будет заниматься обработкой видео на C# или Джаве. И даже в этом случае цветут и пахнут гибридные приложения.

I>>Это все теория. А на практике один лишь переход в ядро и обратно даст столько такто, что покроет минимум десять таких проходв.

V>Не каждый ядерный вызов тяжел. Стоимость голой SYSENTER не так уж высока.

Давай ближе к конкретному примеру.

I>>Спасибо, капитан ! Похоже это новая концепция в многозадачном программировании.

V>Ну гонок при описанном сценарии избегаем в любом случае. А голодание лечится завязкой шедуллинга на состояние прикладных данных.

"Вот простой пример — три короутины, каждая готовит данные для одной из двух других, эдакое колечко. Нарушаешь порядок — получаешь проблемы."

I>>А вот мне кажется, что проблемы уже могут быть в случае с тремя короутинами, каждая из которых готовит данные для другой.

V>Простейшая автовыравнивание нагрузки — взаимная очередь фиксированного сверху размера, блокируемая для кода короутины, если очередь полна при записи или пуста при чтении. Но есть и еще более динамичные варианты, например, на основе некоей информации по обратной связи. Можно сэмулировать простейший фильтр 1-го порядка по обратной связи по информации о текущей длине очереди, по его показаниям фибер-производитель может назначать себе "штрафы".

Вот так время процессора начинает расходоваться непойми на что.

I>>И это гарантирует что проблем с многозадачностью не будет ? Это слишком сильно сказано, что бы принимать без доказательства. Вот простой пример — три короутины, каждая готовит данные для одной из двух других, эдакое колечко. Нарушаешь порядок — получаешь проблемы. Но похоже твоя концепция как то гарантирует невозможность такой ситуации.

V>У каждой короутины доложен быть некий сигнал готовности, чтобы она не получала управление для "холостого" оборота. В чем будет заключаться этот сигнал — сугубо прикладная хрень.

То есть, гарантий никаких, что и требовалось доказать, все конфликты надо разруливать руками, руками и еще раз руками.

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

I>>Халява в данном случае это ручная диспетчеризация и ручной контроль. Когда это нужно для оптимизации — это нормально. А как правило проблемы создает 10-20% кода, за это надо платить тем, что остальные 80-90% кода будет контролировать руками, даже если тебе это не хочется.

_>Какая ещё ручная диспетчеризация и ручной контроль? ) Мы же вроде бы уже давно договорились что C++ вариант внешне отличается от C# варианта только тем что там макросы (которые пишутся один раз вообще).

Это теоретически. Для случаев посложнее надо пилить или макросы посложнее или расширять фремворк или колбасить все вручную.

I>>Это не эффективность а баловство. Любые оптимизации вне узкого места как минимум лишние, как максимум — создают проблемы на ровном месте.

_>Т.е. если завтра компилятор C# каким-то чудом ускорят раза в два, то ты скажешь "извините, но я возможно не буду этим пользоваться, т.к. я ещё не замерил есть ли у меня узкие места в моём ПО или нет"? )))

Скорость компиляции является узким местом в средствах разработки. Полноценная навигация, интеллисенс, юнит тесты и прочие вкусности IDE невозможны без быстрого компилятора. Никто не будет пускать юнит-тесты, если проект надо компилировать по сорок минут.

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

I>Это никому не интересно. Скажем, это не дает объяснения, почему веб-приложения массово пишутся на менеджед платформах, хотя казалось бы, они вечно испытывают нехватку ресусорв, памяти, процессора и тд и тд.

Уже же обсуждали это. Подавляющее чисто всех серверов и баз данных написаны на C/C++ и именно там происходят все критические нагрузки. А то, что ты называешь гордым именем "веб-приложения" — это всего лишь тончайшая скриптовая прослойка между вызовами функций веб-сервера и базы данных. И не удивительно что там лидируют всякие php — у него запредельная скорость написания и модификации кода (говнокода обычно ). Причём для последнего даже не нужны никакие перекомпиляции т.п.

Вот если бы у нас сами сервера и базы данных были написаны на управляемых платформах, то твои слова уже имели бы реальное обоснование....

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

I>Это теоретически. Для случаев посложнее надо пилить или макросы посложнее или расширять фремворк или колбасить все вручную.

Для каких ещё случаев посложнее? Представленное решение полностью повторяет всё поведение C# реализации. Всё, точка. Никакие модификации этих 20 строчек не требуются — оно работает в любых условиях, в которых работает C# вариант.

_>>Т.е. если завтра компилятор C# каким-то чудом ускорят раза в два, то ты скажешь "извините, но я возможно не буду этим пользоваться, т.к. я ещё не замерил есть ли у меня узкие места в моём ПО или нет"? )))
I>Скорость компиляции является узким местом в средствах разработки. Полноценная навигация, интеллисенс, юнит тесты и прочие вкусности IDE невозможны без быстрого компилятора. Никто не будет пускать юнит-тесты, если проект надо компилировать по сорок минут.

Имелось ввиду ускорение генерируемого кода, а не скорости компиляции. Я конечно мутно сказал там... )

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

V>>>>Но когда они вникают в подробности конкретного участка, поверь, их точно так же интересуют точные типы.
AVK>>>Отучайся говорить за всех. Лично я первое, что делаю при ковырянии чужого кода — Full Cleanup, который, в числе прочего, заменяет все типы в декларациях на var.
V>>Мало ли, что лично ты делаешь?

AVK>Тогда поясни — либо "их" это все таки несколько более узкий круг, чем заявлено, либо я не принадлежу к "более опытным разработчикам".

Угу, характерно, что упоминание конкретного примера, где точный тип обязателен, ты проигнорил...