Здравствуйте, alex_public, Вы писали:
_>Обожаю эти фразы в стиле C#/Java. 
Я тоже, от того и использую :P
Вообще, async/await в C# появились после continuation expressions в F# и авторы первого не скрывали, что именно послужило прообразом asyc/await.
_>Единственное преимущество .net в данном случае — это единство синтаксиса. Т.е. запись при просто асинхронной работе или при пуле потоков и т.п. выглядит практически одинаково. А в C++ это вообще отдельные сущности. Т.е. хочется асинхронности — ставим одну библиотеку, хочется пул потоков — ставим другую, хочется одно поверх другого — сопрягаем их вместе. Естественно при этом даётся больше возможностей, чем в .net варианте, но и единого универсального синтаксиса естественно нет. Какой вариант лучше, думаю дело личных вкусов и стилей...
Я тут не пытаюсь доказывать преимущество .NET. Если хотелось поспорить с кем нибудь на эту тему, то я ничем не могу помочь, давно ничего под .NET не писал, а async/await никогда не использовал на практике.
_>На практике? ) Вышеописанное соответствует очень узкой категории задач, типа написания высоконагруженного сервера на множество клиентов. И для таких задач есть свой набор известных по этой области решений.
Обожаю фразу "высоконагруженные сервера"
Если по делу, то расскажите об этом разработчикам, использующим Cilk, пусть они перестанут использовать spawn для распараллеливания всяких там сортировок
Здравствуйте, Lazin, Вы писали:
EP>>Я уверен что можно и больше — но нужно играться с настройками, сейчас мне это не настолько интересно.
L>Можно и больше, но это чревато проблемами если из корутины вызывается thrid party код, который использует слишком много стека.
1. Сотни тысяч корутин нужны крайне редко.
2. Проблема сглаживается
поддержкой segmented stacks.
L>Я не утверждаю что оно не нужно, просто у корутин и async/await несколько разные потенциальные области применения. Посему поддержка async/await в стандарте это гуд, независимо от того, есть ли корутины в стандартной библиотеке или нет.
Есть stackful и stackless корутины, и там и там есть свои уникальные плюсы. Поверх корутин реализуется и await, и yield (в C# и то и то реализуется поверх stackless корутин) — не вижу смысла добавлять только await в ISO, когда можно добавить более общий механизм.
Здравствуйте, Lazin, Вы писали:
L>Я тоже, от того и использую :P
L>Вообще, async/await в C# появились после continuation expressions в F# и авторы первого не скрывали, что именно послужило прообразом asyc/await.
F# интересный, да... Там привносящиеся .net'ом минусы, хотя бы компенсируются добавляемыми фичами языка.
L>Я тут не пытаюсь доказывать преимущество .NET. Если хотелось поспорить с кем нибудь на эту тему, то я ничем не могу помочь, давно ничего под .NET не писал, а async/await никогда не использовал на практике.
Не не, я тут уже наспорился с дотнетчиками — больше нет никакого желания. Они в большинстве своём какие-то тупо непробиваемые. ))) Просто тут же было прямое сравнение между сопроцедурами из буста и await/async, вот я и высказался...
L>Обожаю фразу "высоконагруженные сервера"
L>Если по делу, то расскажите об этом разработчикам, использующим Cilk, пусть они перестанут использовать spawn для распараллеливания всяких там сортировок
Ха, так и я о том же. Что в большинстве задач требуется именно многопоточное программирование. Которое почти всегда удобнее и эффективнее. И кстати для него вообще не нужные никакие await/async или сопроцедуры. Единственная ситуация, когда оно не применимо, это как раз те самые высоконагруженные сервера, потому как в таком случае расход памяти и накладные расходы на переключение контекста становятся слишком высокими. В таком случае применяют какой-то вид асинхронного программирования (и кстати это всё ещё не await/async или сопроцедуры), которое весьма не удобно в программирование, но зато эффективно в данном случае. И вот только теперь у нас ещё дополнительно могут возникнуть сопроцедуры (или await/async) — они позволяют записать наш кривой асинхронный код в таком виде, как будто бы это обычное многопоточное программирование.
Конечно сопроцедуры или await/async могут принести немного пользы и в этом самом обычном многопоточном программирование... Но очень небольшую — исполняя всего лишь роль синтаксического сахара для записи "продолжений". Причём например лично мне это не особо нравится, т.к. на мой взгляд только запутывает код. Мне больше нравится реализовывать многопоточность явной записью и реализуя что-то типа модели акторов.
А так вообще с классической многопоточностью в C++ мне кажется всё нормально уже сейчас. Есть ручные потоки (удобный класс thread и много мелочей вокруг этого), есть пулы потоков (boost:threadpool какой-нибудь), есть автоматическое распараллеливание для алгоритмов (openmp). Это не говоря уже о нескольких монструозных библиотеках (типа tbb), в которых есть сразу всё и ещё куча всего. ))) Единственно, чего на мой взгляд не хватает для многопоточности в C++, это как раз стандартной готовой реализации модели акторов. Есть конечно какие-то там libcppa, theron и т.п., но это всё не то. Кстати, а вот в D подобное реализовано на полную в стандартной библиотеке, причём, благодаря возможностям языка, на базе удобного "сопоставления с образцом".
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Lazin, Вы писали:
L>>Потом я прочитал у Русиновича о том, что каждой странице вирт. памяти в винде должна быть сопоставлена либо страница физической памяти, либо страница в page-файле.
EP>Там скорей всего говорилось про committed memory.
Действительно, речь там кажется шла о commited memory
Тогда да, проблема запуска 100500 корутин должна легко решаться всякими хитрыми алокаторами.
