🚀 go-pugleaf

thats what i get on my PIV 1.5GHz

                      cycles                     ratio
size     move()     fmove()    fmovent()      a     b     c
   4Kb,       3226      13659      13236     0.2   0.2   1.0
   8Kb,       5453      21173      23642     0.3   0.3   0.9
  16Kb,      11900      41718      46751     0.3   0.3   0.9
  32Kb,      26784      84629      89886     0.3   0.3   0.9
  64Kb,      52518     162699     193595     0.3   0.3   0.8
 128Kb,     347189     408041     439215     0.9   0.9   0.9
 256Kb,    1145400     919614     921846     1.2   1.2   1.0
 512Kb,    2370427    1798330    1841942     1.3   1.3   1.0
1024Kb,    5409173    3624693    3659741     1.5   1.5   1.0
2048Kb,   10783934    8007713    8204731     1.3   1.3   1.0
4096Kb,   21413328   15980532   16357972     1.3   1.3   1.0

move()    = normal delphi move()
fmove()  = fastmove() without prefetch
fmovent() = fastmove() with prefetch
ratio a   = move() / fmove()
ratio b   = move() / fmovent()
ratio c   = fmove() / fmovent()


it seem's that only above >= 256Kb copying fastmove() is faster and
most more important there exists no important difference between the use of
prefetch and without.

There must be exists an error in fastmove() because I get AV's on buffers
there are not an multiple of 2048 bytes.

Hagen



