🚀 go-pugleaf

In article <372DD2D2.5DF86734@bigfoot.de>,
  Arno Fehm <afehm@bigfoot.de> wrote:
> Robert AH Prins wrote:
> ...
> > Below is a replacement for the TP/BP MOVE() routine. Two versions are given,
> > one a replacement for the routine in the TP6 RTL (and likely the TP/BP7) the
> > other as an assmbler procedure to be used if you don't have the RTL sources:
> [ good code snipped ]
>
> Robert! It really seems to me, you are spending lot of effort in
> improving the 16 Bit (isn't it?) MOVE of PASCAL. But why always just in
> 32 bit code?

I've got my reasons for still using TP6...

> I compared your optimized MOVE with my primitive MMX MOVE, and the
> results for 64000 Bytes were 1.1msec against 0.6 msec! That is 56 MB/sec
> against 100 MB/sec.
> WHY does none of YOU, who HAVE the ability to write a professional MOVE
> use these extended features? Because you think, there are still these
> without MMX? We can support both!

Have you had a look at the Intel page,

<http://developer.intel.com/drg/pentiumII/appnotes/813/813.htm>

downloaded the program and run it? You will see that the advantage of MMX is
virtually non-existant - in some cases it's worse!

Part of the text on that page is:

<quote> On systems based on the Pentium II processor and with memory
alignment on 8-byte boundaries (memory addresses evenly divisible by 8),
including alignment on 32-byte boundaries, special "fast string" microcode
will be invoked after:

rep movsb = 64 bytes (8 bytes)
rep movsw = 128 bytes (8 words)
rep movsd = 256 bytes (8 dwords)

have been transferred. The range of speedup (0-30%) of "rep movs" over moving
qwords with "movq" using MMX technology is because of evictions from the L1
and L2 caches. There may be negligible speedup using "rep movs" over "movq" if
the load into the register and the store to main memory both cause cache line
evictions. A noticeable speedup will occur if neither the load nor the store
cause any evictions.
</quote>

I could adapt my code very easily to make the destination 8-byte aligned, but
given the above sizes for the invocation of fast microcode and the size of
data structures moved, I'm not sure if I would gain anything.

Here are the results, forgive me the possible typos, as the Intel program
doesn't give them in text form:

Copy & Fill 4194304 bytes
MB/s: cold cache / warm cache
-----------------------------
Source & Destination Aligned
bytes (rep movsb)               69.9/104.9
words (rep movsw)              139.8/104.9
dwords (rep movsd)             139.8/139.8
qwords (FP registers)           83.9/139.8
qwords (MMX (tm) Technology)   139.8/104.9
Fill dwords (rep stosd)        209.7
Fill qwords (rep movq)         139.8

Source Unaligned, Destination Aligned
bytes (rep movsb)               83.9/104.9
words (rep movsw)               83.9/104.9
dwords (rep movsd)              83.9/135.3
qwords (FP registers)           83.9/104.9
qwords (MMX (tm) Technology)    83.9/139.8
Fill dwords (rep stosd)        209.7
Fill qwords (rep movq)         139.8

Source Aligned, Destination Unaligned
bytes (rep movsb)               35.0/ 10.5
words (rep movsw)               59.9/ 52.4
dwords (rep movsd)             104.9/ 83.9
qwords (FP registers)          139.8/ 83.9
qwords (MMX (tm) Technology)   139.8/104.9
Fill dwords (rep stosd)        139.8
Fill qwords (rep movq)         209.7

PC: 350 MHz PII 64 MB NT 4 SP3

> And what about using 80 bit FP instructions to move memory? I once
> heared, this would be possible, too; and could be even more faster than
> these MMX instructions with only 64 bit!

Yes it is, but unless Intel has changed something in the FILD/FIST
instructions it's useless, as the pair cannot handle a number of bit
patterns.

> I really would like do write such MOVEs, but I'm afraid, I cannot manage
> all these aligning things and so on... But if there would be anybody
> interested in a cooperation to develop an optimized 64 or 80 bit MOVE,
> I'd join!

You've got all the aligning you want in my code, it shouldn't be too hard to
change it into 8/16 byte alignements in stead of the 4-bytes I use...

Regards,

Robert
--
Robert AH Prins
prinsra@williscorroon.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own