Автоматическое распараллеливание програм на С

https://gcc.gnu.org/wiki/Graphite

The Graphite branch has been merged in August 2008 into trunk.

раньше все было просто, ставишь нужный очень небольшой пакет deb, для gcc пишешь пару ключей и для математической программы на с получаешь 7% прибавки производительности, А сейчас что делать _

А сейчас что делать

https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Optimize-Options.html

Искать Graphite. Опций не очень много.

7% прибавки в результате распараллеливания это определённо то, к чему стоит стремиться. 🤦

исходный код делали 20 лет разные математики дикого запада крайне сложен и на уровне программирования расспараллелить крайне затруднительно из+за отсутствия у нас специлистов в этой области математики требуемого уровня желающие прочитать около 10 томов математических книг плюс разобраться с современными статьями на тему математическая логика и автоматическое доказательство теорем и править уже существующий самый лучший в мире в этой области проект есть 00 знак вопроса

Красиво сказал! Но таки да, 7% - это как раз оно, параллельность :)

потанцивал, ух как щас фуфыкс затащит

7% прибавки в результате распараллеливания это определённо то, к чему стоит стремиться. 🤦

Ну что ж поделаешь, если сишечка – убогонький недоязычок и не параллелится нормально. Даже у Фортрана дела куда лучше с этим.

Всё прекрасно параллелится, только не магическими библиотеками а программированием.

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

Всё прекрасно параллелится, только не магическими библиотеками а программированием.

Да-да. Сишники будут руками пердолиться всё вместо того, чтобы автоматически распараллеливать код на уровне компилятора. И всё равно обосрутся с указателями где-нибудь, чтобы попасть в топы CVE.

Ну что ж поделаешь, если сишечка – убогонький недоязычок и не параллелится нормально. Даже у Фортрана дела куда лучше с этим.

ничего не знай, сразу отвечай :-)

PS/ просто с интересом почитал источники: в основном весь Graphite с первоосновами было про Фортран и распаралеливание циклов (циклы-в циклах-в циклах). Результаты вошли в GCC, косвенно попали и туда и туда, и в Си и в Фортран..далее вестимо в коммерческие от Intel

ничего не знай, сразу отвечай :-)

Да ладно. Вспомни, сколько жоп было порвано, чтобы в типичный сишный код добавить автоматическое использование SIMD в типичном for(int i = 0; i < ARRAY_SIZE; ++i) { ... }, просто потому что в C нет массивов и нужно доказывать, что доступ по указателю к элементу памяти не затрагивает другие элементы. А restrict сишники в коде не используют принципиально.

Если вы мне скажете способ, как ускорить мой код на 7%, я всегда буду его применять.

7% прибавки в результате распараллеливания это определённо то, к чему стоит стремиться

Ничего себе у тебя хотелки. 7% это довольно много.

Что значит много? Если речь про «сэкономим 7% на цене вычислительного кластера» то наверно это существенно, но в техническом плане это по-моему какая-то ерунда.

Делал бенчмарки разных алгоритмов на своём ноуте: подсчёт длины строки с sse2 получается на 60% быстрее просто оптимизированного читающего по 32 бита, рандом-генератор chacha20 - на 32%, блочный шифр кузнечик - в 3-4 раза если на си, примерно в 2 если на асме (sse2 вариант совпал у обоих по времени).

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