Re: Зачем нам асинхронность?
От: serj.e  
Дата: 28.08.20 17:20
Оценка:
Асинхронность нужна в первую очередь на сервере при перевале (условно) за c100k. Потому что потоковая модель начиная с некоторого порога нагрузки становится неэффективной. В UI не очень-то и нужна, это да.

PS. Впрочем, при сверхвысоких IO–нагрузках лучше пропустить асинхронность, и прыгать сразу из феодализма в коммунизм от тредов к явным конечным автоматам и прямому доступу к сетевухе/NVME (DPDK, SPDK). Как делает ScyllaDB.
Re[2]: Зачем нам асинхронность?
От: Sharov Россия  
Дата: 28.08.20 19:42
Оценка:
Здравствуйте, serj.e, Вы писали:

SE>PS. Впрочем, при сверхвысоких IO–нагрузках лучше пропустить асинхронность, и прыгать сразу из феодализма в коммунизм от тредов к явным конечным автоматам и прямому доступу к сетевухе/NVME (DPDK, SPDK). Как делает ScyllaDB.


О чем идет речь (см. выделенное)?
Кодом людям нужно помогать!
Re[27]: Зачем нам асинхронность?
От: alex_public  
Дата: 30.08.20 05:35
Оценка:
Здравствуйте, Sinclair, Вы писали:

_>>Вообще то там 8 логических ядер. )

_>>А тут их 12. )))
S>Ну, то есть никаких "минимум 24" и не пахнет.

Так и я писал про десктоп, а не про лаптоп.

_>>Лаптоп? фуфуфу — большая неудобная хреновина. Не сравнится по удобству работы с десктопом и по мобильности с планшетом. На конференции или встречи я обычно беру с собой планшетик.

S>А какой смысл брать с собой планшетик, на котором нет ничего из того, чем я занимаюсь? Планшетик (айпад про) у нас есть — отличная штука смотреть инстаграм и фильмы в самолёте.

Можно например подключиться через Jupyter к мощному кластеру и погонять там разные ML модельки. ) Или показать презенташку с диаграммками планируемого роста потенциальным партнёрам. ))) Да, а вот фильмы я смотрю исключительно на большом домашнем кинотеатре с Hi-end акустикой (хотя она больше для музыки, но и для фильмом хорошо). В самолёте же предпочитаю книжки, на том же самом планшетике.

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

S>Мобильность у моего T460 вполне отличная — 14", весит 1.7. Спину не оттянет.


Ну с 500 грамм планшета это всё равно не сравнится. Так же как и размеры. И кстати для мобильного использования сенсорный экран всё же местами удобнее (особенно если ещё и с пером).

_>>Ну раз уж ты так в этом уверен, то тогда конечно же легко скажешь насколько 10000 лишних заблокированных потоков замедлит работу системы?

S>Сходу не скажу, надо замерять. Но даже просто запуск 10000 заблокированных потоков займёт заметное время

Конечно. Но мы же говорим о замусоривание всей ОС этими 10000 потоками, а не об одновременном их старте одним приложением.

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

_>>Безусловно чрезмерное число одновременно работающих потоков ухудшает производительность. Но чрезмерное в данном случае — это тысячи, а не сотни и уж точно не десятки.
S>Вы как-то очень разбрасываетесь словами "вообще говоря" и "безусловно", при этом кидаетесь из крайности в крайность.
S>https://rsdn.org/article/baseserv/liveobj.xml
Автор(ы): Роман Хациев
Дата: 14.02.2002
Довольно давно я прочитал статью, автор которой объединил две концепции — многозадачность и объектно-ориентированное программирование. В результате получились так называемые "живые объекты". Идея крайне проста — при инициализации объекта создается отдельный поток и объект в нем живет своей жизнью, а создатель объекта по мере необходимости получает информацию о состоянии объекта из его свойств.

S>Есть ли у вас замеры на более современном железе?

Да, было дело. И самое забавное, что на самом деле там нет прямой зависимости от числа потоков. Т.е. винда без проблем держит и 100 000 одновременно вычисляющих потоков без всякой деградации производительности. Там нюанс в другом. Когда мы говорим об очень большим числе одновременных задач, то автоматически получается, что каждая задача очень маленькая и тогда расход процессора на её исполнение становится сравнимым с накладными расходами на старт и завершение потока. Т.е. на обычных машинах если у тебя одна задачка занимает более 50 мс (т.е. в среднем это получается где-то по 20*число ядер задач в секунду), то ты точно не будешь замечать накладные расходы от потоков. Если же меньше, то будут линейно расти накладные расходы и где-то при 1 мс будут уже полностью неприемлемыми.

S>Меня беспокоят не потоки сами по себе, а рост их количества. Запуск O(1) потоков для технических целей — это норм. Запуск O(N) потоков — уже плохо.


Ну так задачка загрузить файл на сервер по нажатию кнопки в меню — это по твоему к какой категории относится? )

S>Ещё с девяностых годов известно, что кооперативная многозадачность эффективнее вытесняющей. Но в те времена технические средства по организации кооперативщины были крайне отсталыми; и в чистом виде она не очень хорошо работает с SMP.

S>Теперь же у нас есть прекрасные средства по организации fine-grained многозадачности, которые работают в комфортном для железке количестве потоков, и не требуют от программиста выворачиваться наизнанку.

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

S>А вы зачем-то предлагаете вернуться "назад в пампасы" и запускать ажно целый поток на каждый чих.


