You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, recent days we are developing another WebAssembly JIT engine and make good progress by now, we call it WAMR Fast JIT, which a lightweight JIT. Currently it is under the development branch: https://github.com/bytecodealliance/wasm-micro-runtime/tree/dev/fast_jit
We will do more test and merge it into main branch when it is stable. Developers were encouraged to help test it and report issue if found.
Motivation:
Resolve issues of current LLVM based JIT
Long compilation time
Large footprint: large binary size and memory usage
Portability issue: not easy to port to IoT device, SGX platform, etc.
Resolve issues in deploying AOT
Need to recompile and update AOT file when wasm application changes
Design goals:
Short compilation time, quick startup
Support Linux and SGX platform, support x86-64 target at the first stage
Relatively good performance, 40+% of AOT performance epected
Relatively small footprint, smaller than 300KB increased for binary size
Good scalability
Easy to support more targets, normally only need to re-implement the codegen for a new target
Good portability
Easy to port to other platforms, had better only rely on currently platform APIs
Tier-up to LLVM JIT (long term goal)
Quick startup with Fast JIT and good performance with LLVM JIT
Typical scenarios of Fast JIT
IoT devices
SGX platform
Mini apps
Scenario which requires quick startup
Quick startup and better performance with tier-up from Fast JIT to LLVM JIT
Compilation Pipeline
Currently there are three passes in the JIT compilation for x86-64 bit target:
Frontend: translate wasm opcodes into JIT IRs
Register Allocator
Codegen (backend): translation JIT IRs into machine codes
For 32-bit platforms, developer might need to implement another pass to translate JIT IRs containing 64-bit register operations into 32-bit register operations, e.g. using two 32-bit registers to simulate the operation of 64-bit add/sub/mul/div and so on.
Dependent Libraries
asmjit: use asmjit as codegen encoding library, Assembler class is used
zydis: use zydis to decode the machine code, only required when JIT dump is enabled
How to build
git clone https://github.com/bytecodealliance/wasm-micro-runtime.git
cd wasm-micro-runtime
git checkout dev/fast_jit
cd product-mini/platforms/linux
mkdir build
cd build
cmake .. -DWAMR_BUILD_FAST_JIT=1
make -j
#iwasm generated under current folder
Current progress:
Most of the WebAssembly mvp opcodes (features) are implemented similar to LLVM JIT, except threads and SIMD related opcodes. MVP spec cases and many standalone cases were tested.
Feature plans:
Apply more optimizations
Implement threads related opcodes
Implement SIMD related opcodes
Enable multi-module support
Enable tier-up with LLVM JIT
The text was updated successfully, but these errors were encountered:
Hi, recent days we are developing another WebAssembly JIT engine and make good progress by now, we call it WAMR Fast JIT, which a lightweight JIT. Currently it is under the development branch:
https://github.com/bytecodealliance/wasm-micro-runtime/tree/dev/fast_jit
We will do more test and merge it into main branch when it is stable. Developers were encouraged to help test it and report issue if found.
Motivation:
Design goals:
Typical scenarios of Fast JIT
Compilation Pipeline
Currently there are three passes in the JIT compilation for x86-64 bit target:
For 32-bit platforms, developer might need to implement another pass to translate JIT IRs containing 64-bit register operations into 32-bit register operations, e.g. using two 32-bit registers to simulate the operation of 64-bit add/sub/mul/div and so on.
Dependent Libraries
How to build
Current progress:
Most of the WebAssembly mvp opcodes (features) are implemented similar to LLVM JIT, except threads and SIMD related opcodes. MVP spec cases and many standalone cases were tested.
Feature plans:
The text was updated successfully, but these errors were encountered: