Я так понял, что каждое обращение к памяти, встречающееся в программе, долго и упорно обрабатывается системой на предмет залезания не туда, и если действительно было нарушение, вызывается обработчик исключения. Я сделал одну процедуру, у которой основной рабочий цикл (заполнении линии одинаковым, пока что, значением) выглядел так:
// заполнение регистра ecx длиной участка...
jle @@; @:
mov [eax], edx
add eax, 4
// sub eax, 4
dec ecx; jnz @; @@:
Во-первых, не факт, что на всех процессорах будет тот же эффект. Давай сделаем так: приведи простейшую программку, которая будет использовать LOOP, и которая будет использовать DEC+JNZ, и сравнивать скорости их выполнения. И протестируем эту программку на разных процессорах. Скажем, на DualCore, QuadCore, P4, на Селеронах, на AMD-шках, можно на i7 попробовать потестировать... Я уверен, результаты будут не такими уж однозначными.
Теперь - почему на твоей модели процессора (если можно, формулируй в следующий раз именно так, я еще раз говорю: не факт, что это выполняется везде) LOOP может быть медленнее, чем DEC/JNZ - см. здесь: http://www.wasm.ru/article.php?article=1010018
Добавлено через 22 сек.
P.S. Перенести в Ассемблер?
Добавлено через 3 мин.
P.P.S. А заменить dec ecx на sub ecx,1 не пробовал? Попробуй...
> Давай сделаем так: приведи простейшую программку, которая будет использовать LOOP, и которая будет использовать DEC+JNZ
Ну что-то типа этого:
program Test;
{$APPTYPE CONSOLE}
uses
Windows;
var
T: integer;
i: integer;
procedure Delay1;
begin
asm
mov ecx, $FFFFFFF
@:
loop @;
end;
end;
procedure Delay2;
begin
asm
mov ecx, $FFFFFFF
@:
dec ecx; jnz @;
end;
end;
begin
T := GetTickCount;
while T = GetTickCount do;
T := GetTickCount;
Delay1;
i := GetTickCount - T;
WriteLn('loop: ', i);
T := GetTickCount;
while T = GetTickCount do;
T := GetTickCount;
Delay2;
i := GetTickCount - T;
WriteLn('dec;jnz: ', i);
ReadLn;
end.
Вот, посмотри, что у меня получилось:
На более старой машине (там видно характеристики)
А это на двухядернике:
И там и там Win XP SP3... Запускался один и тот же EXE-шник, если что.
От типа памяти + кэша должно сильно зависеть. TarasBer, давно пора забыть про классическую схему с обращением напрямую к каждому адресу..
> TarasBer, давно пора забыть про классическую схему с обращением напрямую к каждому адресу...
А какие бывают другие? И как заставить процессор выводить не в память, а в кэш?
А можно озвучить задачу, которую ты пытаешься решить?
В рабочем цикле будет заполняться экранный буфер цветом примитива, с учётом тумана и будет заполняться з-буфер.
Если что, на моей видяхе изобретение велосипедов очень даже оправдано.
Я не просто так спросил, если что.
Я бы не стал задавать вопрос, если бы сам код закраски полигона у меня не был готов. Причём большие полигоны у меня закрашиваются медленнее, чем опенглом, а маленькие - быстрее. Это говорит о том, что у меня тормозит внутренний цикл. То есть, как я понял, проблема с fillrate. У меня внутренний цикл написан на асме, рядом стоит его закомментированная копия на Паскале, чтобы, если что, вернуться и перепроверить алгоритм.
И да, тогда перенесите тему в ассемблер, пожалуйста.
Ну, и где этот код и результаты его прогонов на разных компьютерах?
Тему перенес...
Результаты скорости меня интересуют, в первую очередь, для моего компьютера. Я рассуждаю так - что идёт у меня, то пойдёт у всех остальных.
Вот скрин. Сверху - моя заливка полигона (в одном месте вместо мов поставлен ксор для красоты, он на скорость не влияет), снизу - опенгл. В заголовке - сколько миллисекнуд заняла скольки-кратная отрисовка сцены.
Эскизы прикрепленных изображений
Попробовал выводить по 8 байт, при помощи команды movq.
Не помогло.
Добавлено через 10 мин.
Попробовал выводить по 8 байт, при помощи команды movq.
Не помогло - скорость абсолютно та же осталась.
Так в виндовсе память работает в защищённом режиме, имхо, на конечном этапе ресурсами распоряжается менеджер памяти. При выводе картинки задействуется малый объём ресурсов, ситуация напоминает оплату электричества: при низком потреблении за почтовые услуги нужно постоянно платить в разы больше чем за потреблённую энергию (привет экономичным лампочкам)). Если занять у менеджера памяти ~100Мб (или больше) памяти и не дать ему усомниться в том что она нужна приложению всегда и полностью, статистика скорости доступа должна быть более точной. Это только скорость оперативки, видеокарты, отдельный вопрос.