7 ms·

That depends on what you are comparing to. Both GCC and Clang are very slow compared to, say, the Go standard compiler. However, comparing compilation speed ac

That depends on what you are comparing to. Both GCC and Clang are very slow compared to, say, the Go standard compiler. However, comparing compilation speed across languages and compiler implementations is a bit difficult.

banachtarski 9y ago
They also do a lot more work.
- arghwhat 9y ago
  That really depends on your definition of "work". They certainly spend more clock cycles and produce more heat. They might have some more comprehensive optimization passes eating extensive cycles, but even rustc debug builds are extremely slow in comparison to the Go standard compiler.
  - jerf 9y ago
    I'm not sure what a definition of "work" would look like where the Go compiler is doing as much "work" as the Rust compiler, but I expect it would be extraordinarily contrived. Go deliberately prioritizes compiler speed, and definitely skips complex optimizations that Rust or LLVM do, and Go is just generally simpler to compile, because the compiler will do nothing even remotely resembling the borrow checker, nor does it have complex types, and so on. (One of my benchmarks for "Go has really made it" is when someone starts selling an optimized Go compiler that does the expensive optimizations. You could still ideally use the standard Go compiler to develop, but then you'd test and deploy with the slow optimized compiler.)
    - foldr 9y ago
      >Go deliberately prioritizes compiler speed, and definitely skips complex optimizations that Rust or LLVM do As the OP pointed out, Rust debug builds are still much slower than Go builds, so lack of optimizations can't be a big part of the story. The simplicity of the language and the deliberate design of the compiler for speed seem to be the main factors.
      - jerf 9y ago
        You should have added the next bit after where you cut the quote off, which was "and Go is just generally simpler to compile, because the compiler will do nothing even remotely resembling the borrow checker, nor does it have complex types, and so on." I'm not claiming this is true by any means, but it wouldn't surprise me that much that merely the work to tell if a bit of Rust code in, say, Servo, is legal Rust in the presence of a rich type system and the borrow checker and all the other such things going on is more work than it would be to compile the roughly-equivalent Go module entirely. Compared to Rust, Go does not so much "cut corners" as cut entire dimensions out of the picture, and then cut some more corners for good measure.
        pcwalton 9y ago
        The Go compiler cuts out nearly all the optimization that LLVM does.
        foldr 9y ago
        I cut it off because I was only disagreeing with the bit before the 'and'. Indeed, Rust is a more complex language and it is not surprising that it would take longer to compile. Although, as another poster pointed out, Go code also compiles much faster than plain C code (with gcc or clang), and C is of a similar order of complexity to Go.
    - gameswithgo 9y ago
      gccgo
      - jerf 9y ago
        If you are implying that it is the "optimizing compiler" I mentioned, I have not seen good performance numbers that show it as being any better than the official Go compiler. Were I going to start the company to produce the compiler, the question of "why isn't gccgo about 2x faster than Go?" is one of the first I'd examine, though. I personally have zero idea what the answer is. Or, indeed, if it's even still true. However, I am active enough in the Go community that if good benchmarks were going around I'd expect to have seen them. (They'd probably make it to HN.)
        arghwhat 9y ago
        I rarely hear much about gccgo than what I hear in the Go release notes (usually "gccgo is now feature complete at <old version>"). I wonder if it still uses the plain thread implementation of goroutines like it did early on (which provides quite different performance characteristics)? I am frankly too lazy to set up gccgo for comparisons again, but if I recall correctly, it takes considerably longer to compile whilst providing similar quality output. Thus, I would ask the opposite question that you presented: If gccgo isn't notably faster than gc, why is compilation so much slower? If one compiler spends more time generating identical quality output with an identical input language, it is hard to argue against the fact that there are wasted cycles at play. It may of course partly be due to an immature Go frontend. Who knows.
    - arghwhat 9y ago
      Complex optimizations do not apply to debug builds, so we are basically only comparing borrow checker and the likes. However, then we can draw on two facts to kill that this should be a significant part of the issue: The post states that for most projects, the majority of the compile time is spent in LLVM, not Rust. Second (my memory may fail me here, but this is easy to measure), for larger projects, Go also smoke clang/gcc, which do not have Rusts fancy features. But, as I stated in my parent comment, these cross-language, cross-compiler comparisons are quite difficult to make. This is also why I attack comments talking about one compiler doing more "work" than another. It cannot be directly compared. All we know for certain, is that rustc is far too slow for our liking.
  - coldtea 9y ago
    >They might have some more comprehensive optimization passes eating extensive cycles, but even rustc debug builds are extremely slow in comparison to the Go standard compiler. Work is not just the optimization. Having Rust track lifetimes and warn about ownership bugs, races, etc, is also productive work for the compiler -- and happens during the debug builds too.
    - arghwhat 9y ago
      The post mentions that the majority of the execution occurs in LLVM, especially for optimized builds. In other words, anything Rust related has to be a smaller part of the compile time. I stated in my parent comment that cross-language/cross-compiler comparisons is tricky exactly because of the vast differences in both frontends (lifetime tracking, warning generation) and backends (code generation, optimization). So yes, I know there are different amounts of work related with different languages. However, I believe the compile time differences significantly outweigh the compile time differences.
      - coldtea 9y ago
        >The post mentions that the majority of the execution occurs in LLVM, especially for optimized builds. In other words, anything Rust related has to be a smaller part of the compile time. A, true, by the time it hits LLVM Rust's lifetime's analysis has already happened...
      - arghwhat 9y ago
        I'm a retard. > However, I believe the compile time differences significantly outweigh the compile time differences. I meant to say "the compile time differences are significantly greater than the language-independent differences".
