Fraсtal

FPU не используется вовсе. Даже не инициализируется. Только ALU.

Хватает. Массив 16000 байт, переменные... так... 31 байт. Плюс несколько констант-адресов (уж точно меньше 100 байт). А кэш L1 Data у P2/P3/PMMX - 16384 байта. Влезает как раз. А код целиком влезает в любой кэш, даже 8 Кб. Код каждой процедуры в отдельности и того меньше - не более 1 Кб.

Можно. Только графики в текстовом режиме - это не интересно. Скорее всего сделаю. Размер будет все равно ограничен 16000 байт (надо всем массивам и переменным "влезть" в 64К). Так что 1000..16000. А количесто прогонов... Ну пусть будет 1..1000. Но это, как понимаешь, завтра.

Так-то оно так, да вот тока там каждый из двух ALU хоть и работает в 2 раза быстрее, но они 16-битные! и выполняют 32-битное сложение за 2 приёма. (см. 1) Кароче по сути интел удвоила частоту части ядра, но сделала его разрядность меньше в 2 раза (этим видимо уменьшиив размеры ядра) ... реальная производительность осталась на том же уровне, что и если бы были 2 полноценных 32разрядных ALU на 3ГГц.

1) Пока один считает старшую половину своего числа второй считает младшую своего.
#77

З.Ы. Тока вот непонятно, должна ли эта система в 2 раза быстрее считать 16-битные числа? или нет...

Fraсtal
>> Реально частота там такая же, просто исполнительные модули выполняют две инструкции за такт.
Извини конечно, но реально частота так НЕ ТАКАЯ ЖЕ а удвоенная относительно частоты остальных блоков.

Rashid
Можешь выложить исходники для Делфийского компилятора? А то переделывать долго и мучительно. и компилятора старинного нет. Да и тест под дос как-то не интересно.

Fraсtal
Раз пошла такая пьянка...

Вот эффективность каждого метода для случайного массива:

Метод Число сравнений Число присваиваний
Выборкой (N^2)/2 N
Вставкой (N^2)/4 (N^2)/8
Пузырьком (N^2)/2 (N^2)/2
Рекурсией 2N*lnN

Видно, что после рекурсии самый эффективный - метод выборки. Если бы мы сортировали не байты, а большие структуры (скажем, по килобайту каждая), где присваивание и обмен идет долго, а байт служил бы лишь признаком сравнения, то этот метод ушел бы в отрыв далеко вперед.

Ketsalkoatl
Это ново... А откуда информация?

Fraсtal
Сейчас меня интересует, какова "неэффективность" ALU Pentium 1. Вдруг еще меньше, чем у P2/P3? Может в угоду частоте мы с каждым годом все больше и больше расплачиваемся "неэффективностью"? Кстати, вот сейчас подумал: а надо ли выпускать тест с регулируемыми параметрами? По-моему, 7К- и 16К-версии накрывают все возможные цели (а больше-то 16К не сделаешь!). Тест, по-возможности должен быть вообще один, иначе становиться трудно сравнивать.


Вот именно. Нет смысла делать массив меньше (а больше не получится). Ограничусь 7К-версией. Впрочем если уж очень хочется - исходники открыты, дерзайте!


Вот смотри. Это код процедуры SelectionSort. Только он странный какой-то (получен в HIEW), возможно он с адресами напутал, но коды операций, имхо, те. А дебаггера у меня у самого нет.

nop
nop
nop
nop
mov w,[0195E],00001
jmps 000000010
inc w,[0195E]
mov di,[0195E]
mov al,[di][01311]
mov [01970],al
mov ax,[0195E]
mov [01966],ax
mov ax,[0195E]
inc ax
cmp ax,00640
ja 00000005A
mov [01960],ax
jmps 000000033
inc w,[01960]
mov di,[01960]
mov al,[di][01311]
cmp al,[01970]
jae 000000052
mov di,[01960]
mov al,[di][01311]
mov [01970],al
mov ax,[01960]
mov [01966],ax
cmp w,[01960],00640
jne 00000002F
mov di,[0195E]
mov al,[di][01311]
mov di,[01966]
mov [di][01311],al
mov al,[01970]
mov di,[0195E]
mov [di][01311],al
cmp w,[0195E],0063F
jne 00000000C
nop
nop
nop
nop

nop'ы я инлайном насовал в паскалевский текст в начале и в конце процедуры, чтобы потом отыскать эту функцию в HIEW. Больше нигде в exe-шнике 4 nop'а подряд не встречаются. Итого: 22 инструкции mov, 6 jXX, 4 cmp, 3 inc - имхо очень простые инструкции. Как раз для P4. Вот только jXX могут немного подпортить его конвейер. Кстати на этом тесте ядро Netburst дает практически тот же результат, что и P2 (см. детализацию: P4 3.3 = 3-3-2, P3 1.1 = 8-9-8).


