Live data from Hacker News

Intel C/C++ compilers complete adoption of LLVM

software.intel.com

61–70 of 169 posts

Re: Intel C/C++ compilers complete adoption of LLVM

#61
post #9

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…

LLVM is a somewhat modular system. If Microsoft decided to build their own MSVC front end and AMD decided to build their own AMD64 back end, and Intel decided to build their own special set of x64 optimisers, is it really a monoculture? That sounds more like the GNU form of real software diversity—where you can make your own perfect tool by assembling it from parts.

Re: Intel C/C++ compilers complete adoption of LLVM

#62
post #19

Earlier quoted context omitted.

Yeah, I guess LLVM is preferred mostly because license. Companies can keep their optimizations in secrets. Just like why Playststion's OS is based on BSD.

It's nearly impossible to keep optimizations secret. They are the easiest thing in the world to reverse engineer: just look at the output assembly. (And you can't exactly output obfuscated assembly because that would make the performance worse, nullifying the benefits of the optimizations.)

Though in a practical sense, if you've done the work of implementing useful optimisations and keep them closed source, it's not necessarily a trivial matter for others to recognise and replicate how exactly your optimisation is implemented, when it can be used, when it can't be, etc.

Re: Intel C/C++ compilers complete adoption of LLVM

#63
post #15
post #8

Earlier quoted context omitted.

I disagree. Competition is good. 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. And for what it's worth cl compiles faster for me than even clang-cl. I like having both available though.

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.

Funnily, the only reason I ever used ICC was as a linter since it was the most easily available EDG-based commpiler for me and different frontends help find different bugs.

Re: Intel C/C++ compilers complete adoption of LLVM

#64

From the article it is not clear how the Intel compiler differs from base clang/llvm, except for vague marketing bs (“expected” fp performance?!?)

Proprietary optimisation secret sauce that's not up-streamed most likely.

Basically they cannot go into detail because that would be publishing trade secrets or help the competition. I also suspect that they use the compiler for testing pre-production silicon and the like so those changes won't be publicly discussed either.

Re: Intel C/C++ compilers complete adoption of LLVM

#65
post #7

Earlier quoted context omitted.

They are used in High Performance Computing as far as I know. Not systematically though.

I am sure that plenty of existing HPC cluster will remain intel, the interesting question is how much of the new HPC computers will be AMD. or is there any HPC specific reason why Intel would still be preferred?

Existing install base most likely. It's not as if HPC clusters get replaced every other year. Even upgrades usually stay with the same platform and don't switch from Intel to AMD or ARM-based systems.

Re: Intel C/C++ compilers complete adoption of LLVM

#66
post #59

Earlier quoted context omitted.

Copyleft licenses have no way of forcing anyone to follow upstreams more closely. 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. The only thing the GPL changes is the vendor posts a source dump of dubious usefulness in some obscure section of their website.

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

Re: Intel C/C++ compilers complete adoption of LLVM

#67

Anyone actually use Intel compilers

A few years back, Intel was striking marketing deals with large game developers that included them giving away free copies of their compiler and support. It's unclear how prevalent that was, though there were a few titles with an Intel splash logo that were part of this.

This is often assumed to be the cause of the difference of performances between AMD and Intel CPUs in games btw, and while that can definitely come into it, it's not always correct. Sometimes the engines just don't know about the CPUs and treat them like the previous generation (like at Ryzen launch where some games ignored SMT on those), sometimes the devs only tested on one arch, or sometimes it's some extra library that makes incorrect assumptions.

Interesting read on the topic with Cyberpunk : https://cookieplmonster.github.io/2020/12/13/cyberpunk-2077-...

Re: Intel C/C++ compilers complete adoption of LLVM

#68
post #43

Earlier quoted context omitted.

That was ions ago, and if not for anything else, Linux kernel will keep GCC around. Azure Sphere OS is also GCC only, despite Microsoft's new foundled love for clang.

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.

Re: Intel C/C++ compilers complete adoption of LLVM

#69

Earlier quoted context omitted.

Same thing with C++Builder whose last version from this year is still based on LLVM 5, I think. Even Apple's clang is behind LLVM upstream if I'm not mistaken. The joy of permissive licenses!

Copyleft licenses have no way of forcing anyone to follow upstreams more closely. 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. The only thing the GPL changes is the vendor posts a source dump of dubious usefulness in some obscure section of their website.

Yes that's true, the licence alone is not enough.

That said, this "junk" dump can still be used by the community of users to upgrade themselves the software on that hardware, so that's still a nice improvement.

Back to LLVM the question is whether these companies decide to not contribute upstream because they don't bother to make clean patches or because they want to keep it for themselves.

I'd argue that they would be much better off long-term making clean patches anyway, so that's not a valid reason for not contributing.

And even if theynjust dumped their patches, the community could still take them and incorporate nice optimization into upstream.

Re: Intel C/C++ compilers complete adoption of LLVM

#70
post #42

Earlier quoted context omitted.

> I get it, there's no money to be made in just implementing all your optimizations in clang directly. ICC Classic is legacy/dead and also free now. The LLVM-based DPC++ compilers are free as well. These are only making money indirectly and through support contracts.

Yeah, but if you give all the golden eggs away, others can offer support contracts as well.

They can, but who knows more about the issue in question, Intel who designed it, or a third party? This is also a curse to Intel though: they need to ensure their people actually know something, level one support with a bad script and no access to anyone with more ability will get caught quickly when the third party offers better support and generally can figure things out.

There are pros and cons for sure. I'm not sure what it best.

Post reply on HN