[PD-dev] d_math.c "break[s] strict-aliasing rules"
Hans-Christoph Steiner
hans at eds.org
Thu Apr 19 03:18:40 CEST 2007
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
>>>> 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
------------------------------------------------------------------------
----
If you are not part of the solution, you are part of the problem.
More information about the Pd-dev
mailing list