freevec.org

Here's the link to the announcement:

http://lists.fixstars.com/pipermail/yellowdog-announce/2009-June/000214.html

From the press release:

I'm in the process of rewriting libfreevec and porting it to other SIMD platforms, apart from AltiVec (which I consider dead or dying, unfortunately, thanks to the Big Powers that decided it's no longer important along with PowerPC, but that should be another topic). Anyway, the main platforms chosen are AltiVec (of course :), SSE (SSE2, SSE3 and possiby SSE4), ARM NEON and Cell SPU.

There are many comments to be made looking at the results:

• First, the AltiVec unit is a very powerful SIMD engine which is totally underused throughout the OS(Linux that is) apart from specific applications. In fact, its use in the kernel is strongly discouraged, perhaps rightly perhaps not, that still remains to be proved wrong.

• It's a fact that the Athlon X2 is a faster CPU than every PowerPC CPU we tested, but still there are plenty of cases where it proved to be slower than its counterparts and that was not always the "fault" of AltiVec and libfreevec.

• libmotovec behaves strangely and apart from strlen() is slower than libfreevec anyway. Still, it seems to be doing some really clever tricks and I intend to look at it closer in the future.

• The MPC8610 is a very powerful CPU and especially when we consider its specs (1.3Ghz, 25Wts maximum power draw, WITHOUT the need for a northbridge) we see that the CPU is made to be a winner! Imagine a PowerPC netbook with a 8610, builtin display, fast ram access, very low power consumption. We just have to remember that the Intel Atom, the Via Nano AND the AMD Athlon 64 2000 all require a northbridge CPU which consumes too much power (see here and here). However from our own tests, the MPC8610 developer system consumes just 35Wt total at idle, and 37Wts at full power!!! This is a complete system with many features not required for an end consumer product (eg. a netbook). Coupled with the power of the AltiVec unit, it is just a question of time for someone to produce (again) a consumer PowerPC system using the MPC8610.

• Finally, with regard to glibc performance, even if we take into account that some common routines are optimised (like strlen(), memcpy(), memcmp() plus some more), most string functions are NOT optimised. Not only that, glibc only includes reference implementations that perform the operations one-byte-at-a-time! How's that for inefficient? We're not talking about dummy unused joke functions here like memfrob(), but really important string and memory functions that are used pretty much everywhere, like strcmp(), strncmp(), strncpy(), etc.

• In times where power consumption has become so much important, I would think that the first thing to do to save power is optimise the software, and what better place to start than the core parts of an operating system? I can't speak for the kernel -though I'm sure it's very optimised actually- but having looked at the glibc code extensively the past years, I can say that it's grossly unoptimised, so much it hurts.

Hello again,

I managed to find time to update all of the libfreevec benchmarks to the latest version 1.0.4 and also include more complete tests and added a non-ppc architecture (an Athlon X2 5000 @2.6Ghz) where the same tests were run (as 32-bit apps on a 64-bit Linux) for comparison. This is important for two reasons:

• to find how PowerPC CPUs compare to a current popular x86 CPU (the same benchmarks will be done on an Intel CPU soon)
• to find any deficiencies in glibc itself (as you will see there are many).

All benchmarks were run on OpenSuse 11.0, except for the G5 which uses Debian Lenny/testing. The compiler used was gcc 4.3.2. All functions have been tested to work correctly on each platform.

Ok, let's suppose you've downloaded libfreevec, built it successfully and now you want to use it for the whole system, without recompiling the whole system to use the library! Is it possible? Thanks to a glibc feature you can!

There are two ways to do that:

• one is to use the LD_PRELOAD environment variable, eg. at boot time, but there is a more elegant way to do this.
• by use of the /etc/ld.so.preload file, which is most likely distro-agnostic, so that the dynamic loader ld.so loads libfreevec before any other library (including libc.so).

  The 2nd is a much more elegant solution, IMHO, and I've been using it for months with no problems whatsoever. So, after you install the library somewhere (by default it's installed in /usr/local/lib/) you could just do a:

  echo /usr/local/lib/libfreevec_libc.so > /etc/ld.so.preload

  Beware it has to be the libfreevec_libc.so and not the libfreevec.so as the 2nd one prefixes each function with vec_ and is only useful to someone that wants to use the library explicitly -for whatever reason.

  The next application you will load you will use the AltiVec functions in libfreevec! Enjoy! :)

  Note: This has a slight overhead which would reduce some of the performance in the functions, but would still prove a good move in most cases.