Ой, целый поток — ужас то какой!
Re[28]: Зачем нам асинхронность?
От: Sinclair Россия https://github.com/evilguest/
Дата: 30.08.20 10:47
Оценка: +2
Здравствуйте, alex_public, Вы писали:

_>И да, я предпочитаю работать не за ноутом, а за мощной рабочей станций с большим монитором, нормальной клавиатурой и мышкой, специальным эргономичным креслом, приблизительно по тем же причинам, по которым смотрю фильмы только так, как описано выше.

Ваши личные предпочтения интересуют только вас. Меня интересует целевая аудитория. Когда я пишу под винтел, я отдаю себе отчёт в том, что у среднестатистического пользователя нет никаких 24х ядер.
Лично у вас — может быть, да. А на практике мы только что посмотрели на топовые процессоры в мобильном сегменте. Их ставят в ноуты бизнес-класса, которых считанные проценты от массового рынка.
Если же мы посмотрим на массовый рынок, то всё будет гораздо хуже.

Поэтому оправдывать запуск O(N) потоков тем, что у единичных пользователей 24 ядра и выше — мягко говоря, странно.
А что делать тем, кто покупает массовые лэптопы за $500? Не пользоваться софтом?
_>Ну с 500 грамм планшета это всё равно не сравнится. Так же как и размеры. И кстати для мобильного использования сенсорный экран всё же местами удобнее (особенно если ещё и с пером).
Отож. Размеры — штука важная. На 14" работать в студии или экселе куда удобнее, чем на 9". Как бы площадь экрана вдвое больше

_>Конечно. Но мы же говорим о замусоривание всей ОС этими 10000 потоками, а не об одновременном их старте одним приложением.

Мы говорим о том, что приложение, которое якобы пишется для минимизации задержек, зачем-то пытается запускать отдельный поток для I/O операции, вместо того, чтобы взять готовый IOCP-поток из пула.

_>Да, было дело. И самое забавное, что на самом деле там нет прямой зависимости от числа потоков. Т.е. винда без проблем держит и 100 000 одновременно вычисляющих потоков без всякой деградации производительности. Там нюанс в другом. Когда мы говорим об очень большим числе одновременных задач, то автоматически получается, что каждая задача очень маленькая и тогда расход процессора на её исполнение становится сравнимым с накладными расходами на старт и завершение потока. Т.е. на обычных машинах если у тебя одна задачка занимает более 50 мс (т.е. в среднем это получается где-то по 20*число ядер задач в секунду), то ты точно не будешь замечать накладные расходы от потоков. Если же меньше, то будут линейно расти накладные расходы и где-то при 1 мс будут уже полностью неприемлемыми.

Интересно. Есть какие-то воспроизводимые бенчмарки на эту тему?
_>Ну так задачка загрузить файл на сервер по нажатию кнопки в меню — это по твоему к какой категории относится? )
Пограничный случай.

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

А можно ткнуть пальцем в то место, где "очень сильно увеличивается" эта вот "реальная сложность"?
Ну, то есть понятно, что мы в любом случае говорим не о том, чтобы запускать синхронный IO в обработчике OnClick — эту простоту переплюнуть уже не выйдет. Мы говорим о реальной асинхронности — т.е. в процессе загрузки файла на сервер наше приложение всё ещё "шевелится", реагирует на системные события и может отменить операцию.
Давайте посмотрим — сильно ли оно станет проще, если отказаться от async/await, и вернуться в дикие девяностые с CreateThread.

_>Ой, целый поток — ужас то какой!

Именно, именно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[28]: Зачем нам асинхронность?
От: Mystic Artifact  
Дата: 30.08.20 16:52
Оценка:
Здравствуйте, alex_public, Вы писали:

Ну ты б не позорился. Ты вообще понимаешь что такое живой звук и хай энд оборудование? Так вот твое хай энд говно и есть говно, не отличимое от пищалки самсунгов в 4 поколении.
Re[28]: Зачем нам асинхронность?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 30.08.20 17:11
Оценка:
Здравствуйте, alex_public, Вы писали:



_>По факту очень многие "асинхронные программисты" даже не представляют что там на самом дел внутри происходит, а воспринимают данную им систему как волшебный чёрный ящик. У которого в случае использования сопрограмм действительно очень простой внешний интерфейс. Но надо понимать, что это только кажущаяся простота, а реальная сложность приложения от применения этих технологий очень сильно увеличивается. В случае нагруженного сервиса у нас собственно просто не выбора. А вот для обычных приложений...


А вот в случае обычного приложения вообще парится не надо. Нет никакой экономии от ручного применения потоков.
А вот сложность чтения такого кода против async/await значительно выше.

Еще раз. Действительно не нужно знать как работает async/await на разных платформах. Нужно знать принципы.
Для десктопа, сервера и мобильных приложений пиши один и тот же код и не заморачивайся с потоками.
По сути то async/await по сути дает забыть о потоках.

Ты же тащишь в какие то доисторические времена игнорируя эволюцию.
и солнце б утром не вставало, когда бы не было меня
Re[29]: Зачем нам асинхронность?
От: alex_public  
Дата: 31.08.20 15:50
Оценка: :)
Здравствуйте, Mystic Artifact, Вы писали:

MA>Ну ты б не позорился. Ты вообще понимаешь что такое живой звук и хай энд оборудование? Так вот твое хай энд говно и есть говно, не отличимое от пищалки самсунгов в 4 поколении.


Оу, у нас тут появился истинный телепат, видящий аппаратуру коллег силой мысли. А какие ещё суперспособности имеешь? )))
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.