Re: Implementing another language on luajit - function arguments
- From: Raphaël Amiard <raph.amiard@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sun, 3 Nov 2013 20:46:04 +0100
> > One surprise I had is that tables in LuaJIT are more expensive that
> > objects in V8. I don't know exactly why, one possible reason is that
> > LuaJIT's GC is not up to par with V8's for the moment.
> How did you measure this?
Well it was not easy given how hard JITed languages are to benchmark,
but I did some simple tests, profiled with the tools Mike did develop
at the time,and saw that LuaJIT was spending a big part of it's time
in the table initalization routines and in the GC.
> Instead of tables, did you try using ffi objects in a custom memory manager?
No. To the best of my knowledge, there is no way of putting references
to lua objects in FFI objects, and I had no intention of using only
FFI objects everywhere.
The language I translated to Lua was Clojurescript, which being a
functional language, is heavy on memory allocations. Depending on your
requirements, using FFI structures everywhere + custom memory
management (ref counting for example) might be appropriate. If it is
not, the strategy of optimizing the common case (call of a function
statically resolvable in the lexical closure, for which you can
resolve the order of keywords argument at compile time) is quite easy
to implement, and yields you good performance.
That said, functional patterns - combinators - won't be optimized. The
problem in the end is that LuaJIT is not necessarily a good target for
functional languages, when you collude this with the GC and the fact
closures are not (or were not at least when i worked on this project)
JIT compiled. This might change in the future though.
2013/10/25 lex pops <lexpops12@xxxxxxxxx>:
>> One surprise I had is that tables in LuaJIT are more expensive that
>> objects in V8. I don't know exactly why, one possible reason is that
>> LuaJIT's GC is not up to par with V8's for the moment.
>
> How did you measure this? Instead of tables, did you try using ffi
> objects in a custom memory manager?
>
--
Raphaël AMIARD
Other related posts:
