3 ms·

"You wouldn't think it would be possible for compiler speed to be so much better than C that it would make a difference" I would think that, even before I had

"You wouldn't think it would be possible for compiler speed to be so much better than C that it would make a difference" I would think that, even before I had used Go. Ignoring the smaller scanning benefits of Go that come about from the more rigid syntax for braces and such, the C preprocessor system introduces a complete nightmare when it comes to requiring multiple passes over the same code, especially for code that is naive about include guards, pre-compiled headers and other "best practices". C (and C++ is even worse) has a lot of very large low hanging fruit to cull when it comes to writing languages with faster compilers. Whatever speed C compilers have now is due to the geniuses who wrote the compilers and decades of shoulders to stand on, the language is actively working against them at nearly every turn when it comes to compilation speed. That aside, I agree. Go compiles very, very fast. So fast that it never occurred to me that "go get" did a compilation until it was pointed out to me that it did.

haberman 14y ago
> C (and C++ is even worse) has a lot of very large low hanging fruit to cull when it comes to writing languages with faster compilers. I look forward to seeing the speed boost that C and C++ get if/when modules are available: http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf
- pjmlp 14y ago
  Me too. Not sure if they make it to C++14 though. :(
  - pcwalton 14y ago
    They're delayed to C++17. C++14 is an incremental release only.
    - pjmlp 14y ago
      Yes. Actually I wonder if they will make it to C++17 even, but I keep looking forward to it.
vidarh 14y ago
I can't agree regarding C. C++, sure, templates are nasty to compile quickly. C on the other hand have very little that causes problems unless you severely abuse the pre-processor in ways I've seen maybe a handful of times in the last 20 years. Sure, there are compilers that do a poor job at optimizing it, and it's very easy to make it slow on memory starved systems, but on a system with enough RAM to keep your headers in memory, and a compiler that doesn't totally disregard compilation speed, the overhead of skipping over blocks of include files using include guards is low and for code that doesn't, a compiler that can process multiple source files at the time can trivially cache large chunks of parsed headers. As I've pointed out elsewhere, Bellard demonstrated TCCBOOT that used TCC to boot-time compile the Linux kernel in 15 seconds on a P4 - it's sufficient to demonstrate that it's difficulty in pre-processing or parsing C quickly that is the block for fast C compilation, but that to the extent it is even a real problem it is architectural decisions in the major C compilers and/or optimisation. It's quite possible Go can be compiled faster, but so far I've not seen any compelling evidence that it is even roundly beating readily available C compilers. Certainly the numbers bandied around in this thread are not impressive.

haberman 14y ago

> C (and C++ is even worse) has a lot of very large low hanging fruit to cull when it comes to writing languages with faster compilers. I look forward to seeing the speed boost that C and C++ get if/when modules are available: http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf

pjmlp 14y ago
Me too. Not sure if they make it to C++14 though. :(
- pcwalton 14y ago
  They're delayed to C++17. C++14 is an incremental release only.
  - pjmlp 14y ago
    Yes. Actually I wonder if they will make it to C++17 even, but I keep looking forward to it.

vidarh 14y ago

I can't agree regarding C. C++, sure, templates are nasty to compile quickly. C on the other hand have very little that causes problems unless you severely abuse the pre-processor in ways I've seen maybe a handful of times in the last 20 years. Sure, there are compilers that do a poor job at optimizing it, and it's very easy to make it slow on memory starved systems, but on a system with enough RAM to keep your headers in memory, and a compiler that doesn't totally disregard compilation speed, the overhead of skipping over blocks of include files using include guards is low and for code that doesn't, a compiler that can process multiple source files at the time can trivially cache large chunks of parsed headers. As I've pointed out elsewhere, Bellard demonstrated TCCBOOT that used TCC to boot-time compile the Linux kernel in 15 seconds on a P4 - it's sufficient to demonstrate that it's difficulty in pre-processing or parsing C quickly that is the block for fast C compilation, but that to the extent it is even a real problem it is architectural decisions in the major C compilers and/or optimisation. It's quite possible Go can be compiled faster, but so far I've not seen any compelling evidence that it is even roundly beating readily available C compilers. Certainly the numbers bandied around in this thread are not impressive.