Re: asm.js
- From: Dan Eloff <dan.eloff@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Wed, 20 Mar 2013 17:27:48 -0500
I think it's a case of the programmer thinking he knows better than the
compiler (like in C with the inline keyword.) The problem is the programmer
is more often than not wrong. With a trace compiler things get a lot worse,
the runtime really does know much more than the programmer and makes better
decisions. If a function is hot, and can be compiled, it gets compiled. If
either of those conditions are false, compiling it won't make any
difference anyway. The bottom line is that LuaJIT is smarter than you or me
in choosing what code to compile, that's a game it will almost always win.
The smart thing for us to do as programmers is focus on the games where we
can actually win (like making sure hot function are actually jitable, and
profiling and optimizing them if need be.)
Cheers,
Dan
On Tue, Mar 19, 2013 at 9:10 PM, GrrrWaaa <grrrwaaa@xxxxxxxxx> wrote:
> Has this come up before here?
>
> http://asmjs.org/spec/latest/#introduction
> http://asmjs.org/faq.html
>
> The attractive feature is predictability (sometimes you really know that a
> certain function bounds a chunk that should be compiled, and it would be
> nice to tell the VM this).
>
> It made me wonder if a subset of LuaJIT+FFI could fit within an
> ahead-of-time compilation policy for certain functions (in asm.js they are
> maked with the ugly "use asm" directive), and throw an error if the
> function breaks the rules of this subset (e.g. by invoking a non-inlineable
> operator).
>
Other related posts:
