7 Feb
2008
7 Feb
'08
2:02 p.m.
Hello,
I try to squeeze as much performance as possible out of my upcomming
Linux synthesizer and try manual vectorization with following construct
in c, mainly to vectorize away multiplications :
typedef float v4sf __attribute__ ((vector_size(16)));
union f4vector
{
v4sf v __attribute__((aligned (16)));
float f[4] __attribute__((aligned (16)));
};
On AMD 64bit Turion (single core) on 64 Studio in 64bit mode this doesnt
improve performance at all, actually it even get worse. Is GCC that good
at optimizing on its own? I have no access to Intel processors at the
moment but would love to know how to benefit from SIMD optimizations of
float operations.
Sources on the web are rather thin...
Cheers,
Malte
--
Malte Steiner
media art + development
-www.block4.com-
7 Feb
7 Feb
2:07 p.m.
On 07/02/2008, Malte Steiner <steiner(a)block4.com> wrote:
Is GCC that good at optimizing on its own?
Not particularly, though it can do some optimizations especially with
the odd hint.
This article is quite informative:
http://www.advogato.org/article/871.html
Chris
2:11 p.m.
We also played around with GCC's vector extensions years ago. Here's a pointer
to one of many discussions we had:
https://bugs.linuxsampler.org/cgi-bin/show_bug.cgi?id=25
One of the main problems we had, is that there's no way to access the
individual "cells" / members of the vector effectively:
http://gcc.gnu.org/ml/gcc-help/2006-04/msg00178.html
Not sure if that changed in the meantime, but somehow I doubt it. :)
CU
Christian
Am Donnerstag, 7. Februar 2008 17:51:06 schrieb Malte Steiner:
Hello,
I try to squeeze as much performance as possible out of my upcomming
Linux synthesizer and try manual vectorization with following construct
in c, mainly to vectorize away multiplications :
typedef float v4sf __attribute__ ((vector_size(16)));
union f4vector
{
v4sf v __attribute__((aligned (16)));
float f[4] __attribute__((aligned (16)));
};
On AMD 64bit Turion (single core) on 64 Studio in 64bit mode this doesnt
improve performance at all, actually it even get worse. Is GCC that good
at optimizing on its own? I have no access to Intel processors at the
moment but would love to know how to benefit from SIMD optimizations of
float operations.
Sources on the web are rather thin...
Cheers,
Malte
3:42 p.m.
On Thu, 2008-02-07 at 19:13 +0000, Christian Schoenebeck wrote:
We also played around with GCC's vector extensions
years ago. Here's a pointer
to one of many discussions we had:
https://bugs.linuxsampler.org/cgi-bin/show_bug.cgi?id=25
One of the main problems we had, is that there's no way to access the
individual "cells" / members of the vector effectively:
http://gcc.gnu.org/ml/gcc-help/2006-04/msg00178.html
Not sure if that changed in the meantime, but somehow I doubt it. :)
It did change (or will do?) with the Penryn Core 2:
The INSERTPS and PINSR instructions read 8, 16 or 32 bits from an x86
register memory location and insert it into a field in the destination
register given by an immediate operand, EXTRACTPS and PEXTR read a field
from the source register and insert it into an x86 register or memory
location. For example, PEXTRD eax, [xmm0], 1; EXTRACTPS [addr+4*eax],
xmm1, 1 stores the first field of xmm1 in the address given by the first
field of xmm0.
http://en.wikipedia.org/wiki/SSE4
4:55 p.m.
Am Donnerstag, 7. Februar 2008 19:42:46 schrieb Jens M Andreasen:
It did change (or will do?) with the Penryn Core 2:
The INSERTPS and PINSR instructions read 8, 16 or 32 bits from an x86
register memory location and insert it into a field in the destination
register given by an immediate operand, EXTRACTPS and PEXTR read a field
from the source register and insert it into an x86 register or memory
location. For example, PEXTRD eax, [xmm0], 1; EXTRACTPS [addr+4*eax],
xmm1, 1 stores the first field of xmm1 in the address given by the first
field of xmm0.
http://en.wikipedia.org/wiki/SSE4
I didn't mean the hardware restriction, that is the limited power of current
SSE instructions. What I meant was the yet (IMO) incomplete implementation of
vector extensions in gcc.
I would expect to be able to access the cells of a vector in C(++) by pure
high level instructions and gcc to compile them to e.g. "workaround" SHUFPS
instruction sequences automatically. But there's no such (or was not such)
high level access support in gcc at all yet. As soon as you want to be able
to do things on element / cell level (e.g. also rotating the vector cells),
you would have to go low level and in this case there's no much sense in
using gcc's vector extensions at all.
CU
Christian
6:50 p.m.
On Thu, 2008-02-07 at 21:57 +0000, Christian Schoenebeck wrote:
Am Donnerstag, 7. Februar 2008 19:42:46 schrieb Jens M
Andreasen:
I didn't mean the hardware restriction, that is the limited power of current
SSE instructions. What I meant was the yet (IMO) incomplete implementation of
vector extensions in gcc.
The problem is that Intel's implementation of Vector is a moving target,
with a roadmap which retrospectively reads like as if carbon-copied from
a Brazilian Favela ...
I mean, what is there to complete with gcc when nobody knows where the
underlying hardware is moving? There was a presentation of the ultra low
powered Silverthorne - a processor which could bring us back to silent
computing again - this week at ISSCC, but still nobody knows wether it
will have SSE4.1 like Penryn or if it will be stuck with SSSE3 like
Merom?
Creating pseudo vector instructions, running slower than their scalar
counterparts - the field insert/extraction you was looking for being as
good an example as any - without as much as a promise of support in
future hardware, is a waste of perfectly good processor cycles.
[phew! :-D]
mvh // Jens M Andreasen
I would expect to be able to access the cells of a
vector in C(++) by pure
high level instructions and gcc to compile them to e.g. "workaround" SHUFPS
instruction sequences automatically. But there's no such (or was not such)
high level access support in gcc at all yet. As soon as you want to be able
to do things on element / cell level (e.g. also rotating the vector cells),
you would have to go low level and in this case there's no much sense in
using gcc's vector extensions at all.
CU
Christian
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
6:18 p.m.
Malte Steiner wrote:
typedef float v4sf __attribute__ ((vector_size(16)));
These attributes are mostly useful to ensure alignment etc. properties
of variables in stack.
On AMD 64bit Turion (single core) on 64 Studio in
64bit mode this doesnt
improve performance at all, actually it even get worse. Is GCC that good
at optimizing on its own?
Currently compilers are not very good at vectorization of all algorithm
types. Still, best results can be reached with handwritten assembler...
- Jussi
14 Feb
14 Feb
11:25 a.m.
On Thu, 2008-02-07 at 18:51 +0100, Malte Steiner wrote:
Hello,
I try to squeeze as much performance as possible out of my upcomming
Linux synthesizer and try manual vectorization with following construct
in c, mainly to vectorize away multiplications :
Have you checked the SIMD code in Ardour? We have SIMD code for crucial
DSP. The functions we use are:
(pure ASM, defined in libs/ardour/sse_functions.s or _64bit.s)
mix_buffers_with_gain(float *dst, float *src, long nframes, float gain);
mix_buffers_no_gain (float *dst, float *src, long nframes);
apply_gain_to_buffer (float *buf, long nframes, float gain);
float compute_peak(float *buf, long nframes, float current);
(xmmintrin, defined in libs/ardour/sse_functions_xmm.cc)
find_peaks(float *buf, nframes_t nframes, float *min, float *max)
When I wrote the code, I was unable to get better results from the gcc
vectorizer. From what I've heard, it's supposed to be getting better.
But at least until that, we are using the above code.
Note especially the xmmintrin syntax. It's a brilliant way of doing
pseudo-assembler. It gives you the power of direct XMM (SIMD) register
access and direct SIMD calls.
compute_peak() returns the largest absolute peak value in buf and
current. (i,e. return max( max(abs(buf)), current) ). The function we
have is multiple magnitudes faster than anything GCC can come up with
from generic C code. This is partly because we are using 16-byte aligned
buffers and mostly because we can cheat and not run a true ABS function,
but a bit masking operation which works for audio data as there are no
infinites or NaNs in it.
All functions work with aligned and non-aligned data. With non-aligned
data, they will run one sample at a time until they reach alignment and
continue 4 buffers at a time.
Sampo
15 Apr
15 Apr
3:53 p.m.
Yeah, I'm respawning this topic ...
because I was curious how the GCC vector extension situation changed meanwhile
and wrote a small benchmark for mixing signals with and without gain. You can
find it here:
http://download.linuxsampler.org/dev/mixdown.tar.gz
I compared a pure C++ implementation vs. the hand crafted SSE assembly code
(by Sampo Savolainen, Ardour) and of course an implementation utilizing GCC's
vector extensions. On my very weak, but environment friendly ;-) VIA box the
GCC vector implementation outperforms the other two solutions (using GCC
4.2.3 BTW):
Benchmarking mixdown (no coeff):
pure C++ : 670 ms
ASM SSE : 200 ms
GCC vector extensions : 180 ms
Benchmarking mixdown (WITH coeff):
pure C++ : 890 ms
ASM SSE : 300 ms
GCC vector extensions : 230 ms
And this time, the signal output of the vector implementation is even
correct. ;-) BUT, and this is important, you have to supply the correct
C(XX)FLAGS. For the upper result I used:
CXXFLAGS="-O3 -march=i686 -mmmx -msse -ffast-math -funroll-loops -fomit-frame-pointer
-fpermissive -mfpmath=sse"
If you don't advice GCC to emit SSE code, the vector implementation gets
horrible bad performance wise and even a lot worse than the pure C++
solution. Here's my result with just CXXFLAGS="-O3":
Benchmarking mixdown (no coeff):
pure C++ : 680 ms
ASM SSE : 200 ms
GCC vector extensions : 1970 ms
Benchmarking mixdown (WITH coeff):
pure C++ : 1280 ms
ASM SSE : 310 ms
GCC vector extensions : 2540 ms
So I would say it's finally time to put hands on GCC's vector toys, wasting
less time on hairy assembly tasks. I think for such simple algorithms like
mixing it's completely sufficient to keep a pure C++ implementation and a GCC
vector extension implementation side by side and just automatically determine
by a small benchmark in the configure script (or whatever) which one of the
two solutions to pick for compilation, dependent on what the user supplied as
CXXFLAGS. At least that's what I'm going to do ... I think ...
CU
Christian
4:12 p.m.
On Tue, 2008-04-15 at 19:45 +0200, Christian Schoenebeck wrote:
Yeah, I'm respawning this topic ...
because I was curious how the GCC vector extension situation changed meanwhile
and wrote a small benchmark for mixing signals with and without gain. You can
find it here:
http://download.linuxsampler.org/dev/mixdown.tar.gz
I compared a pure C++ implementation vs. the hand crafted SSE assembly code
(by Sampo Savolainen, Ardour) and of course an implementation utilizing GCC's
vector extensions. On my very weak, but environment friendly ;-) VIA box the
GCC vector implementation outperforms the other two solutions (using GCC
4.2.3 BTW):
Benchmarking mixdown (no coeff):
pure C++ : 670 ms
ASM SSE : 200 ms
GCC vector extensions : 180 ms
Benchmarking mixdown (WITH coeff):
pure C++ : 890 ms
ASM SSE : 300 ms
GCC vector extensions : 230 ms
Great stuff, very interesting. It seems it's finally getting easier to
vectorize functions. Too bad the code is awfully slow for non-sse
compiles. That still leaves the responsibility of choosing the fastest
algorithms per architecture at runtime to the application developers.
What about gcc 4.3.0 performance? I seem to recall that 4.3 should have
even better vectorization support.
I have to test whether I could squeeze a few more cycles out of
compute_peak(). That algorithm is the sole reason I started writing SSE
for ardour. The function uses a huge amount of computing time without
optimization.
Sampo
10:10 p.m.
On Tue, 2008-04-15 at 19:45 +0200, Christian Schoenebeck wrote:
Yeah, I'm respawning this topic ...
There is something funny with this benchmark. If we compare your
numbers:
Benchmarking mixdown (WITH coeff):
pure C++ : 890 ms
ASM SSE : 300 ms
GCC vector extensions : 230 ms
.. to mine (on a 1.1G Celeron):
Benchmarking mixdown (WITH coeff):
pure C++ : 390 ms
ASM SSE : 170 ms
GCC vector extensions : 140 ms
.. there is definately a similar pattern showing up, BUT the loops
appear to interfere with each other as you can see when I comment out
everything but ASM:
Benchmarking mixdown (WITH coeff):
ASM SSE : 160 ms <-- faster?
.. or leave in C++ as well:
Benchmarking mixdown (WITH coeff):
pure C++ : 400 ms <-- slower?
ASM SSE : 170 ms
.. or take out only the ASM:
Benchmarking mixdown (WITH coeff):
pure C++ : 380 ms <-- faster?
GCC vector extensions : 160 ms <-- slower?
Me thinks it is very difficult to predict what -O3 will or will not do.
mvh // Jens M Andreasen
g++ (GCC) 4.2.2 20071128 (prerelease) (4.2.2-3.1mdv2008.0)
BTW: I slightly modified the order in x86_sse_mix_buffers_with_gain for
speed:
.MBWG_SSELOOP:
movaps (%esi), %xmm0 #; source => xmm0
addl $16, %esi #; src+=4 //////////////
mulps %xmm1, %xmm0 #; apply gain to source
addps (%edi), %xmm0 #; mix with destination
movaps %xmm0, (%edi) #; copy result to destination
subl $4, %ecx #; nframes-=4
addl $16, %edi #; dst+=4
cmp $4, %ecx
jge .MBWG_SSELOOP
[...]
16 Apr
16 Apr
5:27 a.m.
Am Mittwoch, 16. April 2008 02:10:20 schrieb Jens M Andreasen:
On Tue, 2008-04-15 at 19:45 +0200, Christian
Schoenebeck wrote:
[snip]
Yeah, I'm respawning this topic ...
There is something funny with this benchmark. If we compare your Benchmarking mixdown (WITH coeff):
ASM SSE : 160 ms <-- faster?
.. or leave in C++ as well:
Benchmarking mixdown (WITH coeff):
pure C++ : 400 ms <-- slower?
ASM SSE : 170 ms
.. or take out only the ASM:
Benchmarking mixdown (WITH coeff):
pure C++ : 380 ms <-- faster?
GCC vector extensions : 160 ms <-- slower?
Yeah, it even gets funnier: you may have noticed that ALLOC_BUFFERS macro. The
timing results vary dependent on whether you allocate the buffers at runtime
(memalign()) or use statically allocated buffers at compile time. It could be
the same over-optimizing issue like you already noticed. Haven't investigated
it yet.
Me thinks it is very difficult to predict what -O3 will or will not do.
Yep, but as you already pointed out, the speed relationship between those 3
solutions is clear, no matter what the absolute timing results are. I also
flipped the order of the benchmarks and the coarse speed relationship was
always the same.
But if you're totally sceptical, you could simply move out the mixing
functions into an own C++ file, compile that object file with maximum
optimization, and compile the actual benchmark application with just "-O1" or
something.
CU
Christian
6:14 a.m.
On Wed, 2008-04-16 at 09:19 +0200, Christian Schoenebeck wrote:
But if you're totally sceptical, ...
Yes, it bothers me if the compiler can beat "hand-optimized" ASM :-D
It turns out that I get different results on consecutive runs of the
same binary, look:
Benchmarking mixdown (WITH coeff):
pure C++ : 380 ms
ASM SSE : 150 ms
GCC vector extensions : 140 ms <-- best
Benchmarking mixdown (WITH coeff):
pure C++ : 390 ms
ASM SSE : 140 ms <-- best
GCC vector extensions : 160 ms
This with slightly unrolled ASM to match the --funroll-loops option:
--8<-----------------------------------------
x86_sse_mix_buffers_with_gain --
...
.MBWG_SSE:
cmp $8, %ecx #; we know it's not zero, but if it's not >=8, then
jnge .MBWG_NONALIGN #; we jump straight to the "normal" code
#; copy gain to fill %xmm1
movss 20(%ebp), %xmm1
shufps $0x00, %xmm1, %xmm1
.MBWG_SSELOOP:
movaps (%esi), %xmm0 #; source => xmm0
addl $16, %esi #; src+=4
movaps (%esi), %xmm2 #; ++source => xmm2
addl $16, %esi #; src+=4
mulps %xmm1, %xmm0 #; apply gain to source
mulps %xmm1, %xmm2 #; apply gain to source
addps (%edi), %xmm0 #; mix with destination
movaps %xmm0, (%edi) #; copy result to destination
addl $16, %edi #; dst+=4
addps (%edi), %xmm2 #; mix with destination
movaps %xmm2, (%edi) #; copy result to destination
addl $16, %edi #; dst+=4
subl $8, %ecx #; nframes-=8
cmp $8, %ecx
jge .MBWG_SSELOOP
cmp $0, %ecx
je .MBWG_END
#; if there are remaining frames, the nonalign code will do
nicely
#; for the rest 1-7 frames.
...
6:49 a.m.
Am Mittwoch, 16. April 2008 10:14:33 schrieb Jens M Andreasen:
Yes, it bothers me if the compiler can beat
"hand-optimized" ASM :-D
It turns out that I get different results on consecutive runs of the
same binary, look:
Well, those two mixing tasks are really simple examples and it's easi(er) to
write good hand crafted assembly code for them. But if you consider more
complex algorithms, probably even involving differential calculations, it
gets a lot harder to beat the compiler, since you have to deal with so many
side effects on assembly level (especially all pipelining related issues) to
achieve maximum performance results with modern CPUs. That doesn't mean you
cannot beat the compiler of course, but often you end up working on an
assembly algorithm for a month or so until you finally beat (a good) pure
C++ / gcc vector variant which you just wrote in some hours.
So in practice, if the results are very close together anyway, probably not
even noticeable, I would definitely prefer to spend that time on other tasks
and enjoy the fact that the implementation compiles with very good
performance results on other architectures as well.
CU
Christian
8:17 a.m.
On Wed, 2008-04-16 at 10:41 +0200, Christian Schoenebeck wrote:
So in practice, if the results are very close together
anyway, probably not
even noticeable, I would definitely prefer to spend that time on other tasks
and enjoy the fact that the implementation compiles with very good
performance results on other architectures as well.
Then you will probably like this run of ./mixdown:
Benchmarking mixdown (WITH coeff):
pure C++ : 150 ms <-- pretty good, eh? ;-)
ASM SSE : 140 ms
GCC vector extensions : 150 ms
This is with -ftree-vectorize added to your compile options.
CU
Christian
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
10:10 a.m.
Am Mittwoch, 16. April 2008 12:17:23 schrieb Jens M Andreasen:
Then you will probably like this run of ./mixdown:
Benchmarking mixdown (WITH coeff):
pure C++ : 150 ms <-- pretty good, eh? ;-)
ASM SSE : 140 ms
GCC vector extensions : 150 ms
This is with -ftree-vectorize added to your compile options.
Hey, nice! :-)
But that works only well for the inlined version. If the mixer C(++) function
is located in another object file and the compiler is forced to use real
function calls, then the C(++) result is still worse than the gcc vector
version, even with "-ftree-vectorize":
Benchmarking mixdown (no coeff):
pure C++ : 690 ms
ASM SSE : 210 ms
GCC vector extensions : 190 ms
Benchmarking mixdown (WITH coeff):
pure C++ : 1120 ms
ASM SSE : 320 ms
GCC vector extensions : 300 ms
CU
Christian
12:46 p.m.
On Wed, 2008-04-16 at 14:01 +0200, Christian Schoenebeck wrote:
Am Mittwoch, 16. April 2008 12:17:23 schrieb Jens M
Andreasen:
It is not the function call. Seems more like the vectorizer gets lost?
You can get all kinds of information with -ftree-vectorizer-verbose=5
--8<-------------------------------------------------------
cppmix.cpp:27: note: dependence distance = 0.
cppmix.cpp:27: note: accesses have the same alignment.
cppmix.cpp:27: note: dependence distance modulo vf == 0 between
*D.2232_8 and *D.2232_8
cppmix.cpp:27: note: not vectorized: can't determine dependence between
*D.2235_18 and *D.2232_8
cppmix.cpp:26: note: vectorized 0 loops in function.
.. unfortunately, I have no idea excactly what to do with the
information?
Moving the cpp code back to the main file and adding
-funsafe-math-optimizations proves a lot more interresting:
Benchmarking mixdown (no coeff):
pure C++ : 100 ms
ASM SSE : 140 ms
GCC vector extensions : 120 ms
Benchmarking mixdown (WITH coeff):
pure C++ : 120 ms
ASM SSE : 150 ms
GCC vector extensions : 170 ms
One more time for those who missed it the first time, this time
commenting out everything but 'pure cpp w coff':
Benchmarking mixdown (WITH coeff):
pure C++ : 120 ms <-- bloody murder!
Then you will probably like this run of
./mixdown:
Benchmarking mixdown (WITH coeff):
pure C++ : 150 ms <-- pretty good, eh? ;-)
ASM SSE : 140 ms
GCC vector extensions : 150 ms
This is with -ftree-vectorize added to your compile options.
Hey, nice! :-)
But that works only well for the inlined version. If the mixer C(++) function
is located in another object file and the compiler is forced to use real
function calls, then the C(++) result is still worse than the gcc vector
version, even with "-ftree-vectorize": 
1:30 p.m.
On Wed, Apr 16, 2008 at 04:46:10PM +0200, Jens M Andreasen wrote:
Benchmarking mixdown (no coeff):
pure C++ : 100 ms
ASM SSE : 140 ms
GCC vector extensions : 120 ms
Benchmarking mixdown (WITH coeff):
pure C++ : 120 ms
ASM SSE : 150 ms
GCC vector extensions : 170 ms
One more time for those who missed it the first time, this time
commenting out everything but 'pure cpp w coff':
Benchmarking mixdown (WITH coeff):
pure C++ : 120 ms <-- bloody murder!
hmm.. perhaps i should upgrade my gcc...
on the vector extension:
you should not use it. use xmmintrin.h which even exists on MSVC to
make code compatible... however altivec is not supported then.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
18 Apr
18 Apr
8:47 a.m.
The quest for auto-vectorization continues. Introducing the Intel
icc/icpc combo (scroll down ...)
On Wed, 2008-04-16 at 17:37 +0200, torbenh(a)gmx.de wrote:
--
On Wed, Apr 16, 2008 at 04:46:10PM +0200, Jens M
Andreasen wrote:
If you want to upgrade for speed, consider icc as well. This test is
again the "pure CPP" loop only as per above:
[root@localhost mixdown]# make
icpc -O3 -msse -c mixdown.cpp
mixdown.cpp(159): (col. 9) remark: PERMUTED LOOP WAS VECTORIZED.
mixdown.cpp(58): (col. 5) remark: LOOP WAS VECTORIZED.
mixdown.cpp(54): (col. 5) remark: LOOP WAS VECTORIZED.
icpc -O3 -msse -o mixdown *.o
[root@localhost mixdown]# ./mixdown
Benchmarking mixdown (WITH coeff):
: 80 ms <-- shaved off yet another 30%
Benchmarking mixdown (no coeff):
pure C++ : 100 ms
ASM SSE : 140 ms
GCC vector extensions : 120 ms
Benchmarking mixdown (WITH coeff):
pure C++ : 120 ms
ASM SSE : 150 ms
GCC vector extensions : 170 ms
One more time for those who missed it the first time, this time
commenting out everything but 'pure cpp w coff':
Benchmarking mixdown (WITH coeff):
pure C++ : 120 ms <-- bloody murder!
hmm.. perhaps i should upgrade my gcc...
on the vector extension:
you should not use it. use xmmintrin.h which even exists on MSVC to
make code compatible... however altivec is not supported then.
I spend about 20 - 30 minutes on checking pre-conditions,
post-conditions and reordering/doubling the ASM in the loop for these
two lines of C code, to match the results from g++. I dunno how long
time it would (hypothetically) take to match the output from icpc?
More interresting would be some "real" code. I just did a preliminary
test on a 4-pole filter written in C that I have here. It compiles and
something appeared to happen in the vector department, but I am not sure
how much or what, yet ..
For Altivec: Isn't it so that IBM has some nifty auto-vectorizing
compilers as well?
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
16 Apr
16 Apr
1:37 p.m.
Hi,
And very interesting findings, thanks for looking into this!
Here are some more on my core2 pc.
flags: CFLAGS=-O3 -mmmx -msse -mfpmath=sse -ftree-vectorize
compiler: 4.1.3 or 4.2.1, didn't make a difference.
1.
#define FRAGMENTSIZE 32
Benchmarking mixdown (WITH coeff):
Process time for pure C++: 1505 useconds
Process time for ASM SSE: 2871 useconds
Process time for GCC vector extensions: 503 useconds
2.
#define FRAGMENTSIZE 64
Benchmarking mixdown (WITH coeff):
Process time for pure C++: 3006 useconds
Process time for ASM SSE: 5072 useconds
Process time for GCC vector extensions: 1568 useconds
3.
#define FRAGMENTSIZE 128
Benchmarking mixdown (WITH coeff):
Process time for pure C++: 6793 useconds
Process time for ASM SSE: 8232 useconds
Process time for GCC vector extensions: 6091 useconds
3.
#define FRAGMENTSIZE 512
Benchmarking mixdown (WITH coeff):
Process time for pure C++: 19843 useconds
Process time for ASM SSE: 31141 useconds
Process time for GCC vector extensions: 17669 useconds
4.
#define FRAGMENTSIZE 1024
Benchmarking mixdown (WITH coeff):
Process time for pure C++: 27083 useconds
Process time for ASM SSE: 42730 useconds
Process time for GCC vector extensions: 31436 useconds
I only modified the example to use gettimeofday() instead of clock().
Maybe a gcc developer can shed some light on this issue ?
Greetings,
Remon
3:07 p.m.
On Wed, 2008-04-16 at 17:37 +0200, Remon wrote:
I only modified the example to use gettimeofday()
instead of clock().
Maybe a gcc developer can shed some light on this issue ?
Not a gcc developer, but 'man clock' says that clock is supposed to
measure the time used by the application thus excluding the time spend
by system and other applications, whereas gettimeofday is the wall clock
including everything (as well as using a different unit of measurement.)
To get the real clock-count for running one fragment - as opposed to the
pseudo GHz return from 'clock' - you could use something like this:
/* high resolution processor clock count
*/
static inline unsigned long long
rdtsc()
{
unsigned long long int x;
__asm__ volatile (".byte 0x0f, 0x31" : "=A" (x));
return x;
}
... and then:
long long clck= rdtsc();
for (int i = 0; i < RUNS; i++) {
cpp_mix(pSampleInputBuf, pOutput, FRAGMENTSIZE, coeff);
}
printf ("pure C fragment\t\t: %d clck\n",(int)((rdtsc()-clck)/RUNS));
This could reveal something about how well you are utilizing the added
execution units in later Intel hardware compared to a simple PIII
celeron:
Benchmarking mixdown (WITH coeff):
pure C fragment : 1493 clck
For your C2D, compile with -mssse3 rather than -sse
Greetings,
Remon
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
6:21 a.m.
Am Mittwoch, 16. April 2008 09:19:19 schrieb Christian Schoenebeck:
But if you're totally sceptical, you could simply
move out the mixing
functions into an own C++ file, compile that object file with maximum
optimization, and compile the actual benchmark application with just "-O1"
or something.
Which I just did, and this time the assembly result is equal to the gcc vector
result:
Benchmarking mixdown (no coeff):
pure C++ : 680 ms
ASM SSE : 200 ms
GCC vector extensions : 200 ms
Benchmarking mixdown (WITH coeff):
pure C++ : 1100 ms
ASM SSE : 310 ms
GCC vector extensions : 300 ms
because that way the compiler is forced to compile the gcc vector solution
with real function calls, whereas in yesterday's benchmark the C++ and gcc
vector functions were simply inlined (I checked the compiler's assembly
output). But in practice you would make those short functions inliners
anyway. And even if it's "just" as good as hand crafted assembly code,
it's a
lot easiear to maintain compared to assembly and compiles (and optimizes) for
other architectures as well. So I'm definitely on the vector train now ...
CU
Christian
3:25 p.m.
Christian Schoenebeck <cuse(a)users.sourceforge.net> writes:
[...]
So I would say it's finally time to put hands on
GCC's vector toys, wasting
less time on hairy assembly tasks. I think for such simple algorithms like
mixing it's completely sufficient to keep a pure C++ implementation and a GCC
vector extension implementation side by side and just automatically determine
by a small benchmark in the configure script (or whatever) which one of the
two solutions to pick for compilation, dependent on what the user supplied as
CXXFLAGS. At least that's what I'm going to do ... I think ...
The distributor in me cried out when I read over this. I know I am kind
if nitpicking here, but please consider how much nicer this would be if
the small benchmark was run at start up time instead of compilation time.
Its not much more work to compile both algorithms into different object
files and set up a function pointer at startup. And it will
give you best performance even if you move the precompiled binary
from one machine to the other, or if you change the CPU in your
computer without reinstalling.
Besides, a binary distribution has no chance of knowing the exact
hardware in use on the users side. The configure test will only benchmark
the build host, which is not really useful.
--
CYa,
⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/>
.''`. | Get my public key via finger mlang(a)db.debian.org
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`. `'
`- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>
4:45 p.m.
Am Mittwoch, 16. April 2008 19:25:01 schrieben Sie:
The distributor in me cried out when I read over this.
I know I am kind
if nitpicking here, but please consider how much nicer this would be if
the small benchmark was run at start up time instead of compilation time.
Its not much more work to compile both algorithms into different object
files and set up a function pointer at startup. And it will
give you best performance even if you move the precompiled binary
from one machine to the other, or if you change the CPU in your
computer without reinstalling.
Mmm right, but in that case the upstream author has to do the compilation for
all kind of architectures ... not even knowing what kind of architectures are
covered by distribution X. Isn't that the "job" of a distribution maintainer
to do such compilation task? ;-)
Besides, a binary distribution has no chance of
knowing the exact
hardware in use on the users side. The configure test will only benchmark
the build host, which is not really useful.
Yeah I know, that's why the benchmarks can be circumvented by configure script
parameters for cross compilation. Somebody has to compile and somebody has to
run the benchmarks ... whoever that will be ... :-)
CU
Christian
6:41 p.m.
Christian Schoenebeck <cuse(a)users.sourceforge.net> writes:
You are not really following what I am trying to get across. Cross compilation
isn't the issue. The issue is that something as generic as i386 (or i686 for
rpm based distros IIRC) actually targets a lot of different types of hardware.
It can run on pretty old pentium based CPUs, but also modern
systems. A binary distributor has no way of knowing which
CPU is going to be used, in fact, a single binary package
is going to be used by many of the supported variants.
So if you want working performance optimisations in stock Linux apps that
are not being recompiled by geeky users locally, you need to use runtime
benchmarking, instead of hardcoding the choice into the binary at compilation
time.
--
CYa,
⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/>
.''`. | Get my public key via finger mlang(a)db.debian.org
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`. `'
`- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>
Am Mittwoch, 16. April 2008 19:25:01 schrieben Sie:
I am not talking about compilation. I am trying to explain that it
saves a lot of pain on all sides if the benchmarking and choosing of best
performing variant is done at startup time, instead of forcing the users to
compile a package from source just to have a configure based benchmark
guess their hardware correctly. I think the linux kernel
is a nice example. At startup, you may see some messages in dmesg
where Linux tries differently optimized variants of functions for
RAID related things. The winner is used. So if you shutdown, change your
CPU, and boot up again, the best optimisation for the new CPU is choosen,
and you do not have to recompile the kernel. The same should
be true for user space.
The distributor in me cried out when I read over
this. I know I am kind
if nitpicking here, but please consider how much nicer this would be if
the small benchmark was run at start up time instead of compilation time.
Its not much more work to compile both algorithms into different object
files and set up a function pointer at startup. And it will
give you best performance even if you move the precompiled binary
from one machine to the other, or if you change the CPU in your
computer without reinstalling.
Mmm right, but in that case the upstream author has to do the compilation for
all kind of architectures ... not even knowing what kind of architectures are
covered by distribution X. Isn't that the "job" of a distribution
maintainer
to do such compilation task? ;-) Besides, a
binary distribution has no chance of knowing the exact
hardware in use on the users side. The configure test will only benchmark
the build host, which is not really useful.
Yeah I know, that's why the benchmarks can be circumvented by configure script
parameters for cross compilation. Somebody has to compile and somebody has to
run the benchmarks ... whoever that will be ... :-)
17 Apr
17 Apr
2:41 a.m.
On Wed, 2008-04-16 at 22:41 +0200, Mario Lang wrote:
You are not really following what I am trying to get
across. Cross compilation
isn't the issue. The issue is that something as generic as i386 (or i686 for
rpm based distros IIRC) actually targets a lot of different types of hardware.
It can run on pretty old pentium based CPUs, but also modern
systems. A binary distributor has no way of knowing which
CPU is going to be used, ...
The distributor has one tool at his disposal, the package-manager. This
will know where it lives and could (potentially) choose the right
package.
For Intel vector code unfortunately, the current naming system with -386
-586 and -686 packages isn't very helpful because what we really need to
know is the processors mmx/sse level and wether it can deal with
denormals in a civilized manner. (An army of programmers to take
advantage of and verify systems we have only read about on the 'net
would be handy as well, thankyou ..)
--
4:30 a.m.
On Thu, 2008-04-17 at 06:41 +0200, Jens M Andreasen wrote:
On Wed, 2008-04-16 at 22:41 +0200, Mario Lang wrote:
The package manager does not choose the "right package". There is no
"right package". The packager does not know on which computer the
software will be running and can't pre-optimize for something that is an
unknown at compile or packaging time. The software has to automagically
optimize itself for the processor it is running on when it starts.
That is the way this is done in many other audio oriented software
packages (Jack, Ardour, etc).
You are not really following what I am trying to
get across. Cross compilation
isn't the issue. The issue is that something as generic as i386 (or i686 for
rpm based distros IIRC) actually targets a lot of different types of hardware.
It can run on pretty old pentium based CPUs, but also modern
systems. A binary distributor has no way of knowing which
CPU is going to be used, ...
The distributor has one tool at his disposal, the package-manager. This
will know where it lives and could (potentially) choose the right
package. For Intel vector code unfortunately, the current
naming system with -386
-586 and -686 packages isn't very helpful because what we really need to
know is the processors mmx/sse level and wether it can deal with
denormals in a civilized manner. (An army of programmers to take
advantage of and verify systems we have only read about on the 'net
would be handy as well, thankyou ..)
That is precisely why the detection of the best routines has to be done
at runtime. Look at the capabilities of the processor and then decide
which routines to use.
-- Fernando
3:04 p.m.
Fernando Lopez-Lezcano <nando(a)ccrma.Stanford.EDU> writes:
On Thu, 2008-04-17 at 06:41 +0200, Jens M Andreasen
wrote:
Well said.
On Wed, 2008-04-16 at 22:41 +0200, Mario Lang
wrote:
The package manager does not choose the "right package". There is no
"right package". The packager does not know on which computer the
software will be running and can't pre-optimize for something that is an
unknown at compile or packaging time. The software has to automagically
optimize itself for the processor it is running on when it starts. You are not really following what I am trying to
get across. Cross compilation
isn't the issue. The issue is that something as generic as i386 (or i686 for
rpm based distros IIRC) actually targets a lot of different types of hardware.
It can run on pretty old pentium based CPUs, but also modern
systems. A binary distributor has no way of knowing which
CPU is going to be used, ...
The distributor has one tool at his disposal, the package-manager. This
will know where it lives and could (potentially) choose the right
package. That is the way this is done in many other audio
oriented software
packages (Jack, Ardour, etc).
+1
--
CYa,
⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/>
.''`. | Get my public key via finger mlang(a)db.debian.org
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`. `'
`- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>
3:01 p.m.
Jens M Andreasen <jens.andreasen(a)comhem.se> writes:
On Wed, 2008-04-16 at 22:41 +0200, Mario Lang wrote:
No. If you optimize code, you will only have to special case
a few routines. The greater hunk of the code will stay the same on different
variants. So you do not want to precompile binary packages for
all sorts of special CPU types and feature, that would result in
a huge amount of data.
I am still convinced that runtime detection is a much more sensible solution.
--
CYa,
⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/>
.''`. | Get my public key via finger mlang(a)db.debian.org
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`. `'
`- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>
You are not really following what I am trying to
get across. Cross compilation
isn't the issue. The issue is that something as generic as i386 (or i686 for
rpm based distros IIRC) actually targets a lot of different types of hardware.
It can run on pretty old pentium based CPUs, but also modern
systems. A binary distributor has no way of knowing which
CPU is going to be used, ...
The distributor has one tool at his disposal, the package-manager. This
will know where it lives and could (potentially) choose the right
package.
3:36 p.m.
On Thu, 2008-04-17 at 19:02 +0200, Mario Lang wrote:
No. If you optimize code, you will only have to
special case
a few routines. The greater hunk of the code will stay the same on different
variants. So you do not want to precompile binary packages for
all sorts of special CPU types and feature, that would result in
a huge amount of data.
Look here:
ftp://ftp.sunet.se/pub/Linux/distributions/Mandriva/official/current
Up to higher level directory
SRPMS 09/18/2007 12:00:00 AM
i586 04/10/2008 12:21:00 AM
x86_64 04/10/2008 12:21:00 AM
Here is at least two separate identical distributions of the Intel
"architecture", so it can be done and has happened.
Perhaps x86_64 will be fine-grained enough to define a pleasant platform
seen from an audio developers perspective? Which means death to sse,
long live sse3! :-D
IIRC the current celeron 540M should fit the definition for a low cost
alternative.
I am still convinced that runtime detection is a much
more sensible solution.
--
8:22 p.m.
On Thu, 2008-04-17 at 19:31 +0200, Jens M Andreasen wrote:
On Thu, 2008-04-17 at 19:02 +0200, Mario Lang wrote:
The difference you point out has _nothing_ to do with optimization and
is unavoidable for now.
That is the choice between a 32 bit operating system and a 64 bit
operating system (on both Intel and AMD architectures). Eventually 32
bit systems will die of old age as _all_ programs run fine on 64 bits
and that directory will be erased.
Distributions and packagers will surely make a big party when that
happens.
-- Fernando
No. If you optimize code, you will only have to
special case
a few routines. The greater hunk of the code will stay the same on different
variants. So you do not want to precompile binary packages for
all sorts of special CPU types and feature, that would result in
a huge amount of data.
Look here:
ftp://ftp.sunet.se/pub/Linux/distributions/Mandriva/official/current
Up to higher level directory
SRPMS 09/18/2007 12:00:00 AM
i586 04/10/2008 12:21:00 AM
x86_64 04/10/2008 12:21:00 AM
Here is at least two separate identical distributions of the Intel
"architecture", so it can be done and has happened. Perhaps x86_64 will be fine-grained enough to define a
pleasant platform
seen from an audio developers perspective? Which means death to sse,
long live sse3! :-D
IIRC the current celeron 540M should fit the definition for a low cost
alternative.
> I am still convinced that runtime detection is a much more sensible solution.
18 Apr
18 Apr
10:33 a.m.
Jens M Andreasen <jens.andreasen(a)comhem.se> writes:
On Thu, 2008-04-17 at 19:02 +0200, Mario Lang wrote:
No, the example you are giving has nothing to do with the topic we are
discussing. The one version is compiled for 64bit and the other for 32bit
processors. To claim these to variants are somehow an optimisation
for two special CPU types is really a hopeless attempt to defend
your viewpoint :-). Hell, x86_64 even runs on CPUs of
two completely different vendors, and yes, there are differences
between an AMD64 and an EM64T CPU.
No. If you optimize code, you will only have to
special case
a few routines. The greater hunk of the code will stay the same on different
variants. So you do not want to precompile binary packages for
all sorts of special CPU types and feature, that would result in
a huge amount of data.
Look here:
ftp://ftp.sunet.se/pub/Linux/distributions/Mandriva/official/current
Up to higher level directory
SRPMS 09/18/2007 12:00:00 AM
i586 04/10/2008 12:21:00 AM
x86_64 04/10/2008 12:21:00 AM
Here is at least two separate identical distributions of the Intel
"architecture", so it can be done and has happened. Perhaps x86_64 will be fine-grained enough to define a
pleasant platform
seen from an audio developers perspective? Which means death to sse,
long live sse3! :-D
Your example nicely illustrates that what
you are arguing is not going to work. Not all x86_64 CPUs
do have SSE3. So how would you distribute a binary file
trying to find the best performance? You'd again have
to do (what I am trying to explain) runtime detection of the availability
of SSE3 (or whatever neato new feature of some CPU you'd like to use).
If y<ou do this at configure/compilation time, your optimisations
will not be available to users of precompiled binaries.
And, nearly every distro today (yeah, I *know* about Gentoo)
does use pre-built binaries. If you want otimisations
to be usable to people other than those that compile software
from source, you'll *have* to do runtime detection.
--
CYa,
⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/>
.''`. | Get my public key via finger mlang(a)db.debian.org
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`. `'
`- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>
17 Apr
17 Apr
5:01 a.m.
New subject: optimum binary distribution (was: vectorization)
Am Mittwoch, 16. April 2008 22:41:36 schrieben Sie:
You are not really following what I am trying to get
across. Cross
compilation isn't the issue. The issue is that something as generic as
i386 (or i686 for rpm based distros IIRC) actually targets a lot of
different types of hardware. It can run on pretty old pentium based CPUs,
but also modern
systems. A binary distributor has no way of knowing which
CPU is going to be used, in fact, a single binary package
is going to be used by many of the supported variants.
Trust me, I can follow what you mean and I also thought about a solution for
that problem years ago. The point is, where do you draw the line? You might
say, for the x86 architecture you detect at runtime whether the system
supports: MMX, SSE(1), SSE2, SSE3 and precompile 5 binaries which is going to
be picked automatically at application startup. Unfortunately that's not
sufficient to achieve max. performance. On some weak systems for example you
achieve better results with -Os than with -O3. So wanna make extra binarie(s)
and runtime benchmark for that as well? You could continue that game for a
lot of other GCC flags and your binary collection would grow to a horrible
huge cross product. And we're still just talking about one architecture.
That's why I was thinking about a little different approach for binary
distributions: just precompile some part of the audio application (/most of
it) and actually compile the core elements (the ones that are crucial to
overall performance) on demand by the user. Because I agree compiling a whole
complex audio app is usually an unconvenient user-unfriendly task, especially
because all of those library dependencies and system specific path locations
etc. the user has to deal with and the long time it takes to compile the
whole beast. But with such a partly precompiled solution you (as a
distribution package maintainer) can already take away those hairy tasks,
because the few core elements that are going to be compiled by the user will
only have fery few dependencies left: the applications own library (which is
already there anyway) a compiler and very basic standard header files like
math.h which are usually there on a machine with compiler anyway. And since
those dependencies are so small, it wouldn't be a hard task to integrate such
a build system into the application itself, so the user just has to adjust
the CXXFLAGS in a line input box or something and press the "Recompile"
button.
CU
Christian
5:58 a.m.
New subject: optimum binary distribution (was: vectorization)
2008/4/17, Christian Schoenebeck <cuse(a)users.sourceforge.net>et>:
That's why I was thinking about a little
different approach for binary
distributions: just precompile some part of the audio application (/most of
it) and actually compile the core elements (the ones that are crucial to
overall performance) on demand by the user. Because I agree compiling a whole
complex audio app is usually an unconvenient user-unfriendly task, especially
because all of those library dependencies and system specific path locations
etc. the user has to deal with and the long time it takes to compile the
whole beast. But with such a partly precompiled solution you (as a
distribution package maintainer) can already take away those hairy tasks,
because the few core elements that are going to be compiled by the user will
only have fery few dependencies left: the applications own library (which is
already there anyway) a compiler and very basic standard header files like
math.h which are usually there on a machine with compiler anyway. And since
those dependencies are so small, it wouldn't be a hard task to integrate such
a build system into the application itself, so the user just has to adjust
the CXXFLAGS in a line input box or something and press the "Recompile"
button.
This sounds really cumbersome. And some very widely used distributions
do not install a C-Compiler by default.
What do you think about the approach taken by "liboil"?
http://liboil.freedesktop.org/
The library has implementations for various CPU-Extensions, and at run
time, when the library is initialized, a set of function pointers is
set to point to the "right" implementation functions.
Cheers
-Richard
--
Don't contribute to the Y10K problem!
6:23 a.m.
New subject: optimum binary distribution (was: vectorization)
On Thu, 2008-04-17 at 09:58 +0200, Richard Spindler wrote:
This sounds really cumbersome. And some very widely
used distributions
do not install a C-Compiler by default.
Very few distributions - if any at all? - installs TeX by default
either. Nevertheless this is a dependency if you want
Rosegarden/Lillypond aboard and you'll get it if you click YES to
'install packages'.
A C-compiler would not be any different. So I don't buy your argument!
What do you think about the approach taken by
"liboil"?
http://liboil.freedesktop.org/
The library has implementations for various CPU-Extensions, and at run
time, when the library is initialized, a set of function pointers is
set to point to the "right" implementation functions.
It would have been smarter to have liboil.so be a symlink to
liboil-sse_4_1.so (or whatever hardware you may have)
Cheers
-Richard
--
6:49 a.m.
New subject: optimum binary distribution (was: vectorization)
2008/4/17, Jens M Andreasen <jens.andreasen(a)comhem.se>se>:
What if I export /usr over NFS and have machines with different
x86-processors using that filesystem?
Having a completely "self-contained" solution sure has its merits.
Cheers
-Richard
--
Don't contribute to the Y10K problem!
What do you
think about the approach taken by "liboil"?
http://liboil.freedesktop.org/
The library has implementations for various CPU-Extensions, and at run
time, when the library is initialized, a set of function pointers is
set to point to the "right" implementation functions.
It would have been smarter to have liboil.so be a symlink to
liboil-sse_4_1.so (or whatever hardware you may have)
9:45 a.m.
New subject: optimum binary distribution (was: vectorization)
On Thu, 2008-04-17 at 10:49 +0200, Richard Spindler wrote:
2008/4/17, Jens M Andreasen
<jens.andreasen@comhem.se>:>
You really do that? OK, the solution is identical to choosing the right
base architecture in the first place. One of these gets mounted
as /usr/lib
/*/usr/lib/alpha
/*/usr/lib/mips
/*/usr/lib/ppc
/*/usr/lib/sparc
/*/usr/lib/i386
/*/usr/lib/i686
/*/usr/lib/i686.sse2
...
It would have been smarter to have liboil.so be a
symlink to
liboil-sse_4_1.so (or whatever hardware you may have)
What if I export /usr over NFS and have machines with different
x86-processors using that filesystem?
Having a completely "self-contained"
solution sure has its merits.
Cheers
-Richard
--
10 a.m.
New subject: optimum binary distribution (was: vectorization)
2008/4/17, Jens M Andreasen <jens.andreasen(a)comhem.se>se>:
You really do that? OK, the solution is identical to
choosing the right
base architecture in the first place. One of these gets mounted
as /usr/lib
---8<---
/*/usr/lib/i386
/*/usr/lib/i686
/*/usr/lib/i686.sse2
this is getting ridiculous, what liboil does is definitely the right
thing to do, for a number of reasons. First of all being that the
original developer is likely the most knowledgeable person to handle
this problem. By putting that burden onto the packager or worse the
enduser, who are more often than not clueless about such issues, you
will have a lot of noise in your support channels (irc/mail) of people
that will keep asking the same questions and who will have the same
problems all over again and again. This ... is ... Madness. ;-)
Cheers
-Richard
--
Don't contribute to the Y10K problem!
10:06 a.m.
New subject: optimum binary distribution (was: vectorization)
On Thu, 2008-04-17 at 14:00 +0200, Richard Spindler wrote:
2008/4/17, Jens M Andreasen
<jens.andreasen(a)comhem.se>se>:
Yup, it is madness.
And looks like opinions are unlikely to change in this matter.
So what will actually happen is that the software in question will not
get packaged, or if it is, it will just have to use a compromise set of
assumptions that will make it slower that necessary in most cases. So be
it (shrug).
As mentioned in the thread, other software package optimize at runtime
quite happily, amongst them the actual kernel on which _everything_ else
depends for speed (there used to be i386, i586 and i686 packaged
versions of the kernel - guess what? not anymore...).
-- Fernando
You really do that? OK, the solution is identical
to choosing the right
base architecture in the first place. One of these gets mounted
as /usr/lib
---8<---
/*/usr/lib/i386
/*/usr/lib/i686
/*/usr/lib/i686.sse2
this is getting ridiculous, what liboil does is definitely the right
thing to do, for a number of reasons. First of all being that the
original developer is likely the most knowledgeable person to handle
this problem. By putting that burden onto the packager or worse the
enduser, who are more often than not clueless about such issues, you
will have a lot of noise in your support channels (irc/mail) of people
that will keep asking the same questions and who will have the same
problems all over again and again. This ... is ... Madness. ;-)
10:51 a.m.
New subject: optimum binary distribution (was: vectorization)
On Thu, 2008-04-17 at 14:00 +0200, Richard Spindler wrote:
First of all being that the original developer is
likely the most
knowledgeable person to handle this problem.
You are assuming that the original unpaid developer owns any of the
fancy hardware in question? That is in the general case - to put it
mildly - a stretch.
As has been shown in a previous thread, auto-vectorization is taking off
in a major way approaching and occasionally going beyond what a skilled
ASM programmer can accomplish. If I have understood the gcc mailing-list
correctly, this will go into the next version (4.3?) as default for -O3
The original programmer may not be aware of this, need not even be alive
for a distributor to type 'make world -O3 -msse4.1' (or some such) which
will optimize /everything/ for that processor architecture.
The application on the end-user system sometimes known as the
packet-manager should be able to know where it lives and dive into the
network directory corresponding that architecture. No need for manual
support.
About NFS mount of /usr ... Are you sure that is such a wise decision
these days considering current prices of local storage? What happens
when the user unplugs his laptop and walks away?
12:38 p.m.
New subject: optimum binary distribution (was: vectorization)
2008/4/17, Jens M Andreasen <jens.andreasen(a)comhem.se>se>:
You are assuming that the original unpaid developer
owns any of the
fancy hardware in question? That is in the general case - to put it
mildly - a stretch.
This depends on how much work/money the individual dev wants to put
into his project. Obviously this varies widely.
As has been shown in a previous thread,
auto-vectorization is taking off
in a major way approaching and occasionally going beyond what a skilled
ASM programmer can accomplish. If I have understood the gcc mailing-list
correctly, this will go into the next version (4.3?) as default for -O3
The original programmer may not be aware of this, need not even be alive
for a distributor to type 'make world -O3 -msse4.1' (or some such) which
will optimize /everything/ for that processor architecture.
I think we are mixing up some problems here. If you are packaging an
existing piece of legacy software you will likely take a different
approach then when you are the original author of a program and you
are interested in getting the best performance for as many users as
possible with a minmal amount of fuzz for them.
The application on the end-user system sometimes
known as the
packet-manager should be able to know where it lives and dive into the
network directory corresponding that architecture. No need for manual
support.
Setting up the infrastructure and getting distributions/packaging
software to support this will be much more work. As far as I know a
solution like this has not been implemented yet, and it is not likely
to happen, imho.
About NFS mount of /usr ... Are you sure that is such
a wise decision
these days considering current prices of local storage? What happens
when the user unplugs his laptop and walks away?
This was just one of the many examples to point out what could
"potentially" go wrong if one starts to implement hodgepodge
solutions. But anyways, not everyones setup compares to anyone elses
setup, aiming for universalism where possible is surely what I
consider a best practice.
Cheers
-Richard
PS.: The correct response to "This is Madness" is of course: "Thiiiis
issss SPARTA!!!" ;-) :-P *lol*
--
Don't contribute to the Y10K problem!
12:17 p.m.
New subject: optimum binary distribution (was: vectorization)
This sounds really cumbersome. And some very widely used distributions
do not install a C-Compiler by default.
What do you think about the approach taken by "liboil"?
http://liboil.freedesktop.org/
The library has implementations for various CPU-Extensions, and at run
time, when the library is initialized, a set of function pointers is
set to point to the "right" implementation functions.
Cheers
-Richard
How about getting the package installer to do the test and select the
appropriate binary (or at least dl lib)? Of course, that'd screw up machines
which nfs mount /usr/bin, but do many people use diskless workstations these
days? And you wouldn't have to run the checks every time the application
started up.
Just a thought...
NJB/.
12:59 p.m.
New subject: optimum binary distribution
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Christian Schoenebeck wrote:
| That's why I was thinking about a little different approach for binary
| distributions: just precompile some part of the audio application (/most of
| it) and actually compile the core elements (the ones that are crucial to
| overall performance) on demand by the user.
This is slightly off topic, but people do this for numeric software
libraries. HW platforms for supercomputers vary widely in their
structure. This is true even for similar platforms. Configuration
options on different instances of one kind of machine can cause the
algebraic software to perform wildly differently. You'll still get
the same answer, but one may take a lot longer than the other. So,
there is a distribution of LAPACK and BLAS which compiles them several
ways, and has an optimizer which compares the results and chooses the
best one. In fact, the optimizer steers the selection of which parameters
to choose. I think it's pretty slick.
This is a very different situation, though, as the libraries in question
are very much a shared resource, and they need to be as fast as possible.
People who do numeric computing are also willing to do more work to get
their answers than you are, whoever you may happen to be.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIB2YhTi5xeapaTM0RAlkfAKCBXSC+r5pYzmAMotZgjVUh5GFZ6QCdG/Kn
pkQNj+aZMT7ku2Qzgc/3CfU=
=V2+9
-----END PGP SIGNATURE-----
5:54 p.m.
New subject: optimum binary distribution
Christian Schoenebeck wrote:
Am Mittwoch, 16. April 2008 22:41:36 schrieben Sie:
For audio apps, the only bits that need real optimization are the parts
that sit in the audio path. I.e. The DSP bits.
These are normally best done with hand crafted code. So, one just
includes all the different CPU types, e.g. MMX, SSE etc. in one source
code. Compile it all as one, and then use runtime detection to select
the correct routine to execute.
For example, this is how most of libffmpeg works.
James
You are not really following what I am trying to
get across. Cross
compilation isn't the issue. The issue is that something as generic as
i386 (or i686 for rpm based distros IIRC) actually targets a lot of
different types of hardware. It can run on pretty old pentium based CPUs,
but also modern
systems. A binary distributor has no way of knowing which
CPU is going to be used, in fact, a single binary package
is going to be used by many of the supported variants.
Trust me, I can follow what you mean and I also thought about a solution for
that problem years ago. The point is, where do you draw the line? You might
say, for the x86 architecture you detect at runtime whether the system
supports: MMX, SSE(1), SSE2, SSE3 and precompile 5 binaries which is going to
be picked automatically at application startup. Unfortunately that's not
sufficient to achieve max. performance. On some weak systems for example you
achieve better results with -Os than with -O3. So wanna make extra binarie(s)
and runtime benchmark for that as well? You could continue that game for a
lot of other GCC flags and your binary collection would grow to a horrible
huge cross product. And we're still just talking about one architecture.
That's why I was thinking about a little different approach for binary
distributions: just precompile some part of the audio application (/most of
it) and actually compile the core elements (the ones that are crucial to
overall performance) on demand by the user. Because I agree compiling a whole
complex audio app is usually an unconvenient user-unfriendly task, especially
because all of those library dependencies and system specific path locations
18 Apr
18 Apr
7:30 p.m.
Christian Schoenebeck wrote:
I compared a pure C++ implementation vs. the hand
crafted SSE assembly code
(by Sampo Savolainen, Ardour) and of course an implementation utilizing GCC's
vector extensions. On my very weak, but environment friendly ;-) VIA box the
For simple operations, compilers are rather good on vectorization. Even
though I don't know if there's any support for multi-arch targets on
gcc, so that the SSE2/SSE3 optimized binary would run on hardware
without SSE (dynamic code selection)? I haven't got time to follow the
latest gcc developments.
For more complex operations like FIR, IIR, normalized cross-correlation
or complex multiply-accumulate, I haven't seen any compiler being able
to match hand-crafted assembly code.
BR,
- Jussi Laako
23 Apr
23 Apr
6:04 a.m.
On Sat, Apr 19, 2008 at 12:30:43AM +0300, Jussi Laako wrote:
For simple operations, compilers are rather good on
vectorization. Even
though I don't know if there's any support for multi-arch targets on
gcc, so that the SSE2/SSE3 optimized binary would run on hardware
without SSE (dynamic code selection)? I haven't got time to follow the
latest gcc developments.
For more complex operations like FIR, IIR, normalized cross-correlation
or complex multiply-accumulate, I haven't seen any compiler being able
to match hand-crafted assembly code.
I tried out vectorizing the complex multipl-and-accumulate loop in
zita-convolver. For long convolutions and certainly if you have
convolution matrix the MAC operation dominates the FFT and IFFT
ones.
This requires a permutation of the complex arrays as used by
FFTW after each FFT and before each IFFT. In each block of 4
complex values
x1 y1 x2 y2 x3 y3 x4 y4
swap y1 with x3 and y2 with x4 to get
x1 x3 x2 x4 y1 y3 y2 y4
which can be handled by the vector operations.
The results are very marginal, about 5% relative speed increase
even in cases where the MAC operations largely outnumber any
others. Bypassing the permutations to have an idea of their cost
didn't change anything.
I'm somewhat surprised by this...
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
5:05 p.m.
Fons Adriaensen wrote:
I tried out vectorizing the complex
multipl-and-accumulate loop in
zita-convolver. For long convolutions and certainly if you have
The results are very marginal, about 5% relative speed increase
even in cases where the MAC operations largely outnumber any
For me, the complex MAC operation written for SSE3 practically doubled
the speed for double precision and more than doubled for single
precision, compared to "-march=i686 -O3 -ffast-math" case (the code has
to run practically on all x86 platforms).
Prior to SSE3, there was no nice way to do complex multiplication on
SSE. Now it can be done in three instructions for two single precision
complex numbers.
Still, one of the most elegant is E3DNow on AMD, it can do single
precision complex multiply in four instructions.
These instruction numbers are for the calculation itself, in addition it
of course needs the load and store operations, where SSE3 requires a few
extra instructions compared to E3DNow.
BR,
- Jussi
5 May
5 May
3:19 a.m.
I believe your declaration looks something like this:
float // array of complex
ffta[N][2] __attribute__ ((aligned(16))),
fftb[N][2] __attribute__ ((aligned(16))),
data[N][2] __attribute__ ((aligned(16)));
.. right?
If so, then I can get the auto-vectorizer in icc to kick in with this
construct of complex multiply add:
// CC=icc -O3 -msse3
void cmadd(void)
{
float *A = (float*) ffta;
float *B = (float*) fftb;
float *D = (float*) data;
int i;
for (i = 0;i < N*2; i += 2)
{
D[i] += A[i] * B[i] - A[i+1] * B[i+1];
D[i+1] += A[i] * B[i+1] + A[i+1] * B[i];
}
}
No luck with gcc though :-/
/j
On Wed, 2008-04-23 at 09:59 +0200, Fons Adriaensen wrote:
I tried out vectorizing the complex
multipl-and-accumulate loop in
zita-convolver. For long convolutions and certainly if you have
convolution matrix the MAC operation dominates the FFT and IFFT
ones.
This requires a permutation of the complex arrays as used by
FFTW after each FFT and before each IFFT. In each block of 4
complex values
x1 y1 x2 y2 x3 y3 x4 y4
swap y1 with x3 and y2 with x4 to get
x1 x3 x2 x4 y1 y3 y2 y4
which can be handled by the vector operations.
The results are very marginal, about 5% relative speed increase
even in cases where the MAC operations largely outnumber any
others. Bypassing the permutations to have an idea of their cost
didn't change anything.
I'm somewhat surprised by this...
--
11:35 a.m.
[...]
Another strategy for Complex Multiply Add would be to organize the data
in vertical arrays of the same type. This is to say that there should be
one array of Real followed by another array of Imaginary, perhaps
something like this:
typedef struct {
float r[N] __attribute__ ((aligned(16)));
float i[N] __attribute__ ((aligned(16)));
} cvec_t;
cvec_t cA,cB,cD;
It can be argued that the data is now scattered all over the place, and
twice as many moves are needed to perform a single cmadd. This may be
true in some cases as we shall later see, but when you are operating on
vectors you'd usually want to load and store (at least) 4 variables at a
time.
The routine to calculate them all becomes:
for (i = 0;i < N; ++i)
{
cD.r[i] += cA.r[i] * cB.r[i] - cA.i[i] * cB.i[i];
cD.i[i] += cA.r[i] * cB.i[i] + cA.i[i] * cB.r[i];
}
This auto-vectorizes really well with icc -O3 -msse, here looped a
billion times and compared to the original routine:
clock: 1340 ms (cvec_t) <--
This is not a typo!
clock: 12820 ms (original array of complex)
It is not too bad with gcc -O3 -msse -ftree-vectorize either:
clock: 6490 ms (cvec_t)
clock: 14190 ms (original array of complex)
But all things are not so rosy in the vector-department if we should
also plan to distribute this code fragment as part of a binary generic
i386 package, say conservatively compiled with gcc -O2:
clock: 18880 ms (cvec_t) <--
ouch!
clock: 14230 ms (original array of complex)
That was pretty bad! Your trusted 100MHz pentium suddenly got downgraded
to 66MHz :-/
So to conclude: A more than 10 times speedup of cmadd() of large arrays
is possible by a) rearangement of the data in a format that fits modern
machines and b) switch of compiler (which perhaps not everybody is
willing to do.)
/j
12:25 p.m.
Am Montag, 5. Mai 2008 15:35:42 schrieb Jens M Andreasen:
[...]
Another strategy for Complex Multiply Add would be to organize the data
in vertical arrays of the same type. This is to say that there should be
one array of Real followed by another array of Imaginary, perhaps
something like this:
Uhm, stupid question: already tried if GCC's special "complex" attribute
type
leads to a better result with auto vectorization? At least that could give
the optimizer a better chance.
CU
Christian
2 p.m.
On Mon, 2008-05-05 at 16:07 +0200, Christian Schoenebeck wrote:
Uhm, stupid question: already tried if GCC's
special "complex" attribute type
leads to a better result with auto vectorization? At least that could give
the optimizer a better chance.
No I did not, but thats an idea. This certainly looks nice and clean:
_Complex float cxA[N], cxB[N], cxD[N];
for (i = 0;i < N; ++i)
cxD[i] += cxA[i] * cxB[i];
Comparison to the other two versions with gcc -O3 -msse
-ftree-vectorize, suggests a slight advantage over the original
(non-vectorized) two dimensional array:
clock: 13920 ms (_Complex)
clock: 7040 ms (cvec_t)
clock: 14470 ms (original array of complex)
With icc -O3 -msse the difference is even more pronounced:
clock: 3850 ms (_Complex)
clock: 1410 ms (cvec_t)
clock: 13290 ms (original array of complex)
Moving from 'gcc 4.2.2' to '4.3 20070713 (experimental)' is very
disappointing:
clock: 46180 (_Complex) <-- we have
found a looser!
clock: 7030 (cvec_t)
clock: 14340 (original array of complex)
/j
CU
Christian
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
2:13 p.m.
Jens M Andreasen wrote:
Comparison to the other two versions with gcc -O3
-msse
-ftree-vectorize, suggests a slight advantage over the original
I would propose something like "-march=prescott -O3 -ftree-vectorize" or
"-O3 -sse3 -ftree-vectorize".
With icc -O3 -msse the difference is even more
pronounced:
And something like "-O3 -xT" here.
- Jussi
3:18 p.m.
Jussi!
Could you try this out with your proposed compiler options on your own
hardware?
Admittedly, the recycled PIII here is very unrepresentative, outdated
and old-skool (although it seems to shine when paired up with icc :)
--8<-----------------------------
// include everything just in case we need it ...
#include <unistd.h>
#include <stdio.h>
#include <sched.h>
#include <time.h>
#include <stdlib.h>
#define N 1024
#include <complex.h>
float // complex
ffta[N][2] __attribute__ ((aligned(16))),
fftb[N][2] __attribute__ ((aligned(16))),
data[N][2] __attribute__ ((aligned(16)));
_Complex float
cxA[N] __attribute__ ((aligned(16))),
cxB[N] __attribute__ ((aligned(16))),
cxD[N] __attribute__ ((aligned(16))) ;
typedef struct
{
float r[N] __attribute__ ((aligned(16)));
float i[N] __attribute__ ((aligned(16)));
} cvec_t;
cvec_t cA,cB,cD;
int main()
{
int n = 1000000;
int i,j;
char* s;
clock_t clk = clock();
s = "(_Complex)";
for (j = 0; j < n; ++j)
for (i = 0;i < N; ++i)
cxD[i]+= cxA[i]*cxB[i];
fprintf (stderr,"> clock: %d ms %s\n",(clock()-clk)/1000,s);
s = "(cvec_t)";
clk = clock();
for (j = 0; j < n; ++j)
for (i = 0;i < N; ++i)
{
cD.r[i] += cA.r[i] * cB.r[i] - cA.i[i] * cB.i[i];
cD.i[i] += cA.r[i] * cB.i[i] + cA.i[i] * cB.r[i];
}
fprintf (stderr,"> clock: %d ms %s\n",(clock()-clk)/1000,s);
s = "(original float array[N][2])";
clk = clock();
for (j = 0; j < n ; ++j)
for (i = 0; i <N; ++i)
{
data [i][0] += ffta [i][0] * fftb [i][0] - ffta [i][1] * fftb [i][1];
data [i][1] += ffta [i][0] * fftb [i][1] + ffta [i][1] * fftb [i][0];
}
fprintf (stderr,"> clock: %d ms %s\n",(clock()-clk)/1000,s);
return 0;
}
On Mon, 2008-05-05 at 19:15 +0300, Jussi Laako wrote:
Jussi Laako wrote:
--
I would propose something like
"-march=prescott -O3 -ftree-vectorize" or
"-O3 -sse3 -ftree-vectorize".
Sorry, typo, "-O3 -msse3 -ftree-vectorize" of course...
- Jussi
4:55 p.m.
Jens M Andreasen wrote:
Could you try this out with your proposed compiler
options on your own
hardware?
I also added my own asm flavor...
With "-O3 -msse3 -ffast-math -ftree-vectorize -fprefetch-loop-arrays" on
gcc:
clock: 15740 ms (_Complex)
clock: 24930 ms (cvec_t)
clock: 17770 ms (original float array[N][2])
clock: 13660 ms (asm on float array)
With "-O3 -xO -fp-model fast" on icc (all variants vectorized):
clock: 1030 ms (_Complex)
clock: 520 ms (cvec_t)
clock: 16250 ms (original float array[N][2])
(although it seems to shine when paired up with icc :)
icc is very nice... :)
- Jussi
6:39 p.m.
On Mon, May 05, 2008 at 07:18:39PM +0200, Jens M Andreasen wrote:
Could you try this out with your proposed compiler
options on your own
hardware?
...
#define N 1024
...
int n = 1000000;
...
Looping a million times over the same small data vector
is _not_ very realistic.
In a real app, the data size would be much longer (there's
no need to optimise otherwise), that data would be rewritten
for each iteration (no need to redo the calculation otherwise),
and the work would not be done in a single long run but be
divided over a number of e.g. jack process callbacks.
I've again performed some tests on zita-convolver used by
jconv to do the York Minster config. That means around 240
different blocks of 8192 complex values each. The differences
between plain C++, hand vectorized, and optimised assembly
code are absolutely marginal in that case.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
7:32 p.m.
On Mon, 2008-05-05 at 22:33 +0200, Fons Adriaensen wrote:
OK, good point!
#define N (1024 * 1024 ) // flood the level 2 cache ...
...
int n = 1000; // we need to loop for clock() to take notice
...
with icc I am then getting these numbers:
...
#define N 1024
...
int n = 1000000;
...
Looping a million times over the same small data vector
is _not_ very realistic. clock: 4020 ms (_Complex)
clock: 1550 ms (cvec_t)
clock: 70000 ms (original float array[N][2])
... which supports the notion that the shape of the data structure is an
important factor, not only for the vectorization but also for data
thruput.
(With gcc results for all versions were in the 50 - 60 000 ms range.)
8:10 p.m.
On Mon, 2008-05-05 at 23:32 +0200, Jens M Andreasen wrote:
> clock: 4020 ms (_Complex)
> clock: 1550 ms (cvec_t)
> clock: 70000 ms (original float array[N][2])
Wait a second ... It's a trick! :-D
The compiler splits the iterations up in smaller parts that fits in the
cache and runs them in succesion.
8:31 p.m.
On Tue, May 06, 2008 at 12:10:38AM +0200, Jens M Andreasen wrote:
On Mon, 2008-05-05 at 23:32 +0200, Jens M Andreasen
wrote:
I've know one what that even more clever. It just noticed I didn't use
the result, and skipped the whole loop.
After each iteration, call an empty function, separately compiled,
that takes all three vectors as arguments (and _not_ as const *
of course). No more tricks. The overhead is peanuts compared
to the calculation.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
> clock: 4020 ms (_Complex)
> clock: 1550 ms (cvec_t)
> clock: 70000 ms (original float array[N][2])
Wait a second ... It's a trick! :-D
The compiler splits the iterations up in smaller parts that fits in the
cache and runs them in succesion.
6 May
6 May
5:20 a.m.
On Tue, 2008-05-06 at 00:24 +0200, Fons Adriaensen wrote:
After each iteration, call an empty function,
separately compiled,
that takes all three vectors as arguments (and _not_ as const *
of course). No more tricks. The overhead is peanuts compared
to the calculation.
You mean like this:
// defined in empty.c as return 0;
extern int empty(void*a,void*b,void*d);
And then call it at the end of iteration:
for (j = 0; j < n; ++j)
{
for (i = 0;i < N; ++i)
cxD[i]+= cxA[i]*cxB[i];
empty(&cxA,&cxB,&cxD);
}
fprintf (stderr,"> clock: %d ms %s\n",(clock()-clk)/1000,s);
Well, that certainly did level out everything. For n = 1000:
clock: 64680 ms (_Complex)
clock: 61990 ms (cvec_t)
clock: 71060 ms (original float array[N][2])
This measures the terrible latency I have between main memory and cache.
Changing back N from (1024 * 1024) to
#define N 1024
.. and then increasing n to a million again (this should be safe now?) -
so we can pretend not to be limited by PC100 - yields with icc:
clock: 16510 ms (_Complex)
clock: 6090 ms (cvec_t)
clock: 12800 ms (original float array[N][2])
.. and with gcc:
clock: 13820 ms (_Complex)
clock: 6330 ms (cvec_t)
clock: 13420 ms (original float array[N][2])
Very even I would say.
6:02 a.m.
On Tue, May 06, 2008 at 09:21:09AM +0200, Jens M Andreasen wrote:
On Tue, 2008-05-06 at 00:24 +0200, Fons Adriaensen
wrote:
Yes.
After each iteration, call an empty function,
separately compiled,
that takes all three vectors as arguments (and _not_ as const *
of course). No more tricks. The overhead is peanuts compared
to the calculation.
You mean like this:
// defined in empty.c as return 0;
extern int empty(void*a,void*b,void*d);
And then call it at the end of iteration:
for (j = 0; j < n; ++j)
{
for (i = 0;i < N; ++i)
cxD[i]+= cxA[i]*cxB[i];
empty(&cxA,&cxB,&cxD);
}
fprintf (stderr,"> clock: %d ms %s\n",(clock()-clk)/1000,s); Well, that certainly did level out everything. For n =
1000:
> clock: 64680 ms (_Complex)
> clock: 61990 ms (cvec_t)
> clock: 71060 ms (original float array[N][2])
QED :-)
This measures the terrible latency I have between main
memory and cache.
Which will determine performance for every algorithm that
- is working on a data set that is larger than the cache,
- does not produce multiple results from the same inputs.
A complex MAC uses each data point twice, so it gains a little.
Changing back N from (1024 * 1024) to
#define N 1024
.. and then increasing n to a million again (this should be safe now?) -
It is safe now, but with such a small data size the code is still not
representative of real life use of a very simple operation such as a
MAC loop. In practice you also have to generate the data and use the
result before a second iteration can start and this will trash the
cache even for smaller data sizes. Even more so if the code runs in
a jack callback and other processes will alternate with it.
so we can pretend not to be limited by PC100 - yields
with icc:
Yes, gcc now performs quite well compared to the Intel compiler.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
clock: 16510 ms (_Complex)
clock: 6090 ms (cvec_t)
clock: 12800 ms (original float array[N][2])
.. and with gcc:
clock: 13820 ms (_Complex)
clock: 6330 ms (cvec_t)
clock: 13420 ms (original float array[N][2])
Very even I would say.
8:45 p.m.
Fons Adriaensen wrote:
Which will determine performance for every algorithm
that
- is working on a data set that is larger than the cache,
- does not produce multiple results from the same inputs.
Here are some results with empty() included...
N=1024, n=1000000, gcc:
clock: 16500 ms (_Complex)
clock: 26760 ms (cvec_t)
clock: 15820 ms (original float array[N][2])
clock: 13700 ms (asm on float array)
N=(1024*1024), n=1000, gcc:
clock: 8410 ms (_Complex)
clock: 9360 ms (cvec_t)
clock: 8500 ms (original float array[N][2])
clock: 10540 ms (asm on float array)
And if I remove "-fprefetch-loop-arrays", it degrades to:
clock: 12800 ms (_Complex)
clock: 10010 ms (cvec_t)
clock: 13800 ms (original float array[N][2])
clock: 10510 ms (asm on float array)
And non-vectorized version ("normal x86-64 code"):
clock: 12840 ms (_Complex)
clock: 22830 ms (cvec_t)
clock: 12880 ms (original float array[N][2])
clock: 10470 ms (asm on float array)
The asm code I used doesn't include prefetch instructions, because the
data sets I use at once are smaller. Vectorization improves cvec_t
layout case significantly.
It is safe now, but with such a small data size the
code is still not
representative of real life use of a very simple operation such as a
MAC loop. In practice you also have to generate the data and use the
There are several use cases where the data set is rather small and is
used in several subsequent loops, thus cache can help.
After profiling, I've identified number of algorithms which
significantly benefit from handwritten vectorized asm.
BR,
- Jussi
9:03 p.m.
Jussi Laako wrote:
N=1024, n=1000000, gcc:
> clock: 16500 ms (_Complex)
> clock: 26760 ms (cvec_t)
> clock: 15820 ms (original float array[N][2])
> clock: 13700 ms (asm on float array)
And the above case without vectorization (except the asm version):
clock: 19730 ms (_Complex)
clock: 66840 ms (cvec_t)
clock: 18260 ms (original float array[N][2])
clock: 13680 ms (asm on float array)
I would say there's a "slight" variation for the cvec_t case...
- Jussi
7 May
7 May
2 a.m.
On Wed, 2008-05-07 at 01:45 +0300, Jussi Laako wrote:
Fons Adriaensen wrote:
> Which will determine performance for every algorithm that
>
> - is working on a data set that is larger than the cache,
> - does not produce multiple results from the same inputs.
-<snip>-
There are several use cases where the data set is
rather small and is
used in several subsequent loops, thus cache can help.
After profiling, I've identified number of algorithms which
significantly benefit from handwritten vectorized asm.
One thing that I wonder is what the pattern of addition in Fons's
application really looks like. I assume the fftA * fftB is some windowed
precalculated impulsresponse and a signal? The addition/accumulate
suggests that the output fftD has been touched before, implying that
there could be more variables to work on at once or that the vectors
would still be in the cache if the order of addition was changed.
/j
PS: Your fastest calculation is when the data floods the cache:
N=(1024*1024), n=1000, gcc, clock: 8410 ms (_Complex). Is that a typo?
4:17 a.m.
Jens M Andreasen wrote:
PS: Your fastest calculation is when the data floods
the cache:
N=(1024*1024), n=1000, gcc, clock: 8410 ms (_Complex). Is that a typo?
Nope, that's the actual result, I just verified the settings, recompiled
and re-run, and it's still:
clock: 8390 ms (_Complex)
clock: 9310 ms (cvec_t)
clock: 8480 ms (original float array[N][2])
clock: 10550 ms (asm on float array)
Fast memory bus + prefetch is a really good thing...
I also have vectorized float array copy and it's significantly faster
than memcpy(). While memcpy() stays under 1 GB/s, vectorized version can
reach around 90% of the theoretical memory speed for large copies.
- Jussi
6:56 a.m.
On Wed, May 07, 2008 at 06:00:38AM +0200, Jens M Andreasen wrote:
One thing that I wonder is what the pattern of
addition in Fons's
application really looks like. I assume the fftA * fftB is some windowed
precalculated impulsresponse and a signal? The addition/accumulate
suggests that the output fftD has been touched before, implying that
there could be more variables to work on at once or that the vectors
would still be in the cache if the order of addition was changed.
It's quite complex. I'll try to build up a picture in four steps.
1. The first step to imagine is just a scalar matrix operating on
a number of input sample streams A [j][t] and producing a number
of output sample streams B [i][t]:
index i = output
index j = input
index t = time
B [i][t] = sum_j (M [i][j] * A [j][t])
2. Now imagine that the matrix is not scalar, but a matrix of FIR
filters:
B [i][t] = sum_j (sum_k (M [i][j][k] * A [j][t- k]))
with k = 0...L-1, for filters of length L. We now need to
store the past L-1 samples of each input as well.
Assume this calculation is done for one value of t (i.e. one
sample) at a time (we'll see why soon). There are six ways to
organise the three nested loops. The one actually used is such
that k is the innermost index.
3. Now imagine that each sample in the above equation is actually a
block of P samples. This is how FFT based partitioned convolution
works. We need a size 2P FFT on each input block (the second half
are zeros) and on each matrix element (the latter is precomputed
of course), a size 2P IFFT on each output block, and each of the
multiplications now becomes a MAC loop over P complex values. The
output size is 2P, i.e. the second half overlaps witht the next
iteration and has to be stored. There are size(A) * size(B) * L
such MAC loops for each block, so it helps to optimize this
operation.
4. The scheme above is FFT-based partitioned convolution with a single
partition size P. For efficiency you want large P, but this also
introduces processing delay as you can only start the computation
when P new input samples are available. To avoid this delay in a
real-time application zita-convolver uses multiple partition sizes,
small at the start of an IR, and larger ones for the later parts.
There can be up to five sizes. Calculations for P == period size
are performed directly in the JACK callback, the longer ones are
performed by lower priority threads. A final optimisation is that
a sparse matrix representation is used in all three dimensions,
so no time or memory is wasted on zero-valued data.
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
27 May
27 May
5:58 a.m.
On Wed, 2008-05-07 at 10:50 +0200, Fons Adriaensen wrote:
[about zita convolver]
It's quite complex. I'll try to build up a
picture in four steps.
-<fast FWD>-
4. The scheme above is FFT-based partitioned
convolution with a single
partition size P. For efficiency you want large P, but this also
introduces processing delay as you can only start the computation
when P new input samples are available. To avoid this delay in a
real-time application zita-convolver uses multiple partition sizes,
small at the start of an IR, and larger ones for the later parts.
There can be up to five sizes. Calculations for P == period size
are performed directly in the JACK callback, the longer ones are
performed by lower priority threads. A final optimisation is that
a sparse matrix representation is used in all three dimensions,
so no time or memory is wasted on zero-valued data.
Since you are bound by bandwith to main memory, it would be nice to get
you off the precious level 2 cache. There are hints available to bypass
the cache, but a better solution might be to look into nVidias C-like
CUDA language. Here are some measures for their library FFT involving a
€200 card with a 256bit GDDR3 memory interface:
http://www.cv.nrao.edu/~pdemores/gpu/
... and here is an introduction where you can get an idea of how
involved that might be:
http://www.ddj.com/hpc-high-performance-computing/207200659
Silent cards with passive cooling are available at about €50+ but have
"only" ordinary 128bit DDR2 memory and considerably less computational
power. 4 Gflops (real world) might be enough for the application at hand
though?
Apparently nVidia has implemented some kind of hardware permute in their
later designs (from 8400 an up), opening up their gpu's to a much wider
range of algorithms than previous generations. Real world performance in
Gflops appears to be about 1/10 of the peak shader thruput mentioned in
this table at wikipedia:
http://en.wikipedia.org/wiki/GeForce_8_Series#Technical_summary
As an added bonus, should somebody look into and implement any of this,
we would all get the perfect excuse for achieving insane framerates in
Quake/OpenArena :-D
Disclaimer: NVidias product codes have become a disgustingly confusing
alphabet-soup. I might have misread some comparison table.
--
8:54 a.m.
Hello
while I am impressed by using graphic cards as coprocessors I wonder how
much latency they introduce and if they could be used for low latency
realtime audio now. It used to be impossible because it took to much
time to get the data back.
Cheers,
Malte
--
-------------
Malte Steiner
http://www.block4.com
media art + development
now available:
Minicomputer softwaresynthesizer for Linux
http://minicomputer.sourceforge.net/
9:37 a.m.
According to the first plot here:
http://www.cv.nrao.edu/~pdemores/gpu/
.. the timings for the given FFT tests are a near identical "less than
one ms" for both gpu (including transfer time) and cpu up to a size of
64K samples (after which the gpu runs ahead when the cpu hits the
brickwall cache limit ...)
Transfer time for 4096 samples appears to be in the "less than 0.1ms"
range, which I suppose is realtime enough for most people.
Wether transfer times on more humble/crippled hardware would be similar,
basically bound by the PCIe 16x, is an open question though.
/j
On Tue, 2008-05-27 at 12:54 +0200, Malte Steiner wrote:
Hello
while I am impressed by using graphic cards as coprocessors I wonder how
much latency they introduce and if they could be used for low latency
realtime audio now. It used to be impossible because it took to much
time to get the data back.
Cheers,
Malte
--
5 May
5 May
8:17 p.m.
On Mon, May 05, 2008 at 11:32:56PM +0200, Jens M Andreasen wrote:
> clock: 4020 ms (_Complex)
> clock: 1550 ms (cvec_t)
> clock: 70000 ms (original float array[N][2])
How do you explain the 45:1 ratio for the latter two ?
Just doing 4 operations in parallel can't do this.
I would never trust these numbers without verifying
the numerical result.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
6 May
6 May
7:14 a.m.
Fons Adriaensen wrote:
On Mon, May 05, 2008 at 07:18:39PM +0200, Jens M
Andreasen wrote:
The main problem there is that you are not looking at the speed of the
CPU, but running into memory bandwidth problems. In my own experiments
it was very apparent that it pays off to restructure the code in such a
way that memory access is limited as much as possible, although that
might result in more instructions. (not suggesting that's possible for
you though).
The key point seems to be that you have to do all operations at once
instead of looping over a buffer multiple times. Which is not really a
surprise of course...
e.g.:
for(all samples) {sample = operation1(sample)}
for(all samples) {sample = operation2(sample)}
for(all samples) {sample = operation3(sample)}
can easily be an order of magnitude slower than:
for(all samples) {
sample = operation1(sample)
sample = operation2(sample)
sample = operation3(sample)
}
It is essential that the data does not leave the processors cache,
that's for sure. For the remainder I think modern day processors are
very good at optimizing their computation.
Greets,
Pieter
Could you try this out with your proposed
compiler options on your own
hardware?
...
#define N 1024
...
int n = 1000000;
...
Looping a million times over the same small data vector
is _not_ very realistic.
In a real app, the data size would be much longer (there's
no need to optimise otherwise), that data would be rewritten
for each iteration (no need to redo the calculation otherwise),
and the work would not be done in a single long run but be
divided over a number of e.g. jack process callbacks.
I've again performed some tests on zita-convolver used by
jconv to do the York Minster config. That means around 240
different blocks of 8192 complex values each. The differences
between plain C++, hand vectorized, and optimised assembly
code are absolutely marginal in that case.
28 Apr
28 Apr
8:24 p.m.
On Sat, 2008-04-19 at 00:30 +0300, Jussi Laako wrote:
For simple operations, compilers are rather good on
vectorization. Even
though I don't know if there's any support for multi-arch targets on
gcc, so that the SSE2/SSE3 optimized binary would run on hardware
without SSE (dynamic code selection)? I haven't got time to follow the
latest gcc developments.
I tried rewriting a "moog filter" slightly to calculate 4 voices in
parallel instead of one by declaring all scalars to be arrays and then
looping through them as in:
/* float r1,r2,r3,r4; */
float r1[4],r2[4],r3[4],r4[4]; // tmp
...
for(int i = 0; i < 4; ++i)
{
...
r1[i] = b[1][i];
b[1][i] = r3[i] = p[i] * (r4[i] + r2[i]) - r1[i] * f[i];
...
}
This strategy fails to auto-vectorize with gcc4.3 but works with icc
10.1 and almost quadruples thruput. Breaking up the filter in separate
smaller functions helped getting rid of confusion regarding what should
be the inner and outer loops. The functions are inlined anyways.
For applications that look like a bunch of identical channel strips,
this should be pretty useful. "Buy one and get three for free!" :-D
So it is not all science-fiction, but gcc is not quite there yet.
6019
days inactive
6129
days old
linux-audio-dev@lists.linuxaudio.org
72 comments
16 participants
participants (16)
-
Bill White -
Chris Cannam -
Christian Schoenebeck -
Fernando Lopez-Lezcano -
Fons Adriaensen -
James Courtier-Dutton -
Jens M Andreasen -
Jussi Laako -
Malte Steiner -
Mario Lang -
Nick Bailey -
Pieter Palmers -
Remon -
Richard Spindler -
Sampo Savolainen -
torbenh＠gmx.de