4 ms·

Everyone agrees this is a problem. Today Go only inlines a function under certain very narrow circumstances.

GordonS 8y ago
In C# you can apply an `AggressiveInlining` to remove certain limiting restrictions, making it more likely that a method will be inlined - does Go have something similar?
fwip 8y ago
This has actually improved in the latest release, version 1.12. I'm sure it's still behind other languages, though.
- tmaly 8y ago
  I can only imagine where Go will be with compiler optimizations in 3-5 years. Look at gcc, it has tons, but it took years to get there. Go has the added advantage of being able to learn off this knowledge
  - masklinn 8y ago
    > I can only imagine where Go will be with compiler optimizations in 3-5 years. Nowhere, optimisations cost CPU time and the Go developers focus on compilation time. They could already have implemented plenty of well-known and well-understood optimisation passes in the 10 years since the initial release, that they didn't do so and restricted themselves to the sort of optimisation passes you'd find in a bytecode interpreter was by design. In theory gccgo is where you'd get an optimising go compiler, but apparently even with gcc 8.1's improvements it has issues which lead to the end result being slower than the mainline compiler. I'm sure they'd be glad to get more people involved to resolve this. > Look at gcc, it has tons, but it took years to get there. > Go has the added advantage of being able to learn off this knowledge Go could have used LLVM, they specifically refused to do so on grounds of compilation time being too slow, preferring to not optimise instead.
    - pjmlp 8y ago
      Yet D, Delphi, Eiffel, .NET Native, Free Pascal, OCaml among others, manage to offer rich languages, deliver performance while having fast compilation times.
      - masklinn 8y ago
        I'm pretty sure OCaml doesn't use an optimising compiler, I don't think Delphi or FreePascal do either, not sure about the others. Just as Go does, these compilers will perform some optimisations but generally fairly local and simple. They "deliver performance" in the same way Go does. According to its documentation, dmd doesn't even do function inlining until you specifically opt into that with `-inline`.
        pjmlp 8y ago
        I am pretty sure you are wrong. OCaml has multiple implementations, it is a matter to choose the right one for the task at hand. Delphi can make use of C++Builder's backend. Eiffel uses its MELT VM for development, or compilation via C and C++ code generation, thus enjoying all their optimization capabilities. D has three main implementations available, including GPGPU support on the ldc one. .NET Native uses Visual C++'s C2 backend.
        masklinn 8y ago
        Seems like none of them "deliver performance while having fast compilation times", rather that you can pick between fast compilation and high-performance result. Which is pretty much the theoretical intention between mainline go[0] and gccgo. And I will thus restate my original assertion: in 3-5 Go (the mainline compiler) will be nowhere in terms of optimisations. If you want an optimising Go compiler, work on and help with gccgo. [0] whose maintainers simply don't care for advanced optimisations at the cost of compilation speed
        pjmlp 8y ago
        On the the contrary, in some of the mentioned cases it just the difference between debug and release builds. Go's community approach seems to keep being "you are holding it wrong", disregarding experience from other language communities.

In C# you can apply an `AggressiveInlining` to remove certain limiting restrictions, making it more likely that a method will be inlined - does Go have something similar?

fwip 8y ago

This has actually improved in the latest release, version 1.12. I'm sure it's still behind other languages, though.

tmaly 8y ago
I can only imagine where Go will be with compiler optimizations in 3-5 years. Look at gcc, it has tons, but it took years to get there. Go has the added advantage of being able to learn off this knowledge
- masklinn 8y ago
  > I can only imagine where Go will be with compiler optimizations in 3-5 years. Nowhere, optimisations cost CPU time and the Go developers focus on compilation time. They could already have implemented plenty of well-known and well-understood optimisation passes in the 10 years since the initial release, that they didn't do so and restricted themselves to the sort of optimisation passes you'd find in a bytecode interpreter was by design. In theory gccgo is where you'd get an optimising go compiler, but apparently even with gcc 8.1's improvements it has issues which lead to the end result being slower than the mainline compiler. I'm sure they'd be glad to get more people involved to resolve this. > Look at gcc, it has tons, but it took years to get there. > Go has the added advantage of being able to learn off this knowledge Go could have used LLVM, they specifically refused to do so on grounds of compilation time being too slow, preferring to not optimise instead.
  - pjmlp 8y ago
    Yet D, Delphi, Eiffel, .NET Native, Free Pascal, OCaml among others, manage to offer rich languages, deliver performance while having fast compilation times.
    - masklinn 8y ago
      I'm pretty sure OCaml doesn't use an optimising compiler, I don't think Delphi or FreePascal do either, not sure about the others. Just as Go does, these compilers will perform some optimisations but generally fairly local and simple. They "deliver performance" in the same way Go does. According to its documentation, dmd doesn't even do function inlining until you specifically opt into that with `-inline`.
      - pjmlp 8y ago
        I am pretty sure you are wrong. OCaml has multiple implementations, it is a matter to choose the right one for the task at hand. Delphi can make use of C++Builder's backend. Eiffel uses its MELT VM for development, or compilation via C and C++ code generation, thus enjoying all their optimization capabilities. D has three main implementations available, including GPGPU support on the ldc one. .NET Native uses Visual C++'s C2 backend.
        masklinn 8y ago
        Seems like none of them "deliver performance while having fast compilation times", rather that you can pick between fast compilation and high-performance result. Which is pretty much the theoretical intention between mainline go[0] and gccgo. And I will thus restate my original assertion: in 3-5 Go (the mainline compiler) will be nowhere in terms of optimisations. If you want an optimising Go compiler, work on and help with gccgo. [0] whose maintainers simply don't care for advanced optimisations at the cost of compilation speed
        pjmlp 8y ago
        On the the contrary, in some of the mentioned cases it just the difference between debug and release builds. Go's community approach seems to keep being "you are holding it wrong", disregarding experience from other language communities.