Jan Hubicka

> Most our perf issues were with limiting draw calls and optimizing shaders, not method calling.

Sounds like the work done by tree traversals weren't high overhead in general for your workload. But it does matter for some workloads.

> Similarly, I worked a lot on a browser engine in the past and virtual method dispatch was again not this clear cut performance killer.

We're seeing large gains from, as far as we can tell, having fewer virtual method calls than other engines. Eliminating virtual dispatch opens up a huge range of call-site optimizations since the methods can often be statically inlined (as well as reducing the load on the branch target buffer).

> Similarly, I worked a lot on a browser engine in the past and virtual method dispatch was again not this clear cut performance killer.

That doesn't match my experience. Devirtualization opens up lots of inlining opportunities, and inlining is one of the most critical optimizations that compilers can do (mostly because of the other optimizations that it opens up; e.g. const propagation, GVN, etc. etc.)

See this study: http://hubicka.blogspot.com/2014/04/devirtualization-in-c-part-5-feedback.html

Devirtualization optimizations improve Dromaeo by 7-8%. That's a significant win, especially since devirtualization is only a best-effort optimization and Dromaeo has a lot of JS in it.

Yes, LLVM was designed with speed in mind. However, look at how much faster compile times are in JS VMs compared to LLVM; LLVM's slow compile times are why none of them use it, even though they tried (e.g. WebKit which is dropping LLVM). A lot of SSA-based JITs are just a lot faster than LLVM.

I think it's a matter of tradeoffs. LLVM has multiple IRs on the way to machine code, some quite large, which let it emit pretty good output, on par with gcc. But other designs are possible that avoid a lot of that overhead, and can be far faster than LLVM, like JS VMs, B3 [1] and SubZero [2]. And clang is overall more or less comparable with gcc these days in terms of speed, it's no longer clearly faster [3] (although that also takes into account the frontend).

With all that said, I agree with you that making such a decision without talking to LLVM is a little silly. But, I doubt it would change the outcome: If Go wants fast compile times, has the resources to write its own compiler, and is ok with trading off throughput for compile time, then it's a reasonable decision to avoid LLVM.

[1] https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/

[2] https://github.com/stichnot/subzero

[3] http://hubicka.blogspot.com/2016/03/building-libreoffice-with-gcc-6-and-lto.html

Not that I prefer Java where performance is important, but profile based optimization combined with optimizing across translation units is non-trivial. C/C++ compilers have been increasing support for these more recently. Jan Hubicka's blog has a good example [1].

I have to wonder if they plan to keep the codebase portable though. One of the major benefits of Java was that nearly everything has a JVM.

[1] http://hubicka.blogspot.com/2014/04/linktime-optimization-in-gcc-2-firefox.html

It is Google's blogger.com. I am not very advanced user of it and generally just use whatever it provides for me.

The link is off. This link http://hubicka.blogspot.com/2018/12/even-more-fun-with-building-and.html
renders better in general.

PS: I found it too ironic to mention in the blog, but I had to uninstall mobile firefox to get the two-level application needed to submit a patch :)). For some reason Google authentificator requires over 30MB to take a picture of bar code.