All times are UTC-06:00




Post new topic  Reply to topic  [ 25 posts ] 
Author Message
 Post subject: Re: libfreevec released!
PostPosted: Fri Oct 07, 2005 2:26 am 
Offline

Joined: Mon Oct 11, 2004 12:49 am
Posts: 35
I put together a full suite of scanning routines. Mail me if you didn't get them on the AltiVec mailing list.


Top
   
 Post subject: Re: libfreevec released!
PostPosted: Sat Oct 08, 2005 7:52 pm 
Offline

Joined: Tue Nov 02, 2004 2:11 am
Posts: 161
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


Top
   
 Post subject: Re: libfreevec released!
PostPosted: Sun Oct 09, 2005 12:17 am 
Offline

Joined: Wed Oct 13, 2004 7:26 am
Posts: 348
Quote:
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.
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


Top
   
 Post subject: Re: libfreevec released!
PostPosted: Sun Oct 09, 2005 12:21 am 
Offline

Joined: Wed Oct 13, 2004 7:26 am
Posts: 348
Quote:
I put together a full suite of scanning routines. Mail me if you didn't get them on the AltiVec mailing list.
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


Top
   
 Post subject: Re: libfreevec released!
PostPosted: Mon Oct 10, 2005 2:40 am 
Offline

Joined: Mon Oct 11, 2004 12:49 am
Posts: 35
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.


Top
   
 Post subject: Re: libfreevec released!
PostPosted: Wed Oct 12, 2005 2:12 am 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
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.
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


Top
   
 Post subject: Re: libfreevec released!
PostPosted: Wed Oct 12, 2005 2:15 am 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
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.
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


Top
   
 Post subject: Re: libfreevec released!
PostPosted: Fri Oct 14, 2005 12:12 am 
Offline

Joined: Mon Oct 11, 2004 12:49 am
Posts: 35
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. :-)


Top
   
PostPosted: Sat Dec 23, 2006 5:44 pm 
Offline

Joined: Thu Feb 16, 2006 8:10 pm
Posts: 98
Image

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....


Top
   
 Post subject:
PostPosted: Sat Dec 23, 2006 7:54 pm 
Offline
Genesi

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1422
Thanks for the bump popper!

R&B :)

_________________
http://bbrv.blogspot.com


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 25 posts ] 

All times are UTC-06:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
PowerDeveloper.org: Copyright © 2004-2012, Genesi USA, Inc. The Power Architecture and Power.org wordmarks and the Power and Power.org logos and related marks are trademarks and service marks licensed by Power.org.
All other names and trademarks used are property of their respective owners. Privacy Policy
Powered by phpBB® Forum Software © phpBB Group