"Atle Smelv�r" <atle@datagrafikk.no> schrieb im Newsbeitrag
news:3d7887ef$1@newsgroups.borland.com...
> Here's a memory move routine by me..:
>
> procedure FastMove(const Source; var Dest; count : Integer); assembler;
> asm
>
>   push    ebx
>   push    esi
>   push    edi
>   push    ebp
>   sub     esp, 2048 // Initialiserer buffer
>   mov     edi, edx  // mov edi, dest
>   mov     esi, eax  // eax=source, edx=dest, ecx=count
>   mov     ebx, ecx
>   mov     ebp, esp
>   mov     eax, ecx
>   shr     ebx, 11   // 2048 bytes om gangen
>   and     eax, $7FF // mod 2048
>
> @loop2k: // Kopierer 2k i tempor�r buffer
>
>   mov     edx, ebp
>   mov     ecx, 32
>
> @loopMemToL1:
>
>   prefetchnta [ESI+64]   // Prefetch neste loop, non-temporal
>   prefetchnta [ESI+96]
>   movq    mm1, [ESI]     // Leser inn data til L1
>   movq    mm2, [ESI+8]
>   movq    mm3, [ESI+16]
>   movq    mm4, [ESI+24]
>   movq    mm5, [ESI+32]
>   movq    mm6, [ESI+40]
>   movq    mm7, [ESI+48]
>   movq    mm0, [ESI+56]
>   movq    [EDX], mm1     // Lagrer i L1
>   movq    [EDX+8], mm2
>   movq    [EDX+16], mm3
>   movq    [EDX+24], mm4
>   movq    [EDX+32], mm5
>   movq    [EDX+40], mm6
>   movq    [EDX+48], mm7
>   movq    [EDX+56], mm0
>   add     esi, 64
>   add     edx, 64
>   dec     ecx
>
>   jnz    @loopMemToL1
>
>   mov     edx, ebp       // Kopierer fra L1 til system memory
>   mov     ecx, 32
>
> @loopL1ToMem:
>
>   movq    mm1, [EDX]     // Leser inn data fra L1
>   movq    mm2, [EDX+8]
>   movq    mm3, [EDX+16]
>   movq    mm4, [EDX+24]
>   movq    mm5, [EDX+32]
>   movq    mm6, [EDX+40]
>   movq    mm7, [EDX+48]
>   movq    mm0, [EDX+56]
>   movntq  [EDI], mm1     // Lagrer i dest
>   movntq  [EDI+8], mm2
>   movntq  [EDI+16], mm3
>   movntq  [EDI+24], mm4
>   movntq  [EDI+32], mm5
>   movntq  [EDI+40], mm6
>   movntq  [EDI+48], mm7
>   movntq  [EDI+56], mm0
>   add     edx, 64
>   add     edi, 64
>   dec     ecx
>
>   jnz    @loopL1ToMem
>
>   dec     ebx
>
>   jnz    @loop2k           // Ta neste blokk
>
>   test    eax, eax
>
>   jz     @NoRestMem
>
>   mov     ecx, eax
>   cmp     edi,esi
>
>   ja     @down
>
>   je     @NoRestMem
>
>   sar     ecx, 2           // copy count DIV 4 dwords
>
>   js     @NoRestMem
>
>   rep     movsd
>   mov     ecx, eax
>   and     ecx, 03h
>   rep     movsb            // copy count MOD 4 bytes
>
>   jmp    @NoRestMem
>
> @down:
>
>   lea     esi, [ESI+ECX-4] // point ESI to last dword of source
>   lea     edi, [EDI+ECX-4] // point EDI to last dword of dest
>   sar     ecx, 2           // copy count DIV 4 dwords
>
>   js      @NoRestMem
>
>   std
>   rep     movsd
>   mov     ecx, eax
>   and     ecx, 03H         // copy count MOD 4 bytes
>   and     esi, 4-1         // point to last byte of rest
>   add     edi, 4-1
>   rep     movsb
>   cld
>
> @NoRestMem:
>
>   emms
>   add     ebp, 2048
>   mov     esp, ebp
>   pop     ebp
>   pop     edi
>   pop     esi
>   pop     ebx
>
> end;
>
>
"Atle Smelv�r" <atle@datagrafikk.no> schrieb im Newsbeitrag
news:3d7887ef$1@newsgroups.borland.com...
> Here's a memory move routine by me..:
>
> procedure FastMove(const Source; var Dest; count : Integer); assembler;
> asm
>
>   push    ebx
>   push    esi
>   push    edi
>   push    ebp
>   sub     esp, 2048 // Initialiserer buffer
>   mov     edi, edx  // mov edi, dest
>   mov     esi, eax  // eax=source, edx=dest, ecx=count
>   mov     ebx, ecx
>   mov     ebp, esp
>   mov     eax, ecx
>   shr     ebx, 11   // 2048 bytes om gangen
>   and     eax, $7FF // mod 2048
>
> @loop2k: // Kopierer 2k i tempor�r buffer
>
>   mov     edx, ebp
>   mov     ecx, 32
>
> @loopMemToL1:
>
>   prefetchnta [ESI+64]   // Prefetch neste loop, non-temporal
>   prefetchnta [ESI+96]
>   movq    mm1, [ESI]     // Leser inn data til L1
>   movq    mm2, [ESI+8]
>   movq    mm3, [ESI+16]
>   movq    mm4, [ESI+24]
>   movq    mm5, [ESI+32]
>   movq    mm6, [ESI+40]
>   movq    mm7, [ESI+48]
>   movq    mm0, [ESI+56]
>   movq    [EDX], mm1     // Lagrer i L1
>   movq    [EDX+8], mm2
>   movq    [EDX+16], mm3
>   movq    [EDX+24], mm4
>   movq    [EDX+32], mm5
>   movq    [EDX+40], mm6
>   movq    [EDX+48], mm7
>   movq    [EDX+56], mm0
>   add     esi, 64
>   add     edx, 64
>   dec     ecx
>
>   jnz    @loopMemToL1
>
>   mov     edx, ebp       // Kopierer fra L1 til system memory
>   mov     ecx, 32
>
> @loopL1ToMem:
>
>   movq    mm1, [EDX]     // Leser inn data fra L1
>   movq    mm2, [EDX+8]
>   movq    mm3, [EDX+16]
>   movq    mm4, [EDX+24]
>   movq    mm5, [EDX+32]
>   movq    mm6, [EDX+40]
>   movq    mm7, [EDX+48]
>   movq    mm0, [EDX+56]
>   movntq  [EDI], mm1     // Lagrer i dest
>   movntq  [EDI+8], mm2
>   movntq  [EDI+16], mm3
>   movntq  [EDI+24], mm4
>   movntq  [EDI+32], mm5
>   movntq  [EDI+40], mm6
>   movntq  [EDI+48], mm7
>   movntq  [EDI+56], mm0
>   add     edx, 64
>   add     edi, 64
>   dec     ecx
>
>   jnz    @loopL1ToMem
>
>   dec     ebx
>
>   jnz    @loop2k           // Ta neste blokk
>
>   test    eax, eax
>
>   jz     @NoRestMem
>
>   mov     ecx, eax
>   cmp     edi,esi
>
>   ja     @down
>
>   je     @NoRestMem
>
>   sar     ecx, 2           // copy count DIV 4 dwords
>
>   js     @NoRestMem
>
>   rep     movsd
>   mov     ecx, eax
>   and     ecx, 03h
>   rep     movsb            // copy count MOD 4 bytes
>
>   jmp    @NoRestMem
>
> @down:
>
>   lea     esi, [ESI+ECX-4] // point ESI to last dword of source
>   lea     edi, [EDI+ECX-4] // point EDI to last dword of dest
>   sar     ecx, 2           // copy count DIV 4 dwords
>
>   js      @NoRestMem
>
>   std
>   rep     movsd
>   mov     ecx, eax
>   and     ecx, 03H         // copy count MOD 4 bytes
>   and     esi, 4-1         // point to last byte of rest
>   add     edi, 4-1
>   rep     movsb
>   cld
>
> @NoRestMem:
>
>   emms
>   add     ebp, 2048
>   mov     esp, ebp
>   pop     ebp
>   pop     edi
>   pop     esi
>   pop     ebx
>
> end;
>
>

