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

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.