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

НС>>К какой части высказывания вопрос?
_>К первой. )

Это, как бы, наблюдаемый факт. Асинхронный IO меньше жрет батарейку и обеспечивает меньшую латентность на действия пользователя в условиях ограниченной многозадачности всех трех актуальных мобильных ОС.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Это, как бы, наблюдаемый факт. Асинхронный IO меньше жрет батарейку и обеспечивает меньшую латентность на действия пользователя в условиях ограниченной многозадачности всех трех актуальных мобильных ОС.

И где можно ознакомиться с результатами измерений? )

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

_>>>Ну так а зачем запускать тяжёлые операции в UI потоке, а не в отдельном? )
S>>В терминах мобильных приложений к "тяжёлым" относится всё, что может завесить поток больше, чем на 50 миллисекунд. Т.е. любой ввод-вывод как минимум.
_>И как это отвечает на мой вопрос? )
Очень просто. Сама возможность запустить операцию синхронно означает, что её будут использовать в UI-потоках. Просто потому, что оно не тормозит на машине разработчика. Поэтому единственный способ это предупредить — просто лишить программиста возможности запустить потенциально тормозной код синхронно.

_>Похоже что данного преимущества недостаточно для популярности платформы. Кстати, сама винда это показывала в далёком прошлом: более открытая платформа выигрывает, даже если она более глючная.
Дело не в открытости и не в технических возможностях, точнее, не только и не столько в них. Два примера:
* Урезанная донемогу wp куда популярней на мобильном рынке, чем "более открытая" winrt (понятно что сравниваем яблоки с апельсинами, ну да фиг с ним). Хотя с точки зрения обычного пользователя winrt практически не отличается по возможностям от типовых андроид/ios — приложений.
* Свободный от и до линукс на мобильном рынке не заметен в микроскоп, в отличие от "ограниченного" андроида.

S>>Вот тут я не уверен честно говоря От .net-а там всего ничего, почти всё уходит в нативные вызовы. Как вариант — выложите бинарник, проверю.
_>Легко: http://files.rsdn.ru/98162/test.exe
Вот тут я в непонятках. Хоть убей, у меня выводит что-то типа 5183, т.е. 5k потоков. Win7x64. Или от системы оно зависит куда сильнее, чем managed/unmanaged, или у нас код различается.

_>Thread.Yield это в реальности функция SwitchToThread из win api. И её добавление/убирание для потоков в данном случае естественно никак не влияет на ситуацию — не стоит путать кооперативную и вытесняющую многозадачность.
Немного влияет, по крайней мере под .net — запускающий (основной) поток периодически перестаёт молотить (а приоритет у него выше) и даёт завершиться ожидающим потокам. Но там разброс получается в 5-10%, т.е. в пределах погрешности. Для тасков разброс заметнее.

S>>Это во многом зависит от дизайна языка и фреймворка. Для дотнета замена абсолютно прозрачна. Для скалы/эрланга — незаметна в принципе.
_>Ну начнём с того, что для обычного десктопного ПО (с 1-10 одновременными задачами) асинхронная работа ещё и менее эффективна, чем синхронная. Правда для такого ПО опять же обычно глубоко наплевать на такие нюансы эффективности.
_>Но главный вопрос в другом: а зачем менять код с системных потоков на лёгкие для обычного ПО? Т.е. как у нас это соотносится с принципом Оккама? )
Для обычного десктопного характерны именно что долгие ожидания с промежуточными всплесками активности. Таски тут как раз идеально подходят, т.к. позволяют распределить нагрузку во время всплеска, не завешивая основной поток. При этом код практически не отличается от обычного синхронного.

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

S>Очень просто. Сама возможность запустить операцию синхронно означает, что её будут использовать в UI-потоках. Просто потому, что оно не тормозит на машине разработчика. Поэтому единственный способ это предупредить — просто лишить программиста возможности запустить потенциально тормозной код синхронно.

Т.е. по сути это не технологическое решение, а политическое — сделать платформу более устойчивой к программированию индусами... Ну в таком смысле может и могу согласиться. Собственно java и .net на этом и специализируются, но то что они win api пробуют повернуть туда же — это уже совсем разумно.

S>Вот тут я в непонятках. Хоть убей, у меня выводит что-то типа 5183, т.е. 5k потоков. Win7x64. Или от системы оно зависит куда сильнее, чем managed/unmanaged, или у нас код различается.

Ну так .net вариант как я понял вообще вылетал, причём уже на 3К потоках? )

А так, вполне возможно, что создание потока на Win7x64 стоит в пару раз дороже, чем на WinXPx86. Вообще эта тема конечно же заслуживает более детального исследования, но у меня сейчас на это времени особо нет.

S>Немного влияет, по крайней мере под .net — запускающий (основной) поток периодически перестаёт молотить (а приоритет у него выше) и даёт завершиться ожидающим потокам. Но там разброс получается в 5-10%, т.е. в пределах погрешности. Для тасков разброс заметнее.

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

