On Wed, 2008-08-06 at 21:44 -0400, Stephen Sinclair wrote:
By the way, this little excursion into the source made me notice that every single chuck instruction is executed as a virtual function. This means that for every instruction the struct must be dereferenced, and then it's vtable, and then the function can be called. This would be a great place to look into for optimization, I think. A jump table or big switch statement with inlined functions might be way faster.
1. Before you do any optimization, it might be worthwhile to do some profiling. I don't happen to have a 32-bit machine handy (actually, I have one but it's a laptop and probably way underpowered for ChucK.) But I do have the "recipes" for profiling Linux code down to the chip level (cache misses, pipeline stalls, close-enough-for-government-work annotated source and assembler listings, etc.), courtesy of "oprofile". 2. If you're digging down into virtual machines, "pseduo-instruction dispatching", interpreters, etc., you should probably read http://www.complang.tuwien.ac.at/forth/threaded-code.html. There's a little "trick" you can use to speed up threaded code if you're willing to use a non-standard feature of GCC that most compilers don't have, and some other things you can do to speed up other forms of dispatch. -- M. Edward (Ed) Borasky ruby-perspectives.blogspot.com "A mathematician is a machine for turning coffee into theorems." -- Alfréd Rényi via Paul Erdős