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.

On Saturday, 22 August 2015 at 10:47:55 UTC, Laeeth Isharc wrote:
> Out of curiosity, how much funding is required to develop the more straightforward kind of GCs ?

A classical GC like D has is very straightforward. It is been used since the 60s, I even have a paper from 1974 or so describing the implementation used for Simula which is a precise stop-the world GC. Trivial to do.

> Or to take what's been done and  make it possible for others to use?

Therein is the trouble, a more advanced GC is intrinsically linked to the language semantics and has to be tuned to the hardware. Expect at least 2 years of work for anything approaching state-of-the-art.

In the web server space you wait a lot for I/O so raw performance is not key for Go's success. Stability, memory usage and low latency is more important.

On Saturday, 22 August 2015 at 07:02:40 UTC, Russel Winder wrote:
> I think Go 2 is a long way off, and even then generics will not be part of the plan.

I agree that Go from Google will stay close to the ideals of the creators. I think it would be difficult get beyond that for social reasons.

But I think the mechanics Go provides are generic enough that someone could build a transpiler providing more high level convenience. I am thinking along the lines of a convenient language that can compile to both Go and Javascript... I'm tempted to have a go at it. ;)

> Go UK 2015 was held yesterday. It was less a conference and more a Google "rah rah" event. It was though very clear that Google are looking for new idioms and practices to come from users other than Google, rather than what has happened to date, which is the Go central team dictating everything to everyone else.

Go UK sounds interesting. I wonder if they will have one in Oslo? Probably not :-/.

On Saturday, 22 August 2015 at 10:47:55 UTC, Laeeth Isharc wrote:
> On Saturday, 22 August 2015 at 09:16:32 UTC, Russel Winder wrote:
>> [...]
>
> I didn't mean to start again the whole GC and Go vs D thing.  Just that one ought to know the lay of the land as it develops.
>
> Out of curiosity, how much funding is required to develop the more straightforward kind of GCs ?  Or to take what's been done and  make it possible for others to use?  It needn't be a single organisation I would think if there are many that would benefit and one doesn't get bogged down in a mentality of people worrying about possibly spurious free rider problems.  Since the D Foundation seems under way, it seems worth asking the question first and thinking about goals without worrying for now about what seems realistic.

The problem with D's GC is that there's no scaffolding there for it, so you can't really improve it.
At best you could make the collector parallel.

If I had the runtime hooks and language guarantees I needed I'd begin work on a per-thread GC immediately.

On Saturday, 22 August 2015 at 12:48:31 UTC, rsw0x wrote:
> The problem with D's GC is that there's no scaffolding there for it, so you can't really improve it.
> At best you could make the collector parallel.
>
> If I had the runtime hooks and language guarantees I needed I'd begin work on a per-thread GC immediately.

If you had a fiber local reference type and some guarantees related to that, you probably could do a per-fiber GC and collect when fibers are waiting.

On Sat, 2015-08-22 at 11:06 +0000, Laeeth Isharc via Digitalmars-d -learn wrote:
> […]
> 
> 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.
> 

This is about compiler performance, not about generated code performance.

Anyone interested in performance with Go currently uses gccgo: the standard Go compiler does not generate particularly well optimized code. This has been a resourcing choice to date, it is not a failing. gccgo on the other hand makes use of the whole GCC optimization chain.

On the other hand gc is blindingly fast at compilation compared to gccgo. This seems reminiscent of dmd vs. ldc and gdc!

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sat, 2015-08-22 at 09:27 +0000, rsw0x via Digitalmars-d-learn wrote:
> […]
> 
> The performance decrease has been there since 1.4 and there is no way to remove it - write barriers are the cost you pay for concurrent collection. Go was already much slower than other compiled languages, now it probably struggles to keep up with mono.

I know Walter hates it when people mention the word but: benchmarks.

As soon as someone say things like "it probably struggles to keep up with mono" further discussion of the topic is probably not worth entertaining without getting some agreed codes and running them all on the same machine.

I agree the standard Go compiler generates not well optimized code, but
gccgo generally does, and generally performs at C-level speeds. Of
course Java often performs far better than that, and often fails to.
You have to be careful with benchmarking and performance things
generally.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Sunday, 23 August 2015 at 11:06:20 UTC, Russel Winder wrote:
> On Sat, 2015-08-22 at 09:27 +0000, rsw0x via Digitalmars-d-learn wrote:
>> […]
>> 
>> The performance decrease has been there since 1.4 and there is no way to remove it - write barriers are the cost you pay for concurrent collection. Go was already much slower than other compiled languages, now it probably struggles to keep up with mono.
>
> I know Walter hates it when people mention the word but: benchmarks.
>
> As soon as someone say things like "it probably struggles to keep up with mono" further discussion of the topic is probably not worth entertaining without getting some agreed codes and running them all on the same machine.
>
> I agree the standard Go compiler generates not well optimized code, but
> gccgo generally does, and generally performs at C-level speeds. Of
> course Java often performs far better than that, and often fails to.
> You have to be careful with benchmarking and performance things
> generally.

