Из-за чего программа C++ на amd работает быстрее чем на intel?

Question

[Ilia Tereshenko]

У меня есть программа, которая реализует блочный метод гаусса с выбором главного элемента по столбцу. Проблема заключается в том что, есть две версии этой программы. Цель написания второй версии была ускорение работы программы. Я провел тестирование на своем пк получил прирост скорости порядка 0.6 от времени работы старой программы. После чего протестировал на других конфигурациях и там моя программа замедлилась.
В моем пк стоит AMD Ryzen 5 5600. Замедление происходит на процессорах intel, а также в качестве эксперимента проводил замеры на архитектуре ARM: m1, m2 pro(на них аналогичное замедление на 20%). Получается так что прирост скорости происходит только на AMD процессоре, что я не могу себе объяснить. Важная оговорка в коде программы не используется специфики процессоров amd. Ускорение работы программы заключалось исключительно в оптимизации матричного умножения( изменил итерацию так, что бы максимально двигаться по кешу), а также в уменьшенении кол-ва шагов метода. С чем может быть связанно это?
P.S. Программа однопоточная

Comments

[rPman]

Что за процессор Интел? Каков у него размер Кеша?

У указанного Ryzen кеш большой, аналогичные по цене железки Интел обычно хуже.

Можешь поделиться кодом до и после?

[Dark Hacker]

Потому что амд рулит)

Answer 1

[Zerg89]

Есть два варианта, то что вы не использовали в коде не значит что компилятор не использовал оптимизацию под платформу по которую был собран код, для чистоты эксперимента пробуйте пересобрать проект с процом под которым будете тестировать
Второй вариант до банального простой, частота процессора в однопотоке при турбо-бусте процы амд в большинстве случев имеют большую частоту на ядро
Ps и ещё одно вспомнить о p и e ядрах в интелле да и арм(м1,м2) тоже вроде гибриды с разными ядрами в проце

Answer 2

[VoidVolker]

Из-за того, что процессоры от разных производителей обладают разной производительностью, внезапно, из-за отличий в архитектуре, командах, транзисторах, частотах, кэшах и во всём остальном. Сюрприз! А еще есть такие факторы как: кэши, оперативная память, дисковая подсистема, запущенные приложения, сервисы, разные ОС, разные чипсеты, разные биосы, да даже вентилятор на процессоре может влиять на производительность, из-за которого турбобуст какой-нибудь включится или выключится, и еще целый вагон других факторов.

Comments

[Ilia Tereshenko]

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

[VoidVolker]

что не зависимо от архитектуры должно ускорить работу программы

"Какие ваши доказательства?" Как видно в вашем случае на практике происходит как раз наоборот.

[Ilia Tereshenko]

Речь идет про абсолютное значение времени.

[Ilia Tereshenko]

VoidVolker, Я бы хотел узнать более глубинное объяснение причин происходящего, так как теоритические знания говорят о том, что ускорение должно быть.

[VoidVolker]

Ilia Tereshenko, в этом случае алгоритм примерно следующий: профилируете весь свой код на разных процессорах, смотрите какие функции отличаются по времени выполнения относительно какой-то отдельной стабильной функции-бенчмарка. Далее делаете профилирование и исследование этих конкретных функций с целью выяснить, что именно приводит к этой разнице. Можно даже заглянуть в ассемблерный код - может там оптимизатор чего накрутил. Опять же, если код кроссплатформенный - надо проверять тогда и в разных ОС. Вообще, имеет смысл сделать профилирование и для разных версий винды. Может у вас там системный вызов какой-то тормозит?

Answer 3

[Gaguzavr]

На процессорах архитектуры х86 разница производительности существует из-за разных реализаций микроархитектуры процессора и различных тех.процессов. Это, при прочих равных, единственное и основное, что влияет на скорость выполнения программы, в общем виде.
В частности, процессоры могут отличаться:

• тактовой частотой;
  
• объемом кэш-памяти;
  
• уровнями кэш-памяти;
  
• реализацией части обеспечивающий out-of-order execution;
  
• количеством исполнительных модулей ядра (умножители, сумматоры, делители, сдвиги и т.д. и т.п.);
  
• реализацией протокола поддержания когерентности кэш-памяти с оперативной памятью;
  
• реализацией части ответственной за разбор команд х86 на микрооперации;
  
• различными свойствами элементной базы.
  

Все это влияет на скорость выполнения программы.
При прочих равных, разница в тактовой частоте пропорциональна скорости выполнения программы.
При прочих равных, разница в объеме кэш-памяти на одном уровне может спровоцировать обращение к кэш-памяти вышестоящего уровня или к оперативной памяти - что добавляет временную задержку к работе.
При прочих равных, отсутствие уровня кэш-памяти (например, нет L3 cache) влечет обращение к памяти вверх по иерархии - что добавляет временную задержку к работе (обращение в ОЗУ дольше, чем в L3 cache).
При прочих равных, out-of-order execution - скрытая от программиста часть процессора, реализуемая в различных вариантах, влияет непосредственно на поток выполнения микроопераций, что дает разницу во времени исполнения программы.
При прочих равных, количества исполнительных модулей в ядре может не хватать для более быстрых вычислений.
Также, вы можете использовать процессоры, работающие с разными поколениями оперативной памяти, с разным бустом частоты и т.д.
И это только процессор.

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

Корректное сравнение производительности возможно только при соблюдение одинаковых параметр вычислительной системы.

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