4 ms·
>> "To see how its performance compares, I run a few benchmarks against ... LuaJIT (interpreted)" Why would you use LuaJIT in interpreted mode? That defeats t
by alberth 13y ago
>> "To see how its performance compares, I run a few benchmarks against ... LuaJIT (interpreted)"
Why would you use LuaJIT in interpreted mode?
That defeats the main reason for using LuaJIT, and you'll see massive improvement in speed if you run it not interpreted [1]
It should also be noted that, even in the slower interpreted mode of LuaJIT - it was still the fastest in completing your benchmarks compared to all other languages/implementations. It will run even faster if you don't run LuaJIT in interpreted mode.
[1] http://luajit.org/performance_x86.html http://luajit.org/performance_x86.html
- munificent 13y agoRunning LuaJIT interpreted is a deliberate choice. Some platforms, in particular iOS and game consoles, do not allow generated machine code. I want my language to be usable for games, and that's one reason I'm using bytecode. (Simplicity is the main reason.) Given that, I think it's most helpful for me to compare Wren's performance to other bytecode language implementations. Comparing to JIT compiled languages is a bit apples/oranges. They tend to be something like an order of magnitude faster (and an order of magnitude more complex!). Meanwhile, LuaJIT's interpreted mode is very fast as you note. I think it's one of the fastest bytecode interpreters around, so it's a great target for Wren to aim for. If you want a lot more detail on my thoughts about this, see here: https://github.com/munificent/wren/blob/master/doc/site/performance.markdown https://github.com/munificent/wren/blob/master/doc/site/perf...