29 Nov
2007
29 Nov
'07
8:38 p.m.
On Thu, 2007-11-29 at 01:49 +0100, David Olofson wrote:
On Thursday 29 November 2007, Dave Robillard wrote:
[...]
It makes a lot less sense to explicitly deny them for no particular
reason.
"You can't use events larger than x bytes"
Why? Because some Dave or another said it could possibly be slow in
certain cases? Sure, there's a performance hit running on really
massive buffers. There's a performance hit running on tiny buffers too.
So what?
There are times when running on single sample buffers is what you want
to do, even though it's slow. There are other times when running on
massive buffers is what you want to do, even though it's slow. If you
don't want to do that, well... don't do that. Currently the only limit
on sizes of things in LV2 is the range of uint32_t, and this is a Good
Thing.
Not explicitly making things verboten != "supporting"
I do agree we should not be adding crufty features to support massive
buffers, if that's what you mean. It's easier to just split the cycle
anyway.
Well, sure, but big data is big data. In the
typical case plugin
buffers are much smaller than the cache
[...]
Of course, but that's exactly what I'm talking about - large buffers,
and why it doesn't make sense to support them. :-) Last time I looked into this, a reasonably optimized
resampler with
cubic interpolation and some ramped parameters was memory bound even
on a lowly P-III CPU, at least with integer processing. (Haven't
actually tested this on my AMD64...)
I think floating point should be as fast or faster in most cases, at
least on P-III CPUs and better - and with SIMD, you may get another
2x-4x higher throughput at that.
A clever host can just use the same, say, 2 buffers (stereo audio), so
running a bunch of plugins on it will be in the cache the entire time.
Ardour, for example, (usually) runs the entire route's chain of plugins
on the same buffers in-place. For any reasonable Jack buffer size on
any reasonable modern CPU, those buffers are going to be in the cache
for the duration of that entire chain's processing. For non-in-place
chains, add a factor of 2 (and it's still going to all fit in cache in
many cases).
In other places, that's not the case. Point being this is the host
author's - not the plugin specification's - business.
-DR-