Производительность многопоточности в чистом Си и async C#

[realeugene]

bondkim137 в сообщении #1711044 писал(а):

о каком асинке речь? боюсь, мы говорим о разных вещах, ибо это очень общий термин.

Тема вроде была про Шарп с вcтроенными в язык async/await.

[bondkim137]

realeugene в сообщении #1711045 писал(а):

Тема вроде была про Шарп с вcтроенными в язык async/await

запамятовал с чего начали =) async/await в c# потоки не использует.
это чисто синтаксическая конструкция, предназначенная вообще не для параллельной работы, а для превращения псевдо-синхронного однопоточного кода в асинхронный. и довольно паршивенькая - из-за необходимости сохранять иногда достаточно большое состояние, включая локальные переменные функции. говоря другими словами, если цель производительность - то это совсем не про async/await

[realeugene]

bondkim137 в сообщении #1711241 писал(а):

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

А в чём проблема заводить для локальных переменных объект на куче вместо аллокации куска стека? Куча-то в Шарпе быстрая. Просто на каждый фрейм появляется лишний объект в куче, куда сваливают локальные переменные. Миллион таких объектов всяко менее затратно чем миллион преаллокированных стеков.

[bondkim137]

realeugene
не надо ни то не другое. а зачем миллион преаллоцированных стеков?
откажитесь от синхронных (и псевдосинхронных) ожиданий и мир перевернется

[realeugene]

bondkim137 в сообщении #1711459 писал(а):

а зачем миллион преаллоцированных стеков?

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

Вы как, я понимаю, предлагаете реализовывать хранение состояние этих потоков ручками не пользуясь сервисом компилятора Шарпа?

bondkim137 в сообщении #1711459 писал(а):

откажитесь от синхронных (и псевдосинхронных) ожиданий и мир перевернется

Звучит как реклама секты.

[bondkim137]

realeugene в сообщении #1711515 писал(а):

Вы как, я понимаю, предлагаете реализовывать хранение состояние этих потоков ручками не пользуясь сервисом компилятора Шарпа?

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

На самом деле, это не так страшно, как кажется, при правильном подходе. Смысл не в том, что б работу за компилятор руками сделать, а что б работу эту минимизировать: прежде всего ветвления, которые из простых условных переходов async/await превращает в лютую дичь. Если разработчик понимает, как работает async/await - он может его аккуратно использовать. Если не особо понимает, то это приводит к заметным тормозам. В первом случае, правда, обычно и острая необходимость использовать async/await отпадает. Мы несколько проектов переделывали с синхронного стиля на асинхронный. Больно было только по началу. А если с нуля писать в асинхронном стиле, вообще серьезных неудобств нет. Основной паттерн асинхронизации - захватывать в лямбду руками все что нужно и передавать эту лямбду асинхронным исполнителям + использовать подписи для отмены. Обычно этого хватает. Автоматы руками никакие писать не надо.

[realeugene]

bondkim137 в сообщении #1711525 писал(а):

Тем более, для многопоточной загрузки ядер в любом случае одним async/await не обойтись

С чего бы? В Шарпе рабочий тредпул разве не многопоточный?

bondkim137 в сообщении #1711525 писал(а):

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

Типа как в Скале? На каждое ожидание своя лямбда как новый объект в куче? Которую вызывает рабочий тредпул по событию? На чём ускорение по сравнению с асинками, на отсутствии свитча по состоянию автоматически сгенерированного конечного автомата вверху общей функции вместо кучи отдельных лямбд?

-- 03.12.2025, 16:22 --

bondkim137 в сообщении #1711525 писал(а):

Если не особо понимает, то это приводит к заметным тормозам.

Любопытно, на чём обычно народ лажает по вашей статистике?

[bondkim137]

realeugene в сообщении #1711528 писал(а):

С чего бы? В Шарпе рабочий тредпул разве не многопоточный?

Для этого его нужно начать использовать =). Тредпул и wait/async - вещи ортогональные.

realeugene в сообщении #1711528 писал(а):

На чём ускорение по сравнению с асинками

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

realeugene в сообщении #1711528 писал(а):

Любопытно, на чём обычно народ лажает по вашей статистике?

По-моему, в первую очередь на ошибке в оценке алгоритмической сложности. Когда код выглядит, как, например, $O(N\log(N))$, а внутри еще один скрытый $O(N)$, грубо говоря, сидит. К скрытым издержкам, кстати, активное использование кучи и эксплуатация GC, тоже относятся. А в мультитредовом нативном софте - даже ref-counter-ы и критические секции, которые под капотом активно interlock-операции используют со spin-count-ами, из-за чего память блокируется вертикально сквозь все кеши, и все может начать неожиданно деградировать.

[Dmitriy40]

Я много где читал (вплоть до официальных документов) что критические секции (в WinAPI, про ЯВУ не знаю) - самый быстрый вид синхронизации потоков. Если что-то и можно сделать быстрее, то только очень специфическое.
Понятно что кривым использованием убить можно что угодно.

