This expands out to 95 inline instructions on the MIPS for just the
slow case alone, of which 3 are functions calls to other functions.
So this probably requires thousands of clock cycles to execute.
IMHO it doesn't make sense to inline op_call because:
You've made some interesting theoretical arguments against inlining
op_call, but the empirical win from inlining op_call -- on x86 and
arm, at least -- was tremendous.
Maybe the situation is different on MIPS. You can experiment with the
JIT_OPTIMIZE_CALL preprocessor setting to test your theory.
1. It's a huge amount of JIT code just to save three of four
instructions at runtime (call, return, and maybe some register
shuffling)
I don't understand your math here. Just the code to pass arguments to
a call helper function would be more than three or four instructions.
2. The code which is executed is thousands of instructions and
saving three or four instructions is a microscopic net win.
The generated code for a call slow case is pretty lengthy, but be
careful not to confuse generated code with executed code. Slow case
execution is relatively rare.
6. The JIT-generated code resides in the data cache, and must be
flushed to main memory, then the instruction cache must be
invalidated so the new code will load into the instruction cache.
Because the WebKit JIT seems to do lazy compilation of functions at
call time (instead of compiling all the functions in one pass), this
requires the data cache to be flushed and the instruction cache to
be invalided every time a new function is generated, which further
degrades performance. This type of code generation strategy is ok
for processors with unified caches (or pseudo-ounified on x86) but
for RISC machines with separate instruction and data caches, it's
really awful.
It would be an interesting experiment to compile functions at creation
time instead of call time, and see if things got faster. I'd love to
hear your results, if you try it.
I doubt that eager compilation would be a good strategy for the web,
though, since web pages tend to load very large libraries of
functions, while only calling a small percentage of those functions.
Geoff
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
