28 Nov
2007
28 Nov
'07
6:01 p.m.
On Wed, 2007-11-28 at 16:52 +0100, David Olofson wrote:
On Wednesday 28 November 2007, Krzysztof Foltman
wrote:
[...]
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.
-DR-
I don't think it's a serious problem.
Huge processing buffers are
not very useful in practice.
[...]
Actually, they're directly harmful most of the time!
For any graph with more than one plugin, and with plugins that use
internal buffers of the I/O buffer size, large buffers means you'll
get a gigantic cache footprint. It gets worse in "high" latency real
time situations (games, media players etc), where you have other
threads fighting for the cache as well.
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...