[realeugene]

bondkim137 в сообщении #1711542 писал(а):

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

Ну так давайте писать на ассемблере.

bondkim137 в сообщении #1711542 писал(а):

По-моему, в первую очередь на ошибке в оценке алгоритмической сложности. Когда код выглядит, как, например, $O(N\log(N))$, а внутри еще один скрытый $O(N)$, грубо говоря, сидит.

Круче, когда в $O\left(N^2\right)$ сидит $O\left(N^2\right)$. Это не специфично именно для асинков, но соглашусь, что в плохо спроектированной системе риски велики.

bondkim137 в сообщении #1711542 писал(а):

К скрытым издержкам, кстати, активное использование кучи и эксплуатация GC, тоже относятся.

Опять же, для асинков не специфично. С лямбдами всё равно нужна куча аллокаций, так что быстрый GC наоборот должен давать преимущества. Но польза от GC конечно не в этом, а в том, что не надо думать про владение.

bondkim137 в сообщении #1711542 писал(а):

А в мультитредовом нативном софте - даже ref-counter-ы и критические секции, которые под капотом активно interlock-операции используют со spin-count-ами, из-за чего память блокируется вертикально сквозь все кеши, и все может начать неожиданно деградировать.

Ну да, но опять же, не специфично для асинков.

-- 04.12.2025, 00:18 --

bondkim137 в сообщении #1711525 писал(а):

Мы несколько проектов переделывали с синхронного стиля на асинхронный.

А это не последствия агиля? Был быстро написан MVP, дозрело до спроектировать нормально?

[bondkim137]

realeugene в сообщении #1711575 писал(а):

Ну так давайте писать на ассемблере

не стоит спекулировать. есть задачи, которые разумно отдавать роботам. есть те, где стоит подумать.

realeugene в сообщении #1711575 писал(а):

Круче, когда в $O\left(N^2\right)$ сидит $O\left(N^2\right)$. Это не специфично именно для асинков, но соглашусь, что в плохо спроектированной системе риски велики

и такое бывает. и за такое надо бить =)

realeugene в сообщении #1711575 писал(а):

С лямбдами всё равно нужна куча аллокаций, так что быстрый GC наоборот должен давать преимущества

использование лямбд vs wait/async в нашем случае и использование GC - тоже вещи ортогональные. wait/async можно и на неперемещаемой куче без GC делать (в rust например, даже в с++20 оно уже появилось в каком-то виде). а лямбды в C# будут таже кучу и GC мучать, может разве что поспокойнее, чем wait/async

realeugene в сообщении #1711575 писал(а):

А это не последствия агиля? Был быстро написан MVP, дозрело до спроектировать нормально?

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

-- 04.12.2025, 01:37 --

Dmitriy40 в сообщении #1711572 писал(а):

Я много где читал (вплоть до официальных документов) что критические секции (в WinAPI, про ЯВУ не знаю) - самый быстрый вид синхронизации потоков

строго говоря, это не так. в winapi критические секции написаны так, что синхронизующий семафор (а это системный объект) создается только в случае конфликтной ситуации (сейчас это сделано так не только в winapi) - это большой плюс, и вероятно оттуда ноги и растут. но если вам не нужна полноценная критическая секция (да еще и с поддержкой рекурсивных вызовов) и можно обойтись одной interlocked-операцией, то это значительно быстрее (например, счетчики ссылок принято крутить напрямую, а не окружать критической секцией). выше я имел в виду вообще проблемы с массовым использованием interlocked на backend, они лечатся дроблением процесса и отказом от interlocked в локальных процессах-воркерах, привязанных к одному ядру. если будет время, весной сделаю доклад на эту тему =)

[realeugene]

bondkim137 в сообщении #1711579 писал(а):

и за такое надо бить

Гы. Некого - сами ушли раньше.

[realeugene]

bondkim137 в сообщении #1711579 писал(а):

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

Интерлокед-операции слишком низкоуровневые и при этом сложные примитивы, чтобы с ними можно было наделать тонких ошибок. Синхронизация в программировании вообще сложна. async/await для программиста концептуально гораздо проще.

[bondkim137]

realeugene в сообщении #1711594 писал(а):

async/await для программиста концептуально гораздо проще

именно. настолько проще, что каждый второй, если почти не первый async/await-пользователь не знает, как принципиально оно работает: думает, что там линейный код с магическими префиксами, а на деле там многоэтажная конструкция, эксплуатирующая кучу и GC, со всеми вытекающими. мощный инструмент в руках дурака, так сказать

[realeugene]

bondkim137 в сообщении #1711668 писал(а):

думает, что там линейный код с магическими префиксами

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

-- 04.12.2025, 18:38 --

bondkim137 в сообщении #1711668 писал(а):

мощный инструмент в руках дурака, так сказать

Да ладно, на серверах и Питон успешно гоняют, и ничё.