8 ms·

> being able to throw money and people at LLVM development doesn't explain why it's still much slower than the Go compiler toolchain. Right, you need to specif

> being able to throw money and people at LLVM development doesn't explain why it's still much slower than the Go compiler toolchain. Right, you need to specifically throw money and people at the problem of making LLVM faster, not just at LLVM in general. Neither Swift nor Objective-C have "fast compiles" as part of their pitch. Much of the work on LLVM goes into producing the highest quality object code possible, which is a goal often at odds with compiling quickly, and part of the reason the choose-your-optimization-level flag (-O) exists, though -O0 compiles are still not fast enough. > In hindsight the Go team made the right call to use their own toolchain. No, we don't have the benefit of hindsight yet. We don't know what could have been if the resources that had been spent on the Go toolchain had been spent on LLVM instead. If five highly-qualified engineers spent five years trying to speed up gollvm compiles without success, we'd have strong evidence that something about LLVM prohibits the fast compiles that are possible with the gc toolchain. But that's not the situation.

geodel 7y ago
> If five highly-qualified engineers spent five years trying to speed up gollvm compiles without success, we'd have strong evidence that something about LLVM prohibits the fast compiles that are possible with the gc toolchain. But that's not the situation. At some point people are going to need to put the money where their mouth is. Or they can live with the software which open source developers developed on their own or employers' dime.
- benesch 7y ago
  I spent six weeks, unpaid, at the Recurse Center this year hacking on gccgo to see if I could improve the situation. I didn't get very far—it's hard! And I don't have much experience with compilers. So, truly, I did as much as my finances could reasonably support. (I did manage to write up a blog post about where specifically gccgo needs the most work [0].) I did learn enough in those six weeks to feel comfortable asserting that there is incredible potential in gccgo/gollvm, and that I think Google is making a mistake by continuing to invest so heavily in the gc toolchain. [0]: http://meltware.com/2019/01/16/gccgo-benchmarks-2019.html http://meltware.com/2019/01/16/gccgo-benchmarks-2019.html
  - azylman 7y ago
    If you're going to rely on personal experience in an argument, "in six weeks I learned enough to criticize many engineers with decades of experience" is not a strong argument. That's not even claiming to be a 10x engineer, that's claiming to be a 1000x engineer. I don't intend this to sound harsh, apologies if it does. I strongly recommend you introspect on your own confidence and experience levels. I've mentored a lot of junior engineers with similar viewpoints and often there's a lot of hidden complexity they simply lack the experience to understand. This isn't to say you should take everything anyone with more experience says at blind faith, simply that dismissing without understanding is counter to a growth mentality.
    - benesch 7y ago
      I invoked the personal experience only as evidence that I did what (little) I could to push along the project that I think has the most long term potential. I'm not criticizing without at least trying to do what I can. In short, the reasons gccgo produces worse code than gc are the result of fairly basic optimizations that are/were missing. For example, open-coding string slicing [0] and string equality [1] is enough to close the gap in the TimeParse benchmark in the blog post above. In fact, with those changes, gccgo actually produces better code than gc, because the full power of GCC can be unleashed on the IR, and GCC has more aggressive optimizations than gc. > This isn't to say you should take everything anyone with more experience says at blind faith, simply that dismissing without understanding is counter to a growth mentality. Quite honestly, I think you're more guilty of dismissing without understanding than I am. It's true that I haven't been programming for decades, but I've spent two years dealing with the Go toolchain's shortcomings on a large Go project, and six weeks specifically on a passion project to improve gccgo. Of course it's possible that I'm wrong! But I've spent a while thinking about it, and often just as relevant as experience is a fresh, outside perspective. It's easy for a team to get stuck in tunnel vision or groupthink. [0]: https://github.com/golang/gofrontend/commit/62e3a8cc0a862b0abd3d0b1ef6cf4b228992a137 https://github.com/golang/gofrontend/commit/62e3a8cc0a862b0a... [1]: https://github.com/golang/gofrontend/commit/89b442a0100286ee569b8d2562ce1b2ea602f7e7 https://github.com/golang/gofrontend/commit/89b442a0100286ee...
zeeboo 7y ago
Maybe you should trust the judgement of the highly-qualified engineers then when they decided to go with their own toolchain, and not just assume that they’re doing it because plan 9 or some other vacuous reason.
- apta 7y ago
  The same people who created a language with poor design decisions where superior solutions existed in other languages they could have simply used?
  - hu3 7y ago
    What you vaguely label as poor design decisions are actually trade-offs and they make sense to a plethora of highly educated engineers.
    - apta 7y ago
      The people who made golang are not language designers, and/or did not research established options in other language as per their admittance.
      - pjmlp 7y ago
        Just like when C came around and everyone else was doing safe system programming in Algol dialects, PL/I, Fortran extensions, BLISS, Mesa. I see a trend here.
      - foldr 7y ago
        >The people who made golang are not language designers, I bet they've designed and executed on more programming languages than you have :)
        apta 7y ago
        That's not an argument.
      - 7y ago
