“What the Hardware Does” Is Not What Your Program Does: Uninitialized Memory

Re:“What the Hardware Does” Is Not What Your Program Does: U... by nothrabannosir on Sunday July 14, 2019 @05:03PM (#20436005)

This is driven by programmers' insatiable thirst for performance. Compiler writers are constantly judged on benchmarks, and the only way to squeeze that last flop out of a piece of code is to take the specification to its extreme.

UB is always about optimisations and performance. Incidentally, this is why I don't think talking about "nasal demons" is productive. The compiler mostly just uses UB to assume: ah, this can't happen, so I can optimise it away. Often that means valid programs go faster. We wanted it: we got it.

From my limited experience (and it's been a while), -O0 (no optimisations) is really quite reliable, even if you do all kinds of UB shenanigans.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by naniwaduni on Sunday July 14, 2019 @05:11PM (#20436062)

> This is driven by programmers' insatiable thirst for performance. Compiler writers are constantly judged on benchmarks, and the only way to squeeze that last flop out of a piece of code is to take the specification to its extreme.

Really? I've seen people switch between competing compilers for licensing reasons, platform support, features---but benchmark performance? Maybe blog posts suggesting that a new compiler wasn't ready.

Compiler writers judge themselves on benchmarks.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by closeparen on Sunday July 14, 2019 @06:56PM (#20436795)

Competitive performance for your workload is basically the reason you would buy Intel's compiler, right?

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by mhh__ on Sunday July 14, 2019 @06:39PM (#20436704)

It might not be true now because LLVM and GCC can generally put a commercial compiler 6 feet under, but if you're paying for a compiler you'd definitely want to choose the one that delivers the best performance (Money being no object)

No idea whether ICC is still worth paying for

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by userbinator on Sunday July 14, 2019 @07:02PM (#20436822)

No idea whether ICC is still worth paying for

From my experience, ICC is far more reluctant to exploit UB, yet still generates very good code.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by saagarjha on Monday July 15, 2019 @02:16AM (#20438562)

ICC exploits the standard itself: it generates code that is technically incorrect.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by mehrdadn on Monday July 15, 2019 @03:20AM (#20438784)

What do you mean?

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by saagarjha on Monday July 15, 2019 @03:31AM (#20438830)

As Patrick mentions, ICC generates code that doesn't follow IEEE-754: https://news.ycombinator.com/item?id=20437375 (I should have mentioned I was talking about that rather than the C standard).

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by mehrdadn on Monday July 15, 2019 @03:35AM (#20438855)

Oh I see, you're talking about floating point.

So basically ICC has -ffast-math (or -funsafe-math-optimizations) on by default, and you can turn it off with an explicit flag?

I see this as more of a philosophical difference than a material one since you can just add or remove the flag on either one...

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by dllthomas on Sunday July 14, 2019 @07:09PM (#20436866)

IME, benchmarks aren't enough of an impetus to move between compilers, but are often a not-insignificant piece of what's considered when moving is otherwise motivated.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by SamReidHughes on Monday July 15, 2019 @03:32AM (#20438833)

For C++, compilation time performance is the benchmark. At least it's why I started using clang.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by xeeeeeeeeeeenu on Monday July 15, 2019 @02:25AM (#20438582)

>This is driven by programmers' insatiable thirst for performance. Compiler writers are constantly judged on benchmarks, and the only way to squeeze that last flop out of a piece of code is to take the specification to its extreme.

Ironically, strict aliasing rule (which is one of the most common causes of UB) makes writing fast programs much harder, because it forbids type punning (except via memcpy or unions).

BTW, according to WG14 mailings and minutes, the C committee is considering either relaxing it or creating a standard way to suppress it in C2X. I can't wait for it.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by saagarjha on Monday July 15, 2019 @03:05AM (#20438725)

Writing fast programs while keeping the strict aliasing rule in mind isn't all that hard: compilers know the semantics of memcpy and can optimize your use to what it's "supposed to be in assembly".

[ Parent | on HN ]