41–50 of 169 posts
Earlier quoted context omitted.
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
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…
> 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.
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.
Azure Sphere OS is also GCC only, despite Microsoft's new foundled love for clang.
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'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…
Like the famous check-for-intel-model-instead-of-feature-flag optimization? [0]
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 happ…
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.
> 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…
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?
It's less of a problem if the two of them don't decide to add their own proprietary "extensions" to the language. That may be something to look out for going forward.
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…
>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.
This is an interesting take. I've heard the claim that GCC kept its codebase cryptic to prevent companies running home with it and not upstreaming changes, maybe that's LLVM's strategy.