noelwelsh 9y ago
Right, but compilation performance is not a race in which you have to be first, but a minimum threshold that you must meet. Compilation just has to be fast enough that it doesn't annoy developers most of the time. Once you achieve that they'll mostly stop complaining. I believe Clang et al are fast enough. (This is true for performance and optimisation is general: fast enough is good enough.)
- arghwhat 9y ago
  Compiling larger projects, I certainly do not feel that Clang et.al. are fast enough. It takes minutes to compile stuff at work with 32 Xeon threads powering through at full load. Once it takes seconds, we can talk about "fast enough".
  - noelwelsh 9y ago
    Try using Scala :) Is that minutes for every compile, or for an (infrequent) full compile?
    - pdpi 9y ago
      Not the commenter you're responding to, but at my previous place I dealt with compile times of around 20 minutes from scratch, and 1-2 minutes incremental using Clang/LLVM, on a 20ish physical core Xeon with 128ish gigs of RAM.
      - noelwelsh 9y ago
        Ok, that is pretty slow.
        pdpi 9y ago
        Heavy use of templates does that to you :(.
  - iClaudiusX 9y ago
    Not to pick on you or the parent comment, but this is a such a common mistake that it's worth correcting. "Clang" is a thing not a person, therefore it's appropriate to use et cetera, not et alii. The former is for things, the latter for people (usually limited to authors of academic papers).
coldtea 9y ago
>Both GCC and Clang are very slow compared to, say, the Go standard compiler. Well, the Go standard compiler doesn't do much.

banachtarski 9y ago

They also do a lot more work.

arghwhat 9y ago
That really depends on your definition of "work". They certainly spend more clock cycles and produce more heat. They might have some more comprehensive optimization passes eating extensive cycles, but even rustc debug builds are extremely slow in comparison to the Go standard compiler.
- jerf 9y ago
  I'm not sure what a definition of "work" would look like where the Go compiler is doing as much "work" as the Rust compiler, but I expect it would be extraordinarily contrived. Go deliberately prioritizes compiler speed, and definitely skips complex optimizations that Rust or LLVM do, and Go is just generally simpler to compile, because the compiler will do nothing even remotely resembling the borrow checker, nor does it have complex types, and so on. (One of my benchmarks for "Go has really made it" is when someone starts selling an optimized Go compiler that does the expensive optimizations. You could still ideally use the standard Go compiler to develop, but then you'd test and deploy with the slow optimized compiler.)
  - foldr 9y ago
    >Go deliberately prioritizes compiler speed, and definitely skips complex optimizations that Rust or LLVM do As the OP pointed out, Rust debug builds are still much slower than Go builds, so lack of optimizations can't be a big part of the story. The simplicity of the language and the deliberate design of the compiler for speed seem to be the main factors.
    - jerf 9y ago
      You should have added the next bit after where you cut the quote off, which was "and Go is just generally simpler to compile, because the compiler will do nothing even remotely resembling the borrow checker, nor does it have complex types, and so on." I'm not claiming this is true by any means, but it wouldn't surprise me that much that merely the work to tell if a bit of Rust code in, say, Servo, is legal Rust in the presence of a rich type system and the borrow checker and all the other such things going on is more work than it would be to compile the roughly-equivalent Go module entirely. Compared to Rust, Go does not so much "cut corners" as cut entire dimensions out of the picture, and then cut some more corners for good measure.
      - pcwalton 9y ago
        The Go compiler cuts out nearly all the optimization that LLVM does.
      - foldr 9y ago
        I cut it off because I was only disagreeing with the bit before the 'and'. Indeed, Rust is a more complex language and it is not surprising that it would take longer to compile. Although, as another poster pointed out, Go code also compiles much faster than plain C code (with gcc or clang), and C is of a similar order of complexity to Go.
  - gameswithgo 9y ago
    gccgo
    - jerf 9y ago
      If you are implying that it is the "optimizing compiler" I mentioned, I have not seen good performance numbers that show it as being any better than the official Go compiler. Were I going to start the company to produce the compiler, the question of "why isn't gccgo about 2x faster than Go?" is one of the first I'd examine, though. I personally have zero idea what the answer is. Or, indeed, if it's even still true. However, I am active enough in the Go community that if good benchmarks were going around I'd expect to have seen them. (They'd probably make it to HN.)
      - arghwhat 9y ago
        I rarely hear much about gccgo than what I hear in the Go release notes (usually "gccgo is now feature complete at <old version>"). I wonder if it still uses the plain thread implementation of goroutines like it did early on (which provides quite different performance characteristics)? I am frankly too lazy to set up gccgo for comparisons again, but if I recall correctly, it takes considerably longer to compile whilst providing similar quality output. Thus, I would ask the opposite question that you presented: If gccgo isn't notably faster than gc, why is compilation so much slower? If one compiler spends more time generating identical quality output with an identical input language, it is hard to argue against the fact that there are wasted cycles at play. It may of course partly be due to an immature Go frontend. Who knows.
  - arghwhat 9y ago
    Complex optimizations do not apply to debug builds, so we are basically only comparing borrow checker and the likes. However, then we can draw on two facts to kill that this should be a significant part of the issue: The post states that for most projects, the majority of the compile time is spent in LLVM, not Rust. Second (my memory may fail me here, but this is easy to measure), for larger projects, Go also smoke clang/gcc, which do not have Rusts fancy features. But, as I stated in my parent comment, these cross-language, cross-compiler comparisons are quite difficult to make. This is also why I attack comments talking about one compiler doing more "work" than another. It cannot be directly compared. All we know for certain, is that rustc is far too slow for our liking.
