Здравствуйте, форумцы! Дистрибутив MASM'а включает в себя неплохой хелп по асмовым опкодам и в этом хелпе есть также информация о том, сколько тактов затрачивается на выполнение той или иной команды на процессорах Intel (8086,386,486). Внимание, вопрос... Где бы найти подобную информацию (по количеству тактов), но для команд процессоров вплоть до Pentium4? В интеловской документации этого, к сожалению, нету; там только описание инструкций... У Агнера Фога все как-то размыто...да и далеко не исчерпывающе.
Medstrax, смотрел вот тут: http://www.intel.com/products/processor/manuals/index.htm ближайшее к теме - описание инструкций, но времени выполнения нету нигде.
babandr Значительно более "исчерпывающе", чем в интеловском мануле. Из официальных мануалов только у АМД приведены латентности всех команд (да еще и их разновидностей), а у Интел - только выборочно и только для регистровых операций
Забей на такты. Круто конечно хвалиться что у тебя прога на 3 такта быстрее пашет после оптимизации Однако, когда говрят про оптимизацию, часто забывают про очередь предвыборки команд, переименование регистров и т.д. А сие не маловажно. Как показывает практика овчинка выделки не стоит. Самому в общем плане понимать как работает - надо, но использовать во всей красе... Основные усилия надо прилагать к оптимизации алгоритмов программы (например где кучи циклов намешаны).
MirrorBlack Агнера Фога, наверное, тоже кто-нибудь призывал "забить". Пока сам себе шишек на лоб не набъёшь -- к чужому мнению не прислушиваешься
Mikl___ Фог на этом деньги зарабатывает. Согласен полностью. Любая документация (даже от Intel) неполная и изобилует косяками. Для широких масс ВСЕ сурьёзные вопросы закрыты (например регистры MSR).
Нельзя не согласиться. Правда меня всегда мучал вопрос - откуда у него вся эта инфа? Как пишет сам Фог: "The information is based on my own research and measurements rather than on official sources". С трудом верится, что не имея доступа к внутренней документации Intel(AMD), путем одних только "research and measurements" можно наковырять СТОЛЬКО инфы. Хотя... Имея хардварный дебугер, наверное можно узнать немало...
Medstrax "Пусть даже вероятность истинности теории близка к нулю. До тех пор, пока теория не опровергается реальными экспериментальными данными, а также позволяет предсказывать эти экспериментальные данные, абсолютно не важно, верна она или нет" © l_inc
Вполне достаточно 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.
