Ну вот, готовы результаты целочисленного теста после исправления досадной, грубой ошибки, допущенной мною по невнимательности. Зато добавился новый участник теста: уже немного старенький, но десктопный Intel i5-6500.
Напомню, что тест основан на вычислении обратного элемента в кольце вычетов по модулю N. И фактически тестирует регистровые целочисленные 64-битные операции в двух вариантах: с использованием операции деления или на основе операций сложения и сдвига.
Запустил сначала однопоточный тест на своем AMD FX-4350, получил результаты и подумал, что, наверное, делать многопоточный тест смысле нет: все же чистая синтетика, 100% регистровых операций, ни одного обращения к памяти... Но потом вспомнил про HyperThreading, CMT, SMT и вот это вот всё. Поэтому все же прогнал многопоточный тест ради интереса.
В качестве базы я, как обычно взял свой AMD FX-4350, поэтому его производительность везде принята за единицу. Производительность сложения и сдвига я считаю в 1.5 раза более ценной, чем операции деления (так как встречаются в коде они гораздо чаще), как и производительность однопоточного выполнения. Сначала интегральная производительность.
Как видно из графика, что-то производительность регистровых целочисленных операций у процессоров Intel особо не задалась. Лишь относительно новый i5-8300H в интегральной производительности слегка обгоняет мой старенький FX-4350.
Недавно читал, что за последние лет пять производительность процессоров выросла примерно вдвое. Ну, почти так и есть. Ryzen 5 3600 в 1.82 раза быстрее моего процессора. Но надо заметить, что в основном ускорение пошло экстенсивным путем ‒ за счет увеличения количества ядер, в то время как однопоточная производительность увеличилась всего лишь на жалкие 16%.
Несколько удивляет крайне низкий результат i5-6500, который лишь чуть-чуть быстрее весьма древнего мобильного AMD A10-4600M. Впрочем, тест проводил не я лично, возможно, тестирование было выполнено не совсем аккуратно.
Как можно видеть, в целочисленных регистровых операциях даже относительно новые, хоть и мобильные процессоры Intel с трудом тягаются со стареньким десктопным AMD. Ну а относительно новый Ryzen 5 просто закрепляет победу.
Так что, похоже, и в самом деле архитектура Ryzen очень хороша. Хоть она, похоже, чуть-чуть хуже в операциях с плавающей точкой, но опережает в целочисленных, что для большинства приложений важнее. За исключением, может быть, трехмерных игр и приложений ИИ.
Посмотрим более детально.
Вариант с использованием операции деления.
Если в функции встречается всего лишь одна операция деления, то тут даже старенький процессор от AMD рвет как Тузик грелку все процессоры от Intel, участвовавшие в тестировании. А Ryzen еще немножко добавляет.
Бинарный вариант на сложениях и сдвигах.
Тут Intel в последних поколениях мобильных процессоров в однопотоке немного обогнала PileDriver, но Ryzen 3000 это компенсировал и на обычных целочисленных регистровых операциях AMD и Intel сейчас на равных, но за счет большего количества ядер в общем зачете все же AMD впереди. Из любопытного: все процессоры, за исключением двух, показывают большее ускорение при параллельном выполнении функции на основе деления, что в общем-то понятно при использовании технологии HyperThreading: пока одно виртуальное ядро выполняет длинную операцию деления, другое ядро может вовсю пользоваться остальной частью физического АЛУ. Аномальное поведение замечено лишь у Ryzen 5 3600 и i5-6500. Не могу даже предположить, с чем это может быть связано.
Ну и напоследок табличка с абсолютной производительностью процессоров (кол-во вычисленных обратных элементов в секунду):
Строки с префиксом P ‒ многопоточные данные.
Ну вот, это уже похоже на правду :)
ОтветитьУдалить> пока одно виртуальное ядро выполняет длинную операцию деления, другое ядро может вовсю пользоваться остальной частью физического АЛУ
По моим расчетам даже при одном потоке процессор выполняет деление параллельно остальным операциям за счет суперскалярности. Почему же тогда на Intel Hyper-Threading дает дополнительный прирост, а на AMD нет? Как я понимаю это следствие более быстрого деления реализованного в железе:
- AMD: пока деление выполняется на ALU, 2-е не может начаться, так как деление - узкое место Hyper-Threading не дает никакого прироста.
- Intel: деление в микрокоде, по сути процессор выполняет ворох более простых инструкций на разных блоках ALU и Hyper-Threading позволяет выполнять если не 2, то где-то 1.5 деления параллельно.
Бинарный же вариант целиком состоит из простых операций цепляющихся друг за друга, как результат Hyper-Threading работает как на Intel так и на AMD.
> i5-6500
Вроде только чуть-чуть ниже чем должно быть: в однопоточном режиме цифры должны быть близкие к i7-6700 так как максимальная частота у них почти одинаковая, а в многопоточном режиме результат заметно хуже, так как у него нет Hyper-Threading.
> однопоточная производительность увеличилась всего лишь на жалкие 16%
Это да, интенсивное развитие - это всегда сложнее :) Судя по тестам Apple M1 у ARM с архитектурой все получше. Поживем, увидим к чему это приведет.
>Почему же тогда на Intel Hyper-Threading дает дополнительный прирост, а на AMD нет?
УдалитьНа AMD тоже дает, но небольшой. 6.3 при 6 ядрах, в то время как Intel 6.2-6.8 при четырех.
> Как я понимаю это следствие более быстрого деления реализованного в железе:
Видимо, да. Цикл очень короткий, поэтому набрать простых операций для второго потока негде. Это объясняет и то, почему так же ведет себя i5-6500.
Правда, всё это вызывает второй вопрос: почему тогда реализация функции на более простых командах на Intel дает худшее ускорение, чем деление?
Вариант с делением ускоряется на Intel в 6.2-6.8 раза, а вот бинарный вариант всего лишь в 4.8-5.1. В то время как на Ryzen деление - 6.3, а бинарный - 9.6. Непонятно...
Сейчас посмотрел на абсолютные цифры по i5-6500. И в самом деле, он лишь чуть-чуть медленнее в однопотоке, чем i7-6700HQ, а вот базовая частота у него в 1.23 раза выше, правда пиковая почти одинаковая. Поколение у них тоже одинаковое, так что немного странно. Всегда думал, что десктоп должен быть чуть быстрее мобильных.
> Судя по тестам Apple M1 у ARM с архитектурой все получше.
Мне тоже очень интересно, как Apple могла уделать x64. Вроде там все уже должно быть заоптимизировано до предела в физической реализации за столько лет. Возникает шальная мысль, что переоптимизировали. )
Впрочем, детальных тестов я пока не видел, не понятно, в каких конкретно тестах M1 опережает. Может, только в ИИ. )
> На AMD тоже дает, но небольшой. 6.3 при 6 ядрах
УдалитьСогласен, но это так совсем чуть-чуть.
> почему тогда реализация функции на более простых командах на Intel дает худшее ускорение, чем деление?
Не уверен, но судя по тому что нашел, у Intel ALU блоки более специализированы, скажем SAR может выполняться только на блоках p0 и p6, а скажем JMP только на p6. В итоге скорее всего при бинарном один из блоков уже узкое место и добавление 2-го потока практически не ускоряет. У Zen-2 же: "All ALUs are capable of all integer operations except multiplies, divides, and CRC which are dedicated to one ALU each." Как результат HT дает существенно больший прирост для бинарного алгоритма.
> а вот базовая частота у него в 1.23 раза выше
Ага, но как я понимаю, у современных процессоров, базовая частота - это очень условный параметр, это частота при которой какой-то тест Intel/AMD приводит к заданному тепловыделению. На деле же частота зависит от загруженности блоков, используемой системы охлаждения и банально температуре воздуха. Mobile vs Desktop я почему-то считал, что это больше про физические размеры и на сколько процессор рассчитан на работу в жарких условиях, но я не уверен в этом.
> как Apple могла уделать x64. Вроде там все уже должно быть заоптимизировано до предела в физической реализации за столько лет.
У x86 есть известная проблема в архитектуре: из-за не фиксированного размера инструкций, декодер команд - это сложный монстр, что у Intel что у AMD он способен декодировать до 4-х инструкций за такт, фактически перебирая все возможные варианты параллельно и отбрасывая невозможные, увеличить его скорость еще, вроде как не реально/очень сложно, а значит нет смысла добавлять больше ALU и FPU блоков в ядро, так как декодер не будет успевать помещать декодированные инструкции в очередь. Остается только расти в ширь и добавлять новые ядра.
У ARM размер инструкций фиксированный, как результат, декодер в разы проще и легко масштабируется, а значит и число исполнительных блоков можно легко добавлять в ядро, процессор может далеко убегать вперед и выполнять множество независимых инструкций параллельно. В Apple M1 декодер уже декодирует 8 инструкций и это только начало. Правда интересно, на сколько часто инструкции на столько не зависимы... но наверное - это оправдано.
Amazon тоже стал выпускать свои ARM процессоры и вроде как в плане производительность/ватт они более оптимальны. Посмотрим к чему все это приведет :)
> как я понимаю, у современных процессоров, базовая частота - это очень условный параметр
УдалитьЯ почему-то всегда считал, что это обычная частота работы процессора, до тех пор, пока его (процессор) не ОС не переведет в режим пониженного энергопотребления. ОС переходит в режим пониженного э/п, когда понимает, что процессор ничем не загружен и может начать понемногу кроить эл. энергию. Вроде бы и Интел так пишет, но может ошибаюсь.
> Mobile vs Desktop я почему-то считал, что это больше про физические размеры и на сколько процессор
> рассчитан на работу в жарких условиях, но я не уверен в этом.
Мне казалось, что это как раз про пониженное энергопотребление. То есть у мобильный версий обычно занижают базовую частоту именно с этой целью и иногда делают меньше размер кэш-памяти, кол-во АЛУ и ядер по той же причине. А жаростойкость без изменения тех. процесса, кмк, не поменять.
По поводу декодера. Мне кажется, тут проблема не в том, что он будет очень сложный, а в том, что невозможно его загрузить. Большинство программ даже в 4 независимых инструкций не компилируются, даже со спекулятивным выполнением, так что какой смысл его делать больше?
Я с архитектурой ARM не знаком, но она вроде как рисковая. Соответственно, все команды (кроме загрузки/выгрузки) только регистровые. Поэтому то, что на x64 потребует одной команды, в ARM может скомпилироваться в три. Так что с одной стороны более мощный декодер ARM просто необходим, что бы хотя бы догнать x64. С другой стороны, более длинный конвейер приводит к потерям производительности при промахе предсказания перехода. Опять же 32 регистра замедляют переключение задач.
В общем, эта очень интересная битва будет: ARM vs X64.
Я вот удивляюсь, почему никто не сделал вместо предсказателя переходов несколько конвейеров? В месте ветвления команды из каждой ветке ложатся в свой конвейер, после вычисления перехода один из конвейеров сбрасывается, а второй сцепляется с теущим и после небольшой паузы на сцепку/переключение шпарит дальше.
> Я почему-то всегда считал, что это обычная частота работы процессора
УдалитьЯ тоже так думал, до тестирования алгоритмов с Вами, а теперь не уверен что обычная частота существует в современных CPU. Ни на макбуке, ни на игровом десктопе сына (windows 10) я не смог ее увидеть. Когда запускаю тест процессор работает на максимальной, ноут иногда снижать частоту на 100-200МГц, видимо перегревается, но это все еще не базовая частота, а как только активность пропадает, что OSX, что Windows (или сам процессор?) через несколько секунд уменьшают частоту до смешных 1.2-1.5 ГГц.
> Мне казалось, что это как раз про пониженное энергопотребление.
Да, согласен, про жаростойкость я какую-то чушь смолол :)
> Большинство программ даже в 4 независимых инструкций не компилируются
Вроде практически везде где упирается в процессор, это числомолотилки по массивам данных, а там независимых инструкций хоть отбавляй.
> Поэтому то, что на x64 потребует одной команды, в ARM может скомпилироваться в три.
В теории да, но на практики современные компиляторы очень активно используют регистры, поэтому вроде как сложные команды никому особо и не нужны, лучше занять это место на кристалле чем-то более полезным.
> В общем, эта очень интересная битва будет: ARM vs X64.
Это точно!
> Я вот удивляюсь, почему никто не сделал вместо предсказателя переходов несколько конвейеров?
Интересная идея, IBM вроде пробовала, но не взлетело: https://stackoverflow.com/questions/49622002/why-not-just-predict-both-branches