From: Elliott Oti <e DOT oti AT stud DOT warande DOT ruu DOT nl>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: memcpy(); is there something faster?
Date: Wed, 25 Dec 1996 15:30:30 -0800
Organization: Academic Computer Centre Utrecht, (ACCU)
Lines: 22
Message-ID: <32C1B916.34DF@stud.warande.ruu.nl>
References: <m0vc9eo-000S1jC AT natacha DOT inti DOT edu DOT ar>
NNTP-Posting-Host: warande1078.warande.ruu.nl
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

Salvador Eduardo Tropea (SET) wrote:

  <SNIP> <ALTERNATIVE MEMSET CODE>
 
> That's practically equal to memcpy (you will save some little test at
> the begining of memcpy => 6 o 10 cicles in 128000)


Partially true - but djgpp inlines memcpy only for length values fixed at
compile-time, so for variable buffers you get a function call. Inlined,
Mihai's code is considerably faster for *small* buffers ( 200 bytes - 2K);
while for 64K+ buffers you indeed run against the hardware limits of
memory access times. In my usage, it was about as fast as memcpy() for
double buffers, slightly faster, but when I replaced memcpy() with it in
some polygon filling code I had the run speed doubled.

The fastest method given you know the buffer size in advance would probably
be an unrolled rep movsd loop, not that that would make a world-shaking
difference; on my DX4-100 with slow (70ns) RAM the CPU is idling 7 cycles
for every byte written through in burst mode, so it wouldn't matter a bit.

E