Hacker News Reader

Comment by shmerl | Hacker News Reader

I'm still waiting for this bug to be fixed: https://community.amd.com/message/2796982

Note: this isn't a bug in gcc, but looks like hardware bug related to hyperthreading.

AMD fanboy checking in :)

One of the good OCaml folks over at Jane Street just recently found a bug that crashes systems with Hyperthreading enabled on both Intel Skylake and Kaby Lake as well – just saying:

https://news.ycombinator.com/item?id=14630183

Those hardware bugs are all very disheartening from software folks perspective, doesn't matter which company it pertains... "microcode update" rollseyes

Edit: dear AMD haters, keep the downvotes coming B-) it has only been since May that the first fixes have been rolled out for Skylake / Kaby Lake – and yes, naturally AMD should "fix" (rollseyesagain) their respective issues ASAP but just saying...

https://arstechnica.com/information-technology/2017/06/skyla...

Compare what you can get today: an Intel CPU without a hyperthreading problem (fixed in a microcode update months back) or an AMD CPU with a hyperthreading problem (being investigated by AMD for 3 months).

Edit: thanks, s/unacknowledged/being investigated/

If I remember the story right it took Intel ~8months to accept that it was an issue and fix it.

Would you buy a pile of Ryzen CPUs under the assumption that AMD will be able to fix it properly with an update (without e.g. disabling HT or making performance worse as they did for their TLB fix in 2007)? If they take another 2 months, you're out on your return window.

That bug was acknowledged a while ago.

to be fair, that Intel hyperthreading issue took Intel 5 months to investigate and fix.

I bought my Ryzen CPU already, and going to build a new computer shortly. So I'm literally waiting for that fix.

