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

On Sun, Nov 15, 2009 at 2:24 PM, frederic <fdubois76_AT_gmail.com> wrote:
>> On Sun, Nov 15, 2009 at 12:43:46PM +0100, Szabolcs Nagy wrote:
>>>
>>> On 11/15/09, frederic <fdubois76_AT_gmail.com> wrote:
>>> and sacrifices some efficiency to have a few higher level language
>>> features (gc, interface, string, map, package, init, defer, closure..) as a
>>> bonus it has multi tasking support (go, chan, select), good library support
>>> and stricter semantics
>>
>> Be careful what you say. None of those features necessarilly sacrifice
>> efficiency. In fact, garbage collection can be a huge performace boon when
>> implemented properly, in that garbage can be lazily freed in hunks and with
>> minimal locking.
>
> Compared to your grand-daddy's GC? Obviously yes. But no GC language has yet
> prevailed against C in benchmarks.
>
>> Interfaces and packages are free, as far as performance is concerned,
>> though implementations may vary.
>
> It seems to me that there's virtual tables behind interfaces, which means
> one level of indirection.
> It may be cheap compared to the provided facility, but it's not free.
>
>> C strings are slow when you need to get their length.
>
> It's not a win-all situation. Immutable strings may be more expensive in
> some use cases.
> Furthermore, they either have to convert back to zero-terminated strings
> when passing them to libs, or use the trick of appending ("quand même") a
> zero byte, which is redundant wrt to the array lenght.
>
>> Closures needn't be any more expensive than any other kind of function
>> reference,
>
> One has to pass at least an extra parameter, which is a pointer to the
> captured values. It is always more expensive than passing a pointer to a
> function.
>
> 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

As kris said, that doesn't compare languages, but implementations, and
not just implementations of the language/compilers, but
implementations of the benchmark itself.

Rog (of Vitanuova fame) posted an update to the Go implementation of
the benchmark that improves performance by 20%, and he said he had
barely spent half an hour to get that far.

Also when running the benchmark they don't seem to have set
GOMAXPROCS, so they failed to get any parallelism.

uriel
Received on Sun Nov 15 2009 - 15:50:42 UTC