время выполнения ассемблерной команды

Здравствуйте, форумцы!
Дистрибутив MASM'а включает в себя неплохой хелп по асмовым опкодам и в этом хелпе есть также информация о том, сколько тактов затрачивается на выполнение той или иной команды на процессорах Intel (8086,386,486).


Внимание, вопрос...
Где бы найти подобную информацию (по количеству тактов), но для команд процессоров вплоть до Pentium4? В интеловской документации этого, к сожалению, нету; там только описание инструкций...
У Агнера Фога все как-то размыто...да и далеко не исчерпывающе.

 

Воспользоваться поиском по wasm, в поле "Поиск автора" внеси leo

 

Куда делось то? ))

 

Medstrax, смотрел вот тут:
http://www.intel.com/products/processor/manuals/index.htm

ближайшее к теме - описание инструкций, но времени выполнения нету нигде.

 

Глянь Intel® 64 and IA-32 Architectures Optimization Reference Manual

 

babandr

Значительно более "исчерпывающе", чем в интеловском мануле. Из официальных мануалов только у АМД приведены латентности всех команд (да еще и их разновидностей), а у Интел - только выборочно и только для регистровых операций

 

Medstrax, спасибо большое...не досмотрел я до конца этот документ...виноват.

 

расстрэлять!

 

Забей на такты.
Круто конечно хвалиться что у тебя прога на 3 такта быстрее пашет после оптимизации
Однако, когда говрят про оптимизацию, часто забывают про очередь предвыборки команд, переименование регистров и т.д.
А сие не маловажно.
Как показывает практика овчинка выделки не стоит. Самому в общем плане понимать как работает - надо, но использовать во всей красе...
Основные усилия надо прилагать к оптимизации алгоритмов программы (например где кучи циклов намешаны).

 

Mikl___

Фог на этом деньги зарабатывает.

Согласен полностью.

Любая документация (даже от Intel) неполная и изобилует косяками. Для широких масс ВСЕ сурьёзные вопросы закрыты (например регистры MSR).

 

Нельзя не согласиться. Правда меня всегда мучал вопрос - откуда у него вся эта инфа? Как пишет сам Фог: "The information is based on my own research and measurements rather than on official sources". С трудом верится, что не имея доступа к внутренней документации Intel(AMD), путем одних только "research and measurements" можно наковырять СТОЛЬКО инфы.
Хотя... Имея хардварный дебугер, наверное можно узнать немало...

 

Вполне достаточно rdtsc + мозг, главное иметь достаточно времени и желания на тестирование и осмысливание )

 

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

 

babandr
Вот что я ещё хочу сказать про оптимизацию кода:
Берём книгу Зубкова С.В. Assembler для DOS, Windows и UNIX (в сети видел), и открываем её на 582 странице.
Находим всеми ругаемую команду LOOP и смотрим время её выполнения (в тактах):
8087 - 17
80186 - 15
80286 - 8
80386 - 11
остальные процессоры не беру, т.к. там уже более сложно считается.
Что можно увидеть в этой таблице? А собственно ничего! На более свежем процессоре команда может выполняться дольше...
Учесть все процессоры - утопия.
Давайте рассмотрим следующий код:
40ffe loop @B
и
40ffe dec ecx
40fff jnz @B
Первым значением я указал адрес памяти. Что произойдёт при выгрузке страницы в файл подкачки?
Первый вариант выгрузится и загрузится нормально, а в случае подкачки второго прийдётся грузить две страницы.
Что ещё можно сказать про оптимизацию?
Основное время в программе (почти в любой) проходит в обработке вызовов API.
И любая функция вызывается через промежуточный вызов (т.е. call идёт на jmp и т.д.). В случае COM всё ещё плачевней.
Отсюда вывод - забить на оптимизацию на уровне кода и работать над эфективностью алгоритмов.
Повторюсь - для общего развития надо, а для использования...
Сам после 15 лет asm перешёл на C++, пусть компилятор сам разбирается что к чему
Касперского ещё не читал (хотя купил), посмотрю обязательно.

 

MirrorBlack

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

 

Утопия это думать что за 20 лет процессоры не изменились. И расматривать 386 нестоит. Бери более современный pentium4, core 2 due.

И какая вероятность того что цикл окажетья на границе страниц? 1/размер страницы. Менее 1% расматривать не стоит. Во вторых есть предвыборка. Так что штраф на проверку не накладывается.
Какова вероятность странице оказаться в файле подкачки? Да минимальна. Дупустим так сколько у нас страниц? 4Гб/4кб милион. И того так как вероятности перемножаются получаем вероятность менее 1^-9. На такое даже заморачиваться не стоит.

А вы мерили? Откуда данные?

 

Pavia

Пример я привёл СПЕЦИАЛЬНО чтоб показать что меняется ВСЁ. И то что сегодня от Фога реально - завтра белибердой окажется...

Согласен - ничтожная. Но мы начали считать такты и такой пример не помешает.

На сервере - огромная.

Возмите SoftIce и пробегитесь с ним по свом программам. Я думаю будете "приятно" удивлены. Только советую для полноты ощущений использовать для трассировки F8.