28 Nov
2007
28 Nov
'07
6:15 p.m.
On Wednesday 28 November 2007, Dave Robillard wrote:
[...]
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.
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). 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 --'