<br><br><div><span class="gmail_quote">On 4/9/07, <b class="gmail_sendername">Sampo Savolainen</b> <<a href="mailto:v2@iki.fi">v2@iki.fi</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, 2007-04-09 at 16:26 +0200, Dragan Noveski wrote:<br>> Mike Taht wrote:<br>> > does jack say it's running SSE on startup?<br>> now, since i recompiled with --enable-dynsimd it says:<br>><br>> ...
<br>> JACK tmpdir identified as [/dev/shm/]<br>> SSE2 detected<br>> load = 0.2297 max usecs: 40.000, spare = 10626.000<br>> ...<br>><br>> looks like a nice hint??<br>><br>> what is about processor type and architecture?
<br>> are there more hints about optimizing?</blockquote><div><br>I'm kind of writing this as a general note to other audio authors.<br><br>One big win on large data sets (lots of tracks) that overrun your available cache, is to cache align the floating point data rather than simd align it. On several of my oprofiles and test cases with ardour + jack where I was overrunning L2 cache regularly, cache alignment sped up simd calculations by 9-40%.
<br><br>On a linux system, to find the optimal alignment for your data, do a cat /proc/cpuinfo | grep cache_alignment.<br><br>and go looking through whatever code you are running for calls to "posix_memalign". For example, jack uses a default alignment of 16, when 64 or 128 would be more appropo' for modern processors.
<br><br>Cache alignment is an easy test, I hope more people try it....<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Enabling SSE throughout the project via compiler flags makes the
<br>resulting code /depend/ on SSE. In other words, running that on a<br>platform with no SSE will result in "Illegal instruction (core dumped)".</blockquote><div><br>At present the major bottlenecks in ardour and jackd have all been reduced considerably by extensive oprofiling the hot spots and replacing them, where possible, with SSE. In typical situations the SSE routines are still near the top of the runtime for those two programs. Without SSE, the "normal" equivalents are in general responsible for 3-8x more of the total runtime. Recent example: SSE optimizations to ardour cut total cpu usage for an extreme test case (116 tracks, 40+ busses) from 77% down to 35% in the 64 samples/period case, and from 35% to 12% in the 1024 samples/period case.
<br><br>SSE routines could be used to speed up graphics as well, particularly in RGBA situations. <br><br>Linux's Oprofile subsystem is wonderful as it has low overhead and can run on smp'd rt kernels. <br><br>At present the major bottlenecks left for ardour and jack are very much down in the noise floor. A typical user now spends more cpu time in plugins than in those two core programs. (thus I've been oprofiling a few plugins heavily, among other things, now have a SSE'd comb_run routine... and hopefully will announce some sped up plugins soon)
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">In projects like jackd and Ardour there are places which can be improved<br>vastly via SSE code. Creating a framework which can enable SSE / etc.
<br>per the platform the binary is ran makes it possible for distributions<br>to include optimized versions of the software which will work on any x86<br>platform.</blockquote><div> <br><br>
I note that x86_64 comes with SSE and SSE2 by default and that taking branches (e.g: determining at run time if SSE1 or SSE2 is available), particularly at low period sizes (64), is expensive, so it would be nice if more audio code, when compiled for x86_64, used SSE by default, without the run-time test.
<br>
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I have heard good things about the current development branch of gcc,<br>but gcc
4.1 still has a _long_ way to go when it comes to vectorizing<br>(=writing code using parallel SIMD instructions, in other words SSE).</blockquote><div><br>gcc 4.3 - which is a long way from working - has a vectorizer which understands the type conversions so critical to SSE usage. (sampos's famed assembler SSE peak code uses a clever type conversion)
<br><br>To enable automatic vectorization in gcc 4.1.X, you can turn it on by -ftree-vectorize <br>and see what it is doing by -ftree-vectorizer-verbose=5<br> </div><br>And weep. for example: In the zillions of lines of code in Ardour 2, only 2 loops get automatically vectorized with gcc
4.1.X.<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hand written assembler is still many orders faster than what gcc is<br>capable of doing. In Ardour peak computation (for both metering and
<br>waveform displaying) is written in SSE (the first part in pure assembly,<br>the second in a C-level abstraction which is almost 1:1 assembly). Both<br>functions are more than 20x faster in raw performance than what gcc
4.1<br>can do.</blockquote><div><br>Not only that, but writing SSE code is FUN! It's one of the few cases left in this world where a the human can still be smarter than the compiler! <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Sampo<br><br><br>_______________________________________________<br>Linux-audio-user mailing list<br><a href="mailto:Linux-audio-user@lists.linuxaudio.org">Linux-audio-user@lists.linuxaudio.org</a><br><a href="http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user">
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user</a><br></blockquote></div><br><br clear="all"><br>-- <br>Mike Taht<br>PostCards From the Bleeding Edge<br><a href="http://the-edge.blogspot.com">http://the-edge.blogspot.com
</a>