Open qwerty2501 opened 6 years ago
Hello!
The current JIT backend used by Ice Core is based on LLVM, and only several slight modifications (e.g. symbol resolution) need to be made for it to generate code suitable for AOT caching. However, I don't see much benefit from introducing an AOT mode:
Initialization time: The initialization generally takes no more than a few (0-2) seconds for reasonably complex programs for now, and doesn't matter much as Ice is a server-side container, which is expected to run for much longer time.
Optimizations: All machine-level optimizations, including register allocation and instruction selection, are already done when the LLVM IR is translated to machine code. I've added an option that turns on LLVM frontend optimizations (config.rs#19), but no major improvements on performance are found. I think this is probably because that the compiler that generates the wasm code has already performed necessary optimizations, and we don't need to do the work again.
Actually I'm thinking about implementing a tracing JIT for doing PGO that aren't available on a native environment :-)
Thank you for answer.
- Initialization time: The initialization generally takes no more than a few (0-2) seconds for reasonably complex programs for now, and doesn't matter much as Ice is a server-side container, which is expected to run for much longer time.
Oh, I had overlooked the server-side in README.
I assumed that IceCore will support like non-browser client applications and embedded system(There are cases where the user do not want pay cost of JIT). However, it was my misunderstanding.
I'm sorry.
- Optimizations: All machine-level optimizations, including register allocation and instruction selection, are already done when the LLVM IR is translated to machine code. I've added an option that turns on LLVM frontend optimizations (config.rs#19), but no major improvements on performance are found. I think this is probably because that the compiler that generates the wasm code has already performed necessary optimizations, and we don't need to do the work again.
In my opinion, it is not much difference between JIT and AOT in optimization. But I'm not familiar compiler optimizations. Please do not take too seriously.
PGO, I heard first time it.
Is it Profile-guided optimization?
And are you thinking about implementing like as below?
In my opinion, it is not much difference between JIT and AOT in optimization.
An AOT compiler usually produces better code, while a JIT compiler aims to be faster.
In the Ice (wasm-core) context, all possibly heavy optimizations are left to the compiler that generates wasm, instead of doing it ourselves. The JIT compiler, instead, only does machine code generation.
Is it Profile-guided optimization?
Yes, exactly :-)
I imagine that it would be done by tracing the currently-executing code, collecting profiling information, and dynamically re-generating code based on aggressive assumptions (which falls back to the "baseline" code on assumption failures). Not sure whether this will bring real performance benefits, though.
An AOT compiler usually produces better code, while a JIT compiler aims to be faster.
In the Ice (wasm-core) context, all possibly heavy optimizations are left to the compiler that generates wasm, instead of doing it ourselves. The JIT compiler, instead, only does machine code generation.
Yes, True.
I imagine that it would be done by tracing the currently-executing code, collecting profiling information, and dynamically re-generating code based on aggressive assumptions (which falls back to the "baseline" code on assumption failures). Not sure whether this will bring real performance benefits, though.
I guess it is case by case. It might be nice to have a benchmark when Ice 1.0(or later?) is released.
Hello. Does IceCore has plan about implement AOT in the future?