оценка качества ассемблерного кода

natastream

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

viktor-69

Какое отношение имеет "количество внутренних состояний процессора" к производительности?
Качество бенчмарка может характеризовать приближение к покрытию какого-то объема реальных задач. Совершенно неважно, какие состояния при этом может иметь процессор.

kiritsev

температура

natastream

Какое отношение имеет "количество внутренних состояний процессора" к производительности?
В данном случае тест производительности используется для выявления ошибок в процессоре. Соответственно, хочется иметь некую численную оценку "качества" такого тестирования для конкретного теста. Правильнее всего было бы дать эту оценку путем моделирования исполнения теста процессором и вычисления "покрытия возможных ситуаций" тестом. Однако, это ресурсоемкая задача. Поэтому хочется иметь способ эмпирической оценки "качества" теста по его ассемблерному коду.

kiritsev

Современный x86? Можешь забыть о покрытии состояний. Сотня лет уйдёт на анализ возможных комбинаций.
Даже у интел регулярно отдельные экземпляры весьма дорогих процессоров проходят все тесты но иногда ошибаются.
Разве что можно посчитать покрытие по инструкциям и например прогнать в эмуляторе и посчитать покрытие его кода.

natastream

Современный x86? Можешь забыть о покрытии состояний.
Нет, не x86. Речь идет о некоем гипотетическом процессоре.
Да, все состояния покрыть невозможно.
Но для практических нужд люди придумывают эмпирические метрики, оценивающие функциональное (или какое еще) покрытие ISA тестом.
Вот про эти метрики и хочется услышать. Типа, какая твоя любимая метрика и почему все остальные отстойные. Как-то так.

viktor-69

С практической стороны наблюдал использование проверок на верное выполнение операций. Затем просто большой массив задач с проверкой выхода. В результате все равно просачиваются ошибки.
Ассемблер вам даст набор кодировок инструкций, причем, он может быть и не упорядочен в случае "out of order" машины. Покрытие чего дальше считать? Состояний получаемых на каких-то задачах? Или покрытие всех состояний процессора (выглядит совсем печально)?

natastream

Покрытие чего дальше считать? Состояний получаемых на каких-то задачах? Или покрытие всех состояний процессора (выглядит совсем печально)?
Про покрытие состояний процессора я написал, т.к. это понятная метрика. Но посчитать ее невозможно.
Давайте говорить про "функциональное покрытие", что бы это ни значило =)
Так вот нужна эмпирическая метрика, которая решает такую задачу: есть два теста A и B, надо проанализировать их код и найти пересечение их покрытий и не совпадающие области покрытия. Этим областям надо сопоставить фрагменты ассемблерного кода этих тестов.
Такие метрики вобщем-то известны, но они не универсальны. Интересно было бы обсудить подходы к выбору/выдумыванию таких метрик.
Оставить комментарий
Имя или ник:
Комментарий: