Re: [ANN] llvm-lua 1.0
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: [ANN] llvm-lua 1.0
- From: David Given <dg@...>
- Date: 2009年6月05日 11:46:53 +0100
Mike Pall wrote:
[...]
Well, I've thought about something like an '-Obuiltin' option. This
would pin down all built-in library functions at compile time. Ok,
so monkey patching would no longer give the expected results (you
can still do math.sin = math.random, but it's ignored).
It might be nice to be able to specify this as a per-function or
per-source-file hint, so that you can use it to speed up specific
bottlenecks while retaining traditional Lua semantics elsewhere. This
would, for example, be particularly useful on pure number-crunching
code, like the core of a ray-tracer or 3D engine.
(Also, I am very satisfied to discover that 'monkey patching' is an
accepted industrial term with it's own Wikipedia page. Also known as
'duck punching', apparently. I approve of this.)
[...]
In terms of Lua 5.1 bytecode this would replace GETGLOBAL+GETTABLE*
with a single LOADK. This ought to be *really* fast, both in the
interpreter and when compiled.
For simple numerical stuff like trig functions, would the JIT manage to
then convert them to inline code sequences where appropriate? For
example, math.sin could theoretically become a single inline fsin
instruction in the right circumstances. Or will it still bounce it via
an external C function?
--
David Given
dg@cowlark.com