post on using go 1.5 and GC latency

Laeeth Isharc via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sat Aug 22 04:06:40 PDT 2015


On Saturday, 22 August 2015 at 07:30:23 UTC, rsw0x wrote:
> On Saturday, 22 August 2015 at 06:48:48 UTC, Russel Winder 
> wrote:
>> On Fri, 2015-08-21 at 10:47 +0000, via Digitalmars-d-learn 
>> wrote:
>>> Yes, Go has sacrificed some compute performance in favour of 
>>> latency and convenience. They have also released GC 
>>> improvement plans for 1.6:
>>> 
>>> https://docs.google.com/document/d/1kBx98ulj5V5M9Zdeamy7v6ofZXX3yPziA f0V27A64Mo/edit
>>> 
>>> It is rather obvious that  a building a good concurrent GC is 
>>> a time consuming effort.
>>
>> But one that Google are entirely happy to fully fund.
>
> because Go is not a general purpose language.
> A concurrent GC for D would kill D. Go programs saw a 25-50% 
> performance decrease across the board for the lower latencies.
>
> D could make some very minor changes and be capable of a 
> per-thread GC with none of these performance drawbacks, but 
> nobody seems very interested in it.

This puts ddmd into context, bearing in mind an automated 
translation without won't I guess be much slower in LDC or GDC, 
and it's already a small difference:

Release notes on go 1.5 via stack overflow.

Builds in Go 1.5 will be slower by a factor of about two. The 
automatic translation of the compiler and linker from C to Go 
resulted in unidiomatic Go code that performs poorly compared to 
well-written Go. Analysis tools and refactoring helped to improve 
the code, but much remains to be done. Further profiling and 
optimization will continue in Go 1.6 and future releases. For 
more details, see these slides and associated video.




More information about the Digitalmars-d-learn mailing list