20 Jul
2011
20 Jul
'11
10:27 a.m.
I am playing around with GCC and Clang vector extensions, on Linux and
Mac OS X, and i am getting some strange behaviour.
I am working on jMax Phoenix, and its dsp engine, in its current state,
is very memory bound; it is based on the aggregation of very small
granularity operations, like vector sum or multiply, each of them
executed independently from and to memory.
I tried to implements all this 'primitive' operations using the vector
types.
On clang/MacOSX i get an impressive improvement in performance,
around 4x on the operations, even just using the vector types for
copying data; my impression is that the compiler use some kind of vector
load/store instruction that properly use the available memory bandwidth,
but unfortunately i do not know more about the x86 architecture.
On gcc/Linux, (gcc 4.5.2) the same code produce a *slow down* of around
2.5x.
Well, anybody have an idea of why ?
I am actually running linux (Ubuntu 11.04) under a VMWare virtual
machine, i do not know is this may have any implications.
Thanks,
Maurizio De Cecco
20 Jul
20 Jul
5:03 p.m.
On Wed, Jul 20, 2011 at 1:27 AM, Maurizio De Cecco <jmax(a)dececco.name> wrote:
On clang/MacOSX i get an impressive improvement in
performance,
around 4x on the operations, even just using the vector types for copying
data; my impression is that the compiler use some kind of vector
load/store instruction that properly use the available memory bandwidth, but
unfortunately i do not know more about the x86 architecture.
On gcc/Linux, (gcc 4.5.2) the same code produce a *slow down* of around
2.5x.
It's possible gcc generates code for lowest-common-denominator hardware
by default, and you might need to give some compiler option to get it to use
vector operations. See
http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html
5:47 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/20/2011 10:27 AM, Maurizio De Cecco wrote:
I am playing around with GCC and Clang vector
extensions, on Linux and
Mac OS X, and i am getting some strange behaviour.
I am working on jMax Phoenix, and its dsp engine, in its current state,
is very memory bound; it is based on the aggregation of very small
granularity operations, like vector sum or multiply, each of them
executed independently from and to memory.
I tried to implements all this 'primitive' operations using the vector
types.
On clang/MacOSX i get an impressive improvement in performance,
around 4x on the operations, even just using the vector types for
copying data; my impression is that the compiler use some kind of vector
load/store instruction that properly use the available memory bandwidth,
but unfortunately i do not know more about the x86 architecture.
On gcc/Linux, (gcc 4.5.2) the same code produce a *slow down* of around
2.5x.
Well, anybody have an idea of why ?
I am actually running linux (Ubuntu 11.04) under a VMWare virtual
machine, i do not know is this may have any implications.
Maybe. A better comparison would be: clang/Linux vs. gcc/Linux and
clang/MacOSX vs gcc/MacOSX compiled binaries.
Also as Dan already pointed out: gcc has a whole lot of optimization
flags which are not enabled by default. try '-O3 -msse2 -ffast-math'.
'-ftree-vectorizer-verbose=2' is handy while optimizing code.
have fun,
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk4m+HsACgkQeVUk8U+VK0LgtQCfcL9Jvrtf4kN9iPDMrpKQ/1M7
spwAni358xLLAb4n6LeOEMhiqS/kWnYb
=DmSC
-----END PGP SIGNATURE-----
6:19 p.m.
On Wed, Jul 20, 2011 at 10:47 AM, Robin Gareus <robin(a)gareus.org> wrote:
In addition... inspecting the disassembly is helpful (-S -o
myprogram.s). Rule of thumb is that you should have `movaps` (MOVe
Aligned Packed-Storage) and `mulps` (MULtiply Packed Storage)
instructions for multiplying vectors of single-precision floats.
In addition... profiling with valgrind/callgrind is helpful (esp. if
you have it dump instructions/assembly)...
$ valgrind --tool=callgrind --dump-instr=yes ./myprogram
Open the output file with kcachegrind and it'll save you a lot of time.
-gabriel
On gcc/Linux,
(gcc 4.5.2) the same code produce a *slow down* of around
2.5x.
Well, anybody have an idea of why ?
I am actually running linux (Ubuntu 11.04) under a VMWare virtual
machine, i do not know is this may have any implications.
Maybe. A better comparison would be: clang/Linux vs. gcc/Linux and
clang/MacOSX vs gcc/MacOSX compiled binaries.
Also as Dan already pointed out: gcc has a whole lot of optimization
flags which are not enabled by default. try '-O3 -msse2 -ffast-math'.
'-ftree-vectorizer-verbose=2' is handy while optimizing code.
25 Jul
25 Jul
12:04 p.m.
Short resume of my initial post: i found that using the gcc vector
extensions induced a 2x slow down using gcc, and a 4x speed up in clang.
I made more tests, isolating a small code example, on Mac OS and Ubuntu,
and i found out the origin of the problem, even if i do not know what
exactly happening.
My original test used vectors of float of size 8; the gcc vector
extension documentation says that if the vector size do not match the
hardware vector size, the code is synthesized in some way.
With a vector size of 8 i found the above results under Mac OS X, using
clang and gcc4.2, and under Ubuntu 11.04, using clang and gcc4.5.2.
When i move to a vector size of 4, things go better; clang slow down wrt
the size of 8 of around 2x, and gcc obtains the same result; the
interesting point is that gcc obtains essentially the same speed with
and without vector extensions, meaning probably that the compiler is
good enough in vectorizing the code, at least in the the test cases i used.
I include the code, results and scripts to run the tests in a small zip
if anybody want to make other tests; the test code compute an arbitrary
vector computation (essentially 100 million multiply add), starting from
a seed given as argument.
The code is modeled around the way jmax compute, i.e. one vector
operation at a time on vectors passed by pointers, and it is not
designed to be the fastest possible code to implements this computation.
Thanks for the help,
Maurizio
2:46 p.m.
On 07/25/2011 12:04 PM, Maurizio De Cecco wrote:
Short resume of my initial post: i found that using
the gcc vector
extensions induced a 2x slow down using gcc, and a 4x speed up in clang.
I made more tests, isolating a small code example, on Mac OS and Ubuntu,
and i found out the origin of the problem, even if i do not know what
exactly happening.
My original test used vectors of float of size 8; the gcc vector
extension documentation says that if the vector size do not match the
hardware vector size, the code is synthesized in some way.
With a vector size of 8 i found the above results under Mac OS X, using
clang and gcc4.2, and under Ubuntu 11.04, using clang and gcc4.5.2.
When i move to a vector size of 4, things go better; clang slow down wrt
the size of 8 of around 2x, and gcc obtains the same result; the
interesting point is that gcc obtains essentially the same speed with
and without vector extensions, meaning probably that the compiler is
good enough in vectorizing the code, at least in the the test cases i used.
I include the code, results and scripts to run the tests in a small zip
if anybody want to make other tests; the test code compute an arbitrary
vector computation (essentially 100 million multiply add), starting from
a seed given as argument.
The code is modeled around the way jmax compute, i.e. one vector
operation at a time on vectors passed by pointers, and it is not
designed to be the fastest possible code to implements this computation.
Thanks for the help,
Maurizio
Thanks for coming up with and sharing the tests!
I've just run them on a native i686 GNU/Linux system (1.66 GHz CoreDuo
32 bit vs your 2.7 GHz Core2Duo). The results are pretty much
consistent. They're all about 3x slower, except for gcc/size8 which is
only 1.8x slower and clang/size8 which is 6 times slower! - It might
have to do with 32 vs 64 bit but I don't have an explanation. would need
to look into asm output.
BTW. I'm pretty much impressed that some tests run faster on vmware
virtualization compared to native OSX. But yeah it's also no big
surprise either (and may further be related to ubuntu using a never
version of gcc).
So are you now considering use some #ifdef to select float/4 instead of
double/8 vectors in jMax or just change all of them?
ciao,
robin
PS.
#clang --version
clang version 1.1 (Debian 2.7-3)
Target: i386-pc-linux-gnu
Thread model: posix
#gcc --version
gcc (Debian 4.6.1-4) 4.6.1
26 Jul
26 Jul
10:15 a.m.
On Monday25/7/11 2:45 PM, Robin Gareus wrote:
Thanks for coming up with and sharing the tests!
Thanks for trying :->
would need to look into asm output.
As Stéphane said, i have to generate the assembler code.
I'll modify the scripts and send the assembler generated assembler code
later.
BTW. I'm pretty much impressed that some tests run
faster on vmware
virtualization compared to native OSX. But yeah it's also no big
surprise either (and may further be related to ubuntu using a never
version of gcc).
Yes, the compiler is different, and the code is a lot faster with more
recent gcc versions. Apple froze the environment to gcc 4.2 waiting for
clang. And, afaik, there is no reason for a vm to be slower in
computational code than the real iron, qs long as no system calls are done.
So are you now considering use some #ifdef to select
float/4 instead of
double/8 vectors in jMax or just change all of them?
Well, at the moment on gcc the perfomance with vector types is the same
as without vector types, so i'll leave the Linux version without vector
types (the code is #ifdef'ed).
It seems that it would be interesting to compile jMax with clang,
vector types and vector size 8 vector; i tried, but i find a lot of
problems with include files (a lot of system level includes are not
found by clang). I'll investigate this later :->.
By the way, i forgot to mentions that all my tests where at 64 bits;
i'll try later on a 32 bit Ubuntu.
About the -funroll-loops and the various buffer strategies, i'll give a
try and report later ..
Maurizio
2:30 p.m.
On 07/26/2011 03:15 AM, Maurizio De Cecco wrote:
When I was playing around with this last night... the best performance
came from your non-optimized, non-vectored code.
Why?
Because GCC translated it to optimized, vectored code.
So are you now
considering use some #ifdef to select float/4 instead of
double/8 vectors in jMax or just change all of them?
Well, at the moment on gcc the perfomance with vector types is the same
as without vector types, so i'll leave the Linux version without vector
types (the code is #ifdef'ed). By the way, i forgot to mentions that all my tests
where at 64 bits;
i'll try later on a 32 bit Ubuntu.
I was on 32 bit Ubuntu. Also, with GCC the 64-bit optimizer is known to
be better at optimising SIMD code.
Because I'm a sucker for these kinds of diversions, I came up with a
scheme that shaved about 1 second off your test (on my machine). It
assumes that `vecsize` is a power-of-two. The idea is to store stuff in
the processor registers, and access each buffer one page at a time (a
cache page is 64 bytes on x86... 16 floats).
static inline void add3_vec(float * restrict arg0, float * restrict
arg1, float * restrict arg2, unsigned int vecsize)
{
unsigned int i;
v4sf *v0, *v1, *v2;
v4sf c0, c1, c2, c3, c4, c5, c6, c7;
const unsigned cache_size = 4;
v0 = (v4sf*)arg0;
v1 = (v4sf*)arg1;
v2 = (v4sf*)arg2;
vecsize /= 4*cache_size;
while(vecsize--) {
c0 = *v0++;
c1 = *v0++;
c2 = *v0++;
c3 = *v0++;
c4 = *v1++;
c5 = *v1++;
c6 = *v1++;
c7 = *v1++;
*v2++ = c0 + c4;
*v2++ = c1 + c5;
*v2++ = c2 + c6;
*v2++ = c3 + c7;
}
}
-gabriel
25 Jul
25 Jul
5:17 p.m.
On Mon, Jul 25, 2011 at 5:04 AM, Maurizio De Cecco <jmax(a)dececco.name> wrote:
Short resume of my initial post: i found that using
the gcc vector
extensions induced a 2x slow down using gcc, and a 4x speed up in clang.
[snip]
I include the code, results and scripts to run the tests in a small zip
if anybody want to make other tests; the test code compute an arbitrary
vector computation (essentially 100 million multiply add), starting from a
seed given as argument.
I'm getting SIMD instructions when I compile. However, you have two
things slowing you down:
- The calculations for the for(;;) loop is slowing you down with
every iteration.
- You're only using one xmm register, so you're getting some memory slowdowns.
Both of these can be solved by having gcc unroll your loops for you
(recompile with -funroll-loops).
In addition, you're handling 3 buffers at a time. bufc[k] = bufa[k] *
bufb[k]. You might be able to speed it up a little by converting the
code to:
memcopy(bufc, bufa, N*sizeof(float));
for(k=0; k<N ; ++k) bufc[k] *= bufb[k];
This way you are only handling 2 buffers at a time (which an x86 CPU
generally does better with). But YMMV on this piece of advice.
-gabriel
4661
days inactive
4667
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
5 participants
participants (5)
-
Dan Kegel -
Gabriel Beddingfield -
Maurizio De Cecco -
Robin Gareus -
Robin Gareus