Бенчмарки вообще бесполезны. dhrystone является одним из самых старых, и, возможно, он имел немного большую ценность тогда, перед конвейерами и слишком большой оптимизацией компилятора. Я думаю, что 15 лет назад я сдался на dhrystone примерно примерно в то время, когда начал его использовать.
Это тривиально, чтобы продемонстрировать, что этот код
.globl ASMDELAY
ASMDELAY:
sub r0,r0,#1
bne ASMDELAY
bx lr
Что в первую очередь две инструкции, могут изменяться в широких пределах во время выполнения на одном чипе, если вы понимаете, как современные процессоры работают. Простой трюк, чтобы увидеть это, отключить кэши и prefetchers и т. Д., И поместить этот код со смещением 0x0000, вызвать его с некоторым значением. поместите его на 0x0004 повторите, затем на 0x0008, повторите. продолжайте делать это. Вы можете поместить один, два и т. Д. Между вычитанием и ветвью. попробуйте в разных смещениях.
ТОГДА, включите и кэш для каждого из этих выравниваний, если у вас есть предварительная выборка вне процессора для вспышки, включите и выключите это.
THEN, измените свои часы, esp для тех MCU, где вам нужно настроить состояния ожидания на основе тактовой частоты.
В ОДНОМУ MCU вы увидите, что по существу две команды меняются во время выполнения на очень большую сумму. Давайте просто скажем в 20 раз дольше в некоторых случаях, чем другие.
Теперь возьмите небольшую программу или небольшую часть программы dhrystone. Скомпилируйте, что для вашего mcu, сколько инструкций вы видите? Сделайте незначительные изменения в основной оптимизации и другие варианты командной строки компиляции, насколько изменяется код. Если две инструкции могут различаться, вы можете называть это 20 раз во время выполнения, насколько плохо он может получить 200 инструкций или 2000 инструкций? Это может стать довольно плохим.
Если вы возьмете программы dhrystone, которые у вас есть прямо сейчас, с параметрами компилятора, которые у вас есть прямо сейчас, зайдите в свой загрузочный лоток, добавьте один nop (чтобы все двоичные файлы сдвигались одной инструкцией во флэш-памяти) снова запускались. Добавьте два, три, четыре. Вы по-прежнему не сравниваете разные mcus, которые запускают ваш тест в одной системе.
Запуск с кешем d и без него с кешем i и без него, если у вас есть каждый из них. включите и выключите предварительную выборку флэш-памяти, если она у вас есть, и если у вас есть буфер записи, который вы можете включить и попробовать. Все еще остаются на одном и том же компиляторе такие же параметры, что и mcu.
Возьмите различные функции в исходном коде dhrystone и переустановите их в исходном коде. вместо Proc_1, Proc_2, Proc_3 сделать Proc_1, Proc_3, Proc_2. Повторите все вышеизложенное. Повторно договоритесь, повторите.
Перед тем, как покинуть этот mcu, вы должны увидеть, что время выполнения одного и того же исходного кода, которое полностью немодифицировано (кроме функций переустановки), может и будет иметь значительно разные времена выполнения.
Если вы затем начнете изменять параметры компилятора или сохраните один и тот же источник и смените компиляторы, вы увидите еще большую разницу во времени выполнения.
Как возможно, что тесты dhrystone сегодня или с обратной стороны имели единственный результат для каждой платформы? Простой, этот результат был только одним из широкого диапазона, не представляющим платформу.
Итак, если вы попытаетесь сравнить две разные аппаратные платформы, будь то одно и то же ключевое ядро внутри другого mcu от того же поставщика или разных поставщиков. ядро руки, предполагая (что не является безопасным предположением), является тем же источником с теми же параметрами компиляции/сборки, даже если предполагается, что был использован тот же компилятор и синтез verilog. вы можете иметь такое же основное изменение, основанное на опциях, предоставляемых руками. В любом случае, как поставщик будет одним и тем же поставщиком в двух экземплярах, или два разных производителя обернут это же ядро, вы увидите варианты. Тогда возьмите совершенно другое ядро, будь то другая рука или mips и т. Д. Как вы могли бы оценить какую-либо ценность, используя такую программу, которая сама по себе сильно варьируется на каждой платформе?
Вы не можете. То, что вы можете сделать, это использовать тесты, чтобы придать иллюзию одной вещи лучше, чем другой, один компьютер быстрее другого, один компилятор быстрее другого. Для продажи компьютеров или компиляторов. Спринты в пределах одного процента от Verizons ... это говорит нам что-нибудь полезное? Неа.
Если вы должны были исключить компилятор из уравнения, и если это действительно тот же «ЦП», тот же самый оборот источника из ARM, построенный таким же образом, тогда они должны получить то же самое, но размер кеш является частью этого, поэтому он может быть другой реализацией процессора, поскольку ширина или глубина кеша могут влиять на вещи. В программном обеспечении это похоже на 32-битный указатель, а не на 16-битный указатель (17 бит вместо 16, но вы не можете иметь 17 бит, как правило, в логике).
В любом случае, если вы скомпилируете код под тестом один раз для адресного пространства, которое является общим для обеих платформ, используйте тот же самый двоичный файл именно для этого пространства, можете при необходимости добавить другой код начальной загрузки, обратите внимание, что библиотека C вызывает strcpy, и т. д. также должны быть одинаковыми в одном и том же пространстве между платформами, чтобы исключить компилятор и выравнивание от взлома. это может или не может выравнивать игровое поле.
Если вы хотите верить, что это один и тот же процессор, тогда выключите кеши, устраните варианты компилятора, выполнив вышеуказанное. Посмотрите, выполняются ли они. Скопируйте программу в ram и запустите в ram, устраните проблемы со вспышкой. Я предполагаю, что у вас есть оба режима с одинаковыми состояниями ожидания во флэш-памяти?
Если они являются одним и тем же процессором, и поставщик чипов с этими двумя чипами сделал систему памяти одинаковым количеством часов, скажем, для доступа к штоку, и это действительно тот же самый процессор, вы должны иметь возможность получать одинаковые время, устраняя оптимизацию (кэширование, предварительная выборка флеш-памяти, выравнивание).
Что вы, вероятно, видите, это некоторая форма выравнивания с тем, как код лежит в памяти от строк компилятора и кеша, или это может быть намного проще, это могут быть просто различия в кэшах, как удары и промахи работа и 4 КБ - это больше повезло, чем 8 КБ для этой конкретной программы, составленной определенным образом, выровненной в памяти определенным образом и т. д.
С помощью простого двух цикла команд над ним легко увидеть некоторые причины, по которым производительность зависит от одной и той же системы, если ваш современный процессор получает по 8 инструкций за раз, и ваш цикл слишком близко приближается к хвосту этой выборки, предвыборка может подумать, что ему нужно получить еще один 8 за пределами того, что стоило бы вам этих тактовых циклов. Конечно, поскольку вы точно оседлаете две строки «выборки», как я их называю этими двумя инструкциями, это будет стоить вам намного больше циклов за цикл даже с кешем.Такая же проблема возникает, когда эти две инструкции приближаются к строке кэша (по мере изменения их выравнивания на каждый тест), в конце концов, для получения двух инструкций требуется два чтения строки кэша вместо одного. По крайней мере, в первый раз, если есть дополнительная строка кеширования. Дополнительные часы для этого первого раза - это то, что вы можете увидеть, используя простой эталон, как при игре с выравниванием.
Michael Abrash, Zen of Assembly Language. Существует epub/etc, который вы можете построить из github этой книги. 8088 был устаревшим, когда эта книга вышла, если это все, что вы видите в материале 8088, тогда вам совершенно не хватает смысла. Это относится к самым современным процессорам сегодня, как просматривать проблему, как тестировать, как тестировать время, как интерпретировать результаты. Все, что я упомянул до сих пор, и все, что я знаю об этом, о котором я не упоминал, все исходило из тех книг, которые были применены в течение многих десятилетий, которые я делал.
Итак, если вы действительно устранили компилятор, выравнивание, процессор, систему памяти, привязанную к этому процессору, и т. Д., И это зависит только от размера кеша. Тогда это, вероятно, связано с тем, как линия кэша извлекает и пропускает по-разному на основе выравнивания кода относительно строк кэша для двух кешей. Один из них бьет больше и пропускает меньше и/или выселяет лучше для этого конкретного двоичного файла. Вы можете попробовать переупорядочить функции, добавить nops или если вы не можете получить загрузку, тогда добавьте целые функции или еще один код (другой printf и т. Д.) По более низкому адресу в двоичном файле, что приведет к тому, что компоновщик сдвинет тестируемый код до разные адреса изменяют, как программа выстраивается в линию с линиями кеша. Поскольку функции в тестируемом коде настолько велики (более нескольких инструкций для реализации), вам нужно будет начать изменять программу, чтобы получить более тонкую настройку двоичного кода относительно строк кэша.
Вы, безусловно, должны увидеть разницу во времени выполнения на двух платформах, если вы настроите выравнивание и опционально переустановите двоичный файл на основе перегруппировки функций.
Нижние эталонные тесты действительно не говорят вам, результаты имеют более негативную вонь для них, чем положительную радость. Без повторной записи конкретный тест или приложение могут быть лучше на одной платформе (будь то все одинаково, но размер кеша или две совершенно разные архитектуры), даже если вы пытаетесь изменить результаты из-за выравнивания, включив и от предварительной выборки, буферизации записи, предсказания ветвей и т. д. Вытягивание всех трюков, которые вы можете придумать, может варьироваться от x до y другого от n до m и, возможно, существует некоторое перекрытие в диапазонах. Для этих двух платформ, которые, как вы говорите, являются похожими, кроме размера кеша, я надеюсь, вы найдете комбинацию, где иногда А быстрее, чем B, и по крайней мере одна комбинация, где B быстрее, чем A, с теми же функциями, которые включены и выключены для обоих в этом сравнении. Если/когда вы переключаетесь на какое-либо другое приложение/контрольное значение, все начинается снова, без причины предположить, что результаты dhrystone предсказывают любой другой тестируемый код. Единственная программа, которая имеет значение, особенно на MCU, - это окончательная сборка вашего приложения. Просто запомните изменение одной строки кода или даже добавление единственного nop в bootstrap может иметь резкие результаты в производительности, иногда несколько TIMES медленнее или быстрее с одного nop.