21–30 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…
Because clang is painful to use.
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…
Yes, I think though gcc will go first.
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 (which is a much harder problem to solve)
Anyone actually use Intel compilers
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…
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 optimizations, etc.
When you build a tool on top of LLVM, you are buying into this rapidly changing platform.
The only proven way of using the LLVM platform competitively is to be part of its future: follow upstream closely, upstream most of your code, and actively participate in the platform evolution so that your competitors can't turn it against you.
If you keep most of your code private, following upstream gets very hard. You skip one release, and then its 10x harder, so you skip another release and stop participating in LLVM's evolution cause you'll have to wait years for changes to upstream to land on your compiler. Your competitors do what's best for them, and those can be things that are bad for you, and then you are proper screwed, cause you can't migrate away from LLVM either.
Companies like Intel and NVIDIA do this, e.g., nvcc and ISPC are stuck on LLVM 7 (~4 years old), but these companies have built huge technology stacks like CUDA or DPC++ on top of it!
Intel and NVIDIA might have enough manpower to maintain their own outdated fork of LLVM forever, but at some point it just stops being LLVM, and these companies are not really much better off than where they started.
IMO, building all your technology on top of a platform that either is or can be under your competitors control is just a really bad idea.
One would hope that these companies would realize this and contribute back and help the community as much as possible, but in practice they just don't. By the time they realize it, it's already too late.
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…
Sounds really shortsighted. I would imagine revenue from Intel dev tools is a rounding error in Intel's complete revenue stream?
Earlier quoted context omitted.
Yes, I think though gcc will go first.
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 (…
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.
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 for everybody involved is huge.
Having a single, e.g., C++ parser with a single set of bugs is a much better value proposition for C++ programmers.
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.
On the other hand, collaboration is also good. Why waste time reinventing the wheel?
Anyone actually use Intel compilers
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.
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…
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.