Re: [LAU] optimizing jackd build

On 4/9/07, Tim Blechmann <tim(a)klingt.org> wrote: Two issues - one of the core concepts of jack et al is the idea of a run time defined samples/period. The compiler has no idea that a typical routine is always called with some multiple of 64 samples and can't unroll well. Secondly - the compiler intrinsics for SSE1,2,3,4 basically suck. You can, fairly effectively, use the _mm_whatever abstractions, but as soon as you get into type casting you get into a world of hurt and the compiler generates very inefficient code. beside that, if ardour is using a fixed block size, using compile-time Would be nice, but not enough hardware can run at low samples/period and there are always situations where you want to run at more. loop unrolling would be another point, where one could gain speed (iirc, Consistently memory aligning things is an issue on x86. Since the compiler can't figure it out (and it would be nice if there was some compiler intrinsic that said "this routine is nearly always called with some multiple of 32 bytes) the hand unrolled routines (more every day) basically have to: normally loop until you have alignment (hopefully just a test and branch) on some arches, doing loops in 64 byte quantities is a bigger win than 16, so loop with 16 byte quantities until you can do 64 then do 64 byte quantities for a while then back to 16 then back to 4 It's a pretty easy pattern once you get used to it, but it pays to oprofile first, have the best algorithm second, then... SSE like crazy. :) tim -- Mike Taht PostCards From the Bleeding Edge http://the-edge.blogspot.com