Приложения работают медленнее с несколькими потоками
У меня 40-ядерный сервер под управлением Ubuntu 14.04 LTS. Я использую приложение с возможностью многопоточности. Я обнаружил, что запуск приложения с увеличением числа потоков улучшает время выполнения, пока я не переберу определенное число, и в этот момент время выполнения снова начнет увеличиваться. Этот номер потока намного ниже количества ядер, которые у меня есть. Вот несколько примеров (это «реальные» времена):
8 threads: 1m45.992s
16 threads: 1m7.494s
24 threads: 1m45.174s
32 threads: 3m10.819s
40 threads: 6m12.194s
80 threads: 25m22.937s
У меня не хватает памяти (используется только 4 ГБ из 128 ГБ), и не используется подкачка. Во время этих тестов другие процессы со значительной загрузкой ЦП не выполняются.
Интересно, что когда я запускаю версию того же приложения, скомпилированного из того же источника в OS X, с теми же данными на моем PowerMac с 8 ядрами, я получаю стабильное улучшение времени выполнения до 16 потоков с незначительными ( несколько секунд) замедление в 32 и 64 потоках, поэтому я не думаю, что это проблема с прикладным программным обеспечением. Действительно, когда я использую другое приложение с поддержкой многопоточности с аналогичной функцией, что и первая, на сервере Ubuntu, я вижу похожие, хотя и не столь впечатляющие результаты:
16 threads: 4m4.795s
40 threads: 2m31.430s
60 threads: 3m7.007s
80 threads: 5m6.946s
Мне обычно приходится проводить эти анализы последовательно на сотнях наборов данных, поэтому любой выигрыш в эффективности может иметь большое значение. Мой вопрос заключается в том, может ли это быть связано с проблемой конфигурации системного программного обеспечения по сравнению с проблемой с моим оборудованием. Будем весьма благодарны за любые мысли о том, с чего начать искать решение этой проблемы и получить максимальную выгоду от всех моих процессоров.
Спасибо.
1 ответ
Вы, вероятно, поражаете состязательные точки в коде, такие как блокировка (через futexes и т.п.), где сериализация кода происходит и следовательно останавливает масштабирование производительности.
кроме того, x86 ЦП может иметь ядра N, каждый с говорит, что 2 потока, которые каждый, но который не дает Вам производительность 2 x Н, начиная с гиперпотока, выполняет, когда определенные блоки выполнения доступны. Я верю для снабженного сокетом x86 процессора сингла, можно добраться до 30%-й дополнительной производительности с гиперпотоком.
кроме того, можно получать конкуренцию на памяти, быть этим в кэше (L1, L2 или L3) или даже на самой памяти. Таким образом, можно поражать ограничения на пропускную способность, остановы кэша или на TLB.
С процессом N> N центральные процессоры, Вы закончите с большим количеством процессов, чем может быть выполнимым, таким образом, планировщик должен выполнить больше работы в предвосхищении выполнимых процессов, и это - другой штраф, который разъедает производительность.
можно получить инструменты использования метрик производительности низкого уровня, такие как перфект. Установите его с:
sudo apt-get install linux-tools
И выполненный Вы приложение с перфектом для получения некоторых измерений производительности:
perf stat your-program
можно сделать, более глубокий анализ с помощью записи перфекта и отчета о перфекте, например,
sudo perf record your-program
sudo perf report
, С другой стороны, запускает программу и в то время как это выполняет вершину перфекта использования для получения интерактивного оперативного представления системного действия:
sudo perf top
, Надо надеяться, который даст Вам некоторое представление о том, где горлышко бутылки происходит.