That sucks indeed :(

I just wanted to say that many recent CPUs seem to be rushed efforts - be it Intel or AMD.

AMD has pulled up to match or beat Intel, so both companies were absolutely rushing things out. It will settle down and these bugs will get fixed by microcode updates.

They’re not rushed, you just cannot knock out every bug in a new piece of software or hardware in one go. It is not possible (without some incredibly slow and 3xpensove processes).

Disable hyperthreading, it's overrated anyways

Is it? I know there are workloads when it actually can hurt performance, but are they more common than ones when it helps?

Here's Anandtech's recent SPEC benchmark deltas on hypertheading.

http://www.anandtech.com/show/11544/intel-skylake-ep-vs-amd-...

I see performance increases in every row there, so it must be beneficial in most cases.

comparing single threaded performance vs. two-threads-on-one-core will do that. here's a bunch of real-world tests (mostly gaming) showing HT hurting performance: https://www.techpowerup.com/forums/threads/gaming-benchmarks...

It's not net helpful if it triggers a CPU bug.

Sure, but if it's a feature that's increasing performance without a bug, it's something that should be fixed, otherwise you are paying for broken hardware.

> I know there are workloads when it actually can hurt performance

From what I've seen, performance is only hurt in contrived benchmarks intended to cause slowdowns when HT is in use.

> I know there are workloads when it actually can hurt performance, but are they more common than ones when it helps?

Hyperthreading makes better use of execution units but causes twice as many threads to share memory bandwidth and caches. It's often a good trade-off.

But it's also less valuable for high core-count processors, because workloads that aren't highly parallel will have idle real cores to run other threads on, and highly parallel workloads are more likely to be bottlenecked by memory and caches when there are more cores.

The real question is whether it's faster for your workload. And your hardware. The answer could be different on a system with 8 cores and 2 memory channels than a system with 4 cores and 4 memory channels.

Turn it on and then off and see which is faster for you.

If you are a Linux user it's fine (had two months on a 1700 with Fedora and zero issues) unless you hit the particular edge case.

Sounds like heavy parallel compiling hits it pretty often. Or you mean even that doesn't happen with every chip? Is it some kind of random hardware defect that's not always present?

I hammer the work machine but not at parallel GCC compiles so whatever the underlying cause it's simply not something I've hit.

Just a question (this is how out of touch I am). I thought most linux compilation moved over to a lvvm toolchain?

Not really, but it's generally up to individual projects. Many support both gcc and clang.

Not even remotely close. No major distribution uses the LLVM toolchain.

If you are talking about the kernel itself, I think Debian did some work to support building Linux with clang. But last time I checked, it wasn't ready.

Distributions compile more than just a kernel. That's just one of several thousand packages we build. Usually the problem (even with something as simple as PIC/ASLR) is that old projects might have problems compiling.

We just switched openSUSE Tumbleweed to GCC7 a few months ago, and it was a very large amount of work. I can't imagine how much work it would take to switch to LLVM.

Counterpoint: We compile more than one entire linux distribution (one is gentoo based, others vary) with llvm with essentially no issues (the number of local patches is incredibly small, and most is actually just buggy code that clang happens to detect, and we are waiting for upstream to accept).

Is it work? Sure. But it's not like "years of real work". It's about 5-10 people for a quarter or two.

It is definitely possible, but I was saying that switching to LLVM would take a while, and that even GCC updates are painful. 5-10 people for 6 months is a fairly serious time investment for a community project (especially since we have a lot of other things on our plate).

There are efforts for the kernel itself too.

http://llvm.linuxfoundation.org/index.php/Main_Page

In my experience, most Linux compilation still uses gcc. For instance, Fedora often recompiles all of its packages with a newer gcc for new Fedora releases; see https://fedoraproject.org/wiki/Changes/GCC7 and https://fedoraproject.org/wiki/Changes/GCC6 and so on.

And the Linux kernel, due to its heavy use of gcc-specific extensions, also has some problems compiling with LLVM; see https://bugs.llvm.org/show_bug.cgi?id=4068 for a list.

Actually, these days, it compiles just about fine. (though admittedly it depends on the platform)

FreeBSD has moved to llvm.

NetBSD also supports clang/llvm.

https://wiki.netbsd.org/tutorials/pkgsrc/clang/

For the base system or for everything? I doubt they moved the ports to compiling to LLVM.

It's the default for anything. Many ports override that and specify gcc (but that was already the case in a lot of cases where they needed a newer version than what shipped in the base system).

Starting FreeBSD 10 (released in 2014) the default for everything including ports was to build with clang. There was a large effort leading up to that to get as many ports as possible building with clang. Many bugs in clang were fixed, and patches were submitted upstream to make others work.

At this time that effort is dead: the few ports that don't build with clang are accepted as doing something that will never work.

For compiler for base and most of ports, yes. The linker is still an ancient GPL2 GNU binutils one.

A lot of work happened on linking base with LLVM's LLD, I think it might be already used in -CURRENT for amd64 and arm64.

It's only used for arm64, not amd64, because arm64 doesn't exist in GPL2 binutils (from ~2008).

To add to what other people have said, you can't even compile the kernel unpatched with llvm yet. GCC is still very much a thing.

What would be the benefit to llvm?

more portability, and some of the santiziers that clang has (ubsan, asan). They have gcc equivalents or ports but being able to use more of these kinds of tools is a good thing in the end since it'll allow more bugs to be found without an exploit.

> and some of the santiziers that clang has (ubsan, asan)

GCC has these.

Do they end up finding the same issues/bugs? I thought they didn't always find the same things last I tried using them, so I'd build in both compilers to end up running tests/checks.

No sure what you mean by 'more portability'. gcc compiles to a strict subset of the architectures than llvm supports (at least, last time I checked).

You mean superset, right?

Yes, and it's too late to change now, thanks.

It means that you won't end up relying on a specific compiler's quirks or implementation of the language. You can expect different compilers to handle undefined behavior in different ways which will help you catch where you're doing things you shouldn't be. And since you're no longer relying on a single compiler you are more likely to be able to support other platforms and compilers that don't have a gcc port (they do exist, even if they aren't common).

You have to rely on compiler's implementation -- you can't implement a kernel in pure C unfortunately, you need to do some things "outside" of C.

In practice, most supporting of the kernel has come about by clang implementing things how gcc do them anyway.

Not having the kernel locked into a compiler monoculture for one.

Why does that matter?

Monocultures of any kind in software aren't good.

It leads to lock-ins, like the current kernel is locked into GCC. Some of those GCC Extensions used are effectively proprietary because "the code is the documentation" so nobody can replicate it for their own compiler.

I do not believe that is healthy.

That's definitely a huge disadvantage!

But only supporting one compiler has the advantage that you're aren't limited to the lowest common denominator of compiler features.

You'll notice this especially with C++ codebases which try to support GCC, Clang, Intel and Visual C++. You'll need a lot of macros and workarounds for each compiler's quirks.

When I'm doing a new C project I usually go out of my way to make sure it compiles clean with GCC and clang. Each compiler has its strength and weaknesses. GCC tends to produce faster code in some situations where clang has great static code analysis tools and asan is amazing. I've heard GCC has made major improvements in build speed since the last time I've started a new C project from scratch but that used to be on my list of reasons too.

C can be a hard to wrangle beast and the more checks I have on my code quality the better I sleep at night.

At least from the outside, GCC asan seems comparable to clang's right now. I haven't done back-to-back checking to see if clang finds things it doesn't. I haven't really used the undefined and thread sanitizers though.

Oh wow. That's exciting news. My current job doesn't have me doing any C so I haven't been following the releases as closely as I used to.

LLVM is an extremely open backend. So it can be used for many projects a short list of its usages:

* Compiling SPIR-V shaders to GPU executables

* Compiling C

* Compiling C++

* Compiling Rust

* Compiling Haskell

* Compiling Swift

* JIT compilers for databases

* JVM JIT

Effectively once you translate to LLVM-IR you are basically home free, the LLVM can handle the rest. Which means you have a board range of people providing optimization passes, and catching bugs.

---

With the GCC its IR is tightly coupled to the C front end. While there has been some decoupling, this is generally considered a feature as it doesn't allow for a corporation to _run away_ with part of the project.

---

The LLVM is more modular, you can pick and take what you need. You can embed it, or call it externally. It is a hybrid BST/MIT/X11 license so it is open source, and embedding it in your project doesn't mean your project becomes GPL'd.

Also used to be in WebKit's JS engine https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/ now replaced with a custom thing https://webkit.org/blog/5852/introducing-the-b3-jit-compiler...

It's widely viewed as better designed (though that's obviously somewhat subjective); it's more modular, and a lot of innovative work on optimization now happens there rather than in GCC.

It is not GPL3 licensed. Most of the projects that have moved from gcc to llvm did it because of the license not for technical reasons.

That isn't to say there are not technical reasons to say llvm is better - there are good ones. However they are not compelling like the license is. Llvm has a better internal design which should be better long term, but so far gcc generally compiles faster code which is for most people more important that internal design.

Note that linux distributions are mostly built by the types of people who like the GPL3 license. Using gcc is the correct decision for most linux distributions.

Am I understanding it correctly that you're saying those projects switch because of the license of their compiler?

As far as I know the GPL doesn't "infect" the program compiled with a GPL-licensed compiler, I can have my proprietary binary-only software compiled with the GPLed gcc just fine...

> Am I understanding it correctly that you're saying those projects switch because of the license of their compiler?

Indeed they do.

  $ cc --version
  gcc (GCC) 4.2.1 20070719

This system is stuck with a rather old branch of GCC. It won't ever be upgraded, because of the license. LLVM seems to be on its way though.

It's a factor if you're writing a compiler for a new programming language. LLVM has been a pretty common target for that (see also: Julia and Rust) both for technical reasons and because it means the language itself can be released under a non-GPL license.

It's also a factor if you're distributing a compiler with your operating system. This has already driven FreeBSD (IIRC) to LLVM, and OpenBSD is starting to adopt it for a few platforms (GCC is still required due to certain OpenBSD targets that aren't supported by LLVM, but if that's ever fixed - whether because OpenBSD drops those targets or because LLVM eventually supports them - then I'd be very surprised if a switch doesn't happen for all platforms).

> It's a factor if you're writing a compiler for a new programming language.

Let them release their compiler for that language under GPLv3. What is there to be scared of?

The license for GPLv3 is something to be scared of.

Yes. Apple (NeXT at the time) had to make their objective-c frontend for gcc GPL, and they did not like that. that is why apple spent a lot of money making clang good: it allows them to do have patches they don't want to make available why still getting a good compiler. (I don't know if those patches exist, but they have that ability if they want it)

