At 05:02 AM 5/15/2000, Robin Davies wrote:
>I've been finding tablereads kinda oppressive when trying to write realtime
>instruments with Sfx. Tablereads are a *lot* slower than array references,
>since either interpolation has to be performed, or an explicit test has to
>be made for the integer-ness of the index. Neither of these is terribly
>fast. I'm not sure that interp settings have an effect either way. I'm just
>polishing off a performance monitor opcode, but I rather suspect that Sfx's
>high-quality interpolator is acually faster than the linear interpolation of
>"interp 0" due to the divide required to do linear interpolation. (I'll find
>out tomorrow).
Hi Robin,
on the other hand I suspect that this can't be a general rule. For instance
I know that some DSP platforms directly support linear interpolation.
>My grumble for today: SAOL could *really* use an integer version of
>table-read.
I don't see exactly your point here: I understand well that array references
are faster. When I tried to write down some conformance points for SA in MPEG-4
I decided to calculate a tableread as an interpolation, and a decoder will
be requested to support a number of interpolations that is much smaller than
the number of flops. This at least if you are MPEG-4 oriented. Now, if you
care about the SA decoder you should not care, imho, about the ability or not
to run in real-time a *certain* example, but to have a static optimization that
permit you to execute a certain amount of calculation in reasonable cases.
On his/her side, the content provider will have to produce programs below a
certain level, and then it is his/her problem to think about tablereads or array
references, and how to make the best algorithms for what he want to describe
staying in its target decoder expected capabilities.
Please correct me if I am wrong, but I don't see the difference in functionality
between an array and a table that can be read only at integer locations.
>I've been tracing through elpelele to figure out why it doesn't run in
>realtime. (Reason one: trills and sustains generate enormous numbers of note
>instances because SAOl doesn't perform voice scavenging of midi; reason two:
>although I can run about 90 elpelele voices, the reverb blows the entire
>compute budget because of heavy table-reads performed at a-rate (and a
>gratiutous call or two to pow as well)).
as above. my way of seeing the problem is the other way round...
>It's soooo close to being legal. I suspect that its close enough that it
>probably does work on most compilers.
>
>Here's the problem. It's a subtle one. If the iLastNoteInstance array really
>is copy-in/copy-out-ed then it gets copied-in and copied-out at the
>beginning and the end of the i-rate execution pass. Hence, the array
>reference on line [1], which would otherwise be legal, fails to get the
>correct value since the array doesn't get copied in at the beginning of a
>k-cycle. Semantically, I suppose this would be an error, although the
>standard doesn't consider this case, although it does explicitly say that
>the l-value rate is calculated as expected by this opcode.
I remember that a similar discussion rose a first time about 1 year ago, when I
tried to do a similar thing for the cdl example I produced. The polyphony
is really high there, and it could be reduced in such a way. I remember that
the issue was more biased to the possible parallel execution of instances, but
more or less the practical problem is the same. I think that now the standard
specifies that the several k blocks must be executed in sequence, while a-blocks
can turn in parallel. In the end I imagined a solution as you write below.
>However, here's a test that would allow a program to actually determine
>whether the target of an imports exports statement actually is using
>copy-in/copy-out or direct references.
>
>(btw, the fix for the given opcode is to add a first-time flag and grab the
>note instance at k-rate, so I'm not toooo upset yet. I'm more concerned
>about the fact that behaviour in this case is.. well.... is it or isn't it
>legal?).
imho right now it is not, because the "signal variables" subclause clearly
talks of copying-in at i-rate; and even if I am in favour of references, I think it should
stay like that and I'd use a fix like you write (or a table with tablereads :-), since
the table is updated at control passes). I guess that sooner or later somebody
will need to "keep" the values throughout the instance and then he will need to
"save" them somewhere else. Anyway I will not complain if this is changed,
I will complain if another point of unspecified behavior will be introduced.
Best regards,
Giorgio
__________________________________________________________________
Giorgio ZOIA
Integrated Systems Laboratory - DE/LSI - EPFL
CH-1015 Lausanne - SWITZERLAND
Phone: + 41 21 693 69 79 E-mail: Giorgio.Zoia@epfl.ch
Fax: +41 21 693 46 63
__________________________________________________________________
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:55 EST