21 Jul
2011
21 Jul
'11
2:22 p.m.
On 07/20/2011 10:27 AM, Maurizio De Cecco wrote:
Or you can use LLVM to *directly* generate vector code, as in the following example,
result of some experiments done with Faust and it's LLVM backend:
block_code8: ; preds =
%block_code8.block_code8_crit_edge, %block_code3
%20 = phi float* [ %15, %block_code3 ], [ %.pre11, %block_code8.block_code8_crit_edge ]
%21 = phi float* [ %14, %block_code3 ], [ %.pre10, %block_code8.block_code8_crit_edge ]
%22 = phi float* [ %16, %block_code3 ], [ %.pre9, %block_code8.block_code8_crit_edge ]
%indvar = phi i32 [ 0, %block_code3 ], [ %indvar.next,
%block_code8.block_code8_crit_edge ]
%nextindex1 = shl i32 %indvar, 2
%nextindex = add i32 %nextindex1, 4
%23 = sext i32 %nextindex1 to i64
%24 = getelementptr float* %22, i64 %23
%25 = getelementptr float* %21, i64 %23
%26 = bitcast float* %25 to <4 x float>*
%27 = load <4 x float>* %26, align 1
%28 = getelementptr float* %20, i64 %23
%29 = bitcast float* %28 to <4 x float>*
%30 = load <4 x float>* %29, align 1
%31 = fadd <4 x float> %27, %30
%32 = bitcast float* %24 to <4 x float>*
store <4 x float> %31, <4 x float>* %32, align 1
%33 = icmp ult i32 %nextindex, %18
br i1 %33, label %block_code8.block_code8_crit_edge, label %exit_block6
In this block float* arrays are loaded, then "bitcast" in vector of 4 floats,
the vector of 4 float is loaded, then manipulated with LLVM IR vector version of add,
mult...etc... then stored.
The LLVM IR is still generated to use the "conservative" "align 1"
option since it can not yet be sure data is always aligned. The result SSE code with then
use the MOVUPS (Move Unaligned Packed Single-Precision Floating-Point Values). The next
steps is to generated stuff like:
%27 = load <4 x float>* %26, align 4
so that MOVAPS (Move Aligned Packed Single-Precision Floating-Point Values) is used
instead.
We already see so nice speed improvements, but the Faust vector LLVM backend version is
still not yet complete...
Stéphane
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 
21 Jul
21 Jul
8:15 p.m.
New subject: GCC Vector extensions
On Thursday21/7/11 2:22 PM, Stéphane Letz wrote:
Or you can use LLVM to *directly* generate vector
code, as in the following example, result of some experiments done with Faust and it's
LLVM backend:
I would love to have enough time to implement this :->
Anyway, under clang/Mac OS X, using the vector types reduced the time
spent in simple jmax dsp operator and in the general dsp virtual machine
execution to be around 15-18% for some "typical"
jmax patch. By simple operators i intend the basic signal operations,
like multiplication, constants and so on.
The rest of the time is spent on complex objects, that implements
specific dsp algorithms.
This means that the further performance improvements on jmax dsp
execution code (other than specific objects), whatever technique used,
cannot be higher than around 10%. (OK, as long as this typical patches
are really typical, of course).
Anyway, i repeat the tests on clang/gcc on Mac OS X, and i got, for a
given example patch, 30Msamples/seconds for clang with vector
extensions, 13Msamples/seconds for gcc with normal code, ad 11
Msamples/second with gcc with vector operators (gcc 4.2, latest apple
clang).
Using -mss2 or -mss3 on Linux improved the performance of the code using
the vector extensions but really marginally, leaving it largely slower
of the basic code.
By the way, by vector extensions i intend what is described here:
http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
Maurizio
8:50 p.m.
New subject: GCC Vector extensions
Le 21 juil. 2011 à 20:15, Maurizio De Cecco a écrit :
On Thursday21/7/11 2:22 PM, Stéphane Letz wrote:
This is not completely trivial... it needs to go inside Faust FIR (Faust Intermediate
Representation) and improve it..... Then some new code have to be added in the LLVM
backend itself.
Or you can use LLVM to *directly* generate vector
code, as in the following example, result of some experiments done with Faust and it's
LLVM backend:
I would love to have enough time to implement this :->
Anyway, under clang/Mac OS X, using the vector types reduced the time spent in simple
jmax dsp operator and in the general dsp virtual machine execution to be around 15-18% for
some "typical"
jmax patch. By simple operators i intend the basic signal operations, like
multiplication, constants and so on.
The rest of the time is spent on complex objects, that implements
specific dsp algorithms.
This means that the further performance improvements on jmax dsp execution code (other
than specific objects), whatever technique used, cannot be higher than around 10%. (OK, as
long as this typical patches are really typical, of course).
Anyway, i repeat the tests on clang/gcc on Mac OS X, and i got, for a given example
patch, 30Msamples/seconds for clang with vector extensions, 13Msamples/seconds for gcc
with normal code, ad 11 Msamples/second with gcc with vector operators (gcc 4.2, latest
apple clang).
Using -mss2 or -mss3 on Linux improved the performance of the code using the vector
extensions but really marginally, leaving it largely slower of the basic code.
By the way, by vector extensions i intend what is described here:
http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
Maurizio
You should really look at the generated SSE code. Can you paste the result of each test on
this list?
Thanks.
Stéphane
22 Jul
22 Jul
9:59 a.m.
New subject: GCC Vector extensions
On Thursday21/7/11 8:50 PM, Stéphane Letz wrote:
You should really look at the generated SSE code. Can
you paste the result of each test on this list?
At the moment i am testing with the whole jmax, i'll try to write small
test programs, and i'll post programs, results and assembler.
Well, in the next few days ...
Maurizio
10:10 a.m.
New subject: GCC Vector extensions
Le 22 juil. 2011 à 09:58, Maurizio De Cecco a écrit :
On Thursday21/7/11 8:50 PM, Stéphane Letz wrote:
Some remarks :
- the aligned version of memory access whenever possible should be use: it surely helps
- accessing the cache the correct way (avoiding cache line aliasing...) is important
- my limited test over some Faust examples and even using non-aligned load/store showed
more than 10% improvements...
Stéphane
You should really look at the generated SSE code.
Can you paste the result of each test on this list?
At the moment i am testing with the whole jmax, i'll try to write small test
programs, and i'll post programs, results and assembler.
Well, in the next few days ...
Maurizio
4809
days inactive
4810
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
2 participants
participants (2)
-
Maurizio De Cecco -
Stéphane Letz