lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

my noob input :o)
long time ago, I used Smalltalk for many projects, of course Smalltalk is a vm base language with incremental compile byte code, IBM, pushed it a bit farther incorporating a JIT compile cache of code.
One cool feature was that smaltalk save everything inside its "image" at exit and reload with everything when you restart it... IBM did that for the cache of code too. So you get the full speed up optimization right away... What was kept in the cache was base on frequency hit of that piece of code ... of course smaltalk image were big very big :o)
so I was just asking myself what about a small language and JIT, is there a speed gain when you save compile bytecode and jit compile code into a permanent file and reload that file at re-execution of the script ? 
how big will that cache should/could be ...
is loading few k or meg faster that recompiling it ?


surely that there is some studies benchmarks /metrics  on that already...
can some one gave few pointers?  :o)

:o)



On 2015-07-16 6:12 PM, Dibyendu Majumdar wrote:

Hi,

When I started Ravi at the beginning of this year I did not know
whether I was wasting my time - i.e. whether the investment in effort
would actually result in a faster implementation. The main idea was to
use optional static types to help improve performance. I am now happy
that I can achieve same performance as LuaJIT for a subset of
scenarios involving mainly numeric operations.

Overall my conclusions are:

1. Adding static types in the Interpreter only improves things
slightly - I saw 10-20% improvement.  So static types in interpreter
mode don't give you enough return on investment.

2. Compiling unmodified Lua into machine code (via LLVM or another JIT
library) has variable benefit. In complex benchmarks I only see about
2x improvement in performance. The reason for the degraded performance
is that every numeric operation involves a bunch of if/else branches.

3. The combination of static types and JIT compilation is very
effective and allows Ravi to achieve over 10x improvement in speed for
complex benchmarks, and also performance can match LuaJIT in some
benchmarks.

4. Function calls - whether JITed or C functions - are expensive. The
fannkuchen benchmark improved when function calls were replaced by
inline JIT code. I saw a 2x improvement here - and similarly for
another complex benchmark.

I would like to solve the expensive function call issue but don't know
how. For Ravi I do not intend to implement a LuaJIT FFI type solution
as I feel this is bad for the user base I have in mind; I want a
language that is relatively safe for users.

My focus now will be to test Ravi more extensively and create a bunch
of standard libraries (yes I want Ravi to have a bigger set of
standard libraries than Lua). To start with I need a numerical library
so I am thinking about wrapping GNU Scientific Library. The standard
libraries will be separately maintained from core Ravi - so that I can
keep the core small and clean - but my plan is to support and maintain
these as part of the Ravi eco-system.

I very much appreciate the help received on this forum and I hope you
will continue to support the development - the only incentive for an
OpenSource project that is not being paid for is the pleasure you get
from feedback and usage. I am also hoping that by providing good
documentation I can eventually get others to contribute to the
development - Ravi will be a failure if two years from now I am still
the sole developer.

Thanks and Regards
Dibyendu