11–20 of 169 posts
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…
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…
I assumed the icc secret sauce was in the backend: deep knowledge of how each and every single operation is implemented in every uarch.
Maybe they've written their own x86 backend for LLVM, and are using the rest of LLVM for IR->IR transformations and vectorization?
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…
They're not upstreaming all their optimisations. I'd be surprised if they upstreamed all their FPGA support as well.
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…
It is not like clang is enjoying C++ Builder RAD abilities, PS 4 and 5 optimizations, or bitcode format used by watchOS.
Absolutely sensible move. Time for Microsoft to do the same with MSVC.
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.
Honestly, I think it will be great to have one less set of compiler-specific oddities to worry about.
Anyone actually use Intel compilers
They are used in High Performance Computing as far as I know. Not systematically though.
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? They're not upstreaming all their optimisations. I'd be surprised if they upstreamed all their FPGA support as well.
That's quite reassuring for users of LLVM on non-Intel hardware, where ICC "optimisations" turn into pessimisations.
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…
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 reason in this marketing language though, tbh:
- "Our optimizations are too new" -> So put them behind a feature flag when upstreaming? And why inflict them on icx customers if they are "too new"? What does that even mean?
- "Our optimizations are architecture specific" -> ...yes? Emitting good architecture-specific code is the whole point of an optimizing compiler? How is that an argument against upstreaming?
- "Other compilers also don't upstream everything" -> That's a non-argument.
I get it, there's no money to be made in just implementing all your optimizations in clang directly. But these reasons (together with the repeated emphasis of how they do contribute to LLVM) seem silly. To be clear, I'm all for Intel helping improve LLVM, but the technical arguments for maintaining a separate commercial version don't convince me at all.
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…
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.
Companies can keep their optimizations in secrets. Just like why Playststion's OS is based on BSD.
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.