On Apr 18, 2007, at 9:13 PM, Miller Puckette wrote: > Well, I measured the difference and didn't see significant speedup > (on an > imac recently)... eventually it might make a difference, of > course. But > certain bit-bashing code (the square root thing, but more importantly > phasor~ and osc~) runs half again faster than any version I've been > able > to write with strict aliasing.
Do you have any info on that test, like which optimizations you tested? > An alternative would be to special-case the offending code > somehow. This > could be part of a larger effort to make the DSP code modular so > that SSE > instructions and whatnot could also be "plugged in". Worth > thinking about... Now that gcc is supporting auto-vectorization, I think it would be worth revisiting. That's what pushed me down this route to begin with. I get the feeling that a lot of C code would just need to be massaged a bit in order to get vectorized by gcc. I did have some promising results with that, but it was hard to pin down exactly what was going on. .hc > > cheers > Miller > > On Wed, Apr 18, 2007 at 07:27:29PM -0400, Hans-Christoph Steiner > wrote: >> >> Is there any particular reason why it was done this way? Does any >> object if it was fixed? >> >> It seems that -fstrict-aliasing is basic to compiler optimization >> since gcc -O2 enables it. There has been a lot of work recently in >> making gcc produce faster code. It would be very nice if we could >> take advantage of that. I think -fstrict-aliasing would be a >> necessary part of that. >> >> .hc >> >> >> On Apr 18, 2007, at 4:55 PM, Miller Puckette wrote: >> >>> I think there are several places where "strict-aliasing" isn't >>> followed. I always compile with -fno-strict-aliasing to prevent >>> problems. >>> >>> cheers >>> Miller >>> >>> On Wed, Apr 18, 2007 at 11:19:20AM -0400, Hans-Christoph Steiner >>> wrote: >>>> >>>> So it seems that this bug in d_math.c is triggered by turning on >>>> the >>>> Apple-recommended optimization flags: >>>> >>>> http://sourceforge.net/tracker/index.php? >>>> func=detail&aid=1692649&group_id=55736&atid=478070 >>>> >>>> I did notice that there are these warnings in the source. IIRC, >>>> optimization generally requires strict aliasing, so it seems that >>>> these warnings are probably related to the above bug: >>>> >>>> d_math.c: In function 'init_rsqrt': >>>> d_math.c:79: warning: dereferencing type-punned pointer will break >>>> strict-aliasing rules >>>> d_math.c: In function 'q8_rsqrt': >>>> d_math.c:93: warning: dereferencing type-punned pointer will break >>>> strict-aliasing rules >>>> d_math.c: In function 'q8_sqrt': >>>> d_math.c:101: warning: dereferencing type-punned pointer will break >>>> strict-aliasing rules >>>> >>>> Here are the lines in question: >>>> >>>> 79: *(long *)(&f) = l; >>>> 93: long l = *(long *)(&f); >>>> 101: long l = *(long *)(&f); >>>> >>>> Can anyone speak to what's this for and what it can be replaced >>>> with >>>> so as to follow "strict-aliasing rules". Maybe we could use >>>> something like this instead (from http://www.cs.tut.fi/~jkorpela/ >>>> round.html ): >>>> >>>> #define round(x) ((x) < LONG_MIN-0.5 || (x) > LONG_MAX+0.5 ?\ >>>> error() : ((x)>=0?(long)((x)+0.5):(long)((x)-0.5)) >>>> >>>> This requires that you have #include <limits.h> and that you >>>> have an >>>> error handling routine called error which is a function of type >>>> long. >>>> >>>> >>>> .hc >>>> >>>> ------------------------------------------------------------------- >>>> -- >>>> --- >>>> ---- >>>> >>>> kill your television >>>> >>>> >>>> >>>> _______________________________________________ >>>> PD-dev mailing list >>>> [email protected] >>>> http://lists.puredata.info/listinfo/pd-dev >> >> >> >> --------------------------------------------------------------------- >> --- >> ---- >> >> All information should be free. - the hacker ethic >> >> >> >> >> >> _______________________________________________ >> PD-dev mailing list >> [email protected] >> http://lists.puredata.info/listinfo/pd-dev ------------------------------------------------------------------------ ---- If you are not part of the solution, you are part of the problem. _______________________________________________ PD-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
