@Henry SIMD

you seem to have answered your own question ,or would have if you had read the Lebfrevec pages.

libfreevec appears to be an evolving SIMD routine replacement for GlibC , in this case optimised with Altivec code for any PPC CPU that has this SIMD ability.

just as you could replace the generic slower GlibC routines for any CPU that has other SIMD Co-pro abilitys, MMX/SSE etc with optimised versions there.

even GPU Co-processors if you wanted, and were willing to add to the work already done, such as the Gallium3D driver framework http://www.bitblit.org/gsoc/g3dvl/proposal.shtml with some imagination.

the point being made seems to be there are many totally or little used Co-Processors on many generic Chips and pluged into PC motherboards that could be used to give a massive boost to everyday apps by changing the generic glibc and related librays in whatever CPU family you are using today.

markos of that libFreeVec for instance tells you have to simply start using his replacements and get that needed boost

http://www.freevec.org/content/howto_using_libfreevec_using_ld_preload

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

and

"libfreevec 1.0.4 has been released a while ago, but it's only today that I've managed to finish with the benchmarks. Check the URL to see how a G4, a G5 and a MPC8610 compare to a Athlon X2 5000! :D

http://www.freevec.org/content/libfreevec_104_benchmarks_updated

"

sure, its far harder to wrap 128bit Alitvec code into MMX/SSE SIMD, that the other way around SSE wrapper into Altivec native for Emulation etc but it could still be far better as you pint out above, they hardly even tryed to use the current hardware capabilitys to its SIMD potential

@AC

I don't know what all your comments about freevec are on about... If you look at the Linux kernel, you will find for x86 it basically uses MMX or SSE only for memcpy and I think calculating checksums for RAID stuff. It enables an Altivec bit (so apps can use it), and has Altivec emulation if an app decides to use it without checking if it's on the right CPU type. It's up to applications writers, GCC, and glibc beyond that.

None of this has much to do with virtualbox -- if they use altivec instructions in it, great. If not, the kernel can't help that.