4 ms·

>we started by opening up GCC and I was astonished at just how mindbogglingly complex it had become It's the price of being good ;)

monocasa 7y ago
Well, and just being ancient. LLVM is good too, but a lot cleaner. For instance (from GCC's docs): > Reload is the GCC equivalent of Satan. See [gccsource:reload.c], [gccsource:reload1.c], and [gccsource:reload.h] if you have a brave soul. https://gcc.gnu.org/wiki/reload https://gcc.gnu.org/wiki/reload
- andrepd 7y ago
  AFAIK, gcc still circles around clang.
  - gameswithgo 7y ago
    No. Each compiler has its own set of strengths and weaknesses, which is probably why for any of the big 3 (4 if you count intel?) compilers there are people who think one is the best. Whatever circle of internet people I happen to see a lot all think MSVC is terrible for instance, but the one really low level project I happened to work on, it produced the best code for it. I wouldn't say any of the compilers runs circles around another in general There is also a tendency for, whatever compiler you used mainly while developing your thing, it appears the best since you have been tweaking for that target the whole time.
    - blackflame7000 7y ago
      It would be pretty hard to say objectively that MSVC is terrible without knowing what's in it.
      - tempo33 7y ago
        No. You can evaluate compiler speed, memory use, quality of error output, generated code quality, ie most of what anyone cares about without knowing what's in it.
        fao_ 7y ago
        No. All optimizations have tradeoffs, if you don't know what it's doing then you cannot know the tradeoffs made. Empirical black-box testing works to a degree, past which it only gives false assurance, as it would in this case.
        raverbashing 7y ago
        But you can know what's doing. Just have it output the .s/.asm file You can also look at the flags and the different optimizations you can turn on and off. MSVC had some issues with C++ compatibility (a long time ago) but overall it is not bad. A compiler that can compile a whole operating system probably has most of its issues ironed out.
        fao_ 7y ago
        > But you can know what's doing. Just have it output the .s/.asm file That's still black box testing. There ~may be~ almost certainly is hidden state that could mean that the optimization you expect to be applied is not (or an optimization is misapplied) under certain circumstances, and you can't/won't discover this in advance due to those conditions. > A compiler that can compile a whole operating system probably has most of its issues ironed out. History has shown this to be mostly wrong, given how many critical bugs have been discovered in GCC since it was capable of compiling linux
        blackflame7000 7y ago
        On what code? Any code you pick is an arbitrary benchmark. There are infinite number of context free grammars you could feed the compiler and for any of them in might make some unknown optimization X that is superior to all other compilers. The number of programs that you can write are infinite therefore you cannot say for certain that is better or worse for all programs, or in other words, objectively say it is terrible.
  - musicale 7y ago
    g++ drove me insane with its baroque error messages, but clang++ did not. However, I hear that g++ has improved.
    - LukeShu 7y ago
      I avoid C++ and stay in straight C as much as I can. GCC's C error messages have definitely improved in response to clang (especially around deep preprocessor stuff). I had assumed that the C++ messages had likewise improved, and thought that I had heard that as well. Then I actually had to test that working on Envoy proxy. I was disappointed to get utterly incomprehensible error messages. I'm "GCC-by-default", so a coworker suggested I try switching to clang++... and sure enough, clang++ gave me decent error messages.
    - srean 7y ago
      Yes and yes. I have seen g++ error messages especially template related ones from being horrendously inscrutable to at par with, and now better than clang. Of course this my subjective judgement. One area where i have found g++ to shine over clang is explaining the vectorization choices it makes -- great for understanding why a loop did not get simd'ed. Competition has definitely served us well
  - pertymcpert 7y ago
    Nope. It's not 2010 anymore.
- rvp-x 7y ago
  they can remove reload tonight and most of HN wouldn't have a reason to care, but it'd hurt some old architectures. I personally tried to convert one of them but damn is it hard. bring out all the bugs!
SomeOldThrow 7y ago
GCC was also designed to make it very difficult to modularize on purpose, I believe, when copyleft was still in its infancy. https://gcc.gnu.org/ml/gcc/2007-11/msg00460.html https://gcc.gnu.org/ml/gcc/2007-11/msg00460.html https://gcc.gnu.org/ml/gcc/2004-12/msg00888.html https://gcc.gnu.org/ml/gcc/2004-12/msg00888.html In retrospect I agree more and more with stallman that perhaps we should be actively avoiding helping to build proprietary software, but the tactic they used failed badly, hurt the quality of the software, and turned away prospective contributors such as myself.
mhh__ 7y ago
With GCC it's more of a price of being old and good. LLVM is a lot cleaner (and they are basically even in terms of 1* benchmarks)
squarefoot 7y ago
"It's the price of being good ;) " Not to mention producing code for a huge list of architectures.
im3w1l 7y ago
I wouldn't be too sure of that. I remember reading libc source and thinking "wow this is so complex it must be written by geniuses and be really well optimized". Only years later did I hear that a lot of it is shitty for pretty much no reason and there is a lot of low hanging fruit to pick. I mean gcc is really advanced and it does work very well. But if there is something that intuitively seems bad in there I wouldn't assume it's that way for a really deep reason beyond my comprehension.

monocasa 7y ago

Well, and just being ancient. LLVM is good too, but a lot cleaner. For instance (from GCC's docs): > Reload is the GCC equivalent of Satan. See [gccsource:reload.c], [gccsource:reload1.c], and [gccsource:reload.h] if you have a brave soul. https://gcc.gnu.org/wiki/reload https://gcc.gnu.org/wiki/reload

andrepd 7y ago
AFAIK, gcc still circles around clang.
- gameswithgo 7y ago
  No. Each compiler has its own set of strengths and weaknesses, which is probably why for any of the big 3 (4 if you count intel?) compilers there are people who think one is the best. Whatever circle of internet people I happen to see a lot all think MSVC is terrible for instance, but the one really low level project I happened to work on, it produced the best code for it. I wouldn't say any of the compilers runs circles around another in general There is also a tendency for, whatever compiler you used mainly while developing your thing, it appears the best since you have been tweaking for that target the whole time.
  - blackflame7000 7y ago
    It would be pretty hard to say objectively that MSVC is terrible without knowing what's in it.
    - tempo33 7y ago
      No. You can evaluate compiler speed, memory use, quality of error output, generated code quality, ie most of what anyone cares about without knowing what's in it.
      - fao_ 7y ago
        No. All optimizations have tradeoffs, if you don't know what it's doing then you cannot know the tradeoffs made. Empirical black-box testing works to a degree, past which it only gives false assurance, as it would in this case.
        raverbashing 7y ago
        But you can know what's doing. Just have it output the .s/.asm file You can also look at the flags and the different optimizations you can turn on and off. MSVC had some issues with C++ compatibility (a long time ago) but overall it is not bad. A compiler that can compile a whole operating system probably has most of its issues ironed out.
        fao_ 7y ago
        > But you can know what's doing. Just have it output the .s/.asm file That's still black box testing. There ~may be~ almost certainly is hidden state that could mean that the optimization you expect to be applied is not (or an optimization is misapplied) under certain circumstances, and you can't/won't discover this in advance due to those conditions. > A compiler that can compile a whole operating system probably has most of its issues ironed out. History has shown this to be mostly wrong, given how many critical bugs have been discovered in GCC since it was capable of compiling linux
      - blackflame7000 7y ago
        On what code? Any code you pick is an arbitrary benchmark. There are infinite number of context free grammars you could feed the compiler and for any of them in might make some unknown optimization X that is superior to all other compilers. The number of programs that you can write are infinite therefore you cannot say for certain that is better or worse for all programs, or in other words, objectively say it is terrible.
- musicale 7y ago
  g++ drove me insane with its baroque error messages, but clang++ did not. However, I hear that g++ has improved.
  - LukeShu 7y ago
    I avoid C++ and stay in straight C as much as I can. GCC's C error messages have definitely improved in response to clang (especially around deep preprocessor stuff). I had assumed that the C++ messages had likewise improved, and thought that I had heard that as well. Then I actually had to test that working on Envoy proxy. I was disappointed to get utterly incomprehensible error messages. I'm "GCC-by-default", so a coworker suggested I try switching to clang++... and sure enough, clang++ gave me decent error messages.
  - srean 7y ago
    Yes and yes. I have seen g++ error messages especially template related ones from being horrendously inscrutable to at par with, and now better than clang. Of course this my subjective judgement. One area where i have found g++ to shine over clang is explaining the vectorization choices it makes -- great for understanding why a loop did not get simd'ed. Competition has definitely served us well
- pertymcpert 7y ago
  Nope. It's not 2010 anymore.
rvp-x 7y ago
they can remove reload tonight and most of HN wouldn't have a reason to care, but it'd hurt some old architectures. I personally tried to convert one of them but damn is it hard. bring out all the bugs!

SomeOldThrow 7y ago

GCC was also designed to make it very difficult to modularize on purpose, I believe, when copyleft was still in its infancy. https://gcc.gnu.org/ml/gcc/2007-11/msg00460.html https://gcc.gnu.org/ml/gcc/2007-11/msg00460.html https://gcc.gnu.org/ml/gcc/2004-12/msg00888.html https://gcc.gnu.org/ml/gcc/2004-12/msg00888.html In retrospect I agree more and more with stallman that perhaps we should be actively avoiding helping to build proprietary software, but the tactic they used failed badly, hurt the quality of the software, and turned away prospective contributors such as myself.

mhh__ 7y ago

With GCC it's more of a price of being old and good. LLVM is a lot cleaner (and they are basically even in terms of 1* benchmarks)

squarefoot 7y ago

"It's the price of being good ;) " Not to mention producing code for a huge list of architectures.

im3w1l 7y ago

I wouldn't be too sure of that. I remember reading libc source and thinking "wow this is so complex it must be written by geniuses and be really well optimized". Only years later did I hear that a lot of it is shitty for pretty much no reason and there is a lot of low hanging fruit to pick. I mean gcc is really advanced and it does work very well. But if there is something that intuitively seems bad in there I wouldn't assume it's that way for a really deep reason beyond my comprehension.