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.