*BSD has in generally hated having anything GPL in their base system. OpenBSD played with creating their own C compiler for a while (the goal was just a compiler with only minimal optimizations - they expected everyone would just use that to build gcc and then build everything with gcc)

The "licensing" and "better design" arguments are not really compelling. As for "licensing", basically no commercial operating system distribution ships the compiler in the base system. As for "better design", LLVM still doesn't generate code as well as GCC, especially for the kernel; but over the years as the codegen has become better, the performance has come down to match GCC. LLVM has some pinhole optimizations which don't exist on GCC, and some slightly different behaviours around exotic non-standard types, but they are largely becoming the same compiler.

Turns out that GCC is actually really fast for the quality of the code it generates, and Clang/LLVM take almost exactly the same amount of time to generate similar code.

Licensing was THE reason Apple didn't update their GCC version in Xcode and switched over to Clang/LLVM. IANAL and my history is a bit hazy but the things that Apple wanted to support and the way they wanted to go about doing it was not compatible with the GPL.

Apple first used LLVM for their graphics stack, and it became more attractive to them because of the JIT stuff. Bringing Clang along is more or less an artifact of that. Maybe they weren't interested in GPLv3 since the tivoization clause prohibits them from distributing the compiler on devices which can't be flashed, but I don't think it's exactly rational. They also don't update the version of Emacs that they ship, and there you could make the argument for it since it ships with the operating system.

