111–120 of 167 posts
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.
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.
Having the choice for advanced users is a plus but I think having to choose is a big negative.
Which is the exact opposite of what the intention behind this proposal is, which is to make the language more maintainable.
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…
Yes, this is totally true.
It's also possible to affect this in theory but hard in practice. Usually you shoot for making it O(N^2) (or whatever) where N is the number of variables you want to try to optimize instead of N being number of blocks.
The complete GVN and GVN-PRE in LLVM is theoretically N^3 or N^4, but as engineered it's often much faster (while getting more optimization) or at least not more than a few percent slower than the the existing O(N^2) GVN. It achieves this by being sparser in most cases. The old GVN has to iterate the algorithm, and iterates non-sparsely. Everything is reprocessed because it doesn't know what can change. The new one iterates only the things that could change using fine grained dependency tracking (something akin to how sparse constant prop works). This is often the best you can do.
I will say it's possible to affect these time bounds in theory because if you go down the single static rabbit hole, you realize it's more generally applicable. Kenny (and others) proved this in his thesis about sparse dataflow. That was the whole point. SSA is just one example of a form that enables things to be linear time (and in fact, you can do it without SSA at all using interval methods and such). There are papers that show this about other SS* forms and show examples, but they were mostly (sadly) ignored.
Concretely, for most optimizations like PRE/etc, there are linear time single static transforms of the IR that will make the optimization linear time (Or at least remove a factor of N for you) by explicitly exposing the dataflow in a way that matches what the optimization algorithm wants.
This is awesome in theory - like really cool when you think about it (if you are a compiler nerd), but also completely impractical (at least, AFAIK). Rewriting the IR form for each optimization to the exact requirements of the optimization (single static use, single static exposed uses, single static upwards exposed uses, single static exposed defs, etc) is much more expensive in practice than well engineered, higher complexity, "N in the number of variables" optimizations.
Equality saturation stands more of a chance, IMHO.
With the amount Zig promoted being able to use it to compile c (and maybe c++ I forget) only to decide no LLVM at all seems wild. Without a LOT more people chipping in to support the odds of even coming close to the platform support of LLVM seems incredibly unlikely as well. I would understand planning to add another backend of their own for those who want that, but just getting rid of LLVM seems... rash?
This was exactly my take on it. I'd recently been reading a bit more about zig, and even tried out using it as an easy way to compile c++ with llvm without having to fuss with system packages -- transitioning from c/c++ to zig was a major selling point It just seems really abrupt, certainly unexpected. I'm not saying it's the right/wrong thing for the project -- just really really out of left field from my point of v…
[flagged]
Since you're already not even close to on-topic, I just want to say that people on the internet commenting about "how they misread the title" are some of the worst kind of comments. Titles could mean all kinds of various, new things if you substituted meaningful words for other meaningful words. Or in this case, acronyms hiding several words at a time. The final result of your comment is that apparently you're critiq…
If zig cc and zig c++ die I would instantly stop using the language!
Two issues here. The first is code generation and the other is bootstrapping. Ime, the optimizing passes of a compiler are easy and fun to write. You have to read research papers to understand how register allocation and ssa form works, but it's fun code to write. You just send the ir through various optimizing passes, each refining it in some way. You can write high-quality optimization passes without llvm. But then…
Earlier quoted context omitted.
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 whi…
Apple, of course, dropped LLVM at some point after it didn’t meet their latency needs.
Earlier quoted context omitted.
> In zig you _can_ actually start with a c codebase and rewrite it file by file in zig and you _can_ include c headers in your zig files verbatim. Both of these are not possible in rust. well, you can: i have done this, with Rust. but yes, it’s more the type of thing that well-resourced companies do rather than solo devs, because even with Bindgen and the like Rust really wants the atomic codegen unit to be the “libr…
You still need a separate compiler toolchain next to Rust in order to compile the C, C++ and ObjC dependencies which is a massive build system headache (especially across UNIX-oids and Windows). In Zig that all "just works" with the standard Zig install.
Earlier quoted context omitted.
There's a document that I think was an unofficial project management document from NASA, I can't find it now, but one of the items was something along the lines of 'if your space mission isn't reusing an existing launch vehicle, it will be a launch vehicle development project and everything else, including what you think is the focus of your mission, will be secondary to this'. Edit: additional bit I remembered, this…
Akin's Laws of Spacecraft Design https://spacecraft.ssl.umd.edu/akins_laws.html
39. Any exploration program which "just happens" to include a new launch vehicle is, de facto, a launch vehicle program.