[webkit-dev] arm jit

[Geoffrey Garen]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090610/d997d32a/attachment.html>