Чтение из памяти в обратном порядке

[alcaedo]

        MOV EAX,[R11+00] ; ROL EAX,16 ; XOR EAX,[R12+28] ; JNZ @N1neN2s1
        MOV EAX,[R11+04] ; ROL EAX,16 ; XOR EAX,[R12+24] ; JNZ @N1neN2s1
        MOV EAX,[R11+08] ; ROL EAX,16 ; XOR EAX,[R12+20] ; JNZ @N1neN2s1
        MOV EAX,[R11+12] ; ROL EAX,16 ; XOR EAX,[R12+16] ; JNZ @N1neN2s1
        MOV EAX,[R11+16] ; ROL EAX,16 ; XOR EAX,[R12+12] ; JNZ @N1neN2s1
        MOV EAX,[R11+20] ; ROL EAX,16 ; XOR EAX,[R12+08] ; JNZ @N1neN2s1
        MOV EAX,[R11+24] ; ROL EAX,16 ; XOR EAX,[R12+04] ; JNZ @N1neN2s1
        MOV EAX,[R11+28] ; ROL EAX,16 ; XOR EAX,[R12+00] ; JZ  @N1eqN2
  @N1neN2s1:                        // [R11]^s1 <> [R12]

Это кусок кода из середины ассемблерной функции Delphi. Точки с запятой, если кто не в курсе, просто разделяют команды, а не обозначают начало комментария. В R11 и в R12 находятся адреса некоторых 32-байтных полей. Эти поля могут следовать одно сразу за другим, а могут быть разнесены в памяти на большое расстояние, вплоть до 2-х гигабайт. Единственное, что гарантируется: R11<R12.

Вопрос в том, как оптимально задействовать кэш процессора при таком чтении. Из кода видно, что либо первое поле, либо второе в любом случае придётся читать в обратном направлении. Как я понимаю, с адреса [R11] в кэш будут прочитаны сразу несколько байт на опережение, а с R12 каждый раз будет идти обращение к ОЗУ. Может есть какая-то команда, которая загрузит второе поле в кэш с самого начала? Ну, и вообще, возможно ли тут получить какой-то прирост в производительности?

[Мордохвост]

В целом можно подчерпнуть в Optimizing subroutines in assembly language by Agner Fog.
ROL 16 это ведь как псевдо "bswap ax ; bswap eax ; bswap ax", тогда я вроде корректно сделал пшафл. У меня получилось лишь в 2 раза формально(читай: синтетически) ускорить через sse, набросок:

procedure Experimental(const AddrR11, AddrR12:Pointer);
asm
  push      r12
  mov       r11,rcx
  mov       r12,rdx
  mov       ecx,100

@@loop:
  movdqu    xmm0,[r11+00]  
  movdqu    xmm1,[r12+16] 
  pshuflw   xmm0,xmm0,$B1
  pshufhw   xmm0,xmm0,$B1
  pxor      xmm0,xmm1
  ptest     xmm0,xmm0
  jnz       @@found1
  movdqu    xmm0,[r11+16]
  movdqu    xmm1,[r12+00]
  pshuflw   xmm0,xmm0,$B1
  pshufhw   xmm0,xmm0,$B1
  pxor      xmm0,xmm1
  ptest     xmm0,xmm0
  jnz       @@found2
  sub       ecx,1
  jg        @@loop
  jmp       @@exit

@@found2:
  //do something

@@found1:
  //do something

@@exit:
  pop       r12
end;

...
SetLength(AR11,1000);
SetLength(AR12,1000);
for i := 0 to 999 do
  begin
    AR11[i] := $01020304;
    AR12[i] := $03040102;
  end;

t1 := MIRDTSC;
for i := 0 to 999 do
begin
  Experimental(Pointer(@AR11[0]),Pointer(@AR12[0]));
end;
t2 := MIRDTSC;

Result := t2 - t1;
...

Структуры или что там в r11/r12 якобы будем считать уже адаптированы под такое. Есть ещё хинт для проца "prefetcht0 [rcx]" ( в rcx адресс че нужно прокэшировать для чтения), но эта штука раз на раз не приходится.

[alcaedo]

О! Я тоже в эту сторону посмотрел сегодня и вот, что получилось:

        MOVAPS  XMM0,[R11]
        MOVAPS  XMM1,[R12+$10]
        pshufd  xmm0,xmm0,$4E
        pshufhw xmm0,xmm0,$1B
        pshuflw xmm0,xmm0,$1B
        XORPS   xmm0,xmm1
        PTEST   xmm0,xmm0
        JNZ     @N1neN2s1
        MOVAPS  XMM0,[R11+$10]
        MOVAPS  XMM1,[R12]
        pshufd  xmm0,xmm0,$4E
        pshufhw xmm0,xmm0,$1B
        pshuflw xmm0,xmm0,$1B
        XORPS   xmm0,xmm1
        PTEST   xmm0,xmm0
        JZ      @N1eqN2
  @N1neN2s1: // [R11]^s1 <> [R12]

Все данные в программе выровнены на 16. А чем отличается XORPS от PXOR и чем MOVDQU от MOVAPS(MOVUPS)? У меня вышел выигрыш по времени до 6.2%. 6% получается только на массивах, которые по результату сравнения будут признаны эквивалентными. На случайно заполненных массивах разницы в скорости нет. На частично эквивалентных разница 0..6%. Но у меня большой расход времени на организацию цикла для теста, так что реальный выигрыш больше 6%.

Ещё немного покопался с разных статьях. Нашёл информацию о том, что данные из ОЗУ в кэш загружаются обычно пачками по 64 байта, выровненными на 64. Если так, то код из первого поста никак больше не улучшить. Там и там всё нормально кэшируется. Если второй массив весь умещается в такой выровненный на 64 блок из 64х байт, то при чтении последнего элемента массива, весь массив будет загружен в кэш. А если массив размазан на два блока, то в любом случае (для полного сравнения) придётся эти два блока загружать полностью из памяти.