5 ms·

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

by kookamamie 2y ago

g15jv2dp 2y ago
Do you think other compilers for other languages don't perform optimizations like this?
- adgjlsfhk1 2y ago
  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
  - g15jv2dp 2y ago
    ...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?
    - chongli 2y ago
      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.
      - tcbawo 2y ago
        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.
    - adgjlsfhk1 2y ago
      @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
dist1ll 2y ago
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 https://news.ycombinator.com/item?id=40607845
ComputerGuru 2y ago
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 https://github.com/rust-lang/rust/pull/91743

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

g15jv2dp 2y ago

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

adgjlsfhk1 2y ago
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
- g15jv2dp 2y ago
  ...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?
  - chongli 2y ago
    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.
    - tcbawo 2y ago
      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.
  - adgjlsfhk1 2y ago
    @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

dist1ll 2y ago

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 https://news.ycombinator.com/item?id=40607845

ComputerGuru 2y ago

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 https://github.com/rust-lang/rust/pull/91743