wazero
wazero copied to clipboard
tetratelabs
Will new wazeroir / optimized compilers be supported?
Now, wazeroir is a format similar to LightbeamIR, it is used for singlepass compiler. Does there a plan to have an IR for deeper optimization with higher execution performance？
Hi @hafeidejiangyou, that's a good q! When we first started designing our compiler (which used to be called JIT), I even had no idea whether it was possible to develop the dynamic compilation and execution engine purely in Go. So I didn't spare time to have the optimized infrastructure for the compilation but rather chose to develop the "baseline" compiler as early as possible (given that CGO itself is slow).
Now that we are approaching 1.0 (#506), I plan to spend more time on the optimization later on. That of course comes with the redesign of wazeroir (sure it will be SSA style one!) and the introduction of a more optimized register allocator (vs the one we have now is a naive local register allocator). But it all depends on how we prioritize -- it's only me who works on the compiler backend in the wazero project, and therefore, our cycles are limited.
Anyway, stay tuned!
@mathetake Thanks for your reply, I'll keep an eye on it. By the way, I am interested in contributing in the future.
Here's an update.
We haven't had time to begin this
Until now (mid-2023), we've decided to not displace resources on an optimizing compiler. This has been to support wazero's 1.0 release, and also ensure we have people to champion the success of various things going on in the emerging GOOS=wasip1, as well support end users. That said, the existing codebase has been cleaned significantly and the existing non-optimizing compiler is more efficient than before.
We aren't likely to open the internals for outside compiler implementations
It is technically possible to embed a compiler like cranelift, by compiling it down to wasm and then wazero embedding that and running it internally. However, it is in direct conflict with wazero's goal of being zero dependency. The resulting wasm would be far larger than wazero itself, and an alternative of bootstrapping it somehow makes the runtime fragile on that point and above all more complicated. Further, no one has experience contributing to crane lift and it would end up affecting how we maintain wazero. Meanwhile we would still need our existing compiler backend for the same reasons, so we would have more than twice the problems in reality as now.
We can do an optimizing compiler based on prior art, but not now
The number one focus of wazero is the Go community and there is a lot going on between now and 1.21 release. There is a constantly changing definition of wasip1 (spec tests and practice in Go), as well features being requested (pipes, sockets, etc). Meanwhile, there are important projects beginning (such as k8s scheduler integration). Starting an optimizing compiler can be done at any time, but now is a very bad time to start it. Even if others theoretically wanted to begin this, few have the experience in our compiler internals except Takeshi to lead this. Attempting to start without experience would slow other work down and possible swamp the boat. The long story short is that it isn't wise to start now (in May), and unwise at least until there's a beta of Go 1.21 out. Meanwhile, even if that happens we should be careful because we are looking at a full year of work to complete.
So that means some benchmarks will lose
Yep and if we only think about these specific crunching benchmarks, we ignore the human years of effort working towards end user required benchmarks. We've done a huge amount of effort on reduced init time, function-to-function calls, as well making observability and profiling possible for end users. We can choose to ignore everything and only look at the ones we lose, but then so would everyone else. So, basically all runtimes lose at some benchmark and we will even after this. That's the reality.
Summary
Losing at specific optimizable code is a temporary matter of timing and availability. It can happen and the path forward is natural to wazero, meaning anyone can just have it without complicated linking or anything opposite of our dependency culture. This is a big job and we take commitments seriously. When we start, it will be on this issue, and we'll commit to finishing even though it may take a year to finish. Until then, please enjoy all the other things we crush at!
sorry I conflated JIT when discussing this sometimes. JIT is the wrong term, even if wasmtime, wamr etc say what they are doing is JIT. Nothing done now, and nothing we are thinking about will end up with something that compiles while executing. "Optimizing compiler" is the right term.
xpost from the Gopher Slack (https://gophers.slack.com/archives/C04CG4A2NKX/p1685438483389279)
FYI for anyone interested - I have started the long journey of our optimizing compiler backend which may multiple months to reach stability as we decide that we will implement everything from scratch in Go rather than depending on huge third party (binary) which contradicts our policy of zero dependency (see https://github.com/tetratelabs/wazero/issues/777#issuecomment-1546775472). I will keep you guys posted but for now it’s just the phase I am doing research and reading lots of research papers and prior arts (eg llvm/cranelift). I am planning to create a first poc in a way that multiple people can work on simultaneously (like adding optimization passes etc) but not sure what it will look like for now. Anyway please stay tuned and forgive me for the lack of responses etc meanwhile.
I think the question is answered: we are actually heading towards the optimizing compiler which I expect to take us multiple months even a year or so before it reaches stability.
We will do the actual development tracking in a different issue, so for those interested in, please subscribe the new issue ~which I will link here shortly~ https://github.com/tetratelabs/wazero/issues/1496.