7 ms·

i do wonder why they didn't go with llvm...

by jheriko 11y ago

dantillberg 11y ago
Russ Cox shared his thoughts on this a while back: https://news.ycombinator.com/item?id=8817990 https://news.ycombinator.com/item?id=8817990
tomp 11y ago
It's answered in the post: A common question that comes up is “why not just convert to the IR of {llvm,gcc,...} and go from there?” I think there are 3 major reasons: - Compiler speed. I intend our SSA IR, and the optimizer passes implemented on top of that IR, to be fast by design. We’ll aim for linear-time algorithms wherever possible. The backends of other possible compilers weren’t really designed with fast compile speed in mind. - Runtime information. The runtime needs accurate maps of stack frames for both GC and stack copying, something that is not available from standard backends today. - An additional dependence. Do we want a {llvm,gcc,...} backend as a prerequisite for building Go? (Note that this would only be an issue for those developing Go, not those writing Go programs.) I’m happy to be convinced otherwise - maybe we should throw our effort into getting frame maps out of {llvm,gcc,...} and figuring out how to configure the backend (e.g. which optimizations to turn on) to make it compile quickly.
- DannyBee 11y ago
  Note, for the record, none of these are correct except for the last one: 1. LLVM's SSA based compiler currently uses more linear time algorithms than Go's SSA backend (IE phi placement, etc), and in more places. So yeah. While parts of LLVM definitely could be sped up (particularly the backend), it was originally designed with fast compile speed in mind, just like go! Given how many years it's taken so far, you easily could have gotten the same thing out of LLVM. Would it have been more work? Probably, but not much. Are the other reasons not to do it? Yes. But the idea that their compiler is somehow the only one designed with fast compile time in mind is, honestly, pretty arrogant 2. Stack maps have been supported for quite a while, and statepoint support now exists and is used by real people in real places. But i'll also just point out he's never actually asked, or talked to the LLVM folks about it (search the mailing list, see if you can find any mail about it). Note: I honestly don't care whether they write their own compiler or not. I suspect it's better for them to do it because of the community they want to build, because of how much control they want over their toolchain, etc. But i'm not a fan of saying "someone else's infrastructure sucks, so we are doing it", when 1. That's not the real reason as far as i can tell 2. People are using, in production, the very things they claim don't exist (and they've been told this, it turns out) 3. Answers about linear time algorithms are honestly just BS.
  - danieldk 11y ago
    Agreed. Though another argument in favor was not cited: the SSA backend is in Go, so that means that anyone who knows Go can also hack on the SSA backend. With LLVM, they would have to know Go's internals and C++. Of course, there is also gccgo and llgo, so once the SSA backend is in stable Go, useful comparisons can be made.
    - disposeofnick9 11y ago
      Using llvm might introduce a dependency, but it also gives all the LLVM advantages/disadvantages across platforms for "free" (some work, fewer reinvented wheels) and more toolchain utilities.
    - jheriko 11y ago
      i think that this is a gimmick rather than a reason. languages that have their own tools built with themselves are cool... but it has zero practical value imo. the number of C/C++ programmers interested in Go and capable of contributing meaningfully far outweighs the number of programmers who do not know C/C++ and are interested in Go
  - wyldfire 11y ago
    Is "Stack maps" the same as "segmented stacks" that Mr Cox refers to?
    - riscy 11y ago
      No, stack maps provide information about each stack frame (typically using the return instruction pointer left in that frame) to allow for the garbage collector to determine what is a pointer or not in that frame.
    - DannyBee 11y ago
      Segmented stacks are basically what safestack offers, and that is also something llvm does :)
      - 11y ago
