compiler) I want to go RubyKaigi as a speaker (Last year was LT) This was accepted from 3 CFP I’ve made. Others was: - Continuous integration for mruby and its gems (About CI system I’ve built) - Bringing keyword arguments to mruby (About mruby/mruby#3629)
Lua. Created by Mike Pall. Known as one of the fastest JIT compiler implementation of dynamically typed language. VM is Faster than original Lua implementation
to application Born in Brazil ! Language features is similar to JavaScript - Dynamically Typed - Integer and Float isn’t treated differently - Object Oriented features can be done with metatable(similar to prototype) Very light-weight runtime
Table type with integer index instead - Table with integer indices are optimized Array like table index starts from 1 String type is immutable(like Symbol) Method call operator is `:` ( `call:method(true)` )
a profiler When VM finds code that should be JIT compiled: - Allocates memory that is executable - Compile non native codes to native code and output it to executable memory - Switches execution of bytecodes to native code
initial VM code aren’t JIT compiled at all The codes get compiled to native code after executed When code compilation finishes, VM is warmed-up JIT engine’s peak performance is measured by warmed-up VMs
to generate code: https://defuse.ca/online-x86-assembler.htm Just prints “0x11” with printf Maybe the only code I’ve written for this talk that is working
JIT compilation takes many cost - CPU and memory to compile codes to native form - VM becomes profiler with additional cost JIT compiler and VM is optimized for it It maybe slow before warm up completes than non JIT compilation
beat C extensions: - When FFI Function Calls Beat Native C - DragonFFI libffi is faster than just a VM but there is overheads Cooperation of FFI module and JIT compiler reduces overhead
infrastructure and generates good code. Though it’s designed for statically compiled languages. JavaScriptCore tried it but now it uses own JIT engine. HHVM tried it too but it ended up as experimental project.
implemented with assembly language. Compiler is very small Very memory efficient structure Pointers are limited to 32bit length Can JIT compile with FFIs NaN boxing
number There is articles from JavaScript engine developers - value representation in javascript implementations - NaN boxing (Japanese article) Efficient in language without integer type
is aligned because of allocator - 64-bit address is too large to use all `VALUE` type is the tagged pointer in CRuby Good when non floating point number type is used more
a long list of optimization done in LuaJIT! Bytecode level optimization is well documented SSA-IR level optimization isn’t documented much so need to read codes! - It is well documented in comment - There is page of Allocation Sinking Optimization
Optimizing Composite Conditionals - Elimination of Conditionals - Elimination of Unneeded Results - Jump Folding - Template Tables - Instruction and Operand Specialization Some is done in mruby as peephole optimization too
x86/ARM/MIPS/PowerPC - Optimization is done in DynASM You can’t find lj_vm_call in source code(It’s VM body!) Symbol prefix “lj_” is added to vm_call so vm_call is the VM body Read files under src/host for detail
ravi : Lua 5.3 implementation with GCC/LLVM JIT compiler. Supports optional static typing too. luajit-mm : A LuaJIT fork with 2GB memory support (Original LuaJIT only supports 1GB)
types of mruby to LuaJIT Remove VM (src/vm.c) Replace code generator (mrbgems/mruby-compiler/core/codegen.c) - Generating Lua source code is easier - For optimization bytecode is better though needs knowledge of LuaJIT bytecode If possible re-implement things with DynAsm
in Lua and LuaJIT - It has most of the implementation of Lua API of LuaJIT - It is public API so help learning LuaJIT internal Reading lj_obj.h helped a lot - Defines most data structure of LuaJIT VM - It’s my best friend in LuaJIT now - Type conversion functions and macros
placed locally Memory allocation frequency should be reduced There’s thing that should be allocated once Methods used by language feature should be optimized (meta-method)
can read LuaJIT forever! Re-implementing things is hard and takes time Reinvent the Wheel! (If you have reason: studying, hobby, …) mruby needs more optimization of data structures