[chuck-users] benchmarking UGens

[Stephen Sinclair]

On Tue, Mar 10, 2009 at 11:49 PM, Kassen <signal.automatique at gmail.com> wrote:
> Tom;
>
>>
>> I'm pretty sure there being no Gain-specific functionality is all
>> there is to it. Can you find a UGen that doesn't support "3 => u.op"?
>> I think "Gain" is just the most generic UGen possible.
>
> I agree.
>
>>
>> (I should really go verify it in code, but I'm a little busy tonight.)
>> (Same reason I haven't tried my hand at the ChucK benchmarks.)
>> (I'll probably forget about both of these by the time I'm free, though.
>> ;p)
>
> Well, there are UGens with no input (SndBuf, the STKInstruments...) I'm not
> sure what good .op() is for them but I do believe the docs claim they have
> it. That's not actually useful, but then again; this compiles as well;
>
> 2 => blackhole.op; //it has a .gain() as well, there 's something Zen about
> that.
>
> While we're at it; dac has a .op as well, I found that earlier. This can
> indeed be used to create terrible noises after sporking a few shreds as the
> dac is the same across all shreds, in case you were wondering. In my
> experience it's best left for those situation where you were planning to end
> your set anyway :¬).
>
>>
>> > At any rate this shows that the base-costs of adding a UGen at all are
>> > there
>> > and are quite signifficant compared to the cost a full UGen. IMHO this
>> > pleads for the "blob" project.
>>
>> Or an optimizing ChucK compiler! (heh, heh, any takers?)
>
> That would mean re-compiling the whole UGen graph at any additions as we can
> hot-swap running UGens, I posted about that when we were talking about more
> advanced uses of casting. This would be a spectacularly bad idea unless we
> could also somehow preserve state of individual UGens to prevent glitches.
>
> We may be able to have a optimising compiler but we can't (preserving
> current functionality) condence the UGen graph like some digital modulars do
> (simplifying groups of UGens internally). Well, maybe we could but even
> thinking about it makes my head hurt. IMHO we need more facilities for
> hot-swapping UGens, not less.

That's basically true.  Even if the compiler produced machine code as
fast as C, it would still issue calls to connect up UGens the same way
it is done now.

On the other hand, if the compiler really could generate code that
fast, it would be worthwhile to implement UGens directly in ChucK.

I've been playing more and more with LLVM lately, but still too early
to say anything.  I was messing around with the ChucK compiler
previously, and found a few places to play with its opcode generator.
Don't hold your breath though, as I'm way too busy on other things. :)
 I'd love to spend some more time with it in the summer though.


Steve