Я написал небольшой тест-проверялку. Заранее оговорюсь, что ни под что ее не оптимизировал, но почему-то так вышло, что она СИЛЬНО благоволит процессорам Интел. Вплоть до того, что тулик на равных бьеться с вдвое частотным Атлоном. Почему так вышло? Программка на Паскале. И ведь что интересно - компилятор ничего не знает даже о 486-м процессоре, а набор команд - исключительно 8086. Сопр не используется, так что нагрузка только на ALU/кэш. Откомпилирована для Real Mode. Может, разгадаете в чем такой финт заключается?

Hапример, на моем Селе 433 - 439 сек., на дурике 840 - 398 (!) сек. Кроме как на вдвое меньший кэш L2 у дурика мне такой мизерный разрыв списать не на что. Hу это ладно, у него винда давно не чищенная (хотя это и не должно сильно влиять). Hо дальше: Doors4ever прислал мне свой скрин, так там на А-ХР 2100 Мгц 158 сек., а у соседа на туалатине 1.1 (неразогнанном) - 171 сек, 1.26 (разогнанный) - 157 сек. Что за фигня?

У теста хорошая сходимость - при повторных запусках результат не меняется (разброс общего времени в переделах 2-3 сек.). Сначала грешил на XP, загрузился с дискеты с одним himem.sys - результаты практически те же (быстрее на 1%), так что винда не при чем.

З.Ы. Да вот еще: тест, по идее, должен слабо зависить (почти не зависить) от таймингов памяти и частоты FSB. Потому что код программы - 9К, а массивы и переменные занимают в сумме не более 64К (один DOS-сегмент).

Прогу и скрины тестов можно взять на: http://people.overclockers.ru/Rashid/files

Очень интересно прогнать тест на быстром П4. Если у кого есть, пришлите скрин, пожалуйста, на rashidma(little dog)yandex.ru (с указанием частоты проца). Только сохраните не в bmp, есс-но, а в png или gif. Мне это интересно, потому что я отвечаю за каждую строчку своего кода, строгое соотвествие классическим алгоритмам, и такой результат... слегка шокирует.

Потом я опубликую результаты и подытожу.

Rashid
Щас у себя попробую

Чтобы не было обвинений в подстрое теста "под Интел" выкладываю его код. Компилировать надо не в Borlad Pascal'е (а то на быстрых процах будет ошибка "деление на ноль"), а в Turbo Pascal. Проще взять откомпилированный файл на моей страничке. Ассемблерная вставка используется только для выключения мигающего курсора (для красоты). Кстати, жду результатов. Пока прислал только один человек и он подтверждает дикие тормоза Атлона (почти двукратное отставание: A-XP 3000+ равен Cel 1.2). Результатов P4 еще не было, жду.

Исходники на http://people.overclockers.ru/Rashid/files.

Fraсtal

Это значит твой неподписанный скриншот пришел мне на ящик? Понятно. Да, массив рендомный (это можно увидеть в листинге). А то что дольше... Не всегда дольше. Зависит от специфики алгоритма. Вот мои результаты (Celeron 433 MHz):

Выборкой - 21 21 21
Вставкой - 32 45 21
Пузырьком - 67 66 27
Шекера - 49 68 0

Если внимательно проанализировать, то видно следующее:

Метод выборки (SelectionSort) совершенно нечувствителен к порядку элементов в массиве - время всегда одно и то же. Если оно у вас и различается на 1 сек., то это результат погрешности о которой я говорил (например, если тест начался в 17.99 сек. и закончился 18.00 сек., то результат все равно равен 1 сек., и наоборот: если он начался в 17.00 сек., а закончился в 17.99 сек., то результат 0 сек., таким образом, предел погрешности - ровно 1 сек.).

Метод вставки (InsertionSort) к порядку чувствителен сильно. При упорядоченном массиве результат один-в-один с методом выборки. При "упорядоченном наоборот" - вдвое медленнее. При случайном - среднее арифметическое между крайними значениями.

