111–120 of 165 posts
Is it just me or I find it difficult to believe that 19 year olds can implement the LLVM alternative?
(But you probably need to be older to be a good project manager.)
Is it just me or I find it difficult to believe that 19 year olds can implement the LLVM alternative?
They exist, and have truly enviable amounts of time for projects.
Also, don't overestimate compilers (or kernels). They can be much simpler than they might seem! The difficult/tedious parts are optimizations(!) and broad compatibility with bizarre real-world stuff.
I'm saying this as someone who uses LLVM daily and wishes that it was written in anything else than C/CPP,
those languages bring so many cons that it is unreal.
Slow compilation, mediocre tooling (cmake), terrible error messages, etc, etc.
What's the point of starting with tech debt?
Is it just me or I find it difficult to believe that 19 year olds can implement the LLVM alternative?
Earlier quoted context omitted.
I wonder if this question can attract any MLIR people to answer my question: From Chris Lattner's descriptions of LLVM vs MLIR in various podcasts, it seems like LLVM is often used as a backend for MLIR, but only because so much work has been put into optimizing in LLVM. It also seems like MLIR is strictly a superset of LLVM in terms of capabilities. Here's my question: It seems inevitable that people will eventually…
All the important bits of MLIR are closed source and there’s no indication that’ll change anytime soon. The big players have their own frontend, dialects, and mostly use LLVM backends. There’s very little common usable infrastructure that is upstreamed. Some of the upstreamed bits are missing large pieces.
> I believe it's (LLVM) far too slow at compiling and far too big to be fixed from the inside What are you doing to make sure Tilde does not end up like this?
* Less cache churn, I'm doing more work per cacheline loaded in (rather than rescanning the same function over and over again).
* Combining mutually beneficial optimizations can lead to less phase ordering problems and a better solve (this is why SCCP is better than DCE and constant prop separately).
In a few years when TB is mature, I'd wager I'll have maybe 10-20 real passes for the "-O2 competitive" optimizer pipeline because in practice there's no need to have so many passes.
Earlier quoted context omitted.
It certainly has, as proven by recent talk at BlueHat 2024, on Windows kernel refactorings, as not everyone is knowledgeable of ISO C minutia and how optimisers take advantage of it, and still think they know better than analysers.
Maybe you can explain this better. People not knowing about footguns is also not the same complexity, it is just having footguns and people not knowing about them.
Nonetheless, it is good to see efforts to reduce UB on the standard.
My complaints apply to C++ as well, naturally.
Earlier quoted context omitted.
Not really. In the initial phase of a project there is usually so much churn than enforcing proper commit messages is not worth it, until the dust settle down.
I am deeply suspicious of anyone who doesn't bother or who is unable to explain this churn. For the right kind of people, this is an excellent opportunity to reflect: why is there churn? Why did the dust not settle down? Why was the initial approach wrong and reworked into a new approach? I can understand this if you are coding for a corporate. But if it's your own project, you should care about it enough to write go…