S>Для обычного десктопного характерны именно что долгие ожидания с промежуточными всплесками активности. Таски тут как раз идеально подходят, т.к. позволяют распределить нагрузку во время всплеска, не завешивая основной поток. При этом код практически не отличается от обычного синхронного.

Эммм, вообще то вопрос был немного не про это. Я спрашивал зачем заменять системные потоки лёгкими, а не зачем заменять однопоточный код на лёгкие потоки. ) Понятно что таски лучше линейного кода. Но чем они могут быть лучше своего многопоточного аналога? )

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

_>Эммм, вообще то вопрос был немного не про это. Я спрашивал зачем заменять системные потоки лёгкими, а не зачем заменять однопоточный код на лёгкие потоки. ) Понятно что таски лучше линейного кода. Но чем они могут быть лучше своего многопоточного аналога? )

Тем, что не привязаны к потокам системы. Как результат — можно распределять нагрузку прозрачно для пользовательского кода. Звучит скромно, на практике разница как между циклами и linq: основная часть рутинного кода спрятана под капот и многопоточный/асинхронный код получается очень легко.

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

S>Тем, что не привязаны к потокам системы. Как результат — можно распределять нагрузку прозрачно для пользовательского кода. Звучит скромно, на практике разница как между циклами и linq: основная часть рутинного кода спрятана под капот и многопоточный/асинхронный код получается очень легко.

Что-то сомневаюсь. Вот мы тут рассматривали для теста два примера на C# — они выглядели практически одинаково. И даже у варианта с Task'ми было чуть больше мусора (await'ы и т.п.).

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

_>Что-то сомневаюсь. Вот мы тут рассматривали для теста два примера на C# — они выглядели практически одинаково. И даже у варианта с Task'ми было чуть больше мусора (await'ы и т.п.).

Так в варианте с тасками и работы больше было. Вместо тупого блокирования потока он передавался следующей задаче, таски были настроены так чтобы для продолжения работы использовать первый свободный поток, а не исходный (.ConfigureAwait(false)). Попробуете так же лаконично записать это с "простыми" потоками?

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

S>Так в варианте с тасками и работы больше было. Вместо тупого блокирования потока он передавался следующей задаче, таски были настроены так чтобы для продолжения работы использовать первый свободный поток, а не исходный (.ConfigureAwait(false)). Попробуете так же лаконично записать это с "простыми" потоками?

Не понял, что надо записать лаконично простыми потоками? ) У нас есть два примера, реализующих одну и ту же функциональность. При этом вариант с тасками более замусорен.

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

_>Не понял, что надо записать лаконично простыми потоками? ) У нас есть два примера, реализующих одну и ту же функциональность. При этом вариант с тасками более замусорен.

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

Функциональность разная. Как и нагрузка на комп. У вас Test.exe на ~5000 потоках жрёт 170 мб. Если ограничить вариант на дотнете теми же пятью тысячами задач, получаем ~14мб private bytes.

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

S>Функциональность разная. Как и нагрузка на комп. У вас Test.exe на ~5000 потоках жрёт 170 мб. Если ограничить вариант на дотнете теми же пятью тысячами задач, получаем ~14мб private bytes.

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

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


_>То, что лёгкие потоки однозначно лучше системных в узкой нише "тысяч одновременных задач", мы уже давно выяснили. Вопрос в том, зачем нужны лёгкие потоки в обычных приложениях.
Затем, что "лёгкие потоки" изначально строятся на continuation passing-модели в отличие от lock-n-wait для "обычных" потоков.

Отличие в том, что continuation passing позволяет писать эффективный асинхронный код даже если он будет работать в одном потоке. Большинство сценариев для десктопов, мобильного и веб-софта превосходно ложатся на "запусти, дай работать другому коду, продолжи по завершении".

Для "классики" приходится или мириться с блокирующими ожиданиями, или переизобретать лёгкие потоки — очередь сообщений, шедулер, приоритеты и т.п.

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

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

С чего ты взял что в тасках легкие потоки?

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

S>Отличие в том, что continuation passing позволяет писать эффективный асинхронный код даже если он будет работать в одном потоке. Большинство сценариев для десктопов, мобильного и веб-софта превосходно ложатся на "запусти, дай работать другому коду, продолжи по завершении".

То, что это возможно, я понимаю. Но вопрос "а зачем?" остаётся по прежнему... )

S>Для "классики" приходится или мириться с блокирующими ожиданиями, или переизобретать лёгкие потоки — очередь сообщений, шедулер, приоритеты и т.п.

Так а чем плохо то блокирующее ожидание в отдельном потоке?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>С чего ты взял что в тасках легкие потоки?

Не в них, а они сами являются неким подобием. )

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

