RE: AltiVec in the kernel

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> I remember a discussion from one of the Gentoo guys wanting to do this
> with libfreevec.
> 
> Getting into Gentoo, though, is not difficult. The problem with this
> is Gentoo is one Linux distribution. I would be more impressed if code
> was in Debian or Ubuntu considering their exhausting lead times on
> producing new package trees and accepting new code :D

It seems to me that the "problem" just doesn't exist at the moment...
libfreevec is nice, but it's unfinished, and the author is away for now
and thus not able to complete nor work on a port to glibc or others.

Once he's back, of course, it would be nice to have him complete the
work (and maybe get some outside help).

I'd like to also verify his methodology for measuring the performance
improvements, I'm not saying it's wrong, I want to make sure some of the
overhead of enabling altivec has been properly measured for various
usage patterns and thus possibly restrict the optimisations to patterns
where that matter, as an example, only use altivec for large memcpy's.

Once that's done, I don't see any good reason why it would be so hard to
include that work into glibc, or rather into the powerpc add-ons in a
first step and maybe then the whole into glibc. Maintainers rarely
rejects things just for the sake of doing so. If they do so, they
usually provide reasons, often boiling to implementation details, than
can then be fixed. Note also that in the case of submitting code to
glibc, there is a copyright assignment issue to be sorted out I think (I
don't know the details here).

I have the feeling that there is very little point to this thread. Let's
wait for Konstantinos to be back and submit his work, possibly to this
list at first for review, tests, etc... and then to the appropriate
maintainers. If there is a problem at that point, then we'll see how we
can address it.

Regards,
Ben.