Здравствуйте, Sinix, Вы писали:
S>Да ну? Это именно что 99% асинхронных задач в wp/winrt — запулили в фоновый поток, чтобы не морозить UI из-за зависшей сети, оно отработало сразу, продолжаем в UI-потоке.
Ну так пришедшие по сети данных в большинстве случаев ещё и обработать надо. Логично это сделать в том же потоке и тогда всё получается вполне эффективно. )
S>Не в большей степени, чем индусоориентированность компиляторов, не дающих запихнуть string в int. По этому критерию самый тру-програмерский язык у нас, выходит, яваскрипт
Использование или неиспользование лёгких потоков — это вопрос скорее не языка, а подключаемых библиотек.
Re[41]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, alex_public, Вы писали:
_>Ну так пришедшие по сети данных в большинстве случаев ещё и обработать надо. Логично это сделать в том же потоке и тогда всё получается вполне эффективно. )
Угу. Только обработка на современных компах — тоже копейки. Возвращаемся к тому, с чего начали: время исполнения потока становится сравнимым со временем его создания.
_>Использование или неиспользование лёгких потоков — это вопрос скорее не языка, а подключаемых библиотек.
В обоих случаях согласен, но, как показала практика, без поддержки асинхронности языком и без обязательных к использованию библиотек в массе никто асинхронностью не занимается. Просто потому, что правильно написать async-код (с передачей контекста, TLS, исключений и тп) — тот ещё гемморой. А самописные недоделки, особенно если их скрестить с чужим кодом, без всего вышеперечисленного бывает так выстреливают в ногу в продакшне, что лучше бы их и не было
Re[22]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Sinix, Вы писали:
N>>Если принять за основу, что нить в Windows очень дорога в держании и переключении, то неудивительно стремление MS к IOCP — выигрыш идёт действительно в разы. В Linux разница значительно меньше. S>Дело не столько в "дорога в держании и переключении", сколько в накладных расходах на kernel switch и загруженный впустую планировщик. Сравни сам:
[...] S>Вариант с потоками под x86 затыкается с OutOfMemory уже на ~3000 потоков (несмотря на стек в 100 кб), под x64 — стабилизируется где-то на 30k потоков. S>Вариант с тасками спокойно пережёвывает 800k одновременно работающих тасков.
Цена переключения нитей меня удивляет. Как оно организовано в Windows?
Насколько я знаю разные Unix, там это очень дёшево — задача та же, проход через TSS не делается, вся цена — перезагрузка регистров (которую процессор может растянуть) и 1-2 конкретных страниц TLS.
Стиль работы планировщика в этом случае не знаю, но в Linux они переключаемые и постоянно обновляются на отработку маргинальных случаев
S>Если перейти на пул потоков с IOCP при должном везении получается нечто среднее.
N>>И в результате 99% индусов будут писать в духе S>
N>Цена переключения нитей меня удивляет. Как оно организовано в Windows?
Совсем точно я сейчас не напишу — надо открывать WinInternals Руссиновича и перечитывать пару глав, за практической ненадобностью позабыл давно. Принципиально всё везде более-менее одинаково, дьявол в деталях. Детали — всё в том же Руссиновиче, или (тезисно) вот в этой презенташке, с 19 страницы (pdf).
Если ничего не путаю, само переключение контекста по времени сопоставимо что в win, что в lin. В pdf-нике про singularity была вот такая табличка:
На конкретные цифры без уточнения версий win/lin/freebsd ориентироваться смысла нет, но нам важен порядок значений. Переключение контекста на объяснение "почему тормозим" не катит.
Из более-менее объективных причин у нас остаётся стоимость работы шедулера. В десктопной win шедулер заточен под примерно 300..1000 переключений в секунду:
A context switching rate of 300 per second per processor is a moderate amount; a rate of 1000 per second or more is high. Values at this high level may be a problem
Всё, что больше — на ваш страх и риск, как говорится
Если не лень — проверьте под lin, на скольки потоках загнётся?
S>>С вероятностью выше >>0.5 не пройдёт тест в маркете. Даже не ручное тестирование, а WACK tool. N>Как именно она проверяет такое?
Ну... Евгений Акиньшин выше написал, что на практике оно никак не отслеживается, т.е. тут я точно не прав.
А чтобы обломать — будет достаточно предупреждения при вызове блокирующих методов из ui-потока. Найти их — дело несложное, или правилом в FxCop, или инструментированием и запуском приложения. Т.е. технических причин почему оно так не делается точно нет.
Re[41]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, alex_public, Вы писали:
S>>Не в большей степени, чем индусоориентированность компиляторов, не дающих запихнуть string в int. По этому критерию самый тру-програмерский язык у нас, выходит, яваскрипт
_>Использование или неиспользование лёгких потоков — это вопрос скорее не языка, а подключаемых библиотек.
Теоретически. Нужно сравнивать немного иначе — не код vs код, код в единицу времени vs код в единицу времени. И здесь оказывается, что изобретение зеленых потоков даже используя мега библиотеки тупо неффективно исходя из экономических соображений. Асинхронный код не станет легче, если его обложить либами. Наоборот, нужно быть в курсе, где когда либа делает переключение контекста, на каком из потоков делается какой вызов, иначе дедлоков не избежать.
Потому на игровых серверах WoT или Evo Online используется какой нибудь Stackless Python
Т.е. пока одни компилируют и ищут, где же указатель не той системы или дедлок, другие уже релизятся, хотя и с много меньшим перформансом. Пока первые выкатят стабильную версию, вторые успеют заработать денег на новое железо, соптимизировать узкие места и снова будут в профите.
Если нет жестких ограничений по времени или есть жесткие требования по производительности, команды меняются местами — в профите гарантировано первые. Фокус в том, что таких приложений буквально единицы.
Re[34]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>То, что лёгкие потоки однозначно лучше системных в узкой нише "тысяч одновременных задач", мы уже давно выяснили
НС>С чего ты взял что в тасках легкие потоки?
Таски и есть легкие потоки. Точнее это реализация легких потоков с помощью библиотеки, костылей в языке и такой то матери.
Re[36]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Вот именно что неким подобием. Fine grained параллелизм никто 1 в 1 на физические потоки и не кладет, потому что накладные расходы весь выигрышь сожрут. Тем не менее с точки зрения ожидания ввода/вывода и т.п. это самые настоящие потоки.
Правильно, в зеленых потоках все точно так же — с т.з. ожидания ввода-вывода это настоящие потоки.
Re[35]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ikemefula, Вы писали:
I>И в чем отличие ?
In computer programming, green threads are threads that are scheduled by a virtual machine (VM) instead of natively by the underlying operating system. Green threads emulate multithreaded environments without relying on any native OS capabilities, and they are managed in user space instead of kernel space, enabling them to work in environments that do not have native thread support.
Re[38]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Ikemefula, Вы писали:
I>>И в чем отличие ?
НС>
НС>In computer programming, green threads are threads that are scheduled by a virtual machine (VM) instead of natively by the underlying operating system. Green threads emulate multithreaded environments without relying on any native OS capabilities, and they are managed in user space instead of kernel space, enabling them to work in environments that do not have native thread support.
Если смотреть первое выделение, то окажется, что зеленые потоки вообще никакие не зеленые, а то в реализациях то тут, то там могут использовать возможности OS.
Если второе, то таски из дотнета можно прикрутить к рантайме без нативной поддержки тредов.
Re[37]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, alex_public, Вы писали:
S>>время на переключение контекстов, память, объекты ядра. Мелочь конечно, но для типовой десктопной нагрузки: 99% спим, 1% изображаем бешеную активность они становятся сопоставимы с собственно полезной деятельностью.
_>Это вряд ли. Ну точнее если время исполнения (а не жизни!) потока становится сравнимым со временем его создания (как кстати было в том нашем тестовом примерчике), то тогда действительно потоки становятся весьма не эффективными. Но это явно вырожденный случай.
Это обычный случай в десктопе и мобайле. 90-99% времени это idle.
S>>Нет. Чисто вычислительных задач в десктопе очень мало, а вот затыков из-за IO, наоборот, много.
_>И? ) Это как-то отменяет многоядерность современных процессоров? )
S>>Осталось объяснить это 95% разработчиков
_>Вот, с таким объяснением (индусоориентированность) пользы лёгких потоков в десктопном софте я вполне могу согласиться. )))
Ну да, всё просто — все дураки, один ты д'Артаньян. Вероятно оттого, что ни десктопом, ни мобайлом не занимался.
Re[8]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Aлeкceй, Вы писали:
IT>Забыл добавить.
IT>Если бы MS выпустил .NET под Линукс, то дни Java ну не то чтобы были сочтены, но мы бы её оттуда очень сильно подвинули, т.к. желающих очень много. А когда .NET обосновался бы на серверах, то можно было бы ставить вопрос о нужности Линукса на сервере и доказывать, что его обслуживание вовсе не дешевле Windows, а гемора при разработке больше. Т.е. .NET вполне мог бы оказаться тем поршнем, который помог бы выдавать Линукс с серверной части. А пока получается, что на серверах, за исключением веба, MS представлена очень слабо.
Здравствуйте, Ikemefula, Вы писали:
I>>>Таски и есть легкие потоки. НС>>Нет. I>И в чем отличие ?
Сорри, что влажу, но таски — это не потоки, это абстракция уровнем выше. За Task может скрываться классический поток, шедулер TPL, шедулер ms sql, iocp-порт или вообще балансер для кластера, как в orleans.
Ближайшая аналогия для Task — запущенная операция. Она может завершиться, быть отменена, упасть с ошибкой, продолжена произвольным кодом после своего завершения и тд и тп. На поток это мало похоже
Re[9]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Если второе, то таски из дотнета можно прикрутить к рантайме без нативной поддержки тредов.
НС>Ага, если обеспечить отдельную поддержку зеленых потоков.
Это можно сделать прямо в прикладном коде.
Re[41]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ikemefula, Вы писали:
I>Это можно сделать прямо в прикладном коде.
Все можно. Но это никак не делает таски зелеными потоками. Таски это абстракция для fine grained параллелизма, могущая работать и на настоящих потоках, и на зеленых, и вообще без потоков.
Re[40]: Зачем Майкрософту рубить сук, на котором он сидит?
Здравствуйте, Ночной Смотрящий, Вы писали:
I>>Если второе, то таски из дотнета можно прикрутить к рантайме без нативной поддержки тредов.
НС>Ага, если обеспечить отдельную поддержку зеленых потоков.
Это именно что 99% асинхронных задач в wp/winrt — запулили в фоновый поток, чтобы не морозить UI из-за зависшей сети, оно отработало сразу, продолжаем в UI-потоке.
Если нам не помогут, то мы тоже никого не пощадим.
