I6 optimizations

(Forking off from a different thread…)

If I’m reading this profiling output right, Quixe spends 40% of its time running compiled code. 6.5% is in execute_loop(), which does work whenever the interpreter jumps code paths – that includes branches, calls, and returns. 18% is associated directly with function calls and returns. 8% is reading from memory. 15.5% is accelerated opcodes. The rest is assorted stuff.

(Safari 5.0.4 on a MacBook Pro. Tested Reliques after a restart, so no new functions were being compiled.)

Function calls are certainly significant. But refactoring the I6-level parser isn’t going to change performance noticeably, not unless you add a function call inside the most critical tight loops. What were your numbers – hundreds of thousands of function calls? The parser has no major code paths that are repeated hundreds of thousands of times per turn. That’s all inefficiency in low-level property-checking and activity-invoking.

It’s been a few years since I looked. But it doesn’t do a lot, that I remember. (Take the below with a grain of hazy memory.)

No function inlining. No eliminating entire dead functions. Not much that you’d call peephole optimizing, although I think it’s pretty good at compiling expressions into efficient code.

Things it does do: Folding constants in arithmetic operations. Eliminating dead code inside functions – I think.

code.google.com/p/parchment/issu … violet.log
Is the worst example I’ve found so far, from a single command in Violet. Now there is sure to be some buggy I7 code there, but the I7 compiler must still be generating a whole lot of recursive code.

But perhaps Quixe performs a lot better because of it’s accelerated function support. That would bypass the function enter/exit infrastructure entirely wouldn’t it? Especially when those functions call each other. Maybe the best optimisation for Gnusto would be acceleration too.

I6 throws warning messages on unreachable code, most of it return EMPTY_TEXT_VALUE; and the like that I7 appends to everything to ensure a to-decide phrase has a return value, so it’s not unreasonable to assume it can eliminate dead code inside a function, at least if that code follows a naked return statement.

It also throws lots of warnings about unused routines, variables, constants, etc. It looks like the potential for dead code removal exists if it doesn’t do so already.

Thanks for the haze-dump, zarf. My curiosity is sated for now, I think. Back to CLM.