3 ms·

Why would anyone care about relative code size or compile time for a program this small? Because it can be extrapolated [obviously, not perfectly]... The

Why would anyone care about relative code size or compile time for a program this small? Because it can be extrapolated [obviously, not perfectly]... The nice thing about a mandelbrot benchmark is that it's FP and optimization driven, so does a decent quick-and-dirty job of illuminating the parallelizable performances produced by different compilers. Once you add in regexes, databases, etc, you move beyond the compiler and on to the performance of secondary or tertiary systems. Why not try a handful of programs to get a scatterplot between the two toolchains? Because relative to the question I was trying to answer ("as someone investigating Go, should I also investigate GCCGo?"), that would be a waste of time. Were I to have gotten a result that suggested that GCCGo was markedly better along some dimension, I would have done more testing to quantify "markedly". Go is a lovely, young language, but the GCCGo implementation is very young. The GCCGo folks will catch up soon enough with Google. Until then, Google has produced a nice toolchain for you.

onan_barbarian 13y ago
I'm not arguing that it's a bad microbenchmark for FP run-time performance. I'm arguing that it's a bad microbenchmark for compile time and code size. I'm not all that familiar with go, but in most systems I've used, if you write a really tiny program, you will find that there's a "fixed cost of entry' where the standard libraries get munged through the linker (or whatever) and that writing a program 10x larger will not cost you 10x as much. Since you took only one measurement of one program, you have no idea what the trend lines might look like here. It seems like you are going out of your way to do this badly and make a snap judgement that you can proclaim to the world. I am surprised at the extent to which you seem to think you need to ration your investigation and avoid wasting your time by the exhausting task of "also investigating GCCGo". Also, in the world of high-performance computing, 10% for zero programmer effort is huge.
igouy 13y ago
>>Because it can be extrapolated...<< How can we extrapolate from a single data point? We need 2 points for any kind of line. >>Were I to have gotten a result that suggested that GCCGo was markedly better along some dimension...<< Maybe you would have gotten that result on a different program?

onan_barbarian 13y ago

I'm not arguing that it's a bad microbenchmark for FP run-time performance. I'm arguing that it's a bad microbenchmark for compile time and code size. I'm not all that familiar with go, but in most systems I've used, if you write a really tiny program, you will find that there's a "fixed cost of entry' where the standard libraries get munged through the linker (or whatever) and that writing a program 10x larger will not cost you 10x as much. Since you took only one measurement of one program, you have no idea what the trend lines might look like here. It seems like you are going out of your way to do this badly and make a snap judgement that you can proclaim to the world. I am surprised at the extent to which you seem to think you need to ration your investigation and avoid wasting your time by the exhausting task of "also investigating GCCGo". Also, in the world of high-performance computing, 10% for zero programmer effort is huge.

igouy 13y ago

>>Because it can be extrapolated...<< How can we extrapolate from a single data point? We need 2 points for any kind of line. >>Were I to have gotten a result that suggested that GCCGo was markedly better along some dimension...<< Maybe you would have gotten that result on a different program?