Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel C/C++ compilers complete adoption of LLVM

software.intel.com

Post reply on HN
Print view View original

161–169 of 169 posts

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

#161

Post by pjmlp »

phendrenad2 wrote: post #155
zamadatix wrote: post #145

Earlier quoted context omitted.

The Linux kernel isn't a monoculture yet. For example there is no indication Apple or the BSDs are going to stop developing their kernels nor is there indication Windows is dropping NT and most anything can/is easily moved between them (particularly the *NIX kernels) still. That doesn't mean there are certain places the only choice is the Linux kernel but that alone isn't enough to make it a monoculture in this sense…

Linux powers most of the internet, most mobile devices, and most embedded and IoT devices. Maybe it's not a complete monopoly, but it's close.

Except it doesn't, go check termux's future on Android, as its developers refuse to adopt the Java APIs that are actually what it public on Android (Linux kernel syscalls aren't a public API).

https://developer.android.com/ndk/guides/stable_apis

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

#162

Post by pjmlp »

CalChris wrote: post #131

Apple has been the longtime LLVM stalwart, starting from when they first brought out Chris Lattner from the University of Illinois. There are whole subsystems which they've driven such as GlobalISel. However with the M1, Apple has moved wholesale over to ARMv8. Consequently, their efforts are with the AArch64 backend (which they also wrote) and not with X86. Yes, this announcement has to do with the Intel toolchain a…

Apple also kind of removed itself from clang contributions as their focus is on Objective-C and Swift, with most of their C++ use cases covered by ISO C++14.

Which is one of the reasons why ISO C++20 support in clang is lagging, alongside Google also kind of reducing their involvement.

Concepts support was mostly done by one dev.

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

#163

Post by volta83 »

zetalyrae wrote: post #50
volta83 wrote: post #24

Earlier quoted context omitted.

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…

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

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.

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

#164

Post by phkahler »

DSingularity wrote: post #92
phkahler wrote: post #90

Earlier quoted context omitted.

>> I'm all for Intel helping improve LLVM, but the technical arguments for maintaining a separate commercial version don't convince me at all. This is exactly why GCC is GPL and why RMS didn't want to make it more modular. Taken to the extreme we could end up with proprietary hardware that requires a proprietary (closed) compiler even though it's built on open source. Going back to "trusting trust" things might not b…

What does “trusting trust” have to do with this? That problem is a bootstrapping problem when trying to establish a trusted base. Simple summary is: if the first compiler was backdoored to detect when it is compiling other versions of itself and then inserting the same backdoor in the assembly of the target then how can you trust anything compiled by it?

You're right, the "trusting trust" compiler hack is way more complicated.

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

#165

Post by vlovich123 »

andi999 wrote: post #158
vlovich123 wrote: post #35

Earlier quoted context omitted.

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/

Thanks for the article, I am not sure I fully understand it. Could you point to the section about the missed email? Also, do I understand it right, that emacs doesnt integrate well with llvm? (maybe that explains why in llvm presentations ppl use the 'other' editor, I always wondered why not use emacs)

> An interesting side note to the debate emerged when Liang Wang posted about LLVM creator Chris Lattner's offer to try to get LLVM's copyright assigned to the FSF back in 2005. It was part of an effort (that seemingly went nowhere) to integrate LLVM and GCC. Stallman never heard about the message:

So basically, if Stallman hadn't have missed the message, there's a very real possibility that LLVM would have ended up licensed under GPLv2 & then re-licensed to GPLv3. The engineering world would probably look radically different if that had happened.

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

#166

Post by volta83 »

qayxc wrote: post #75
jitl wrote: post #66

Earlier quoted context omitted.

Intel and NVIDIA make their money selling hardware.

> "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-i... It's a very similar story for Intel. NVIDIA and Intel are selling hardware because of their software portfolio. How…

> How many GPUs would NVIDIA sell in the HPC market if it wasn't for CUDA and the various support libraries around it?

We don't have to hypothesize about this. The HPC GPU market has multiple vendors, just look at how many HPC GPUs AMD or Intel are selling: AMD and Intel have ~0.8% or so market share. NVIDIA has >99%.

Pretty much every review of HPC GPUs states that AMD GPUs are both faster and cheaper.

So how come they don't sell?

The answer is software.

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

#168

Post by pumpkinpal »

volta83 wrote: post #27
xamolxix wrote: 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.

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

There are real benefits to be gained though from new compilers. Look at "Circle" by Sean Baxter as an example. Outside of supporting a powerful form of compile time computation and allowing things such as reflection and writing shaders directly in C++, benchmarks have been floating around showing that it compiles quite a bit faster than GCC and Clang whilst still being able to compile big projects such as Boost. Although LLVM is the backend, the front-end is written from scratch by one guy.

https://www.circle-lang.org/

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

#169

Post by physicsguy »

slavik81 wrote: post #128
physicsguy wrote: post #31

Earlier quoted context omitted.

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.

What makes compiling FFTW on Windows so troublesome? That's currently on my to-do list.

Well, most Windows applications you have to actually deploy are compiled with MSVC, and historically most OSS libs don’t use cross platform build scripts, etc.

FFTW these days I think has a CMakeLists.txt file, and Visual Studio well supports CMake now but it didn’t used to.

Post reply on HN