Эквивалентное количество инструкций

У меня вопрос (как и я)...

но... если у меня есть выбранный алгоритм, написанный на C или С++ или любой другой код, который вы хотите... исправил компилятор, я могу определить количество инструкций, но эти наборы отличаются друг от друга: x ADD, y MUL, z MOV, f FADD, t FMUL (F означает FLOATING)... Существует ли методология или уравнение или что-то еще, что позволяет записывать количество инструкций в количестве "Эквивалентная инструкция" для сравнения другого алгоритма? Кто-нибудь из вас использует этот тип метрики? это мусор?

Спасибо

Marco

Ч .2: Я знаю, что он распространяется на uP и архитектуру в целом. Моя проблема: определить время выполнения различных алгоритмов, реализованных на разных архитектурах мягкого ядра. На оси Y я должен написать время, по оси x число команд и точка графика параметризуются типом архитектуры (извините за мой английский). Но на x-axix я думаю, что лучше использовать что-то вроде числа "эквивалентной инструкции"...

Это идея мусора?

Ответ 1

Вы не совсем понимаете проблему. Скорость выполнения зависит не только от инструкций, но и от зависимостей между командами. Микропроцессоры могут выполнять несколько инструкций одновременно, учитывая, что эти инструкции не зависят друг от друга. Возможность выполнять несколько команд одновременно отличается от одного семейства процессоров другим. Вот почему эта задача действительно специфична для аппаратного обеспечения, она не может быть решена раз и навсегда.

Все, что вы можете сделать, это график времени выполнения команд и циклов процессора. Циклы процессора могут быть осью y, инструкции могут быть осью x. У вас будут проблемы с предсказанием удалений и пропусков кеша, а время выполнения многих инструкций будет сильно различаться в зависимости от хитов/пропусков кеша. Будьте готовы потратить много времени на руководства по процессорам.

Ответ 2

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

Есть также вещи, которые алгоритм не сможет вам сказать, например, сколько промахов в кеше будет и т.д. - это может быть гораздо более важным, чем подсчет необработанных команд.

Ответ 3

Это не мусор, это просто расплывчато. Чтобы перейти от алгоритма к SOurce коду к объекту COde к ядру... так много деталей, чтобы пригвоздить, каждый из которых может иметь значительные последствия для производительности.

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