jbarham 7y ago
> Right, you need to specifically throw money and people at the problem of making LLVM faster I repeat, Apple is the major sponsor of LLVM and is sitting on ~$250 billion in cash. If LLVM could be made significantly faster by simply throwing money at it, presumably this has also occurred to Apple management. I can't believe they're not doing it because it doesn't align with their marketing pitch.
- hollerith 7y ago
  Apple embraced LLVM because Apple's lawyers are scared of version 3 of the GPL and consequently of GCC, and they need something to compile Objective C. That is different from a belief that making LLVM better is worth management's attention or a slice of Apple's budget once it proved a satisfactory replacement for GCC.
renox 7y ago
If memory serves, AMD switched to a different compiler to reduce compilation time of the shaders, so reducing LLVM compilation time doesn't seem easy..

geodel 7y ago

> If five highly-qualified engineers spent five years trying to speed up gollvm compiles without success, we'd have strong evidence that something about LLVM prohibits the fast compiles that are possible with the gc toolchain. But that's not the situation. At some point people are going to need to put the money where their mouth is. Or they can live with the software which open source developers developed on their own or employers' dime.

benesch 7y ago
I spent six weeks, unpaid, at the Recurse Center this year hacking on gccgo to see if I could improve the situation. I didn't get very far—it's hard! And I don't have much experience with compilers. So, truly, I did as much as my finances could reasonably support. (I did manage to write up a blog post about where specifically gccgo needs the most work [0].) I did learn enough in those six weeks to feel comfortable asserting that there is incredible potential in gccgo/gollvm, and that I think Google is making a mistake by continuing to invest so heavily in the gc toolchain. [0]: http://meltware.com/2019/01/16/gccgo-benchmarks-2019.html http://meltware.com/2019/01/16/gccgo-benchmarks-2019.html
- azylman 7y ago
  If you're going to rely on personal experience in an argument, "in six weeks I learned enough to criticize many engineers with decades of experience" is not a strong argument. That's not even claiming to be a 10x engineer, that's claiming to be a 1000x engineer. I don't intend this to sound harsh, apologies if it does. I strongly recommend you introspect on your own confidence and experience levels. I've mentored a lot of junior engineers with similar viewpoints and often there's a lot of hidden complexity they simply lack the experience to understand. This isn't to say you should take everything anyone with more experience says at blind faith, simply that dismissing without understanding is counter to a growth mentality.
  - benesch 7y ago
    I invoked the personal experience only as evidence that I did what (little) I could to push along the project that I think has the most long term potential. I'm not criticizing without at least trying to do what I can. In short, the reasons gccgo produces worse code than gc are the result of fairly basic optimizations that are/were missing. For example, open-coding string slicing [0] and string equality [1] is enough to close the gap in the TimeParse benchmark in the blog post above. In fact, with those changes, gccgo actually produces better code than gc, because the full power of GCC can be unleashed on the IR, and GCC has more aggressive optimizations than gc. > This isn't to say you should take everything anyone with more experience says at blind faith, simply that dismissing without understanding is counter to a growth mentality. Quite honestly, I think you're more guilty of dismissing without understanding than I am. It's true that I haven't been programming for decades, but I've spent two years dealing with the Go toolchain's shortcomings on a large Go project, and six weeks specifically on a passion project to improve gccgo. Of course it's possible that I'm wrong! But I've spent a while thinking about it, and often just as relevant as experience is a fresh, outside perspective. It's easy for a team to get stuck in tunnel vision or groupthink. [0]: https://github.com/golang/gofrontend/commit/62e3a8cc0a862b0abd3d0b1ef6cf4b228992a137 https://github.com/golang/gofrontend/commit/62e3a8cc0a862b0a... [1]: https://github.com/golang/gofrontend/commit/89b442a0100286ee569b8d2562ce1b2ea602f7e7 https://github.com/golang/gofrontend/commit/89b442a0100286ee...

zeeboo 7y ago

Maybe you should trust the judgement of the highly-qualified engineers then when they decided to go with their own toolchain, and not just assume that they’re doing it because plan 9 or some other vacuous reason.

apta 7y ago
The same people who created a language with poor design decisions where superior solutions existed in other languages they could have simply used?
- hu3 7y ago
  What you vaguely label as poor design decisions are actually trade-offs and they make sense to a plethora of highly educated engineers.
  - apta 7y ago
    The people who made golang are not language designers, and/or did not research established options in other language as per their admittance.
    - pjmlp 7y ago
      Just like when C came around and everyone else was doing safe system programming in Algol dialects, PL/I, Fortran extensions, BLISS, Mesa. I see a trend here.
    - foldr 7y ago
      >The people who made golang are not language designers, I bet they've designed and executed on more programming languages than you have :)
      - apta 7y ago
        That's not an argument.
    - 7y ago

jbarham 7y ago

> Right, you need to specifically throw money and people at the problem of making LLVM faster I repeat, Apple is the major sponsor of LLVM and is sitting on ~$250 billion in cash. If LLVM could be made significantly faster by simply throwing money at it, presumably this has also occurred to Apple management. I can't believe they're not doing it because it doesn't align with their marketing pitch.

hollerith 7y ago
Apple embraced LLVM because Apple's lawyers are scared of version 3 of the GPL and consequently of GCC, and they need something to compile Objective C. That is different from a belief that making LLVM better is worth management's attention or a slice of Apple's budget once it proved a satisfactory replacement for GCC.

renox 7y ago

If memory serves, AMD switched to a different compiler to reduce compilation time of the shaders, so reducing LLVM compilation time doesn't seem easy..