5 ms·

Why didn't they use LLVM?

saagarjha 7y ago
Does https://golang.org/doc/faq#What_compiler_technology_is_used_to_build_the_compilers https://golang.org/doc/faq#What_compiler_technology_is_used_... answer your question (I interpreted it as "why doesn't the Go compiler use LLVM?")?
edflsafoiewq 7y ago
LLVM is very slow.
- kspp 7y ago
  It seems to be fast enough for SQL JIT-compiler in PostgreSQL 11+ and shader compilation in the *nix OpenGL stack (mesa), both of which are sort-of-realtime systems.
  - sanxiyn 7y ago
    There is an ongoing work to move Mesa away from LLVM because LLVM is slow.
  - vkazanov 7y ago
    Can't say anything about shaders but I do know a thing or two about database queries: 1. Queries are often repeated, i.e. most of backend DBs get the same requests over and over again. Even a slow jit compiler is fine here as things just get cached. 2. Queries usually take some time to complete, and this offsets the jit-related latency. Also, Postgres has a very limited kind of jit compilation, i.e. for expressions only. Notice that javascript jit compilers usually have a multi-tiered compilation. That's because proper compilation takes time, and sometimes it is more efficient to just do some basic template jiting (or no additional compilation) instead of firing the heavy guns. None of them use LLVM, btw.
    - simias 7y ago
      I'm not sure I follow your reasoning, Go isn't JITed, is it?
      - pjmlp 7y ago
        Language != Implementation. And yes, there are Go interpreters as well. https://github.com/go-interpreter https://github.com/go-interpreter
  - saturn_vk 7y ago
    Valve doesn't think so: https://steamcommunity.com/games/221410/announcements/detail/1602634609636894200 https://steamcommunity.com/games/221410/announcements/detail...
  - deleted 7y ago
    [deleted]
  - eatonphil 7y ago
    Another HN thread on projects that found LLVM to be slow. https://news.ycombinator.com/item?id=16956589 https://news.ycombinator.com/item?id=16956589
    - kspp 7y ago
      That's the best way to learn — post a stupid thing on the internet and let the internet prove you wrong. Thanks to everyone who replied!
  - azakai 7y ago
    SQL queries and GL shaders tend to be much shorter than a typical program. There are exceptions of course, but it's rare to find shaders with thousands of lines of code or more.
  - nicoburns 7y ago
    Rust compilation is slow, and a large part of that is due to the use of LLVM.
    - jashmatthews 7y ago
      LLVM is slow but swapping for CraneLift only improves compile times 33%. Other work is needed for a dramatic reduction in compile times: https://github.com/bjorn3/rustc_codegen_cranelift/issues/133#issuecomment-439475172 https://github.com/bjorn3/rustc_codegen_cranelift/issues/133...
- ajkjk 7y ago
  it is?
deleted 7y ago
[deleted]
pjmlp 7y ago
Because it is good to have options, and we don't need compiler monocultures.
- mhh__ 7y ago
  That's not a huge problem now that we have GCC and LLVM. The real issue is that the generic-ness, and optimisations, of them makes them pretty damn slow for non-performance critical code. Writing a basic backend isn't a huge project for a language backed as thoroughly as Go. D, for example, has a non-GCC/LLVM backend which isn't as fast but still does some advanced optimisations (but compiles at warp speed)
m_sahaf 7y ago
This has been answered twice[0] by Russ Cox himself[1]. Some of the reasons were familiarity and the need for segmented stacks, but he goes more on the details in his comments. [0] https://news.ycombinator.com/item?id=8817990 https://news.ycombinator.com/item?id=8817990 [1] https://news.ycombinator.com/item?id=1509700 https://news.ycombinator.com/item?id=1509700

Does https://golang.org/doc/faq#What_compiler_technology_is_used_to_build_the_compilers https://golang.org/doc/faq#What_compiler_technology_is_used_... answer your question (I interpreted it as "why doesn't the Go compiler use LLVM?")?

edflsafoiewq 7y ago

LLVM is very slow.

kspp 7y ago
It seems to be fast enough for SQL JIT-compiler in PostgreSQL 11+ and shader compilation in the *nix OpenGL stack (mesa), both of which are sort-of-realtime systems.
- sanxiyn 7y ago
  There is an ongoing work to move Mesa away from LLVM because LLVM is slow.
- vkazanov 7y ago
  Can't say anything about shaders but I do know a thing or two about database queries: 1. Queries are often repeated, i.e. most of backend DBs get the same requests over and over again. Even a slow jit compiler is fine here as things just get cached. 2. Queries usually take some time to complete, and this offsets the jit-related latency. Also, Postgres has a very limited kind of jit compilation, i.e. for expressions only. Notice that javascript jit compilers usually have a multi-tiered compilation. That's because proper compilation takes time, and sometimes it is more efficient to just do some basic template jiting (or no additional compilation) instead of firing the heavy guns. None of them use LLVM, btw.
  - simias 7y ago
    I'm not sure I follow your reasoning, Go isn't JITed, is it?
    - pjmlp 7y ago
      Language != Implementation. And yes, there are Go interpreters as well. https://github.com/go-interpreter https://github.com/go-interpreter
- saturn_vk 7y ago
  Valve doesn't think so: https://steamcommunity.com/games/221410/announcements/detail/1602634609636894200 https://steamcommunity.com/games/221410/announcements/detail...
- deleted 7y ago
  [deleted]
- eatonphil 7y ago
  Another HN thread on projects that found LLVM to be slow. https://news.ycombinator.com/item?id=16956589 https://news.ycombinator.com/item?id=16956589
  - kspp 7y ago
    That's the best way to learn — post a stupid thing on the internet and let the internet prove you wrong. Thanks to everyone who replied!
- azakai 7y ago
  SQL queries and GL shaders tend to be much shorter than a typical program. There are exceptions of course, but it's rare to find shaders with thousands of lines of code or more.
- nicoburns 7y ago
  Rust compilation is slow, and a large part of that is due to the use of LLVM.
  - jashmatthews 7y ago
    LLVM is slow but swapping for CraneLift only improves compile times 33%. Other work is needed for a dramatic reduction in compile times: https://github.com/bjorn3/rustc_codegen_cranelift/issues/133#issuecomment-439475172 https://github.com/bjorn3/rustc_codegen_cranelift/issues/133...
ajkjk 7y ago
it is?

deleted 7y ago

[deleted]

pjmlp 7y ago

Because it is good to have options, and we don't need compiler monocultures.

mhh__ 7y ago
That's not a huge problem now that we have GCC and LLVM. The real issue is that the generic-ness, and optimisations, of them makes them pretty damn slow for non-performance critical code. Writing a basic backend isn't a huge project for a language backed as thoroughly as Go. D, for example, has a non-GCC/LLVM backend which isn't as fast but still does some advanced optimisations (but compiles at warp speed)

m_sahaf 7y ago

This has been answered twice[0] by Russ Cox himself[1]. Some of the reasons were familiarity and the need for segmented stacks, but he goes more on the details in his comments. [0] https://news.ycombinator.com/item?id=8817990 https://news.ycombinator.com/item?id=8817990 [1] https://news.ycombinator.com/item?id=1509700 https://news.ycombinator.com/item?id=1509700