On Wednesday 28 November 2007, Dave Robillard wrote:
[...]
> > Obviously, this effect is less visible with non-trivial plugins -
> > but even how many plugins in a "normal" graph are actually CPU
> > bound? In my experience, the effect is very pronounced (several
> > times higher CPU load with 512 samples/buffer than with 32) when
> > using a bunch of sampleplayer voices (cubic interpolation +
> > oversampling) and some simple effects. You have to do some pretty
> > serious processing to go CPU bound on a modern PC...
>
> Not really true for linear scans through memory, which reading
> plugin buffers usually is. This is the ideal cache situation, and
> you can definitely get full utilization sweeping through things much
> larger than the cache this way (this is exactly what the cache is
> designed to do, and it does it well; try it).
I did, and that's what I'm drawing my conclusions from. ;-)
No cache controller logic in the world can avoid the bottleneck that
is memory bandwidth. If your data has been kicked from the cache, it
needs to get back in, and the only time you're not taking a hit from
that is when you're doing sequential access *and* your code is CPU
bound, rather than memory bound.
> When you're jumping all over the place things do go to hell fast,
> but luckily we're not.
Right, that's not the issue here, but I'm talking about "cold" memory
and raw bandwidth.
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Thu Nov 29 04:15:02 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 29 2007 - 04:15:02 EET