Почему у меня AMD Ryzen 3970 в 2-3 раза медленее Core i9 10850K?

Question

[thecove]

Такая ситуация странная. Купили для работы AMD Ryzen 3970. Предполагалось на нем многопоточно считать наши мат. задачи.
До этого использовали Core i9 10850K ( 10 ядер + 10 Hyper-threading ).
По итогу имею вот такую некрасивую картинку....
40 миллионов наших мат итераций ( мат операции не содержат операций с плавающей запятой вообще, только сложение, вычитание, умножение и сдвиг )
- на Intel при использовании 20 потоков занимает 20,5 секунд
- на Amd при использовании 64 потоков занимает 37,0 секунд
При этом в мониторе ресурсов видно что все ядра Intel загружены на 100% а AMD на 35-45%

установка приоритетов при создании потока никакого эффекта не имеет:

threads[ core  ] = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)testMathThread, params, 0, NULL);
 ::SetThreadPriority( threads[ core ], THREAD_PRIORITY_HIGHEST);
 ::SetThreadAffinityMask( threads[ core ], 1 << core );

Глобальных переменных нет. У каждого потока свой собственный объект в памяти куда они заносят свои результаты.
Если делать расчет на одном ядре то результат такой: 4 миллиона итераций Intel 7.7 сек. AMD 9.25 сек

Включение / выключение в BIOS SMT у AMD практически ничего не меняет.
Переключение в Windows профиля питания со схемы AMD Rizen Balanced на схему "Максимальная производительность" то время обработки увеличивается на 10-12% до 45с.

Такое ощущение что у АМД где то предохранитель стоит который не позволяет ядро загрузить на 100%.
40-50% и всё

Последняя надежда разобраться что блин происходит на сообщество. А то уже руки тянутся обратно в магазин сдать.

PS да, оперативная память идентичная на обоих машинах DDR4 3200 по 32 гига на каждой. Но матан память мало есть.

Answer 1

[thecove]

Update Вопрос решен!
С проблемой за 12 часов секаса удалось разобраться.
В проекте использовалась самописная либа для ГСЧ на базе mt19937 и человек писавший ее лет 5 назад сделал ее потокобезопасной. Понапихав во все вызовы
std::lock_guard guard(mMutex);

Не знаю почему AMD на этих вызовах "отдыхал" дольше чем Intel но факт остается фактом. В два раза больше проц от красных терял времени чем синие. В итоге у синих 100% загрузка проца а у красных около 50.
Как временное решение ( пока старую либу не переписали ) я в каждый поток добавил свой собственный класс Random на базе стандартного rand() / srand() из C++
__declspec(thread) Random* random= nullptr;
это решение на коленке. Но главное причина найдена и точность рассчетов не пострадала

class Random
{
public:
Random()
{
 _rand_state = 0;
}
void srand(unsigned int const seed)
{
    _rand_state = seed;
}
uint16_t rand()
{
    _rand_state = _rand_state * 214013 + 2531011;
    return (_rand_state >> 16) & RAND_MAX;
}
private:
uint32_t _rand_state; 
}

в итоге результат.
Вот было:

4 млн. итераций AMD 32 потока = 4,05 сек. Загрузка CPU 45%
4 млн. итераций AMD 64 потока = 3,61 сек. Загрузка CPU 47%
4 млн. итераций Intel 10 потоков = 4,01 сек. Загрузка CPU 75%
4 млн. итераций Intel 20 потока = 2,61 сек. Загрузка CPU 100%

после исправлений стало:

4 млн. итераций AMD 32 потока = 1,25 сек. Загрузка CPU 60% ( 1 поток на физическое ядро )
4 млн. итераций AMD 64 потока = 0,71 сек. Загрузка CPU 100% ( 1 поток на физическое ядро + HP )
4 млн. итераций Intel 10 потоков = 2,8 сек. Загрузка CPU 70% ( 1 поток на физическое ядро )
4 млн. итераций Intel 20 потока = 2,1 сек. Загрузка CPU 100% ( 1 поток на физическое ядро + HP )

Как видно из нового теста AMD как и предсказывали все известные бенчмарки примерно в 3 раза производительнее чем Intel при полном использовании всех ядер.
Тесты при загрузке на одно ядро у меня показывали что Intel на 15-20 процентов шустрее чем AMD

Answer 2

[Рональд Макдональд]

- на Intel при использовании 20 потоков занимает 20,5 секунд
- на Amd при использовании 64 потоков занимает 37,0 секунд

