“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 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 ]