8 ms·

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

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

varajelle 5y ago
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!
- floatboth 5y ago
  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.
  - qayxc 5y ago
    > 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 customers fall in the same category - smartphone manufacturers want to sell units, not keep software up-to-date.
    - jitl 5y ago
      Intel and NVIDIA make their money selling hardware.
      - qayxc 5y ago
        > "NVIDIA is a software-defined company today," Huang said, "with rich software content like GeForce NOW, NVIDIA virtual workstation in the cloud, NVIDIA AI, and NVIDIA Drive that will add recurring software revenue to our business model." https://www.msn.com/en-us/money/technologyinvesting/nvidia-is-more-than-a-semiconductor-company/ar-BB18egA5 https://www.msn.com/en-us/money/technologyinvesting/nvidia-i... It's a very similar story for Intel. NVIDIA and Intel are selling hardware because of their software portfolio. How many GPUs would NVIDIA sell in the HPC market if it wasn't for CUDA and the various support libraries around it? Intel's non-client solution revenue was over 40% of their total revenue in 2020. This includes their (software-) AI solutions, applications, licence business and services. So Intel, too makes a significant amount of money from software and services around their software ecosystem.
- beached_whale 5y ago
  Apple's is up to 6mo old at release, so currently around clang10/11. Every so often it gets 2 releases behind as they are both on 6mo cycles. It's not bad really and currently Clang 12 brings few compelling reasons to upgrade. The issue will be Clang 13 is supposed to have a bunch of C++20 things, I think, and it will also be one of those ones that has a long time before Apple releases their next one.
- deleted 5y ago
  [deleted]
pjmlp 5y ago
Besides C++ Builder already referred in a sibiling comment, that is how you get stabilitiy on bitcode for watchOS apps.
zetalyrae 5y ago
>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. 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.
- volta83 5y ago
  This is not really a strategy, but rather a consequence of LLVM having hundreds of developers, most of which use LLVM upstream, and therefore don't care about maintaining an API compatibility that they themselves do not need. It turns out that it is impossible to convince people working on LLVM on their free time or academics to invest part of their time on "preserving" API compatibility instead of adding new features, fixing bugs, or improving perf, for the benefit of companies that don't want to contribute their improvements to the community.
floatboth 5y ago
ISPC is not stuck on LLVM 7. Only fails on 12 currently, works on 11 and earlier: https://github.com/freebsd/freebsd-ports/blob/85cccf4f15c42d9668f90a3c5fd5ab12df39d4f2/devel/ispc/Makefile#L25-L28 https://github.com/freebsd/freebsd-ports/blob/85cccf4f15c42d... But hopefully that will be fixed soon.
- volta83 5y ago
  +1 thanks for the correction, should have verified this. Last time I used ISPC it was using an extremely outdated LLVM version (5) or so, and it took years to move it to LLVM 7. I wasn't aware that they have been slowly migrating to newer LLVM versions.
infogulch 5y ago
I like this strategy to encourage contributing back to open source by being a huge and foundational and producing so fast that the cost of forking is almost never worth it except in extreme circumstances. This feels more like voluntary cooperation than being smacked in the face with ~~the book~~ a license. Though I suppose it wouldn't always work if you're not a big project with lots of contributions.
thereddaikon 5y ago
I think its even simpler than that. They don't want to reveal any of their secret sauce through available source be it tipping off competitors to hardware designs or just revealing compiler optimizations they believe are valuable enough to keep as trade secrets. Why would they make AMD's job easier? Intel's C compiler has always played games with non-intel x86 architectures compared to their own.

varajelle 5y ago

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!

floatboth 5y ago
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.
- qayxc 5y ago
  > 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 customers fall in the same category - smartphone manufacturers want to sell units, not keep software up-to-date.
  - jitl 5y ago
    Intel and NVIDIA make their money selling hardware.
    - qayxc 5y ago
      > "NVIDIA is a software-defined company today," Huang said, "with rich software content like GeForce NOW, NVIDIA virtual workstation in the cloud, NVIDIA AI, and NVIDIA Drive that will add recurring software revenue to our business model." https://www.msn.com/en-us/money/technologyinvesting/nvidia-is-more-than-a-semiconductor-company/ar-BB18egA5 https://www.msn.com/en-us/money/technologyinvesting/nvidia-i... It's a very similar story for Intel. NVIDIA and Intel are selling hardware because of their software portfolio. How many GPUs would NVIDIA sell in the HPC market if it wasn't for CUDA and the various support libraries around it? Intel's non-client solution revenue was over 40% of their total revenue in 2020. This includes their (software-) AI solutions, applications, licence business and services. So Intel, too makes a significant amount of money from software and services around their software ecosystem.
beached_whale 5y ago
Apple's is up to 6mo old at release, so currently around clang10/11. Every so often it gets 2 releases behind as they are both on 6mo cycles. It's not bad really and currently Clang 12 brings few compelling reasons to upgrade. The issue will be Clang 13 is supposed to have a bunch of C++20 things, I think, and it will also be one of those ones that has a long time before Apple releases their next one.
deleted 5y ago
[deleted]

pjmlp 5y ago

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

zetalyrae 5y ago

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

volta83 5y ago
This is not really a strategy, but rather a consequence of LLVM having hundreds of developers, most of which use LLVM upstream, and therefore don't care about maintaining an API compatibility that they themselves do not need. It turns out that it is impossible to convince people working on LLVM on their free time or academics to invest part of their time on "preserving" API compatibility instead of adding new features, fixing bugs, or improving perf, for the benefit of companies that don't want to contribute their improvements to the community.

floatboth 5y ago

ISPC is not stuck on LLVM 7. Only fails on 12 currently, works on 11 and earlier: https://github.com/freebsd/freebsd-ports/blob/85cccf4f15c42d9668f90a3c5fd5ab12df39d4f2/devel/ispc/Makefile#L25-L28 https://github.com/freebsd/freebsd-ports/blob/85cccf4f15c42d... But hopefully that will be fixed soon.

volta83 5y ago
+1 thanks for the correction, should have verified this. Last time I used ISPC it was using an extremely outdated LLVM version (5) or so, and it took years to move it to LLVM 7. I wasn't aware that they have been slowly migrating to newer LLVM versions.

infogulch 5y ago

I like this strategy to encourage contributing back to open source by being a huge and foundational and producing so fast that the cost of forking is almost never worth it except in extreme circumstances. This feels more like voluntary cooperation than being smacked in the face with ~~the book~~ a license. Though I suppose it wouldn't always work if you're not a big project with lots of contributions.

thereddaikon 5y ago

I think its even simpler than that. They don't want to reveal any of their secret sauce through available source be it tipping off competitors to hardware designs or just revealing compiler optimizations they believe are valuable enough to keep as trade secrets. Why would they make AMD's job easier? Intel's C compiler has always played games with non-intel x86 architectures compared to their own.