Метод пузырька (BubbleSort) - самый плохой метод. Уступает по показателям практически всем алгоритмам. Разницы между "упорядоченным наоборот" и неупорядоченным почти нулевая на P6-архитектуре (Mendocino, Tualatin) и вышла небольшая (10%) на твоем процессоре (P4) (интересно почему) в пользу случайного (16 и 18 соответственно).

Метод рекурсии (RecurSort) стоит особняком. Это прославленный Quicksoft, придуманный в 1960-м проф. Хоаром. Он у меня выполняется за 0-0-0 (и на любом компьютере >100 MHz должно быть так же) и помогает быстро создать "упорядоченный наоборот" массив в начале теста. У этого метода только один минус - рекурсивная природа. Это делает его использование невозможным на архитектурах с внутренним (маленьким) стеком.

Метод Шекера (SheckerSort) для случайного массива по эффективности стоит где-то посредине пузырька и вставки. Для "упорядоченного наоборот" он даже хуже пузырька (но не намного), зато у него одно принципиальное достоинство: самая быстрая сортировка уже отсортированных массивов (здесь он даже лучше Quicksoft).


Однако, все равно странно выходит: P4 3.3 GHz всего в 4.5 раза быстрее Celeron 433 MHz. А по частоте должно быть в 7.5 раз. В случае с Атлон, если смотреть по частоте - примерно так же. А если по рейтингу - гораздо хуже. Т. е. рейтинг в этом случае оказывается неоправданным: Атлон 2 GHz работает в полтора раза медленее P4 3 GHz.

Размер строки cache у P3 = 32, у K7 = 64, у P4 = 64*2

Я вот прогнал сие творение на своем ноутбуке, цел 2.5 Ггц, 127 сек... скрин ушел...

Fraсtal

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

Забавно что мы умудряемся писать друг другу почти одновременно, не видя того что пишет другой.

ИМХО отставание Атлонов говорит только о том, что они медленней Интела исполняют 16-битный код.
Попробуй скомпилировать тоё творение в 32 битном паскале (хоть в Дельфи), а там уже посмотрим результаты.

Результаты so far...

Celeron 433 MHz (Mendocino) - 439 сек.
Celeron 1100 MHz (Tualatin) - 171 сек.
Duron 840 MHz (Spitfire) (105 * 8) - 398 сек.
Athlon XP 3000+ (200 * 10.5 = 2100 MHz) - 165 сек.
Athlon XP 2100 MHz - 158 сек.
Athlon XP 3200 - 155 сек.
Celeron 2500 MHz - 127 сек.
Pentium 4 3300 MHz - 96 сек.

Не совсем понятна, какая частота у "Athlon XP 3200" (я плохо разбираюсь в рейтингах Athlon). Он чуть быстрее предыдущих, скорее всего, 2150 MHz или 2200 MHz. Ладно, исключим его из подсчетов.

Теперь самое интересное, отношение "частота * время" (чем оно меньше тем архитектура процессора для данного теста быстрее):

Mendocino - 433 * 439 = 190087
Tualatin - 1100 * 171 = 188100

Получаем, что архитектура P6 имеет этот коэффициент на уровне 190 (разброс в несколько тыс. единиц не имеет значения и может варьироваться от запуска к запуску).

Duron 840 * 398 = 334320
Athlon XP 2100 * 158 = 331800
Athlon XP 2100 * 165 = 346500

Коэффициент на уровне 330. Очень интересный вывод получается: у старенького Duron и сравнительно нового Athlon этот коэффициент одинаков! Значит на маленький кэш L2 отставание Duron списать уже нельзя (у Athlon он даже больше чем у Mendocino, однако коэффициент заметно хуже). Оно и понятно: сортируется массив размеров 16000 байт + два десятка байт на переменные, все это поместится в кэше L2 любого рассмотренного процессора. Второй вывод, что архитектура K7 крайне плохо приспособлена для этой задачи, коэффициент "неэффективности" (назовем его так) больше в 1.7 раза. Посмотрим на архитектуру NetBurst:

Pentium 4 3300 * 96 = 316800
Celeron 2500 * 127 = 317500

