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

[Astronavt]

Добрый день! Подскажите, пожалуйста, как правильно реализовывать многопоточное приложение на чистом Си, чтобы оно показывало лучшую производительность, чем async/await C#? Дело в том, что сколько я ни пытался, мне не удалось добиться в C# с использованием класса Thread лучшего результата, чем даёт async/await, поэтому опасаюсь, что при переходе на Си возникнет проблема производительности.

[worm2]

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

[Dmitriy40]

Писанины будет больше, а толку столько же.
К тому же на С можно и не останавливаться, а сразу и WinAPI использовать (или аналогичный интерфейс любой другой ОС).
Тут многое зависит от задачи и от разбиения её на множество подзадач (считаемых параллельно), нередко накладные расходы на связь подзадач между собой намного превышают накладные расходы на организацию многозадачности и потому как именно она организована уже без разницы.
Если надо ускорить выполнение многозадачного кода, то стоит укрупнять куски разбиения задачи, но не превышать нескольких процентов от общего (чтобы не ждать слишком долго завершения последних подзадач), но и не дробить задачу на куски длительностью микросекунды (слишком долгим будет вызов функций ОС), для себя оптимальным считаю длину подзадач в десятки миллисекунд. Уменьшать количество точек взаимодействия подзадач друг с другом. Уменьшать объёмы перезаписываемой информации в каждой подзадаче. Максимально много данных объявлять константными чтобы они не дублировались в каждую подзадачу (если компилятор это позволяет, не дублировать). По возможности использовать более простые механизмы синхронизации/арбитража подзадач друг с другом (в идеале - только критические секции с не слишком долгим кодом в них).
Перехода на более простой/примитивный язык программирования в этом списке нет - слишком мал эффект от этого (в плане организации многозадачности, не самих вычислений). Стоит задумываться когда исчерпаны все другие возможности. Тем более что высока вероятность что придётся реализовывать самому почти весь функционал механизмов арбитража более продвинутого языка, с неизбежными ошибками и временем на написание и отладку, ну кроме совсем уж простых случаев (скажем на которые хватает критических секций).

worm2 в сообщении #1635228 писал(а):

А у вас что за задача, что прирост производительности по сравнению с однопоточным вариантом сразу виден?

Таких задач полно, вопрос насколько в ней критичны именно накладные расходы организации многозадачности и синхронизации потоков между собой. Часто можно чуть по другому побить задачу на куски и все накладные расходы уходят ниже 1% общего времени. Без смены языка.
К тому уже у ТС уже многопоточный код, но он зачем-то хочет переписать его на более примитивном языке, ожидая выигрыша скорости, чего вполне может и не быть.

[bondkim137]

Astronavt в сообщении #1635172 писал(а):

Добрый день! Подскажите, пожалуйста, как правильно реализовывать многопоточное приложение на чистом Си, чтобы оно показывало лучшую производительность, чем async/await C#?

Однозначно можно. Но не всегда рентабельно. Опишите проблему (задачу) детальнее.

[Vista7]

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

Astronavt в сообщении #1635172 писал(а):

Добрый день! Подскажите, пожалуйста, как правильно реализовывать многопоточное приложение на чистом Си, чтобы оно показывало лучшую производительность, чем async/await C#?

Однозначно можно. Но не всегда рентабельно. Опишите проблему (задачу) детальнее.

Хочу сделать простейший FastCGI веб-сервер.

[zykov]

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

[bondkim137]

Vista7 в сообщении #1672015 писал(а):

Хочу сделать простейший FastCGI веб-сервер

Если вы хотите простейший сделать, то можете убрать в названии слово Fast и используйте потоки в лоб.
Если хотите быстрый и экономный по памяти сделать - то придется писать (или искать готовый) шедулер потоков. Системный в современных ОС хоть и относительно быстрый, но ограничен архитектурой: вынужден выделять пр-во и память для стека, создает массу системных объектов, относительно медленно переключается даже при заморозке/разморозке, не говоря о создании на каждую микро-задачу нового потока и т.д. Также процессы с бесчисленным роем системных потоков отвратительно отлаживаются по понятным причинам.
А если хотите совсем быстрый - придется еще глубже поковыряться: минимизировать интерлок-операции с памятью и сброс кешей: например, с помощью пула тонких процессов, привязанных к ядрам. А также вероятно придется использовать локальные временные кучи для оптимизации работы с памятью и поковыряться в memory-manager-ах.

[Vista7]

bondkim137

А как обойти известную дыру CGI с бесконечным созданием процессов, пока сервер не захлебнётся?

[DemISdx]

Только качеством проработки кода.
Без вариантов.
Что потребует достаточно глубокого вхождения в тему при написании...

(Оффтоп)

Просто посмотрите опенсоурсные варианты проработки подобных вещей, как пример:
https://github.com/BOINC/boinc/blob/master/sched/file_upload_handler.cpp
https://github.com/BOINC/boinc/wiki/FileUpload

[bondkim137]

Vista7 в сообщении #1700561 писал(а):

А как обойти известную дыру CGI с бесконечным созданием процессов, пока сервер не захлебнётся?

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

[denprog]

Почему именно C, не C++? Для C++ в std библиотеке есть поддержка многопоточности, есть сторонние библиотеки... В том же boost::asio есть готовые примеры.

[realeugene]

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

[bondkim137]

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

асинки гораздо лучше тяжёлых потоков

они на этих самых "тяжелых потоках" и сидят. в пулах, собственно.

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

придётся моделировать на сях конечные автоматы

не надо так усложнять =)

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

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

в последнее время не приходится бороться. забыл уже, когда в последний раз боролся. сейчас память дешевая, оверхед в 1.5-2 раза вполне себе ок. да и у jvm-подобных gc все равно зачастую в итоге хуже: и процент неубранной памяти тоже постоянно присутствует и cpu-расходы на сборку заметные.

[realeugene]

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

они на этих самых "тяжелых потоках" и сидят. в пулах, собственно.

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

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

забыл уже, когда в последний раз боролся. сейчас память дешевая, оверхед в 1.5-2 раза вполне себе ок.

Кэш всё равно небольшой.

[bondkim137]

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

Компилятор превращает асинк в конечный автомат, который шагает на этом тредпуле

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

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

Кэш всё равно небольшой

он настолько небольшой, что фрагментация кучи погоды не делает (в контексте использования non-moving аллокаторов против relocating аллокаторов)