Комментарии 9
Спасибо за перевод.
В разделе «Больше вычислений» код и таблица ошибочно продублированы из раздела «Простое преобразование», в оригинале они, разумеется, другие.
В разделе «Больше вычислений» код и таблица ошибочно продублированы из раздела «Простое преобразование», в оригинале они, разумеется, другие.
+1
Подскажу ещё одну интересную тему для тестирования. Вопрос, который не охвачен статьёй. Параллельное исполнение распараллеленных программ. Если в системе большую часть процессора берёт на себя одна высоконагруженная программа, то будет выигрыш, но если таких программ будет много, то производительность может, в зависимости от роста их количества и от количества ядер, сравняться с последовательным исполнением, а затем стать медленнее его. Но это теоретически.
0
В Linux уж точно, но наверняка и в Windows есть механизм эксклюзивного выделения ядер для процесса. Думаю для числодробилок, работающих в потоке это может быть хорошим подспорьем.
Я пользовался таким биндингом и видел прирост для задач шифрования и сжатия, поэтому думаю ваше теоретическое предположение более чем реально.
0
Спасибо за интересную статью! Только вот таблицы ну очень не наглядные — что в оригинале, что у вас. Совершенно не видно того, что все они, по сути, разбиваются на три области (по кол-ву элементов). Как варианты: 1) отделить в каждой таблице жирной горизонтальной линией по три строки (с одинаковым кол-вом элементов); 2) разделить их цветом фона (первые три строки белый фон, дальше три светло-серый, потом опять три белых). Мне кажется, так результаты бенчмарков станут ещё наглядней.
0
А почему OpenMP может себя так плохо показывать в случае с тригонометрическими функциями?
0
У насколько GLM круче от математической библиотеки от nVidia?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Удивительная производительность параллельных алгоритмов C++17. Миф или Реальность?