Re: Consoles and interpreters (was Re: FYI: No JIT on Windows 8 for ARM)
- From: Tomas Lundell <tomas.lundell@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Fri, 11 May 2012 08:54:28 +1000
>
> PPC has strictly segregated integer and FP register banks. You can
> only transfer from one to the other via memory. This means all
> double-to-integer conversions have to go through memory and incur
> the dreaded 40 cycle penalty. Yes, fourty cycles!
Though with dual-mode we would surely be suffering from some extra
branching. From recollection a the branch misprediction penalty is fairly
stiff as well (maybe 20-25 cycles off the top of my head). As I couldn't
even recall whether we even tested dual-number mode, I certainly can't
remember how it worked out performance-wise. Might have been six of these
for half a dozen of those. If you are curious I could probably find out.
The ideal might be to use platform specific instructions (I refer to the
VMX set) to eliminate some of the LHS. I don't pretend to understand how
complicated that would be to implement nor what (if any) the gains would be.
>
> Yes, this is all due to the @$%&)" design of these chips, that
> penalizes all interpreters. On top of this, the console
> manufacturers had the brilliant idea to ban JIT compilers, which
> wouldn't suffer from all of this. :-/
>
>
Hopefully for the forthcoming crop of consoles they realise it would be a
competitive advantage to allow JIT on their system. I'm not holding my
breath though...
> Now you know why a Lua interpreter runs dog-slow on consoles, even
> though they run at around 3GHz, which is similar to your desktop PC.
>
For the benefit of the audience, the LuaJIT interpreter is two to three
times faster in at least one real-world scenario compared to stock Lua. Not
as good as a full JIT, but it's certainly nothing to sneeze at :)
Other related posts:
