Subject: Re: AltiVec in the kernel

From: [email-masked] (Linas Vepstas)
Date: Wed, 19 Jul 2006 13:10:47 -0500

On Wed, Jul 19, 2006 at 03:56:10AM +1000, Paul Mackerras wrote:
> A lot of compression and encryption algorithms, by their very nature,
> are very difficult to parallelize enough to get any significant
> improvement from altivec.  I looked at SHA1 for instance, and the
> sequential dependencies in the computation are such that it is
> practically impossible to find a way to do 4 things in parallel.  The
> sequential dependencies are of course a critical part of the way that
> SHA1 ensures that a small change in any part of the input data results
> in substantial changes in every byte of the output.

But perhaps, in principle, couldn't one run four independent streams 
in parallel?  Thus, for example, on an SSL-enabled web server, one 
could service multiple encryption/decryption threads at once. 

In practice, I don't beleive the infrastructure for that kind of
parallelism is in place. I'm struggling to find a reason to develop
that kind of infrastructure. Mumble something about Cell. 

> I think that there are actually very few places in the kernel where we
> are doing something which is parallelizable, sufficiently
> compute-intensive, and not bound by memory bandwidth, to be worth
> using altivec.

Yes.

As to non-kernel applications, is there anything for GMP (the 
Gnu Multi-Precision library, an arbitrary-precision math library)
on the Altivec? How aout the Cell?

--linas