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

[Astronavt]

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

[worm2]

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

[Dmitriy40]

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

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

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

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