Тест скорости процессора...

Если бы вам надо было написать "Тест скорости CPU"

Какие бы вы десять самых важных тестов(процедур) ALU и десять(процедур) FPU написали?

Надо например сравнить P4 2600 и AMD2600+...

 

Включил бы OpenGL в софтварный режим и FPS-ы какой-нибудь квачи сравнил бы.

 

_DEN_

А как это сделать?

 

locki

Да чепуха все это - посмотри внимательно все энти тесты - на сайтах производителей и их прихвостней они ТЩАТЕЛЬНО ПОДОБРАНЫ. А независимые дают очень циничные результаты - типа "Бывает так, что P4 2600 лучше, чем AMD 2600+... а бывает, что и хуже - да, бывает..." А все потому, что хрен теперь сравнишь их разные процессоры, разные сопроцессоры... разные кэши... разная память... разные шины... разные конвееры... разная арифметика... продолжать можно до бесконечности. Можно только получить КОНКРЕТНЫЕ ЗНАЧЕНИЯ на КОНКРЕТНЫХ ЗАДАЧАХ. Но это ровно ничего не значит даже для однотипных задач.

(Разумеется все вышеизложенное есть мое непоколебимое ИМХО

 

Можно только получить КОНКРЕТНЫЕ ЗНАЧЕНИЯ на КОНКРЕТНЫХ ЗАДАЧАХ. Но это ровно ничего не значит даже для однотипных задач.

- так вот я и прошу 20 задач в кторых их можно сравнить...

 

locki

Ну, если сравнивать математику, то есть общепринятые алгоритмы - например преобразование Фурье для вещественных вычислений, решето Эратосфена для целочисленных (хотя скорее больше зависит от производительности памяти) и т.п.

Лучше наверное будет покопаться в исходниках чего-то типа RightMark'а и ему подобных (каюсь, у самого руки не дошли)



Кстати, надо оценить только ALU/FPU или также эффективность кэшей, памяти и прочей лабуды? Оптимизированого кода или неоптимизированого? (вопрос не праздный ибо P4 и Intel'овская архитектура вообще гораздо чувствительней к оптимизации, чем AMD'шная)

 

locki

В настройках дров видеокарты

 

Лучше наверное будет покопаться в исходниках чего-то типа RightMark'а и ему подобных (каюсь, у самого руки не дошли

все райтмарк ДА РАЙТМАРК, а сами мы че???

 

locki

А сами мы "ниче", нам умишка и усидчивости не хватает, и главное - желания

Тебе же русскими словами объясняют - латентности некоторых операций в P4 и атлоне различаются очень сильно. Но ведь нельзя же считать интелов полными идиотами - раз они заложили в Northwood'е существенно (в разы) увеличенные задержки сдвигов, mul\imul, adc\sbb, bswap и т.п., значит посчитали что для типовых задач этот проигрыш на отдельных операциях сгладится в общем потоке команд.

Думать над типовыми задачами мне в лом, зато легко и просто можно придумать нереальные задачи, в которых P4 будет проигрывать в разы - достаточно взять цепочку зависимых инструкций из перечисленных выше тормозов P4. А еще лучше денормальные вещественные операнды в SSE использовать (у тебя видимо есть опыт или в секцию кода че-нить записывать на расстоянии 100 байт от исполняемого куска - вот тут уж P4 даже i486 может проиграть )

 

А вот я как-то извращался - писал в следующий исполняемый байт 90h...

Вот черт, не нашел исходники, слепил заново - на Celeron Mendocino +140 такта как с куста, на Northwood - +320, на Thunderbird'е - порядка +700!!! Вывод - нортвуд в два, а тандерберд в пять тормознутее мендосина... ))))))

 

> "писал в следующий исполняемый байт 90h..."

Ну ежели в следующий, так это любой проц будет тормозить

А вот если на расстоянии сотни-другой байт, то P4 будет несомненным лидером по тормозам. И все из-за трэйс-кэша. В P6 и АМД в текущую линейку кэша инструкций писать нельзя, а в P4 аж в килобайтный блок - иначе он подозревает модификацию кода и сбрасывает целый килобайт трэйс-кэша

 

leo

Килобайт или киломикрооперацию?

 

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

 

А случайно не весь trace cache?

 

Ну весь-то это слишком... Было бы логичнее сбрасывать линейку L2 кэша.

И вообще, leo, признавайся откуда ты все знаешь. Я тоже хочу... (Потрясенным шепотом) ...неужели из мануалов?..

 

Извиняюсь, со сбросом килобайта я фигню сморозил. Действительно, captain cobalt прав - сбрасывается весь Т-кэш. И связано это видимо с особой организацией Т-кэша. В обычном кэше по любому адресу можно определить кэш-линейку, в которой находятся соответсвующие данные или код. А T-кэш, во-первых, работает не с байтами кода, а с декодированными мопами, во-вторых, не с отдельными мопами, а с целыми трассами мопов (до 64-х 6-тимоповых блоков). И соответсвенно адресуется (т.е. имеет фиксированное положение в кэше) только начало трассы, ее первый блок, а остальные блоки просто увязаны в двунаправленный список и могут находиться где угодно (грубо говоря). Поэтому и нет механизма, как для любого адреса найти соответсвующую ему трассу (если только это не адрес начала этой трассы). Поэтому ИМХО при модификации и приходится сбрасывать весь трэйс-кэш.

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

Кстати на том же Ф-центре можно найти массу сравнительных тестов разных процессоров (locki для справочки , а также кое-что по NetBurst в популярном изложении

 

leo

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



Насчет сброса т-к так ничего и не понял. Но логично было бы сбрасывать его при попытке загрузки из модифицированой линейки L2? (Чую, чую, щас мя опять ламером обзовут

 

Ustus

> "Насчет сброса т-к так ничего и не понял"

Да я тоже Точнее сказать я понял почему проще сбрасывать весь кэш, чем искать трассы которые могли быть модифицированы. Но сам механизм контроля модификации остается не ясным.

Но ИМХО это должен быть специальный механизм, выявляющий модификацию в момент исполнения или отставки операции записи, а не тогда когда изменения попадут в L2. Ведь L2 может лишь сигнализировать, что линейка модифицировалась, но нужно еще знать в какой момент это произошло чтобы сделать откат потенциально инвалидных мопов, которые уже загружены в конвеер, а с учетом задержки записи в L2 могли быть уже исполнены. Поэтому анализ должен производиться сразу после выполнения мопа вычислении адреса записи store-address или по кр.мере сразу после отставки операции записи, тогда будет ясно что последующие мопы могут быть инвалидными и нужно сбрасывать конвеер и т-кэш, ждать пока изменения попадут в L2 и начинать декодировать трассу заново со следующей инструкции.

 

leo

Ну, насчет отката - так на том же ф-центре даже цельная статья по replay, правда там идет речь о зависимости по данным, но кто мешает применить сей механизьм и здесь.

Собственно, я другое имел в виду - откуда берется 1кб? Если бы там 128б или 4кб то я бы еще понял, но что за мистическая цифра 1кб? Че у него такого размера-то?

Кстати, потыкал модифицируемый код в Athlon - ему кажется еще хуже от этого, чем Northwood'у... но еще не все варианты потыкал, поэтому цифири приводить не буду, только на модификации следующего байта он теряет порядка 900(!!!) тактов. Правда проц неудачный для таких исследований - Thorton, у него множитель 12.5, поэтому ему всегда очень тяжко при кэш-промахах. Да еще чипсет - KT333, его еще Касперски ругал по этому параметру. Но все равно цифра что-то уж очень большая, причем при увеличении расстояния до модифицируемого байта задержка падает очень неохотно. Непонятка...

 

Ustus

На атлонах кэш-линейка 64 байта поэтому на расстояниях вперед на одну-две линейки задержка вроде как и не должна падать "охотно". А вот если назад писать в предыдущую линейку, то может и вообще потерь не будет. А на P4 не зависит куда пишешь - вперед или назад