21 Oct
2012
21 Oct
'12
7:36 p.m.
On Sun, 2012-10-21 at 11:38 +0000, Fons Adriaensen wrote:
On Sat, Oct 20, 2012 at 07:02:16PM -0400, David
Robillard wrote:
The goal of the plugin is to do synchronous (i.e.
processing in the
run() context) convolution in a *strictly* hard-real-time fashion with
no latency. Doing the processing in another thread(s) does not meet
this requirement essentially by definition.
This is again *simply not true*. It's actually possible to prove that
the scheme used by zita-convolver will not fail unless the synchronous
solution would fail as well. This goes back to research done in the
1980's, you'll find the proof somewhere in the IEEE transactions on
parallel processing of around that time.
[etcetcetcetcetcetc] As shown above, in real life it will be much *less*
reliable.
As *speculated* above. Things like this are shown by experiment, and
experiment only. If either of us wants to show that threads or
synchronous is better, the only way to do so is to actually load a
system with many such plugins and plot the results. There is a reason
parallel computing literature is full of such plots, and nobody cares
about performance arguments that lack them whatsoever. It's simple to
convincingly argue just about anything "would" be faster - and be wrong.
This is true even sequentially on modern architectures, and it's
*really* true when threads get involved.
More to the point though, your argument is convincing - and a straw man
(see below). More importantly, I don't care, and it was a mistake to
ever indulge it.
The point of this was to invent and implement a bunch of LV2 things,
including block length restrictions in general (something you are about
the only advocate of around here, ironically).
Perhaps convolving in this way is completely idiotic. Great, fine,
fantastic, DON'T CARE, because that is not the point. I never claimed
this plugin was the best way to do convolution (I explicitly did the
exact opposite), so stop arguing against nothing.
It's not the best convolver.
It's not the best way to convolve.
It's not the best way to use libzita-convolver.
It's not an IR.lv2 replacement.
It's not recommended for use, by anyone, at all, for anything.
It is a tech experiment. Get it?
Both (1) and (2) are simply untrue, there is *no*
relation at all between
using threads and allowable block sizes. You are really showing that you
haven't even started to understand how partitioned convolution works.
As it happens you are using the exact same confusion of concepts to make
a straw man of my argument so you can subsequently burn it. You asked
what's wrong with threads, and I made some points about why *threads* in
plugins are undesirable, in general. I didn't even say anything about
partitioned convolution.
I also don't care, and didn't write that part. Yell at Robin instead.
-dr