On Tue, 2005-11-15 at 11:58 +0000, James McDermott wrote: it depends whether playback + recording is the only goal, or editing is in the potential workflow. editing interleaved data, especially if there are unrelated signals in different channels that will be treated differently, is really, really hard. if all you do is playback and record, interleaved is marginally more efficient.

On a related subject: How is level one cache replaced with new data, should one (or ones compiler) decide to use some of the prefetch instructions available from Intel PII and up? It would make sense to fetch the next dataset while doing what has to be done "now". On the other hand, overwriting the current dataset is somewhat counter productive. The layout of the data would influence these decisions, no? mvh // Jens M Andreasen On Tue, 2005-11-15 at 11:58 +0000, James McDermott wrote: --

float z[n], and do sse as good as the next person. How far it will dive into other goodies in sse/altivec, I dunno. Apple used to have some advice on portable gcc vector programming but I can't find it in the latest revision. There is a general discussion here, well worth reading: http://developer.apple.com/hardware/ve/simd.html I am still on gcc 3.4 though. It will use the sse unit for scalar floats (if you ask politely), more on this later. About prefetch, I can say that this gcc will not recognize a linked list in a doforall loop. Perhaps looping thru an array could help? Hey, and isn't this where all these hot diodes in modern hardware is supposed to look ahead and recognize a pointer being incremented? Speculatively fetching instructions to fill the pipe without also getting the data makes no sense, that would just stall execution. Mmmm ... wait a second. Speculatively fetching a load will eventually get you the data also. OK, so the system works :) I am on a PIII these days, and this one has only a very small window of opportunity where it can shuffle instructions around. Actually it feels more like marketing bull since nothing much happens without interleaving what you are doing right now with what you have (almost) done and what you are about to do next. I said more on scalar sse floats later? If you think this code snippet looks funny: if(x == 0.0) x = 0.0; ... then wait untill you take it away from the code attached below, and watch execution time more than double up. (And no, it is not the missing cast to float.) Don't ask! I have no idea how I could dream up that expression ... There is some unfinished work in the function: int set_DAZ_and_FTZ(int on) .. where I do not recognize an (early) AMD k8. Anybody care to enlighten me? mvh // Jens M Andreasen (still fighting the man.) --

On Wed, 2005-11-16 at 00:05 +0100, Florian Schmidt wrote: Most of the time prefetch is left to compiler (works ok most of the time), though it's done manually for some functions. For x86 there is handwritten SIMD (E3DNow! and SSE2/SSE3) version of these operations, automatically used depending on runtime architecture: - Copy - Add - Multiply - Complex multiply - Multiply-add - Complex multiply-add - Add-multiply - Multiply-accumulate - Min-max - Normalized cross-correlation - i16 -> float, i32 -> float conversion - FIR filter - IIR filter Optimized functions are also used as part of more complex functions. All allocations are aligned to required boundary. There are C, C++ and C++ template APIs. Btw. Intel's compiler can vectorize most of the remaining functions and for some even parallelize. Currently the lib is missing autotools stuff, so it's makefile-configured... -- Jussi Laako <jussi.laako(a)pp.inet.fi>

I don't think runtime detection is necessary if you compile both library and app for the specific arch. A few ifdef's take care of the selection at compile time. If you want to provide a multiarch binary, I don't know how he does it, but you probably only have to check once when the library is first loaded. You link your app against stub functions and then the detection procedure can point the stubs to the right set of functions (via, i.e., function pointers) and from there on no further check is needed, unless you want to provide support for hot swappable cpu's ;) The penalty in this case is an extra level of indirection (a few stack instructions a jump and a ret) for each call. Well worth the pain, IMO. Luis

Jussi Laako wrote: For multimedia applications, one crafts a different entire function per CPU type. One then simply uses function pointers to select the best function at init stage. This therefore results in a jump without a comparison. For example, A resampling routine. There is a CPU specific function to handle a block of samples, so the extra "jump" cost is only used per sample block, and not per SIMD instruction. James