71–80 of 169 posts
Earlier quoted context omitted.
There is significant investment in building Linux with Clang so I wouldn't count on Linux keeping GCC relevant forever. Doubly so with the inevitable rustc requirement.
The ongoing efforts to add a Rust frontend to GCC prove otherwise. No Rust in GCC? No play.
Earlier quoted context omitted.
> Competition is good. On the other hand, collaboration is also good. Why waste time reinventing the wheel?
Wasn't LLVM reinventing the wheel at the time? They could just collaborate to GCC.
I have also been told by more than one person that does professional compiler development that GCC's codebase is very difficult to work with. At least some commentary I've read suggests that this was a deliberate choice on the part of the GNU project.
Anyone actually use Intel compilers
Earlier quoted context omitted.
Many of the proprietary C++ compilers (Intel included) are just repackaging of the EDG front end. The monoculture has existed for a long time in the C++ world due to the complexity of implementing the language to spec. Honestly, I think it will be great to have one less set of compiler-specific oddities to worry about.
MSVC does not use EDG for the frontend as far as I'm aware. IntelliSense does, though.
Earlier quoted context omitted.
> Android is a great example. Typical Qualcomm/Mediatek/etc. behavior: take a "stable" kernel, stuff it with custom undocumented drivers and junk, be stuck on that version forever. I don't think that's such a great example in this context. Qualcomm, Mediatek, etc. are hardware vendors after all. Software to them is a necessary evil, not a reason d'être or complementary tool (as it is for NVIDIA and Intel). Their cust…
Intel and NVIDIA make their money selling hardware.
https://www.msn.com/en-us/money/technologyinvesting/nvidia-i...
It's a very similar story for Intel. NVIDIA and Intel are selling hardware because of their software portfolio. How many GPUs would NVIDIA sell in the HPC market if it wasn't for CUDA and the various support libraries around it?
Intel's non-client solution revenue was over 40% of their total revenue in 2020. This includes their (software-) AI solutions, applications, licence business and services. So Intel, too makes a significant amount of money from software and services around their software ecosystem.
Earlier quoted context omitted.
What that sentence actually means is "we don't want to help our competition (AMD, NVIDIA) but we don't want to re-implement the wheel". The API and fundamental part of LLVM is its IR, LLVM-IR, which is where most optimizations happen. From this point-of-view, LLVM is a "platform", and an extremely brittle one: every release has breaking changes to the IR, the IR is constantly evolved to support new hardware and new o…
ISPC is not stuck on LLVM 7. Only fails on 12 currently, works on 11 and earlier: https://github.com/freebsd/freebsd-ports/blob/85cccf4f15c42d... But hopefully that will be fixed soon.
Earlier quoted context omitted.
> Don't want to end up with every C/C++ compiler being a clang skin in the same way as (almost) every browser is a chrome skin. Why not ? There is one open C++ spec, that's really hard to implement, so we have a dozen C++ compilers that are impossible to support properly because they each have their own set of different ten thousand bugs. The value of supporting all of this is really small in practice, and the cost f…
Clang is lagging behind in C++ 20 support while MSVC is miles ahead. LLVM is also getting slower and slower every release.
I don't see how focusing the available manpower on one implementation instead of splitting it over 10 different implementations would make this worse.
I do see how it would make this much better.
What one implementation lacks, another implementation provides. This is a weakness of the current ecosystem. Most software projects restrict themselves to the minimum common denominator, and splitting manpower across compilers lowers it.
I'm not sure I love this. I mean, LLVM is awesome and everthing, but software monocultures are pretty bad. It's not like the situation is dire yet (given that there are also GCC and MSVC), but you can imagine a situation in a couple of years when Microsoft goes "yeah, we're also gonna go with LLVM now" and also GCC starting to fade away. It's a bit concerning. Also: if icc is going to go with LLVM as a backend, then…
In it, the guest talks about how he couldn't rely on LLVM for things like optimizing array operations; LLVM apparently does a poor job of that so he had to implement his own. Given that one of the key selling points of Intel's compiler is that it does a better job with SIMD optimizations, it may be exactly the same story here.
(In the past, people have dismissed such concerns, saying that it would be impractical for anyone to actually do such a thing. But this project by Intel shows that it isn't just possible--in fact, it's almost inevitable.)
This is exactly why I've been concerned about LLVM's use of a non-copyleft license: unlike with GCC, vendors can create their own proprietary extensions and optimizations without contributing them back to the community. (In the past, people have dismissed such concerns, saying that it would be impractical for anyone to actually do such a thing. But this project by Intel shows that it isn't just possible--in fact, it'…
The problem is GCC made these concerns completely irrelevant. You wanted refactoring support for C or C++? Either build it on clang or get screamed at by RMS for leaking GCC internals when text base search and replace was enough for him in the early 80s.
The simple fact is that there is no GNU based alternative to clang/llvm.