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
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
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
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
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@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
------------------------------------------------------------------------ ----
If you are not part of the solution, you are part of the problem.
hi miller,
On Wed, 2007-04-18 at 18:13 -0700, 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.
i did some benchmarks of pd's phasor~ code against a straight-forward implementation on my pentium-m, when implementing the objects for nova. the straight-forward implementation ran about 20 to 30 % faster than the pd-style implementation. code like sqare root or inverse square root can be coded by just utilizing the rsqrtps and sqrtps opcodes, with a 14 bit precision, when working on the sse unit ...
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...
according to the gcc manual, simple vectorizable operactions, that's used for audio processing, can be autovectorized, if (and only if) the programmer takes care of both alignment and aliasing issues ...
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Life is really simple, but we insist on making it complicated. Confucius
On Apr 19, 2007, at 10:18 AM, Tim Blechmann wrote:
hi miller,
On Wed, 2007-04-18 at 18:13 -0700, 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.
i did some benchmarks of pd's phasor~ code against a straight-forward implementation on my pentium-m, when implementing the objects for nova. the straight-forward implementation ran about 20 to 30 % faster than the pd-style implementation.
Do you still have the code from the straight forward implementation?
code like sqare root or inverse square root can be coded by just utilizing the rsqrtps and sqrtps opcodes, with a 14 bit precision, when working on the sse unit ...
14bit precision would leave a lot to be desired in Pd. Are there high precision operators?
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...
according to the gcc manual, simple vectorizable operactions, that's used for audio processing, can be autovectorized, if (and only if) the programmer takes care of both alignment and aliasing issues ...
Is complying with -fstrict-aliasing enough to take care of the aliasing issues?
Do you have any examples of handling alignment issues?
.hc
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Life is really simple, but we insist on making it complicated. Confucius
------------------------------------------------------------------------ ----
There is no way to peace, peace is the way. -A.J. Muste
code like sqare root or inverse square root can be coded by just utilizing the rsqrtps and sqrtps opcodes, with a 14 bit precision, when working on the sse unit ...
14bit precision would leave a lot to be desired in Pd. Are there high precision operators?
From what i recall, the opcodes are meant to be used iteratively (like in root-finding), then yielding full precision.
Is complying with -fstrict-aliasing enough to take care of the aliasing issues? Do you have any examples of handling alignment issues?
I posted an example of autovectorizing code taking that into account a while ago http://lists.puredata.info/pipermail/pd-dev/2006-11/007880.html
greetings, Thomas
i did some benchmarks of pd's phasor~ code against a straight-forward implementation on my pentium-m, when implementing the objects for nova. the straight-forward implementation ran about 20 to 30 % faster than the pd-style implementation.
Do you still have the code from the straight forward implementation?
i'm not sure, if i still have the benchmark code somewhere on my machine, the phasor~/osc~ implementation can be found at http://svn.klingt.org/nova/trunk/source/language/dsp/oscillator.cpp ...
code like sqare root or inverse square root can be coded by just utilizing the rsqrtps and sqrtps opcodes, with a 14 bit precision, when working on the sse unit ...
14bit precision would leave a lot to be desired in Pd. Are there high precision operators?
erm, according to the comments in d_math.c, miller's code only precise for 8 mantissa bits and sqrt/rsqrt are aliases for q8_sqrt/q8_rsqrt
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...
according to the gcc manual, simple vectorizable operactions, that's used for audio processing, can be autovectorized, if (and only if) the programmer takes care of both alignment and aliasing issues ...
Is complying with -fstrict-aliasing enough to take care of the aliasing issues?
aeh, no ... when referring to the term aliasing when talking about of vectorizable functions, i'm referring to the aliasing of pointers as function arguments ... it should be described in the gcc manual in detail ...
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Silence is only frightening to people who are compulsively verbalizing. William S. Burroughs
On Apr 19, 2007, at 6:08 PM, Tim Blechmann wrote:
i did some benchmarks of pd's phasor~ code against a straight- forward implementation on my pentium-m, when implementing the objects for nova. the straight-forward implementation ran about 20 to 30 % faster than the pd-style implementation.
Do you still have the code from the straight forward implementation?
i'm not sure, if i still have the benchmark code somewhere on my machine, the phasor~/osc~ implementation can be found at http://svn.klingt.org/nova/trunk/source/language/dsp/ oscillator.cpp ...
code like sqare root or inverse square root can be coded by just utilizing the rsqrtps and sqrtps opcodes, with a 14 bit precision, when working on the sse unit ...
14bit precision would leave a lot to be desired in Pd. Are there high precision operators?
erm, according to the comments in d_math.c, miller's code only precise for 8 mantissa bits and sqrt/rsqrt are aliases for q8_sqrt/q8_rsqrt
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...
according to the gcc manual, simple vectorizable operactions, that's used for audio processing, can be autovectorized, if (and only if) the programmer takes care of both alignment and aliasing issues ...
Is complying with -fstrict-aliasing enough to take care of the aliasing issues?
aeh, no ... when referring to the term aliasing when talking about of vectorizable functions, i'm referring to the aliasing of pointers as function arguments ... it should be described in the gcc manual in detail ...
Well, as you can see, this is not my area of expertise :). Thanks for the responses. At this point, I am mostly trying to get the issues out on the table so we can know how to proceed.
.hc
tim
-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org
Silence is only frightening to people who are compulsively verbalizing. William S. Burroughs
------------------------------------------------------------------------ ----
Access to computers should be unlimited and total. - the hacker ethic