Коэффициент на уровне 310. Результаты с K7 почти одинаковы, но NetBurst все же чуть быстрее, примерно на 5%. Напомню, речь о РЕАЛЬНЫХ мегагерцах, а не о рейтингах. Т. е. даже он одной с Атлоном частоте П4 его обгоняет (или во всяком случае не отстает). Если же за основу взять рейтинг, получается совсем страшно:

Athlon XP 3000 * 160 = 480000

Результат K7 в 1.5 раза больше (хуже) архитектуры NetBurst. Случалось, конечно, видеть что P4 обгонял Атлон с одинаковым рейтингом, но чтоб в полтора раза и без SSE... Значит ли это что рейтинг Атлону присужден не совсем правомерно? Мне интересно: это результат конкретно моей программы (напомню, что алгоритмы классические, из учебника) или тут есть какая то закономерность? А может P4 "заточен" под код, генерируемый Паскалем (Паскаль "заточить" под P4 не могли, тогда процессора не было)? Или дело, как говорит Ketsalkoatl, в 16-битном коде? Надо бы проверить в С/С++. Скоро напишу другой тест, на Visual C++. Посмотрим на коэффициент "неэффективности" в этом случае...

P.S. Я решил убрать из форума текст программы (он слишком громоздкий) и поместил его на http://people.overclockers.ru/Rashid/files. Там же можно взять результаты всех тестов в архиве.

Fraсtal
Да, твои выводы совпали с моими. Интересно, что П4 в DOS'е быстрее равночастотного Атлона! И это несмторя на то, что данные целиком помещаются в кэше L1 Атлона (64К), а вот в кэше P4 (8К) нет. Если уменьшить размер массива до 7000 байт, то разрыв между Атлоном и P4 станет побольше, т. к. в этом случае все данные поместятся в кэше L1 и проц будет функционировать на всю катушку...

А детализацию тестов можешь взять по ссылке на моей личной страничке. Хочу завтра прогнать тест на работе на Tualatin 1.2 (погоню до 1.6-1.7). Он, наверное, обгонит даже твой процессор.

Athlon 2700+(2171Mhz) результат 156с.
Тестировал в WinXp, в фоне играет mp3шка и просматривается данная конференция в Опере
В чистом досе 153с.

Fraсtal



Напиши, проверим. Массив - 16000 элементов (один элемент = 1 байт), заполняется рендомом от 0 до 255. Количество сортировок (иначе тест слишком быстро прогоняется, цифры сравнивать неудобно) - 10 для каждого случая. На скорость это влияет слабо, но все же: перед началом каждой сортировки я заполняю рабочий массив данными из другого массива (исходный, обратный, упорядоченный), даже в том случае если сортируется уже упорядоченный массив (иначе у этого случая будет фора перед другими, а это нечестно). Делается это всего одной строкой for i:=1 to N do A[i]:=B[i];, но я выделил в отдельную процедуру для удобства чтения. Таким образом, всего в программе 4 массива по 16000 байт. Попробуй сделать такую же на C.

Да, меня заинтересовало уменьшение коэффициента «неэффективности» на P4 уменьшением массива. Сейчас сделаю «7К-версию» своего теста и выложу там же. Массив (7000 байт) и все переменные должны поместиться в кэше данных L1. Так мы «раскочегарим» ALU P4 на всю катушку. Попутно сделаю новые тесты на Туалатине, Мендочине и Паломине (а мне пришли свои). Кстати, этот тест позволит также на всю катушку использовать старые процессоры (486, Pentium), так как у них кэш данных тоже 8К. Интересно, а у них коэффициент «неэффективности» будет меньше чему P2/P3? Да, для того чтобы новый тест не пролетал слишком быстро, я увеличу число сортировок до 50.

Дествительно интересно. Преимущество P4 обьясняется очень просто, реально ALU у этого камня работает на удвоенной частоте ядра, так что с коеффициентами вы сильно погарячились В коде программы используются только базовые операции типа mov, xchg, cmp, inc, для ALU с частотой 6Ггц это самое оно. Непонятны только результаты П3, возможно тут компилятор вносит какие-то свои умные оптимизации которые П3 нравятся больше чем атлону