They wanted the freedom to make the base system read only, and I get that, but if LLVM weren't there they would be shipping GPLv3 GCC and Emacs 25.

> tivoization clause prohibits them from distributing the compiler on devices which can't be flashed

The tivoization clause has an explicit exception that allows for devices which can't be flashed. What the clause prohibits is the case when devices can only be flashed if you got the right developer password, and the publisher deny the owner of the device to have that password.

rms used to tell a story about NeXT approaching him to come to a deal to throw money at the FSF in order to avoid having to open source the Objective C gcc toolchain. The FSF (predictably) refused.

I wouldn't be surprised if the decision to go all-in on Clang was a reaction to a decade old grudge.

While I'm sure there would be benefits to LLVM from having such a well funded depend on it, the kernel has driven a lot of patches for GCC, I imagine the kernel would benefit more. Here is a list of advantages copy and pasted from llvm.linuxfoundation.org

Why use Clang/LLVM with the Linux Kernel?

Fast Compiles (making you able to work faster)

LLVM/Clang is a fast moving project with many things fixed quickly and features added.

LLVM is a family of tools used in many problem domains leading to one code base being able to build tools to work on just about anything you need: one place to add features, or fix bugs.

BSD License (some people prefer this license to the GPL)

Built in static analyzer

Great error reporting and Fix-it hints

LLVM technology can be embedded into many tools (even yours!)

Already in wide used in OSS projects and in industry

Turns out that after Clang got all the features GCC already had, compile times where even worse. At least for my C++ programs compiling with g++ is faster than with clang++.

Why would you want to switch to llvm from gcc for a GNU/Linux distribution? (I mean, beyond proving that the code is portable and do regression testing)?

I do remember talk on and off about shifting to the Intel c compiler, for increased performance - apparently Intel now has their own distro:

https://clearlinux.org/

I am still waiting the official errata for Family 17h

Reply on news.ycombinator.com