Re: [dev] [OT]: Go programming language

> On Sun, Nov 15, 2009 at 02:54:23PM +0100, Tobias Ulmer wrote:
>> On Sun, Nov 15, 2009 at 02:24:41PM +0100, frederic wrote:
>>> All this is more than just nit-picking. Pike claims a 10-20% loss
>>> compared to C, which would still be quite good. However, the first
>>> benchmarks tell another story at the moment:
>>> http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=go
>>
>> Be careful with this link, the results may be ok for higher level
>> languages with built-in datatypes, but they are not for low level
>> languages. One example i've looked at just yesterday demonstrates
>> this nicely:
>>
>> http://shootout.alioth.debian.org/u64/benchmark.php?test=knucleotide&lang=all&box=1
>>

Indeed, I found 3 more of this "anomalies". I think it has more to do
with social aspects - that is the fact that there are people interested in
improving the benchmark results in language X - than with high/low level;
the general shape of the results shows quite the opposite of your
hypothesis.

I didn't dig into your example, but one possible reason C++ does better
than
C is that the programmer uses templates in order to perform compile-time
evaluation.

>> Take a look at the implementation before you draw any conclusion,
>> that's all.
>

I pointed out this benchmark precisely because I was puzzled by the low
performances of Go - I don't think Pike is lies. I was wondering if the
10-20% loss applied to gccgo or 6g.
When I compiled Go, I saw that these benchmarks were in the package, so
I thought that they were ok for the shootout (including appropriate
makefiles).
But apparently the submitters have screwed it up.

> I'd also mention that that compares 6g, rather than GCC Go, to GCC C. 6g
> uses very meager optimizations, and they claim that the GCC version is
> faster. The standard caveat of the shootout stands: it compares
> implementations, not languages.

Yes, I was also puzzled that they use 6g instead of gccgo, or even better
that
they didn't submit both. It looks like sabotage.

That said, I don't see what's wrong with using this benchmark to compare
the
efficiency of two languages - provided that one interprets the results
carefully.
Received on Mon Nov 16 2009 - 11:47:26 UTC