New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make compilation faster #2182
Comments
wazero is maintained by a small team, so when the new compiler was introduced, it was decided to renove the old compiler (which was a totally different code base). The new compiler is more modular, so it may be possible to disable certain optimization passes (I'll leave it to @mathetake to comment on that). It's also a recent codebase, and there might be some opportunity to optimize it. Having said that, it's probably unrealistic to expect it to become as fast as the previous compiler was. You have two mitigation strategies at your disposal:
Other than that, if you can find (or fix!) a bottleneck in the compiler ( |
Thanks for your response. Firstly I want to say how much I appreciate the wazero project, and understand the limitations it is under and think y'all are doing a fantastic job. Hopefully, given the modularity of the new compiler, this feature could be feasible. Opening this issue not as a bug but just as a mark of interest in this aspect of the compiler. Given the varied use cases of wasm, I hope in the future wazero can provide an option for use cases that prefer quick compilation over quick runtime performance. I will experiment with the interpreter and report back with hard numbers later but I think the interpreter seemed to take as much time as the v1.7.0 compiler. If the interpreter can work for fast startup then this is fine for me! |
As promised here are my findings running against a 65Mb wasm file on my Macbook Air M2 (Arm64):
What we can draw is that the the compiler is about one order of magnitude (10x) slower than the previous 1.6.0 compiler. However, that being said, I was wrong when I created the issue, and must have had a misconfiguration on my end: The interpreter is only marginally, and arguably negligibly slower. Previous to v1.7.X there was little reason to use the interpreter over the compiler except for supporting more architectures. This advice could be revisited if and when optimization levels become a thing. In the meantime, I am satisfied using the interpreter. |
Turns out the interpreter does not scale very well. For programs that I can compile and run quickly with v1.6.0 (~5s), with the interpreter it takes 30+ seconds on both v1.6.0 and v1.7.x of wazero. An option similar to zig's releaseFast flag, where we could disable a lot of the optimizations and achieve closer to the compilation speed of v1.6.0 would be beneficial. TLDR: Contrary to what I believed before, the interpreter is not a silver bullet as it does not scale for complex tasks. |
so basically, we have no resources or plan to introduce any other complexity in compiler implementation. In fact, as you can see #2214, there's really plenty of rooms for making the current compiler faster. You can try and see where is the bottleneck of compilation, and if you can contribute as well. At least, we should be able to make our current compiler as fast as wasmtime in terms of compilation performance (not runtime perf!). Given that, I am changing the title of this issue to something like optimizing compilation perf |
Is your feature request related to a problem? Please describe.
When running large wasm files like the ones generated by the Go Toolchain (that embed the goruntime), it now takes 5-6 times longer on my machine to compile a module.
For some program I have to compile and execute it takes:
v1.6.0 ~= 4s
v1.7.0 ~= 30s+
Although I can expect the executables produced by
v1.7.0
to be much more optimized and efficient, this tradeoff is not worth it for programs that want to interpret one-off wasm programs.Describe the solution you'd like
Ideally when compiling a module as part of the runtime config, I should be able to choose an optimization level to choose between fast compilation with slow performance vs slow compilation with fast performance.
The text was updated successfully, but these errors were encountered: