5 ms·

> I urge everyone in power regarding this issue to think this through -- and then, make your simple compiler which we can build into a trusted component FREE, o

by Pyxl101 11y ago

> I urge everyone in power regarding this issue to think this through -- and then, make your simple compiler which we can build into a trusted component FREE, or, if you don't, sometime in the next few years something else which is simple and matches it in power, can and might and probably will show up (because it is clear the gnu bloat compiler will never achieve such a goal...) Looks like Theo correctly predicted the advent of clang. Related: http://www.quora.com/Compilers/Why-did-Apple-create-Clang http://www.quora.com/Compilers/Why-did-Apple-create-Clang

cwzwarich 11y ago
Clang is dramatically more complex than the Plan 9 compiler, and doesn't really qualify for satisfying Theo's prediction.
- Flow 11y ago
  Maybe that is because clang supports much more than plain C? Also, they have set a very ambitious goal with the friendly error messages for C++.
  - ben_bai 11y ago
    Just linking libclang.so (newest svn version) takes over 8GB of memory. How much more you ask? Well we will find out when i got more ram. So i don't see that compiler becoming a gcc replacement in OpenBSD anytime soon.
    - batou 11y ago
      I think something that requires 8Gb memory to run the linker has a bug.
      - rockdoe 11y ago
        The memory use at the "link step" is so high because due to whole-program optimization, that's the point where everything actually compiles. It used to be fairly typical for large C++ applications. Chromium and Firefox had problems with it before GCC got fixed. Sounds like clang still has work to do there.
        batou 11y ago
        I completely agree but my point is more that the compiler shouldn't be that large even whilst linking and doing whole program optimisation. Proportionately to the size of the output binary the overhead is unreasonably large. Firefox and Chrome for example are problematic due to the architecture. I've built modular applications which compile smaller units (.so's) that are runtime linked using dlopen() etc. Not quite the same scale but this was in a time when the kit was a lot slower. I'd like to see a return to a simpler time. We can afford to lose some of the optimisations now and produce clean, simple, fast and predictable compilers. I think Roslyn/RyuJIT on the .Net platform is an example of where this all falls apart: bad tail call optimisation leads to non-determinism in parameter passing. If the compiler consists of lots of code then there are lots of bugs and you can't afford bugs there.
        mcguire 11y ago
        Can I interest you in the original Plan 9 compilers? Their source should be around somewhere and they don't do much in the way of optimization, if any, so they shouldn't any giant memory use problems.
        batou 11y ago
        You can indeed. Are they the ones that shipped with the original Go as well?
        bkeroack 11y ago
        My understanding is that the original C toolchain in Go (only recently removed in 1.5) was based heavily on the Plan 9 compilers. In fact there was a rather inflammatory blog post[1] whose basic theme was that "Golang is trash" because the toolchain was so simple. One of the main Go developers then responded[2] on HN. Different people value different things I suppose. 1. http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/ http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/ 2. https://news.ycombinator.com/item?id=8817990 https://news.ycombinator.com/item?id=8817990
        11y ago
      - dumael 11y ago
        Linking several hundred objects in a dozen or so libaries out of 2.5kish objects together is going to get hairily expensive memory wise no matter what way you do it. Compiling with debug information embedded raises that to around 12GB to do it in a practical timeframe, though it may have dropped recently with some tweaks that have been published on llvmdev. Unless you've willing to wait a few hours. GCC is no slouch in that area either but its usage spikes feel lower. (Source: compiler dev)
    - rasz_pl 11y ago
      wow, whole $40 in memory?
      - justin66 11y ago
        You're trolling, but the thing a lot of people might not realize is that OpenBSD builds are done on the hardware. Each platform is capable of building itself and that's how they operate. I'm not aware of any exceptions.
justincormack 11y ago
OpenBSD is still using their patched old version of gcc, and they are still looking for another solution.
- batou 11y ago
  Didn't they look at PCC as well? No idea what happened to that.
  - justincormack 11y ago
    They did, they seemed to have ruled it out. It doesnt support all their platforms yet, and development is fairly slow (small community, but growing). NetBSD (which supports clang or gcc because portability and choice) supports it but it cannot yet compile all the kernel for any architecture, so bits are marked to be compiled with gcc if you select pcc. It would be nice if all of kernel plus (non C++) userspace worked...
    - batou 11y ago
      Interesting. Thanks for the detailed reply.

by Pyxl101 11y ago

cwzwarich 11y ago

Clang is dramatically more complex than the Plan 9 compiler, and doesn't really qualify for satisfying Theo's prediction.

Flow 11y ago
Maybe that is because clang supports much more than plain C? Also, they have set a very ambitious goal with the friendly error messages for C++.
- ben_bai 11y ago
  Just linking libclang.so (newest svn version) takes over 8GB of memory. How much more you ask? Well we will find out when i got more ram. So i don't see that compiler becoming a gcc replacement in OpenBSD anytime soon.
  - batou 11y ago
    I think something that requires 8Gb memory to run the linker has a bug.
    - rockdoe 11y ago
      The memory use at the "link step" is so high because due to whole-program optimization, that's the point where everything actually compiles. It used to be fairly typical for large C++ applications. Chromium and Firefox had problems with it before GCC got fixed. Sounds like clang still has work to do there.
      - batou 11y ago
        I completely agree but my point is more that the compiler shouldn't be that large even whilst linking and doing whole program optimisation. Proportionately to the size of the output binary the overhead is unreasonably large. Firefox and Chrome for example are problematic due to the architecture. I've built modular applications which compile smaller units (.so's) that are runtime linked using dlopen() etc. Not quite the same scale but this was in a time when the kit was a lot slower. I'd like to see a return to a simpler time. We can afford to lose some of the optimisations now and produce clean, simple, fast and predictable compilers. I think Roslyn/RyuJIT on the .Net platform is an example of where this all falls apart: bad tail call optimisation leads to non-determinism in parameter passing. If the compiler consists of lots of code then there are lots of bugs and you can't afford bugs there.
        mcguire 11y ago
        Can I interest you in the original Plan 9 compilers? Their source should be around somewhere and they don't do much in the way of optimization, if any, so they shouldn't any giant memory use problems.
        batou 11y ago
        You can indeed. Are they the ones that shipped with the original Go as well?
        bkeroack 11y ago
        My understanding is that the original C toolchain in Go (only recently removed in 1.5) was based heavily on the Plan 9 compilers. In fact there was a rather inflammatory blog post[1] whose basic theme was that "Golang is trash" because the toolchain was so simple. One of the main Go developers then responded[2] on HN. Different people value different things I suppose. 1. http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/ http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/ 2. https://news.ycombinator.com/item?id=8817990 https://news.ycombinator.com/item?id=8817990
        11y ago
    - dumael 11y ago
      Linking several hundred objects in a dozen or so libaries out of 2.5kish objects together is going to get hairily expensive memory wise no matter what way you do it. Compiling with debug information embedded raises that to around 12GB to do it in a practical timeframe, though it may have dropped recently with some tweaks that have been published on llvmdev. Unless you've willing to wait a few hours. GCC is no slouch in that area either but its usage spikes feel lower. (Source: compiler dev)
  - rasz_pl 11y ago
    wow, whole $40 in memory?
    - justin66 11y ago
      You're trolling, but the thing a lot of people might not realize is that OpenBSD builds are done on the hardware. Each platform is capable of building itself and that's how they operate. I'm not aware of any exceptions.

justincormack 11y ago

OpenBSD is still using their patched old version of gcc, and they are still looking for another solution.

batou 11y ago
Didn't they look at PCC as well? No idea what happened to that.
- justincormack 11y ago
  They did, they seemed to have ruled it out. It doesnt support all their platforms yet, and development is fairly slow (small community, but growing). NetBSD (which supports clang or gcc because portability and choice) supports it but it cannot yet compile all the kernel for any architecture, so bits are marked to be compiled with gcc if you select pcc. It would be nice if all of kernel plus (non C++) userspace worked...
  - batou 11y ago
    Interesting. Thanks for the detailed reply.