Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <3510D70A.7DBC@rug.ac.be>
Date: Thu, 19 Mar 1998 09:27:54 +0100
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: Burton Radons <loth AT gec DOT net>
Cc: djgpp-workers AT delorie DOT com
Subject: Re: libc replacement (memcmp)
References: <350f6b73 DOT 34099775 AT mail DOT gec DOT net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Burton Radons wrote:
> 
> memcmp used to compare using char-by-char, so I replaced it with
> int-by-int -- quick optimizations, but it hadn't been done in three
> years, so... bcmp follows this message.
> 
> 350% speed increase in memcmp at peak (12 bytes and up), never slower,
> reacts the same as before.

For functions that are inlined by the compiler, I suggest to leave the
libc functions in their most simple (and inefficient) form, since they
won't be used at all. If it is decided to optimize them in despite, it
may be better to rewrite them in (inline) assembler. That way you might
get a 1000% speed increase on the slower varieties of x86 processors. 
On this particular function:
Since memcmp is often done on byte-aligned data, it may be better to
pre-align the pointers before going 'lword'.
Does this function work with s1 or s2 being NULL, or shouldn't it?
This function contains bugs. (If it may be a hint: unsigned char)

That reminds me that I have a function for memmove, which isn't inlined,
is extremily slow and used quite often. I'll send the patch shortly.

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/