4 ms·
Of course, there's no good reason why compiling the compiler should be relevant to typical applications. I'm glad GCC doesn't drop optimizations for fast numer
by gnufx 7y ago
Of course, there's no good reason why compiling the compiler should be relevant to typical applications. I'm glad GCC doesn't drop optimizations for fast numerical Fortran that surely won't speed up the compiler.
- nickpsecurity 7y agoTrue. I didn't agree with his metric. Mine came from my experience with BASIC and Lisps. It was that the compile should happen in no more than a few seconds if iteration speed was the goal. My metric was about keeping the mind in a state of flow for maximum creative output. Otherwise, it could take all night if I wasn't staring at the screen waiting on it.
- vidarh 7y agoIt's not so relevant for compiler suites that handle many languages, but for Wirth-style compiler the compiler is largely a bunch of branches and IO, so while it won't be representative for everything, it is quite representative. And of course it will mean the result is slower, but it represents a belief that the speed and simplicity of the compiler matters more for a whole lot of uses. Thankfully nothing prevents us from having multiple compilers, or settings, so we can get both very fast compiles and optimizations. Indeed, several of Wirth's thesis students did optimization work that plugged in optimizations in the Oberon compiler.
- gnufx 7y agoI don't necessarily disagree, and I grew up with rather fast compilers on rather fast interactive systems; they may even have been Wirth-style, but I didn't study the source. It's just that it's not a useful metric for, say, numerical code that doesn't look like a compiler. Also I suspect the difference in hardware architecture in those days was relevant.