Comment by azakai | Hacker News Reader

Comment by azakai | Hacker News Reader

Parent Full thread

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-wit...

You can certainly go faster than LLVM if you're willing to sacrifice code quality (which B3 and SubZero do... or for the extreme example there is no way on Earth LLVM will catch up to TCC). But I think that DannyBee is totally right that "we can go faster than LLVM at the same level of code quality just by rewriting it" is magical thinking. As far as I'm aware, there are no design decisions in LLVM that are pervasive mistakes that sacrifice compilation speed for no reason [1]. If there's nothing you can point to and say "THIS is what I'm going to do better than LLVM", then you're probably going to end up at the same speed as LLVM. The parent comment's point is that none of the attempts to answer that question have been valid: so far the reasons cited have been based on misconceptions about what LLVM provides.

[1] Well, OK, I'm not a fan of SelectionDAGISel's interpreter. But switching that to AOT won't result in huge differences in compile times. (Note that it's been a couple of years since I really worked with LLVM closely.)

FYI a new instruction selector is in development to replace SDAG.

That's great news. LLVM keeps getting better and better :)

Do you have more information about that effort?

Do you have a specific question? It is not gonna be there before 2y I think. You can search for GlobalISel on the llvm mailing list to see discussions and patches.

I disagree. It's not that LLVM made "pervasive mistakes", it's that other design decisions can be much faster, such as those mentioned in the B3 JIT link above.

Of course, some tradeoffs are made, but actually I don't see why they substantially limit B3's output code quality. Perhaps slightly, but in return for a massive speedup in compilation times.

Well, if B3 is able to do something faster with the same level of code quality, then I'd say it was a mistake in LLVM to not make the same decisions.

But this proves the overall point: B3 is able to specifically say "we are going to be faster than LLVM because we are replacing RAUW with identities, packing multiple operands into an Inst, fusing operations into macro-ops, using arrays instead of linked lists, etc." Those are specific technical decisions that the WebKit authors believe will make things faster than LLVM, and they aren't based on misunderstandings of the things that LLVM provides.

Edit: That said, there's skepticism that B3's advantages will persist in the long term. See: https://news.ycombinator.com/item?id=11107082 and http://lists.llvm.org/pipermail/llvm-dev/2016-February/09546...

I expect B3 and JS JITs in general to remain much faster, for the simple reason that speeding up compilation by 2x might be worth a 5% throughput loss for a JS VM (numbers made up, but you get the idea). But it is very unlikely such a tradeoff would be acceptable to LLVM, given the projects and corporations already heavily invested in it.

In theory, LLVM might support both a very fast compilation model and a slower and more efficient one. But supporting two complete codegen backends is a lot more effort.

And overall, codegen compilation speed has never been a priority for LLVM to anywhere near the extent that it is for JS VMs. It still doesn't have parallel codegen, while all JS VMs do. That shows the very different focuses on those projects.

" It still doesn't have parallel codegen, while all JS VMs do."

Actually, it can be done. It's just not the default.

"Well, if B3 is able to do something faster with the same level of code quality, then I'd say it was a mistake in LLVM to not make the same decisions. "

It's more "nobody has had the time to erase this particular technical debt yet". Chandler, for example, is focused on erasing the debt of the old pass manager first. The B3 guys, had they focused on doing this in llvm instead of writing a new JIT + new passes + .... probably could have done that in less time.

But at this point, there are concrete plans to erase it, so as you suggest, it is highly unlikely advantages will persist in the long term :)

"it's that other design decisions can be much faster, such as those mentioned in the B3 JIT link above."

The B3 JIT link describes things that LLVM plans on doing in the next year, precisely for these reasons, so ...

Had they emailed the list, ever, they would have known this.

It's not like these were design decisions that someone said "we should never change these", they were design decisions that were good at the time, but like anything else, need to grow and change over time.

If you give up and rewrite an entire jit/compiler every time it might require rearchitecting, that may be fun but it doesn't make a lot of progress. You will spend years to get to a no-regressions vs old compiler state (unless your old compiler was truly bad)

really?

LLVM based toolchains compile hairy native code faster than any other tools i've seen... GCC, MS, Intel compilers for C/C++ are all very slow by comparison and the benefits are marginal (but still valuable).

for JIT or dynamic stuff LLVM is a poor fit. it doesn't surprise me that JS VMs do better with JS than LLVM, because there is no actual compilation involved as such - its a completely different class of problem, and its just not designed for that kind of language and environment, which is highly derivative, dynamically late binding and built in many layers, the vast majority of which are themselves compiled with C/C++ toolchains like Clang/LLVM, GCC or the MS compiler from necessity...

quoting that first article you link: "it isn’t specifically designed for the optimization challenges of dynamic languages like JavaScript."

Reply on news.ycombinator.com