- naasking 11y ago
  > - Runtime information. The runtime needs accurate maps of stack frames for both GC and stack copying, something that is not available from standard backends today. DannyBee addressed most of these points, however I just wanted to note that even if LLVM didn't provide stack maps, it's easy to recover stack information using lazy pointer stacks [1] [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158.9799 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158....
- jheriko 11y ago
  sorry i missed your reply at the time, but DannyBee's comment is very close to what i would have said in response thankfully. :)

i do wonder why they didn't go with llvm...

by jheriko 11y ago

i do wonder why they didn't go with llvm...

Russ Cox shared his thoughts on this a while back: https://news.ycombinator.com/item?id=8817990 https://news.ycombinator.com/item?id=8817990

tomp 11y ago

It's answered in the post: A common question that comes up is “why not just convert to the IR of {llvm,gcc,...} and go from there?” I think there are 3 major reasons: - Compiler speed. I intend our SSA IR, and the optimizer passes implemented on top of that IR, to be fast by design. We’ll aim for linear-time algorithms wherever possible. The backends of other possible compilers weren’t really designed with fast compile speed in mind. - Runtime information. The runtime needs accurate maps of stack frames for both GC and stack copying, something that is not available from standard backends today. - An additional dependence. Do we want a {llvm,gcc,...} backend as a prerequisite for building Go? (Note that this would only be an issue for those developing Go, not those writing Go programs.) I’m happy to be convinced otherwise - maybe we should throw our effort into getting frame maps out of {llvm,gcc,...} and figuring out how to configure the backend (e.g. which optimizations to turn on) to make it compile quickly.

DannyBee 11y ago
Note, for the record, none of these are correct except for the last one: 1. LLVM's SSA based compiler currently uses more linear time algorithms than Go's SSA backend (IE phi placement, etc), and in more places. So yeah. While parts of LLVM definitely could be sped up (particularly the backend), it was originally designed with fast compile speed in mind, just like go! Given how many years it's taken so far, you easily could have gotten the same thing out of LLVM. Would it have been more work? Probably, but not much. Are the other reasons not to do it? Yes. But the idea that their compiler is somehow the only one designed with fast compile time in mind is, honestly, pretty arrogant 2. Stack maps have been supported for quite a while, and statepoint support now exists and is used by real people in real places. But i'll also just point out he's never actually asked, or talked to the LLVM folks about it (search the mailing list, see if you can find any mail about it). Note: I honestly don't care whether they write their own compiler or not. I suspect it's better for them to do it because of the community they want to build, because of how much control they want over their toolchain, etc. But i'm not a fan of saying "someone else's infrastructure sucks, so we are doing it", when 1. That's not the real reason as far as i can tell 2. People are using, in production, the very things they claim don't exist (and they've been told this, it turns out) 3. Answers about linear time algorithms are honestly just BS.
- danieldk 11y ago
  Agreed. Though another argument in favor was not cited: the SSA backend is in Go, so that means that anyone who knows Go can also hack on the SSA backend. With LLVM, they would have to know Go's internals and C++. Of course, there is also gccgo and llgo, so once the SSA backend is in stable Go, useful comparisons can be made.
  - disposeofnick9 11y ago
    Using llvm might introduce a dependency, but it also gives all the LLVM advantages/disadvantages across platforms for "free" (some work, fewer reinvented wheels) and more toolchain utilities.
  - jheriko 11y ago
    i think that this is a gimmick rather than a reason. languages that have their own tools built with themselves are cool... but it has zero practical value imo. the number of C/C++ programmers interested in Go and capable of contributing meaningfully far outweighs the number of programmers who do not know C/C++ and are interested in Go
- wyldfire 11y ago
  Is "Stack maps" the same as "segmented stacks" that Mr Cox refers to?
  - riscy 11y ago
    No, stack maps provide information about each stack frame (typically using the return instruction pointer left in that frame) to allow for the garbage collector to determine what is a pointer or not in that frame.
  - DannyBee 11y ago
    Segmented stacks are basically what safestack offers, and that is also something llvm does :)
    - 11y ago
naasking 11y ago
> - Runtime information. The runtime needs accurate maps of stack frames for both GC and stack copying, something that is not available from standard backends today. DannyBee addressed most of these points, however I just wanted to note that even if LLVM didn't provide stack maps, it's easy to recover stack information using lazy pointer stacks [1] [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158.9799 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158....
jheriko 11y ago
sorry i missed your reply at the time, but DannyBee's comment is very close to what i would have said in response thankfully. :)