Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

File for divorce from LLVM

github.com

Post reply on HN
Print view View original

51–60 of 167 posts

Re: File for divorce from LLVM

#51

Post by coldtea »

WalterBright wrote: post #25

The DLang has 3 compilers: 1. gdc - based on the Gnu compiler collection back end 2. ldc - based on the LLVM back end 3. dmd - based on the x86 code generator that I wrote for Zortech/Symantec/Digital Mars They each have their pluses, minuses, and targets. But the D language each supports is the same. Overall, our users like the choice. Some even use more than one.

>Overall, our users like the choice.

All 10 of them? I mean, if Zig's target is eventual wide adoption, DLang is not a good precedent to model upon.

Re: File for divorce from LLVM

#52

Post by Solvency »

defen wrote: post #48
DannyBee wrote: post #35

Some of this reasoning is just wild. 1. "We can attract direct contributions from Intel, ARM, RISC-V chip manufacturers, etc., who have a vested interest in making our machine code better on their CPUs." They are nowhere near popular enough (or used enough by some particularly important customer) for any major architecture vendor to spend any time contributing except as someone's random side project. To think otherwi…

I agree that it's probably impossible to write something that is orders of magnitude faster than LLVM and better than LLVM at optimizing, but I don't see that claim in the original text. It seems like a lot of work but also doable to create something that is orders of magnitude faster than LLVM for unoptimized debug builds. Furthermore, the Zig compiler might be an easier thing to work with than LLVM/Clang for doing…

Just to play devils advocate..who would've thought Javascript would ever end up as blazingly fast as it has become since V8. Maybe Zigworld can do it.

Re: File for divorce from LLVM

#53

Post by schemescape »

I'll admit that I've only considered using Zig for its ability to easily compile (and cross-compile) C/C++ code into static binaries.

Hopefully if any of that functionality gets removed someone manages to fork off the "C/C++ magic" part into its own project. Clang itself is much less convenient to use.

Re: File for divorce from LLVM

#54

Post by anonymoushn »

DannyBee wrote: post #35

Some of this reasoning is just wild. 1. "We can attract direct contributions from Intel, ARM, RISC-V chip manufacturers, etc., who have a vested interest in making our machine code better on their CPUs." They are nowhere near popular enough (or used enough by some particularly important customer) for any major architecture vendor to spend any time contributing except as someone's random side project. To think otherwi…

My impression is that LLVM spends the bulk of its time chasing pointers, so one could fix the issue by "only" changing the layout of the data to one that is friendlier to computers.

Re: File for divorce from LLVM

#55

Post by prpl »

brucethemoose2 wrote: post #29
MuffinFlavored wrote: post #24

Earlier quoted context omitted.

They're dropping LLVM by re-implementing everything it does in their own homegrown fashion?... To what benefit? Isn't this a waste of resources?

The reasoning seems to be the flood of LLVM bugs, but I don't think reinventing such a large wheel will be any easier.

It sounds like some of those bugs are just related to people using distro compilers?

Re: File for divorce from LLVM

#56

Post by wyldfire »

Andrew is super sharp so I imagine he and the team will get there now that it's declared as a goal.

But man, it seems to me (uneducated on the challenges zig faces w/LLVM) that this shifts the team's capacity away from zig and towards things like binutils. When I read the headline I assumed that they were throwing out the compiler (IIRC they had mostly/totally excised it already). But for a project like zig it just seems like there's a lot to be gained from keeping it.

That said -- the prospect of rewriting a lot of the stuff that's in the LLVM project now in zig instead of c++ - that's pretty cool and ambitious. Just as ambitious as it was for Lattner to create LLVM, I suppose.

But code that's accidentally quadratic - well, that's bound to happen to zig too, if it's as popular and useful as LLVM project is.

Re: File for divorce from LLVM

#57

Post by jroesch »

DannyBee wrote: post #35

Some of this reasoning is just wild. 1. "We can attract direct contributions from Intel, ARM, RISC-V chip manufacturers, etc., who have a vested interest in making our machine code better on their CPUs." They are nowhere near popular enough (or used enough by some particularly important customer) for any major architecture vendor to spend any time contributing except as someone's random side project. To think otherwi…

Long time compiler hacker/engineer and compiler/programming language PhD here all great points. Worth saying out loud that many reasons why this stuff is slow is not due to bad code, its due to the fact that many of the best algorithms are in higher complexity classes and just scale poorly with program/translation unit size. For example when I was working on `rustc` a big challenge was heavy reliance on inlining and inlining has a cost, plus it increases program sizes making everything else take longer as well.

I feel like Go already went through a whole saga of this where the community started with "LLVM and SSA are bad and slow", then a few years go by and they end up building their own SSA IR and spending a bunch of time trying to bring compilation time closer to what it was before as it made everything much slower.

Re: File for divorce from LLVM

#58

Post by jroesch »

Solvency wrote: post #52
defen wrote: post #48

Earlier quoted context omitted.

I agree that it's probably impossible to write something that is orders of magnitude faster than LLVM and better than LLVM at optimizing, but I don't see that claim in the original text. It seems like a lot of work but also doable to create something that is orders of magnitude faster than LLVM for unoptimized debug builds. Furthermore, the Zig compiler might be an easier thing to work with than LLVM/Clang for doing…

Just to play devils advocate..who would've thought Javascript would ever end up as blazingly fast as it has become since V8. Maybe Zigworld can do it.

As the parent comment said, and I mentioned in my reply. JavaScript was just incredibly poorly optimized/not compiled and they applied 20-30 years worth of compiler research to make it significantly faster. You also had an alliance of every hyperscaler working on the tooling for a decade plus with help from all major hardware vendors to bring the best performance out of it. One driver of LLVM was Apple and WebKit which at one point was using LLVM for its JIT compiler so many improvements figured out in that period have also already been applied to LLVM.

LLVM already has decades of research applied to it to make it produce fast code, it will be incredibly challenging to even match its performance across all the targets it supports let alone improve on it in significant ways. It would be better to spend the time building an optimization pipeline for Zig itself and being more thoughtful about what code you send to LLVM versus trying to replace it wholesale.

Re: File for divorce from LLVM

#59

Post by Hermitian909 »

wyldfire wrote: post #56

Andrew is super sharp so I imagine he and the team will get there now that it's declared as a goal. But man, it seems to me (uneducated on the challenges zig faces w/LLVM) that this shifts the team's capacity away from zig and towards things like binutils. When I read the headline I assumed that they were throwing out the compiler (IIRC they had mostly/totally excised it already). But for a project like zig it just s…

I'm reminded of a recent interview with Chris Latner about the success of Swift - he credits the success to the fact that you could start with a large objective C project and begin writing Swift without rewriting anything. Part of Rust's success is off the back of a similar compatibility with C/C++.

It is difficult for me to imagine Zig succeeding without a similar capability - which is to say I hope they do not follow through on this milestone.

Post reply on HN