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

>> Compared to your grand-daddy's GC? Obviously yes. But no GC language
>> has yet prevailed against C in benchmarks.
>
> I don't have any statistics, but I'm not so sure of that. At least, as I
> said, depending on the use case. Heavily multi-threaded and dynamic
> memory intensive code takes a huge hit in locking for every malloc, and
> garbage collectors have a lot to gain by managing their collection in
> batches. I'm fairly certain that I can find benchmarks to the contrary.
>

You're right, I've read something similar: the GC-featured performed better
because the multi-thread/manual memory management was beyond human
capabilities.
In these situations, it's hard to get things right for a start, and one
may argue that the programmer has simply shot himself in the foot; heavy
use of threads and dynamic allocation doesn't look like a "suckless"
implementation.

> Beyond that, there are cases like the Dis vm, which uses ref counting
> with a low priority, real-time, non-locking GC to clean up cycles.
> Automatic ref counting has no performance drawbacks over manual ref
> counting, and the GC has virtually no impact on performance otherwise.
>

This must be taken with a grain of salt. A measured performance impact of
the GC of 2% in a VM-based system is one thing. Given that VMs are
generally
an order of magnitude slower than native code, the measured performance
impact of the same GC in a native code program could raise to 20%.

>>> 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.
>
> That's an implementation detail. In principal, they're not necessary.
> And it very much depends on what you're comparing them to. It's fairly
> common for C code to provide structs of function pointers, and this is
> no different. Namespaces require nothing more than symbol mangling.
>

You're right, it's not more expensive than function pointers.

>>> 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.
>
> Well, you didn't exactly elaborate on "strings". C provides both mutable
> and immutable strings, and I imagine that Go provides the same, too
> (although it would probably call the former byte arrays). There's no
> issue with passing them to libs, since Go uses its own libs. The C code
> it might interface with is a different (and irrelevant, given that the
> same issue presents itself in any language-to-language interface) issue.
>

I took a look in Go's library, and it seems to me they are using
zero-terminated
strings. I bet they use the trick I talked about.
In Go, strings are indeed read-only byte arrays, but I'm not sure one may
pass
a byte array to a function that expects a string.
I don't agree that library interface is irrelevant to the language
implementation.
The availability of library bindings and their quality is 50% of a
language.
Hard to make bindings is a serious drawback IMO. I heard garbeam complained
about that on IRC, but OTOH his binding to xlib in godwm looks like a
trivial
thing.

>>> Closures needn't be any more expensive than any other kind of function
>>> reference,
>>
[...]
> I'll admit, though, that without the restriction that a closure is only
> valid along with the current stack frame, closed over variables are
> forced into heap allocation, but again it's no loss over other methods.
>

Yes, I was talking about closures :-)

You're right, it's certainly no more expensive than doing the
same in C, and perhaps even less expensive.

[...]
> it's very easy to decide what is heap and what is static or stack
> allocated in C, and I very much doubt that to be the case in Go (yes,
> I'm citing memory management issues other than GC).
>

I don't understand your point. The removal of these storage specifications
is precisely one of the benefits of a GC; storage specifications only exist
because different objects in programs may have different lifespans, which
is
what the GC watches and manages.
Received on Mon Nov 16 2009 - 10:14:40 UTC