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.
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...
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 PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
All information should be free. - the hacker ethic
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev