FAQ

A collection of Frequently Asked Questions about libfreevec. 

Q: Who should use libfreevec? 

A: libfreevec is targeted for use in applications that are destined to run in
the G4 PowerPC family of CPUs, or any PowerPC that includes an AltiVec unit,
and could benefit from a speed up in commonly used routines, such as memory
and string routines. It's more fitted for use in larger cpu-intensive apps
rather than the custom 100-line C program that takes 1 second to run. 

Q: What about the G5 CPUs? 

A: Well, in theory these should run, or at least with slight modifications, 
but there is no guarrantee that they will perform as well as on the G4. One 
reason is that the G5 has a slightly different Altivec unit (I will not say
'crippled' because it isn't, it's just different). The other, more important,
reason is that the G5 has a very capable 64-bit unit, and a much faster FSB
which in some cases more than makes up for the less capable AltiVec unit.
Preliminary tests on the G5 using very early versions of the library, have
shown that if there is to be any gain from using AltiVec for such function
replacements, then these will have to be modified specifically for the G5.
It won't do to just take the 32-bit versions and expect them to work 
top-speed. 

Q: Who can use it and under what License? 

A: Anyone really. The license chosen is the LGPL. This means that you are
free to use it in free software projects, and you're most welcome to use it
even in closed-source/proprietary software, albeit with a few not irrational
restrictions. Read the license text for details. 

Q: Why libfreevec? There is already libmotovec by Freescale! 

A: Indeed. And much to their credit I'm still struggling to reach the
performance of this library. These guys really knew what they did :-)

Seriously, the fact is that libmotovec is not really free software, there are
difficulties in getting it incorporated into major distributions, eg. Debian
will never include it under this current license. Plus, it's written in ppc
assembly, which although is great for performance, it's really difficult to
maintain/debug/whatever. Not many people are that proficient with ppc asm, I
know I am not. libfreevec is written in C, using the AltiVec intrinsics
available in GCC. This means that as GCC gets better instruction scheduling
for the G4, so libfreevec might benefit from this as well. In addition, the
way it's written right now, it allows for easy expansion with new functions,
or even optimization of the existing ones, with just fiddling with a couple
of macro modules. And lastly, libfreevec offers more AltiVec optimized
functions than libmotovec, plus a consistent cache-prefetching mechanism
used in all of the available functions. Plus, if I might say so myself, some
of the libfreevec functions are even faster than the libmotovec
equivalents.:-) 

Q: Why can't you just copy parts of libmotovec into libfreevec? 

A: That's not really a solution. To be truthful, I actually have looked at
the source code of the libmotovec's functions. But my knowledge of ppc asm
is very minimal, I barely understood the reason of the particular choice of
instructions, and their sequence. I'm sure others will probably find it as
obvious as sunlight, but I assure you I didn't. Anyway, the thing is that I
can't just copy them, due to license issues. Even if it was possible, I don't
think it would be nice, at least not without extensive comments, which I can't
add anyway. And as an AltiVec guru, Holger Bettag, says quite often, "AltiVec
asm might give you an extra 2% performance, but why bother?". Holger, I
paraphrased it a little bit, I hope you don't mind! And anyway, the fact that
it would be written in ppc asm, would also mean that I would not be able to
get as much feedback from users as I would like, as again not many people are
experienced in PowerPC assembly. 

Q: There is already liboil, why don't you put your code there? 

A: Actually I intend to, but not this particular code. The goal for liboil is
slightly different, it offers its own API, and a whole lot of highly optimized
routines to perform various algorithms. On the other hand, I wanted to
optimize existing functions from GLIBC, libstring (which is heavily used in
MySQL), etc. I do plan to write some code for liboil at a later stage, but not
at this particular moment. 

Q: Will my program run faster with this library? And how much faster? 

A: It depends. If your program does 1 million memcpy(), of 5 bytes each, the
library will not benefit you at all. It might even be slower, due to the a
slightly bigger overhead. Actually, in truth it's quite bad design to do a
memcpy for such a small buffer. On the other hand, depending on what your
application does, you might enjoy significant benefit from using such a
library. Eg. the AltiVec version of swab() in this library is ~7x faster than
the scalar code. But it won't make a difference to your program if you only
call it at the initialization code for a 100 byte buffer. Also, does your app
use mainly aligned or unaligned buffers? So far, I can say that the
performance hit from unaligned addresses is mostly minimized, but it's of
course a penalty. For actual results, please check the Features and Benchmarks
pages. 

Q: But AltiVec is useless/not good on small buffers? 

A: Quite true. AltiVec is a very powerful beast but it needs lots of data to
feed. Throughout the library I try to use AltiVec only where it's useful and
needed. Most of the times, I just redesign an algorithm to be more efficient,
and after a particular size threshold, AltiVec kicks in. That way I try to get
the best of both worlds. 

Q: I noticed that some of the functions are even faster for small sizes, how 
is that possible? 

A: Well, for certain AltiVec is not used in these cases. Most probably the
original algorithm was quite dumb (ie. not optimized). When I was writing the
replacement functions, I always had in mind that they have to be equally fast,
if not faster, to the originals, for small sizes. It would look bad if a
program that uses memcpy(), but only on smaller sizes, became slower for that
reason. I tried to achieve this as much as possible, though I might have missed
something. That's why user and developer feedback is so important, so send them
patches :-) 

Q: Why does the speed drop so much with very big sizes? 

A: Assuming you refer to the memory functions, it's because data has to be
fetched from the actual memory rather than the L1 or L2 caches. And AltiVec
has an 128-bit bus but to the L1 and L2 caches not to the main memory. Still,
I use cache prefetching in most of the functions and the performance will
still be better than the original functions. Don't expect miracles though,
in these cases a 20-30% performance gain is more likely rather than a 10x. 

Q: How can I make sure I get the most of it? 

A: Try to use as much aligned data as possible. eg using well known tricks
like the following: 

unsigned char __attribute__ ((aligned(16))) *buffer; 

instead of just declaring a variable. That way, you'll skip the time spent
on handling unaligned data. Also, try to avoid useless invocations of
memcpy() or similar functions for tiny buffers. Though GCC is supposed to
inline copying code for some cases, this is not guaranteed and should not
be taken for granted all of the time. Instead try to organize your data
into bigger structures. It's better in the long run anyway. Q: How does
it work? 

A: Please see the Docs section and the actual Source code for details. 

Q: Ok, let's say that it's nice, what's next? 

A: Well, the ultimate goal is to get as much user feedback for these
functions, optimize them as much as possible and then incorporate them
into the actual GLIBC and perhaps even the kernel. That way, Linux/powerpc
will have what MacOS X users have enjoyed for years :-) 

Q: Are there any mailing lists to discuss about its development? 

A: There is a project on Alioth, which offers a mailing list, plus the
Forums on PPCZone. Also, great discussions on AltiVec are taking place on simdtech.org.