On Tuesday 09 October 2001 02:11 pm, Michael Maraist wrote: > I saw another post on the improvements provided by the simple > modification of: > > goto *array[*code]; > > lbl1: > # do stuff > goto *array[*code]; > lbl2: > # do stuff > goto *array[*code]; > ... > end: > return; > > And they were right. I received MASSIVE performance boosts.
Yeah, this is what I coded up into the current Parrot baseline. I went from 46M to 113M ops/sec. (On test.pasm. This is my Linux/Athlon system. The 46M is normalized to a no-input-checking dispatch loop.) > The next thing to test is having 100 core op-codes. Then it'll be > interesting to see how horrible adding the conditionals are. > Theoretically we don't need any conditionals. "change_state" op-codes > can simply return NULL just like end does, thereby breaking out of the > loop automatically. Except how do you determine at compile time when to insert change state opcodes? I'm convinced (and humbled :-) by this approach (even though it makes gcc scream under Wap rules), but I'm not convinced that we'll have an all-inclusive static set of opcode functions. (Which means that you'll still have to check for a valid target.) > > I never understood the reasoning behind while(*code) instead of just > while(code) (which is properly handled here). Obviously there's value > to while( code > start && code < end ), but that's in the non-hell-bent > loop. As I previously posted, that was probably my typo (left over from caching the value on x86) and should have been pc. -- Bryan C. Warnock [EMAIL PROTECTED]
