AltiVec in the kernel

[Brian D. Carlstrom]

At Thu, 20 Jul 2006 12:42:55 -0500,
Linas Vepstas wrote:
> > We found glibc sucked for that.
> 
> Only because someone was asleep at the wheel, or there was a bug. 
> 
> When glibc gets ported to a new architecture, one of the earliest 
> tasks is to create optimized versions of memcpy and the like. 
> Presumably, on powerpc, this would have been done more than a 
> decade ago; its hard for me to imagine that there'd be a problem 
> there.  Now, I haven't looked at the code, but I just can't imagine 
> how this would not have been found and fixed by now. Is there
> really a problem wiht glibc performance on powerpc? I mean,
> this is a pretty serious accusation, and something that should 
> be fixed asap.

In the course of my work, I use powerpc architecture simulators. When
working on Mac OS X with a G5, I had to implement some of the basic
AltiVec specifically for use by their libc memcpy implementation. A
quick grep memcpy in the recent glibc sources on my linux/ppc box seems
to show no where near that level of optimization, but I admit that I
could have missed something. However, I would not be surprised that
glibc avoided AltiVec specific optimizations since it would add to the
complexity of supporting various architectures with one binary. On Mac
OS X, libc actually delegated a small number of libc calls such as
memcpy via a kernel managed page at the end of the address space that
setup which routines to use based on currently running architecture.

-bri