freevec.org

Description

According to the man page, the strcmp() function compares the two strings s1 and s2. It returns an integer less than, equal to, or greater than zero if s1 is found, respectively, to be less than, to match, or be greater than s2. It returns an integer less than, equal to, or greater than zero if s1 (or the first n bytes thereof) is found, respectively, to be less than, to match, or be greater than s2.

strcmp() due to its extended use in many applications, is usually assembly optimised for most architectures (actually most string functions are optimised). Obviously, it most likely is optimised for x86 and x86_64, but and most of the times for PowerPC too. In any case the glibc implementation compares 32-bit (or 64-bit depending on the arch) blocks where possible. In libfreevec we also do that, but as we already have stated, we also use modern SIMD units (AltiVec for PowerPC CPUs, and in the future SSE for x86 CPUs).

Each CPU in detail:

And for comparison here is the result of the same benchmark run on an Athlon X2 5000 (2.5Ghz), running 32-bit code:

Results/Comments

The Athlon has a much faster FSB (800Mhz vs 533Mhz for the G5 and the MPC8610), and given the performance in memcmp() we should expect something similar, since, after all, the difference of memcmp() and strcmp() is just a check for the zero byte (a branch, which should drop performance, but not much). However, we were greatly surprised to see that strcmp() is probably the reference implementation (doing byte compares, as shown by the throughput, ~800MB/s which is the speed of the FSB really), which made the Athlon slower even than the MPC8610 and up to the same level as the G4!! Comparing only glibc functions the G5 is more than twice as fast as the Athlon and more than 500% faster when using libfreevec! Though to be frank, this speed occurs only in aligned strings, for unaligned strings, performance drops badly on the PowerPC CPUs, while the Athlon retains the ~800MB/s speed.

This is really a great handicap of glibc, we're not talking about some exotic media encoding, but a commonly used string comparison function in the most widely used free C library!!! As you will see in the rest of the string functions, the situation is not much better and strcmp() is not just an exception, unfortunately. Lastly, libmotovec's version (tested on the G4), while it performs ok for smaller sizes, for some reason performance drops to an abysmal level for larger sizes, but libfreevec is consistently faster anyway.