Сделайте количество потоков равным количеству потоков процессора. У вас производительность уходит на переключение контекста ядер с потока на поток.

Comments

[Drno]

+1
Я бы еще удалил AMD Rizen Balanced, и отдал производительность на откуп винды

[thecove]

Сделайте количество потоков равным количеству потоков процессора. У вас производительность уходит на переключение контекста ядер с потока на поток.

ну так у интела 10 ядер + HT = 20 потоков а у AMD 32 ядра + 32HP = 64 потока.
Но я пробовал на 10 потоках для интела и на 32 для AMD - AMD все так же проигрывает. в 2 раза почти

[Рональд Макдональд]

thecove, значит, вы что-то делаете не так.

[thecove]

Drno,

Я бы еще удалил AMD Rizen Balanced, и отдал производительность на откуп винды

Ну так если я профиль питания переключаю в винде разве это не то же самое?
именно физическое удаление надо? Просто он с драйверами AMD интегрирован

[thecove]

Рональд Макдональд,

значит, вы что-то делаете не так.

вот еще понять бы что..
4 млн. итераций AMD 32 потока = 4,05 сек. Загрузка CPU 45%
4 млн. итераций AMD 64 потока = 3,61 сек. Загрузка CPU 47%
4 млн. итераций Intel 10 потоков = 4,01 сек. Загрузка CPU 75%
4 млн. итераций Intel 20 потока = 2,61 сек. Загрузка CPU 100%

[Drno]

thecove, так никто не мешает не использовать настройки энергосбережения от амд и эту приблуду
достаточно же просто по отдельности драйвера поставить, без этой проги AMD. да и драйверов то там... 3 штуки вроде

Есть мнение что программа просто не может работать с таким кол потоков. может попробовать 2 просчета одновременно запустить?

[Tony]

А вы точно создаёте 64 потока? Такое чувство что только 32.

[thecove]

Tony,

А вы точно создаёте 64 потока? Такое чувство что только 32.

Абсолютно точно. Более того между 32 и 64 есть заметная разница на 40 миллионах расчетов.
ну и сложно ошибиться если в цикле:
Я даже убрал функцию вызова кол-ва ядер. вручную прописываю для тестов. так что 100% 32 и 64 потока в тестах создавалось

int processors= 32; //getNumberOfProcessors();
for (int core = 0; core < processors; core++)
{
	threads[i] = CreateThread( 0, 0, (LPTHREAD_START_ROUTINE)testMathThread, params, 0, NULL);					
	//::SetThreadPriority(threads[i], THREAD_PRIORITY_HIGHEST);
	//::SetThreadAffinityMask(threads[i], 1 << i  );
}

[thecove]

Drno,

Есть мнение что программа просто не может работать с таким кол потоков. может попробовать 2 просчета одновременно запустить?

А что ей может мешать? Вы полагаете что планировщик windows в случае с AMD тупит и не вешает по одному потоку на каждое ядро? А в случае с Intel планировщик не тупит и аккуратно выделяет по ядру на поток. ?
Вызов по идее ::SetThreadAffinityMask указывает планировщику на каком физическом ядре выполнять этот поток. Но я разницы не вижу никакой. Есть вызов или нет вызова.

PS в менеджере задач и в мониторе ресурсов видно что AMD задействует все логические ядра, все 64. Но нагрузка на них ниже всегда 50%. Я не понимаю почему.
такое ощущение что у CPU стоит ограничение на мощность.

[hint000]

thecove, случайно вы не использовали для своих задач компилятор Intel?
Потому что если использовали, то у меня для вас плохие новости (ну как "новости"... AMD уже лет 15 как говорит о нечестной игре Intel'а).
https://www.servethehome.com/intel-performance-str...
Unfortunately, software compiled with the Intel compiler or the Intel function libraries has inferior performance on AMD and VIA processors. The reason is that the compiler or library can make multiple versions of a piece of code, each optimized for a certain processor and instruction set, for example SSE2, SSE3, etc. The system includes a function that detects which type of CPU it is running on and chooses the optimal code path for that CPU. This is called a CPU dispatcher. However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string. If the vendor string says “GenuineIntel” then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version.

[thecove]

hint000,

случайно вы не использовали для своих задач компилятор Intel?

я использую Visual Studio 2019 там от M$ компилятор

[hint000]

thecove, там ещё упомянуты "or the Intel function libraries", что уже не так очевидно. Посмотрите, не использованы ли MKL (Math Kernel Library).

[thecove]

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