- coldtea 9y ago
  >They might have some more comprehensive optimization passes eating extensive cycles, but even rustc debug builds are extremely slow in comparison to the Go standard compiler. Work is not just the optimization. Having Rust track lifetimes and warn about ownership bugs, races, etc, is also productive work for the compiler -- and happens during the debug builds too.
  - arghwhat 9y ago
    The post mentions that the majority of the execution occurs in LLVM, especially for optimized builds. In other words, anything Rust related has to be a smaller part of the compile time. I stated in my parent comment that cross-language/cross-compiler comparisons is tricky exactly because of the vast differences in both frontends (lifetime tracking, warning generation) and backends (code generation, optimization). So yes, I know there are different amounts of work related with different languages. However, I believe the compile time differences significantly outweigh the compile time differences.
    - coldtea 9y ago
      >The post mentions that the majority of the execution occurs in LLVM, especially for optimized builds. In other words, anything Rust related has to be a smaller part of the compile time. A, true, by the time it hits LLVM Rust's lifetime's analysis has already happened...
    - arghwhat 9y ago
      I'm a retard. > However, I believe the compile time differences significantly outweigh the compile time differences. I meant to say "the compile time differences are significantly greater than the language-independent differences".

noelwelsh 9y ago

Right, but compilation performance is not a race in which you have to be first, but a minimum threshold that you must meet. Compilation just has to be fast enough that it doesn't annoy developers most of the time. Once you achieve that they'll mostly stop complaining. I believe Clang et al are fast enough. (This is true for performance and optimisation is general: fast enough is good enough.)

arghwhat 9y ago
Compiling larger projects, I certainly do not feel that Clang et.al. are fast enough. It takes minutes to compile stuff at work with 32 Xeon threads powering through at full load. Once it takes seconds, we can talk about "fast enough".
- noelwelsh 9y ago
  Try using Scala :) Is that minutes for every compile, or for an (infrequent) full compile?
  - pdpi 9y ago
    Not the commenter you're responding to, but at my previous place I dealt with compile times of around 20 minutes from scratch, and 1-2 minutes incremental using Clang/LLVM, on a 20ish physical core Xeon with 128ish gigs of RAM.
    - noelwelsh 9y ago
      Ok, that is pretty slow.
      - pdpi 9y ago
        Heavy use of templates does that to you :(.
- iClaudiusX 9y ago
  Not to pick on you or the parent comment, but this is a such a common mistake that it's worth correcting. "Clang" is a thing not a person, therefore it's appropriate to use et cetera, not et alii. The former is for things, the latter for people (usually limited to authors of academic papers).

coldtea 9y ago

>Both GCC and Clang are very slow compared to, say, the Go standard compiler. Well, the Go standard compiler doesn't do much.