https://groups.google.com/forum/#!msg/golang-dev/pIuOcqAlvKU/C0wooVzXLZwJ
25-50% performance decrease across the board in 1.4 with the addition of write barriers, to an already slow language.

random benchmarks of Go performing 3x(+) slower than C/C++/D, some of these predate Go 1.4.
https://github.com/kostya/benchmarks
https://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=gcc&data=u64
https://togototo.wordpress.com/2013/07/23/benchmarking-level-generation-go-rust-haskell-and-d/ (gcc-go performed the _worst_)
https://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/ (and again)
https://github.com/logicchains/LPATHBench/blob/master/writeup.md (once again, Go is nowhere near C/C++/D/Rust. Where is it? Hanging out with C#/Mono.)

Go is slow. These aren't cherrypicked, just random samples from a quick Googling.
Where is Go performing "C-level speeds" at? D claims this, and D shows it does. Go falls into the "fast enough" category, because it is _not_ a general purpose programming language. So unless multiple randomly sampled benchmarks are all wrong, I'm going to stick with 'Go is slow.'

On Sun, 2015-08-23 at 11:26 +0000, rsw0x via Digitalmars-d-learn wrote:
> […]
> 
> https://groups.google.com/forum/#!msg/golang
> -dev/pIuOcqAlvKU/C0wooVzXLZwJ
> 25-50% performance decrease across the board in 1.4 with the
> addition of write barriers, to an already slow language.

Garbage collection is a hard problem for performance oriented code. I am sure someone will come up with a way of improving the Go one. "Across the board" though does worry me, my codes never get a sweep. D's garbage collector could also do with some work.

> random benchmarks of Go performing 3x(+) slower than C/C++/D,
> some of these predate Go 1.4.
> https://github.com/kostya/benchmarks
> https://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&l
> ang=go&lang2=gcc&data=u64
> https://togototo.wordpress.com/2013/07/23/benchmarking-level
> -generation-go-rust-haskell-and-d/ (gcc-go performed the _worst_)
> https://togototo.wordpress.com/2013/08/23/benchmarks-round-two
> -parallel-go-rust-d-scala-and-nimrod/ (and again)
> https://github.com/logicchains/LPATHBench/blob/master/writeup.md
> (once again, Go is nowhere near C/C++/D/Rust. Where is it?
> Hanging out with C#/Mono.)

Thanks for those pointers, I shall have a look at them. Sadly though not for a couple of weeks due to various commitments.

> Go is slow. These aren't cherrypicked, just random samples from a quick Googling.

But why use absolutes. Go may be slow for you in your context, but that doesn't mean the observation applies everywhere (note the interesting turn of phrase). For my (admittedly small) codes that do not cause a garbage collect and are basically just a loop, I find things are fine.

So for a π approximation sequential code using 64-bit:

C, gcc -O3: 8.847241
C++, gcc -O3: 8.916043
Fortran, gfortran -O3: 8.893000
D, ldc -O -release: 8.722329
D, dmd -O -release: 8.787744
Rust, cargo --release: 8.715818
Go, gccgo: 8.823525
Go, 6g: 8.824643
 Go is definitely not slow there then. Thus Go is not slow.

> Where is Go performing "C-level speeds" at? D claims this, and D shows it does. Go falls into the "fast enough" category, because it is _not_ a general purpose programming language. So unless multiple randomly sampled benchmarks are all wrong, I'm going to stick with 'Go is slow.'

You are mixing too many factors here. "General purpose" has nothing to do with performance, it is to do with can the language describe most if not all forms of computation. Go is a general purpose programming language just like C, C++, D, Rust, Haskell, OCaml.

If for you Go is not performant enough, that is fine. But for many people in various contexts, Go is more the comparable with other languages. This is not just "Go is fast enough", but "Go is as fast as any other option".

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Saturday, 22 August 2015 at 06:54:43 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 22 August 2015 at 06:48:48 UTC, Russel Winder wrote:
>> But one that Google are entirely happy to fully fund.
>
> Yes, they have made Go fully supported on Google Cloud now, so I think it is safe to say that Google management is backing Go fully.
>
> I'm kinda hoping for Go++...

The other day I thought it'd be hilarious if I did a Bjarne and wrote a preprocessor to generate Go code that would accept a superset of Go syntax but added generics, function overloading, etc. And, of course, called it Go++.

Alas, 'tis too much work for just the lulz. I'd rather spend the time making D better.

Atila