I put together a full suite of scanning routines. Mail me if you didn't get them on the AltiVec mailing list.

Markos,

I'm wondering if it would be worth to write libfreevec in asm.

I'm not saying this because I think that asm is always a lot faster than c.
But I noticed the other day how retarded GCC can be.

I looked at GCC's asm output of a simple while loop and it made me cry.
The way GCC had build the loop it was 20% slower than it should have been.

Cheers
Gunnar

I'm not exactly I agree with that in general, though it may be worth in some cases where that extra 2% -as Holger puts it- is necessary.

For all this effort to succeed we have to first prove that Altivec can be beneficial in a wide range of tasks. To do that in asm, it will take 5x more the time it will do for the C versions and esp. in cases, where it's not just a simple algorithm, it will take probably more. Eg. I just finished the anagram algorithm -not Levenstein yet, it's next- which you asked, and it's quite complicated - details in separate message. I doubt I could have done it so fast in asm, even if I were a ppc asm expert -which I'm not. Of course, I would be quite happy to accept asm rewrites of particular functions in case they are proven to be faster and bug-free.

Also, another reason for being sceptical: The situation with powerpc support in gcc is getting better all the time. Eventually, it will reach a point where it will be hardly different than good hand-written asm, except perhaps some very weird cases. And I strongly believe in this.

Konstantinos

I actually extended your version a little bit, before I saw your routines there. And I scan for chars not ints so, i'd have to modify them a bit anyway. I'll post the modifications here, and of course in libfreevec, crediting you

Konstantinos

I made routines for all data types, for both directions, and scanning for either 'true' or 'false'. I noticed that each case could be slightly tuned in individual ways, so it is worth having a specific function for each case.

The thing about int-wise string compares rather than char-wise comes from the idea that what you really want is a vector-wide compare. Once you handled string end special cases (by masking off the junk after the terminating zero), a vector wide compare would make scanning completely unnecessary. But as it is, you have to scan for the leftmost difference. And scanning for ints is faster than scanning for chars, but equivalent once you solve the string end issue.


Oh, with regards to asm: asm will always tend to be a bit faster than C. But with the AltiVec interface, you are already using very specific vector instructions, so you have pretty much the same amount of control. Even scheduling can be done by hand for routines that need it, by compiling with -fno-schedule-insns -fno-schedule-insns2 -fno-strength-reduce.

I'd say the gap between C and asm is narrower for AltiVec than for plain C code. Going asm can still be a valid tuning option, but I see it as a final step. Starting out in asm is a lot more work. And if you have set your mind on finding the utimate fastest solution, you _will_ change the fundamental algorithm a few times over as you learn more about the problem. That means more work squared if you do it all in asm.

Wouldn't that completely break any optimisations gcc was making to any code AROUND your specially optimized AltiVec?

Is there a pragma or something that would turn off those in gcc for a certain block of code? I don't see anything in the gcc manual..

--
Matt Sealey

Wouldn't that completely break any optimisations gcc was making to any code AROUND your specially optimized AltiVec?

Is there a pragma or something that would turn off those in gcc for a certain block of code? I don't see anything in the gcc manual..

--
Matt Sealey

You'll have to separate the hand scheduled AltiVec code into a different compilation unit and compile with different flags. In most cases, GCC's instruction scheduling is beneficial, but it will mercilessly break any hand scheduled code. You cannot have your cake and eat it, too. But you can have two distinct cakes.

i didnt know which thread to bump so this seems good as it has many specialists.

i was just spending some spare time looking through the glibc altivec search to see how much work might have been done on Markos's wish to include his work one day and given that the CELL patches were put in it seems about the right time to look.

i was suprised to see freeVec mentioned and really think you might want to know about it...

heres the link and full text
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00149.html
"Re: [PATCH][PING] Add vectorization of builtin functions
From: Dorit Nuzman <DORIT at il dot ibm dot com>
To: Richard Guenther <rguenther at suse dot de>
Cc: gcc-patches at gcc dot gnu dot org, Andrew Pinski <pinskia at gmail dot com>, Roger Sayle <roger at eyesopen dot com>, Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>
Date: Sun, 3 Dec 2006 22:50:12 +0200
Subject: Re: [PATCH][PING] Add vectorization of builtin functions

--------------------------------------------------------------------------------

Richard Guenther <rguenther@suse.de> wrote on 30/11/2006 16:22:14:

> > > This is OK for mainline, assuming that the vectorization folks have
no
> > > objections. This infrastructure looks to be independent of the other
> > > pieces, so presumably can be committed before resurecting libgcc-math
> > > library (though my vote is that your exisiting maintainership is
still
> > > valid) or adding the x86 backend support. Is there anyone
investigating
> > > vectorized math support for the other backends?
> > >
> >
> > We'd probably want to exploit this feature for the Cell backend.
> >
> > On the SPU side, a simd math lib would probably be made available in
the
> > near future; the question is - do the library functions have to be
provided
> > with GCC, like Richard Guenther's implementation for AMD, or could we
rely
> > on the library to be present as an external package?
> >
> If libgcc-math works out it would be a natural place to stick these
> parts. This eases gcc configuration and usage.
>

but only for cases in which you can make the library code available with
gcc.
Andrew, do you know if that's going to be the case with the "SIMD Math
library for the Cell BEA"
(as you mention in -
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00019.html)?

> My fallback plan is to support target/OS dependent vector libraries
> similar to fortran -fexternal-blas, let's call it -fvecmath. At
> configure time the system provider could choose a kind of vector
> library he wants to support (like Intel MKL or AMD MKL) with
> --enable-vecmath=intel-mkl which the target/OS config could then
> use for enabling the right set of transformations (sin -> __sse2_sinv
> in case of Intel MKL, other symbols in other cases). We could even
> try to support multiple libraries, but then automatically linking
> both with -fvecmath could create symbol conflicts. Or allow
> configuring for multiple libraries but only enable one with
> -fvecmath=intel-mkl and let the target sort out things.
>
> The problem is really while for -fexternal-blas the ABI to the
> library is well-defined it differs for the different vector
> libraries (there's even PR22226 requesting support for IBM MASSV
> or Intel VML libraries).
>
> But before I start working on the infrastructure part of such
> change I'd rather have a decision on libgcc-math (to not waste
> my time twice).
>

sounds like there's room for both approaches?

> > On the PPU/powerpc side, would be nice to use some Altivec math library
> > (e.g. something like http://www.freevec.org/ ?)?
>

on second look - freevec doesn't look so relevant - it's not a vector-API
math lib, but
rather a vectorized implementation of standard GLIBC memory/string
functions.

Anyone knows a non proprietary math library for Altivec that we could make
available with gcc, using the libgcc-math scheme?

dorit"

http://gcc.gnu.org/cgi-bin/search.cgi?q=glibc+altivec

it seems if theres anyone patching for improved G4/G5 generic Altivec linux support , NOW IS THE TIME to do it or loose out on the momentum....

Thanks for the bump popper!

R&B :)

_________________
http://bbrv.blogspot.com