[chuck-users] benchmarking UGens

[Stephen Sinclair]

On Wed, Mar 11, 2009 at 10:08 AM, Kassen <signal.automatique at gmail.com> wrote:
> Steve;
>
>> > 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.
>
> Yes, I was talking about optimising UGen performance though. There are some
> digital modular synths that optimise by taking a group of  "UGens" and
> converting those to instructions in a optimised way. I meant we couldn't do
> that as we want to be able to re-route them.

That's basically true.  It's not _impossible_ to optimize them
(inlining "tick" functions, etc), but it would be a completely
different problem to tackle.  A pretty interesting one however!


>> On the other hand, if the compiler really could generate code that
>> fast, it would be worthwhile to implement UGens directly in ChucK.
>
> I still think that would be worthwhile to have as a option. Even if it would
> be slow(er) it would be great for prototyping and would lead to cleaner
> code. For example; I sometimes use a overdrive that consists of a a set of
> UGens. When I use that a few times, on a few sounds, I end up with code that
> may work and be relatively fast but that's not so pretty.
>
>
>>
>> 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.
>>
>
> Could you explain what you mean by "ChucK's opcode generator"? "Opcode" is a
> CSound term that translates roughly to "UGen", right?

Sorry for the confusion.  I meant opcode as it is used in talking
about compilers.  The word just refers to "operation codes", i.e.,
codes that represent machine instructions.  In ChucK, its VM opcodes
are actually instances of the Chuck_Instr class.  Not the same as
CSound's opcodes.  (Though, shamefully, I don't actually know CSound
very well.)

Steve