[PD-dev] d_math.c "break[s] strict-aliasing rules"

Miller Puckette mpuckett at imusic1.ucsd.edu
Thu Apr 19 03:13:35 CEST 2007


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




More information about the Pd-dev mailing list