On Saturday 05 October 2002 10.51, you wrote: Yes, it probably is in some way (to my knowledge, this only occurs when I have quite large blocks to process), however, the task and data is the same for both cases, the difference is that some unrelated code has been run in a dlopen'd module before it. The work-around I'm doing now is to fork the convolution process early, before any dlopen stuff, it makes the initialisation much more cumbersome, but the performance problem goes away. /Anders Torger

On Sat, Oct 05, 2002 at 12:19:04 +0200, Anders Torger wrote: Yeah, I've seen this. If you look around on the web there is some code for cache aligning in x86's - I've never tried it though. In the last plugin I was writing I got a huge perfomance increase by increasing the size of a ringbuffer, of course that was only in one host. - Steve

On Saturday, October 5, 2002, at 04:30 PM, nick wrote: Techniques for improving cache performance should be common in any MS-level compilers class, so you may want to search for course notes on the web. Here are a few other things to check out: * "Compiler transformations for high-performance computing" http://citeseer.nj.nec.com/bacon93compiler.html This is a survey paper that covers compiler optimizations, emphasizing techniques for implementing high-performance scientific code; you'll probably find that it shares several things in common with high-performance audio code (except for the RT requirements of audio and the massive data sizes of scientific code, of course). You can probably implement most of these by hand or coax gcc to implement some of them for you. * http://oprofile.sf.net Oprofile is a profiler that uses the hardware counters. On most modern processors, you can get a counter for I-cache and D-cache misses. * _Modern Compiler Design and Implementation_ by Steven Muchnick * _Modern Compiler Implementation in {Java|ML|C}_ (pick one) by Andrew Appel I don't remember how big cache lines are on the x86, but page-aligning data (i.e. address % 4096 == 0) should be a good start. You also want to try and have inner loops operate only on data that fits in a cache line. There is a technique called "loop tiling" to restructure loops so that they will work on a cache line worth of data at a time. As an aside, you can usually get loop performance gains by loop unrolling or software pipelining, but you'll want to make sure that the code for your inner loop fits in the I-cache. The big thing to remember is that once you start getting into this stuff, you're getting into optimizations that are not only specific to one architecture, but to a particular processor. Optimizations that will work on a PIII might not improve performance on an Athlon, and optimizations for either will result in code that is much slower on a celeron (and vice versa). Therefore, most of the serious low-level stuff is best left to a compiler backend. If you're willing to do serious autoconf work, though (I think fftw does something like this), you can probably implement some good stuff by hand. In general, you can get huge performance increases by respecting the memory hierarchy. That is to say, if your code (or the code your compiler generates) respects the fact that REGISTERS are an order of magnitude faster than L1 CACHE which is an order of magnitude faster than L2 CACHE which is an order of magnitude faster than MAIN MEMORY which is an order of magnitude faster than DISK... then you'll have code that's much, much faster than a naive translation. However, a lot of this is probably overkill for an effects plugin or pattern-based softsynth. :-) best, wb