Live data from Hacker News

Intel C/C++ compilers complete adoption of LLVM

software.intel.com

31–40 of 169 posts

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

#31

Anyone actually use Intel compilers

Yeah, I used in my last job (commercial CFD code), and it was widely used by others in our sector. It's nice if you need to support Windows/Linux as well as brings for e.g. MPI, etc. and compiling scietnfic libs like FFTW on Windows is a PITA, so using MKL which comes bundled with it is very easy.

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

#32
post #23

Earlier quoted context omitted.

Pretty much in computer vision / image processing related companies and software products. The performance related advantage on Intel x86 architectures in particular is not to be neglected.

My understanding (but I'm not an ICC user) is the majority of the performance improvement are from the vectorized math libraries (that technically you can use from GCC as well).

It uses a default lower accuracy floating point model than GCC, so initially people think it's faster til they realise their results are slightly different and have to mess around with the `fp-model` flag

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

#33
post #7

Anyone actually use Intel compilers

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?

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

#34
post #19
post #14

Earlier quoted context omitted.

Because not everything on icc is going to be upstreamed to clang, thanks license. It is not like clang is enjoying C++ Builder RAD abilities, PS 4 and 5 optimizations, or bitcode format used by watchOS.

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.

LLVM is also preferred because it has much cleaner internals than gcc (although gcc has gotten hugely better over the years). And of course, all production compilers become monumentally complex over the years (I once worked with Open64 - gah).

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

#35
post #26
post #22

Earlier quoted context omitted.

GCC will never completely die. MS though have been moving in the Clang/LLVM direction for years, so I would have zero surprise if VC++ was completely removed tomorrow. My feeling is, as soon as they can be sure they have achieved 100% binary compatibility, MS will jump. The optimizers in VC++ are light years behind, and companies like Apple are embarrassing them on the compatibility front with things like Rosetta 2 (…

My understanding was the llvm was made because the code basis of gcc is too complicated. Since seems to be a killer move.

That was a long time ago and the actual primary reason was apparently Stallman missed an email [1], although I think the intentional technical hurdles to plugins was another of many reasons. When GNU moved all their software to GPLv3 and the business community decided they didn’t like that license and Apple brought LLVM as a serious contender.

GCC hasn’t remained stagnant though.

[1] https://lwn.net/Articles/632062/

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

#36
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…

> Also: if icc is going to go with LLVM as a backend, then what is the point of using icc at all? Why not just use clang? From the blog post: " Not all our optimization techniques get upstreamed—sometimes because they are too new, sometimes because they are very specific for Intel architecture. This is to be expected and is consistent with other compilers that have adopted LLVM. " I don't see any good technical reaso…

You over-estimate how much LLVM might want Intel's code dumps.

Based on (minor) personal experience of gcc forks, it's not unusual to make some fairly significant change to some major data structure to make your CPU work better, but which would break several other backends.

There may not be any nice way of integrating these changes in a way which would make the acceptable upstream, without multi-months of work refactoring huge chunks of the compiler (which would still also need lots of work on all those other architectures, to make them compatible with your changes).

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

#37
post #24

Earlier quoted context omitted.

> Also: if icc is going to go with LLVM as a backend, then what is the point of using icc at all? Why not just use clang? From the blog post: " Not all our optimization techniques get upstreamed—sometimes because they are too new, sometimes because they are very specific for Intel architecture. This is to be expected and is consistent with other compilers that have adopted LLVM. " I don't see any good technical reaso…

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…

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!

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

#38
post #28
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.

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

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

#39
One more proprietary compiler suite [1] bites the dust. Hopefully this will mean improvements will flow to the open source upstream, rather than just being a cost-cutting measure for the vendors with all improvements kept proprietary.

[1] A year ago IBM announced they are switching their "XL" compilers over to LLVM: https://developer.ibm.com/components/ibm-power/blogs/c-and-f... . (I haven't followed up what has happened since that announcement.)

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

#40
post #24

Earlier quoted context omitted.

> Also: if icc is going to go with LLVM as a backend, then what is the point of using icc at all? Why not just use clang? From the blog post: " Not all our optimization techniques get upstreamed—sometimes because they are too new, sometimes because they are very specific for Intel architecture. This is to be expected and is consistent with other compilers that have adopted LLVM. " I don't see any good technical reaso…

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…

Besides C++ Builder already referred in a sibiling comment, that is how you get stabilitiy on bitcode for watchOS apps.
Post reply on HN