Hacker News Reader

Comment by kookamamie | Hacker News Reader

It's just so fiddly - can't trust the compiler, not a good sign for a language or its implementation.

You can never trust an optimizing compiler. I’ve seen similar issues in pretty much every language I’ve written performance-sensitive code in. Point revisions change optimizations all the time, sometimes with horribly disastrous results. One example: every time rust upgrades the version of LLVM underlying the compiler backend, the team prepares itself for a deluge of optimization regression reports (though this has been somewhat "mitigated" by a massive regression in rustc's ability to convey sufficient information to the LLVM backend for it to optimize to begin with, thanks to a change made to improve compile times [0]).

This is almost universally true across all languages. The behaviors you see are usually the result of countless heuristics stacked one atop the other, and a tiny change here can end up with huge changes there.

[0]: https://github.com/rust-lang/rust/pull/91743

Do you think other compilers for other languages don't perform optimizations like this?

Julia does all of this correctly (although there are a few 0 cost redundant move instructions presumably for ABI reasons).

julia> f(x) = @fastmath sqrt.(x)

julia > @code_native debuginfo=:none f.(Tuple(rand(Float32, 8)))

vsqrtps ymm0, ymmword ptr [rsi]

mov rbp, rsp

mov rax, rdi

vmovups ymmword ptr [rdi], ymm0

pop rbp

vzeroupper

ret

julia> g() = f((1f0, 2f0, 3f0, 4f0))

julia> @code_native debuginfo=:none g()

.LCPI0_0:

.long 0x3f800000 # float 1

.long 0x3fb504f3 # float 1.41421354

.long 0x3fddb3d7 # float 1.73205078

.long 0x40000000 # float 2

.text

.globl julia_g_600

.p2align 4, 0x90

.type julia_g_600,@function

julia_g_600: # @julia_g_600

# %bb.0: # %top

push rbp

movabs rcx, offset .LCPI0_0

mov rbp, rsp

mov rax, rdi

vmovaps xmm0, xmmword ptr [rcx]

vmovups xmmword ptr [rdi], xmm0

pop rbp

ret

...so does LLVM, unless you specifically instruct it to do otherwise with -ffast-math. Don't be fooled by the name of this flag, if it were possible to just do math faster without compromising anything, it wouldn't be a flag, it would be the default. It seems that Julia has a flag with the same name but a different behavior. Okay? What's your point exactly?

@fastmath in Julia is telling LLVM (basically) the same thing. I think the only difference is that Julia doesn't think rsqrt(x)*x with Newton iteration is a good way of computing sqrt

But in this case, -ffast-math actually results in slower math, so the flag is badly named. Naming things is important (and hard). The naive expectation of a flag named -ffast-math is that the math should never be slower, sometimes be faster, and potentially less accurate and/or error prone. The fact that it can also be sometimes slower means the flag really should be named -fdifferent-math or (uncharitably) -funreliable-math.

It’s too bad that it hasn’t acquired the name of an author to describe this alternative functionality more concisely without being judgy (like Nagle’s algorithm). I looked around, and it seems that there isn’t any one designer/author that you could give credit to.

I mean, the fiddly-ness comes from wanting to use inline assembly, which is often considered to be niche and second-class in most modern languages. Even writing the asm in the first place is full of footguns [0]. There are ways to reduce the optimization barrier of asm, and implementing constant folding is one such example. But I can see why most compiler writers wouldn't be that interested in it.

[0] https://news.ycombinator.com/item?id=40607845

Reply on news.ycombinator.com