Нет выгоды от нескольких потоков на процессоре AMD?

Question

Итак, я только что получил новый 16-ядерный сервер с процессорами AMD 6212.У меня есть код, который я запускаю на различных процессорах Intel.Он использует заблокированные очереди для распределения работы в pthreads, которые затем записывают работу обратно в общую память с блокировками на записи.Я в основном связан с вычислениями.

На процессорах Intel, когда я увеличиваю количество потоков, моя производительность немедленно увеличивается.Переход от 1 до 2 потоков почти удваивает производительность.

При одинаковом коде на процессорах AMD я не получаю никакого выигрыша (небольшое замедление) даже с 4 потоками.Но когда я использую 128 потоков, я вижу ускорение в 6 раз.

Кто-нибудь имеет представление, что это может произойти?

Что касается спецификаций ОС, если я наберу:

cat /proc/version

Я получаю:

Linux version 2.6.32-5-amd64 (Debian 2.6.32-39) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Thu Nov 3 03:41:26 UTC 2011

Answer 1

Мое первое предположение состоит в том, что планировщик Linux не поместил ваши потоки в отдельные ядра.

Планировщик Linux пытается очень усердно сохранить задачи на процессоре, который они использовали в последний раз, чтобы кэш-память имела наилучшие шансы для хранения соответствующих и полезных данных или инструкций. Я обнаружил, что на самом деле это не перебалансирует. (Я знаю, я даже видел код, который утверждает, что выполняет перебалансировку, но я заметил рабочие нагрузки с интенсивным использованием ЦП, все выполнявшиеся ранее на одном и том же уровне, не переходя на другое ядро.)

Использует ли ваш код механизм taskset(1), sched_setaffinity(2) или cpuset(7), чтобы вручную распространять задачи, требующие большого объема вычислений, на все процессоры? Если нет, я советую сначала попробовать taskset(1), чтобы посмотреть, улучшится ли ваша пропускная способность, и включить вызовы sched_setaffinity(2) в вашу программу, если вы увидите ожидаемые улучшения.

Answer 2

Итак, это еще не решено на 100%, но похоже, что проблема была связана с доступом к памяти.Код не имеет динамического выделения памяти в течение большей части запуска, но потоки выделяли около 100 маленьких кусочков памяти в куче при запуске.В небольших типовых версиях программы мне удалось устранить узкие места, выделив память для каждого потока в стеке, а не кучи.

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