| Power Developer https://www.powerdeveloper.org/forums/ |
|
| libfreevec released! https://www.powerdeveloper.org/forums/viewtopic.php?f=23&t=387 |
Page 2 of 2 |
| Author: | hobold [ Fri Oct 07, 2005 2:26 am ] |
| Post subject: | Re: libfreevec released! |
I put together a full suite of scanning routines. Mail me if you didn't get them on the AltiVec mailing list. |
|
| Author: | gunnar [ Sat Oct 08, 2005 7:52 pm ] |
| Post subject: | Re: libfreevec released! |
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 |
|
| Author: | markos [ Sun Oct 09, 2005 12:17 am ] |
| Post subject: | Re: libfreevec released! |
Quote: Markos,
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.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. 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 |
|
| Author: | markos [ Sun Oct 09, 2005 12:21 am ] |
| Post subject: | Re: libfreevec released! |
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 |
|
| Author: | hobold [ Mon Oct 10, 2005 2:40 am ] |
| Post subject: | Re: libfreevec released! |
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. |
|
| Author: | Neko [ Wed Oct 12, 2005 2:12 am ] |
| Post subject: | Re: libfreevec released! |
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 |
|
| Author: | Neko [ Wed Oct 12, 2005 2:15 am ] |
| Post subject: | Re: libfreevec released! |
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 |
|
| Author: | hobold [ Fri Oct 14, 2005 12:12 am ] |
| Post subject: | Re: libfreevec released! |
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.
|
|
| Author: | popper [ Sat Dec 23, 2006 5:44 pm ] |
| Post subject: | libfreevec mentioned in the gcc-patches |
 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.... |
|
| Author: | bbrv [ Sat Dec 23, 2006 7:54 pm ] |
| Post subject: | |
Thanks for the bump popper! R&B :) |
|
| Page 2 of 2 | All times are UTC-06:00 |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|