> it seem's that only above >= 256Kb copying fastmove() is faster and
> most more important there exists no important difference between the use of
> prefetch and without.

Apparently your processor has 256Kb cache :)

--
Andrew Rybenkov.

create labels, logos, image lists
for your programs and websites with
  "Imagizer: Click and Get It",
  http://www.geocities.com/arybenkov/imagizer/

> most more important there exists no important difference 
> between the use of prefetch and without.

I usually get at least 20% perf. improvement with prefetching
on memory-intensive code, but tweaking the prefetching distance
and time is paramount.

Eric

Hm, how should be an optimial performance test code programmed ?

In my measurement I allocate 3 distinct memorybuffer's, say A,B, X and copy
interleaved from A to X and B to X. This in a loop 100 times.
I tried to use NOT aligned buffers, because that's more often the case,
and i tried to use non-multiple buffersize but fastmove() raises AV's on
these :(

I known an PIV is not the best CPU for comparsions, it is to unpredictable.
But fastmove() show's me it is only in certainly small cases usefull such
highoptimized stuff :)

Best, Hagen

"Eric Grange" <egrange@glscene.org> schrieb im Newsbeitrag
news:3D78C549.6C15FD71@glscene.org...
> > most more important there exists no important difference
> > between the use of prefetch and without.
>
> I usually get at least 20% perf. improvement with prefetching
> on memory-intensive code, but tweaking the prefetching distance
> and time is paramount.
>
> Eric

If memory bandwidth is fully used by the code there is no time left for
prefetching. (memory bound code)

If the algorithm loads data and works on them, the memory bus will not
be utilized when the CPU is "working" that is calculating something.
Here the bus can be doing prefetch's. This will parallelize calculations
with data load/store and maximize throughput. Code will now be memory or
CPU bound.

A MemMove will hopefully be memory bound and there will be no time left
for prefetch.

However Atle's FastMove is kind of special. It is like the algorithm
proposed by Intel.
My own timings showed that it clearly benefitted from prefetches.
It is only fast when copying data from RAM to RAM.

Greetings
Dennis