_>Не в них, а они сами являются неким подобием. )

Вот именно что неким подобием. Fine grained параллелизм никто 1 в 1 на физические потоки и не кладет, потому что накладные расходы весь выигрышь сожрут. Тем не менее с точки зрения ожидания ввода/вывода и т.п. это самые настоящие потоки.

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

S>>Для "классики" приходится или мириться с блокирующими ожиданиями, или переизобретать лёгкие потоки — очередь сообщений, шедулер, приоритеты и т.п.
_>Так а чем плохо то блокирующее ожидание в отдельном потоке?
1. Впустую тратятся ресурсы. Для десктопа некритично, для мобильного софта — очень важно.
2. Переход от одного потока к другому или освобождение блокировки требует обращения к объектам ядра. Т.е. о "лёгком" переключении и построении цепочек асинхронных действий можно забыть.
3. Слишком легко заблокировать UI-поток из-за вещей, который тяжело ловятся при тестировании. Например, сбойный винт или интернет на соплях — и "быстрый-быстрый" софт превращается в тыкву

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

S>1. Впустую тратятся ресурсы. Для десктопа некритично, для мобильного софта — очень важно.

С чего это впустую тратятся? )

S>2. Переход от одного потока к другому или освобождение блокировки требует обращения к объектам ядра. Т.е. о "лёгком" переключении и построении цепочек асинхронных действий можно забыть.

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

S>3. Слишком легко заблокировать UI-поток из-за вещей, который тяжело ловятся при тестировании. Например, сбойный винт или интернет на соплях — и "быстрый-быстрый" софт превращается в тыкву

В UI потоке и не надо такое вызывать. )

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


S>>1. Впустую тратятся ресурсы. Для десктопа некритично, для мобильного софта — очень важно.
_>С чего это впустую тратятся?)
время на переключение контекстов, память, объекты ядра. Мелочь конечно, но для типовой десктопной нагрузки: 99% спим, 1% изображаем бешеную активность они становятся сопоставимы с собственно полезной деятельностью.

S>>2. Переход от одного потока к другому или освобождение блокировки требует обращения к объектам ядра. Т.е. о "лёгком" переключении и построении цепочек асинхронных действий можно забыть.
_>Вообще то в случае обычных десктопных задач эти потоки будут не переключаться, а нормально исполняться параллельно, каждый на своём ядре процессора... )
Нет. Чисто вычислительных задач в десктопе очень мало, а вот затыков из-за IO, наоборот, много.

S>>3. Слишком легко заблокировать UI-поток из-за вещей, который тяжело ловятся при тестировании. Например, сбойный винт или интернет на соплях — и "быстрый-быстрый" софт превращается в тыкву
_>В UI потоке и не надо такое вызывать.
Осталось объяснить это 95% разработчиков

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

S>время на переключение контекстов, память, объекты ядра. Мелочь конечно, но для типовой десктопной нагрузки: 99% спим, 1% изображаем бешеную активность они становятся сопоставимы с собственно полезной деятельностью.

Это вряд ли. Ну точнее если время исполнения (а не жизни!) потока становится сравнимым со временем его создания (как кстати было в том нашем тестовом примерчике), то тогда действительно потоки становятся весьма не эффективными. Но это явно вырожденный случай.

S>Нет. Чисто вычислительных задач в десктопе очень мало, а вот затыков из-за IO, наоборот, много.

И? ) Это как-то отменяет многоядерность современных процессоров? )

S>Осталось объяснить это 95% разработчиков

Вот, с таким объяснением (индусоориентированность) пользы лёгких потоков в десктопном софте я вполне могу согласиться. )))

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

S>>время на переключение контекстов, память, объекты ядра. Мелочь конечно, но для типовой десктопной нагрузки: 99% спим, 1% изображаем бешеную активность они становятся сопоставимы с собственно полезной деятельностью.
_>Это вряд ли. Ну точнее если время исполнения (а не жизни!) потока становится сравнимым со временем его создания (как кстати было в том нашем тестовом примерчике), то тогда действительно потоки становятся весьма не эффективными. Но это явно вырожденный случай.
Да ну? Это именно что 99% асинхронных задач в wp/winrt — запулили в фоновый поток, чтобы не морозить UI из-за зависшей сети, оно отработало сразу, продолжаем в UI-потоке.


S>>Нет. Чисто вычислительных задач в десктопе очень мало, а вот затыков из-за IO, наоборот, много.
_>И? ) Это как-то отменяет многоядерность современных процессоров? )
S>>Осталось объяснить это 95% разработчиков
_>Вот, с таким объяснением (индусоориентированность) пользы лёгких потоков в десктопном софте я вполне могу согласиться. )))
Не в большей степени, чем индусоориентированность компиляторов, не дающих запихнуть string в int. По этому критерию самый тру-програмерский язык у нас, выходит, яваскрипт

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