Кстати посмотри ради интереса результат в голом DOS'е. Там должно быть получше (винда несколько сот раз в секунду переписывает часть L1 Data своими данными). Для запуска теста ничего не надо, даже himem.sys.

Кстати, вот это пассаж мне совершенно не ясен:

mov ax,[0195E]
mov [01966],ax
mov ax,[0195E]

Зачем еще раз в ax гнать константу по адресу 0195E? А может это HIEW гонит? Где можно скачать Turbo Debugger?

Rashid
Сделай версию под делфю!!

НАРОД!!!
Я сделал версию для Делфи 7 и стало быстрее раза в два!!!!!!!!
было 200 стало 103 секунды. (конфа на работе:п4-1800 (512к)) ВОТ!!!!!!!!!!!!
На Атлоне дома попробую. Результат пришлю позже.

Да и еще я думаю что Атлон медленее выполняет 16 разрядный код. Но это не принципиально.
А под Делфёй компилятор делает 32 разрядный код. Поэтому стало быстрее. А вообще Раскаль и делфи компилируют самый тормозной код ( хотя наверняка можно найти компилятор хуже )

Он не гонит. смотри сл строку : Inc ax
Просто компилятор не умеет оптимизировать код. (о чем я писал выше)

Протестил я свой проц P4 2.0A@2.67(bus real 133Mhz), получил 114 сек...

BDS

Это-то как раз нормально (inc ax). Инкрементрует ax (который здесь судя по всему является счетчиком I). А то, что он не оптимизирует код - уже почти понятно. Дай-ка я посмотрю на него... М-да. В процедуре, где целых 2 вложенных цикла ни разу не задействовать регистры сх, bx, dx! В горячечном бреду такого бы не сделал. Зато какие-то извраты с постоянным сохранением и восстановлением регистров ax и di (Ну а он то здесь зачем!? Что dx нельзя было заюзать?). Теперь неудивительно, что в Delphi ты без труда получил двукратный прирост. Кстати, пришли мне на мыло (есть в первом письме треда). Интересно, а в P4/P3 прирост будет такой же? Тогда это ничего не меняет. Меня ведь главным образом интересует не качество компиляции, а скорость ALU.

Почему-то я не могу ничего скачать. Как свои так и твои файлы. Два раза открывается web-страница, а потом обратно на заглавную.

1. Опции компиляции не указаны.
2. Все люди уже давно себе правильный CRT пересобрали Но пользовать его - не рулез. Простая консоль легче портируется.
3. Копировать однотипные массивы можно простым присваиванием. Никаких форов.
4. CLRSCR в конце явно не в тему
5. Практику программирования иначе как китайской с современной точки зрения не назовешь. Хотя хозяин - барин.

Порт исходника на D5 со всеми отключенными проверками и включенной оптимизацией на P3 866Mhz cumine выполянется за 93 секунды, причем QuickSort (поименованный автором рекурсией почему-то, хотя это безусловно и Хоар ) выполняется быстрее одной секунды (программа ноль кажет). Увеличенное в три раза (до 30 ) количество циклов - 273. QuickSort становится ненулем только на количестве циклов порядка 100.

Проверить на моем торе смогу только на выходных.

Поставил я Borland C++ 3.1. Вот код процедуры на Паскале:



Вот что мне выдал Turbo Debugger:



В приципе, если не считать "зевка" с

mov ax,[195E]
mov [1966],ax
mov ax,[195E]

(3-я строчка лишняя), то компилятор сделал все правильно, НО: непонятна его "аскетичность" к используемым регистрам. В не маленькой, в общем-то, процедуре он использует всего 2 регистра ax и di. Это странно. Прекрасно можно было бы задействовать регистры cx, dx, si, хотя бы для хранения дополнительных переменных (I, J, MinIndex). Код стал бы меньше раза в полтора.

SweetLow

Я поначалу не думал открывать исходник, а для exe-шника это не надо. Да и не сильно эти опции влияют (на результат не сказывается).

Все же, наверное, не все люди. У кого-то пойдет, у кого-то нет. А Crt можно и не использовать, он только для красоты.

Спасибо. Не знал. Впрочем, на результаты это не сказалось.

Я не хочу оставлять следы на экране после выхода в DOS. Все просто.

Зачем же так грубо? 90% кода взято из классических учебников алгоритмического программирования (Кнут, Дейкстра). Я не изменил ни строчки. Думаю, что у Билли Гейтса в Windows алгоритмы не лучше. А мои 10% - это интерфейс и замер времени. Я не виноват, что Turbo Pascal так компилирует.