Eric Grange wrote:

> > most more important there exists no important difference
> > between the use of prefetch and without.
>
> I usually get at least 20% perf. improvement with prefetching
> on memory-intensive code, but tweaking the prefetching distance
> and time is paramount.
>
> Eric

I was referring to the prefetch distance, if prefetch at [EAX+64] f.i.
that it should be timed as appropriately so that whenever the data
at [EAX+64] is requested (via movq f.i), is the time the prefetch
just completed.
If you request what you prefetched too soon, it won't be ready, 
and there will be a stall, and you will not gain much. If you request
what you prefetched too late, the cache may be busy prefetching
the next bit and will not be able to respond immediately. In that case
I've often seen performance go down (I don't know the exact
explanation, I suppose it is a synchronization thing between all the
cache levels, I only know it exists...).

> I tried to use NOT aligned buffers, because that's more often the case,

Not necessarily, unless this moves are used in string manipulations,
you'll often transfer (or should at least) between aligned blocks
(because your structure sizes should be aligned).

Eric

If the CPU has no full-featured speculative prefetching 
(P3, early K7 and previous), or if this speculative prefetching 
is disabled due to silicium bugs (all P4s before Northwood),
if your load/store instructions are arranged in a long bunch,
you'll not be completely memory bound, but rather have something like:

 1) reads memory
 2) writes the first read bits while reading the lasts
 3) write last bits

If you have more opcodes than the pipeline and instruction scheduler 
can accomodate (or are nearing that limit), 1 & 3 won't overlap completely
when looping.

Prefetching should ensure that data needed by 1 is already in cache,
thus allowing 1 to be fast, and allowing in turn 1 & 3 to be fully overlapped.
This also allows sendind sustained requests to the memory with no "wait cycles"
between requests. Such waits will results in full memory-cycles waits, 
and memory-cycles are much longer than cpu-cycles. F.i. a 1 cpu-cycle wait for 
a 1 GHz CPU can effectively result in a 4 to 5 cpu-cycle wait with DDR 266, 
plus the various memory latencies...

Eric

Sorry, 
Outlook Express must have done that behind my back, 
I almost never use it...

BTW, which newsreader still does not support Base64?

Eric

In article <3D7CCAD2.84E99281@glscene.org>, Eric Grange says...

> Sorry, 
> Outlook Express must have done that behind my back, 
> I almost never use it...
> 
> BTW, which newsreader still does not support Base64?

Gravity, for instance.
-- 
Rudy Velthuis (TeamB)

"If we knew what it was we were doing, it would not be called research,
 would it?" -- Albert Einstein

What I have seen also is that speed gain when using prefetching is higher on
Athlon that on PIV.

see http://esibert.developpez.com/delphi/prefetch/

I have about 20-30% on my athlon and 0% (and sometime less) on my PIV

Armindo


> Hi,
>
> where can I found some prefetching example?
>
> thanks
>
> Armindo
>
>

>
> Here is an example of how you can use the routine above to move
> memory in blocks of 4k. It uses about 90% of theoretical memory
> bandwidth (at least it does with 133MHz SDRAM and 1GHz PIII).
>
thanks

Armindo

Hi
Can i see your programm that you used to test this?
Would be interested to see if i get the same results on my systems.

cya


"ADS" <nospam@wanadoo.fr> wrote in message
news:3d7defa3@newsgroups.borland.com...
>
> What I have seen also is that speed gain when using prefetching is higher
on
> Athlon that on PIV.
>
> see http://esibert.developpez.com/delphi/prefetch/
>
> I have about 20-30% on my athlon and 0% (and sometime less) on my PIV
>
> Armindo
>
>
> > Hi,
> >
> > where can I found some prefetching example?
> >
> > thanks
> >
> > Armindo
> >
> >
>
>

Try this link for the exe
http://esibert.developpez.com/delphi/prefetch/atelier.exe

and for the source http://esibert.developpez.com/delphi/mmx2/image.zip

Armindo