Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Go: Where we are in February 2016

talks.golang.org

Post reply on HN
Print view View original

71–80 of 224 posts

Re: The State of Go: Where we are in February 2016

#71

Post by voidlogic »

kasey_junk wrote: post #68
voidlogic wrote: post #64

Earlier quoted context omitted.

Go is also better about allocating on the stack (vs heap) and provides a very solid pool implementation (sync.Pool). Both of these can dramatically reduce GC pressure too.

The golang object pool is a bit of a problem (compared to the JVM alternatives) due to lack of generics. You tend to need to do object pooling when you have tight performance requirements which is at odds with the type manipulation you have to do with the sync.Pool. So the golang pool is good for the case where you have GC heavy but non-latency sensitive operations, but not the more general performance sensitive prob…

Have you benched "myPool.Get()" vs "myPool.Get().(*myStruct)" ? I don't think the "type manipulation" is the problem you think it is.

Re: The State of Go: Where we are in February 2016

#72

Post by [deleted] »

kasey_junk wrote: post #68
voidlogic wrote: post #64

Earlier quoted context omitted.

Go is also better about allocating on the stack (vs heap) and provides a very solid pool implementation (sync.Pool). Both of these can dramatically reduce GC pressure too.

The golang object pool is a bit of a problem (compared to the JVM alternatives) due to lack of generics. You tend to need to do object pooling when you have tight performance requirements which is at odds with the type manipulation you have to do with the sync.Pool. So the golang pool is good for the case where you have GC heavy but non-latency sensitive operations, but not the more general performance sensitive prob…

[deleted]

Re: The State of Go: Where we are in February 2016

#73

Post by masklinn »

zimpenfish wrote: post #62
masklinn wrote: post #43

Earlier quoted context omitted.

This change simply draws from Jinja, which has had this feature for nearly 10 years[0]. It's a simple and efficient solution to the problem of trimming whitespace on either side of a template tag, I fail to see what is kludgy about it (and intuitiveness is in the eye of the beholder). In my experience it's clear, simple and doesn't make the template less readable. > Sure, it's terse and being terse can be nice, but t…

Perl's Template Toolkit has had this feature since at least 2001 (and I remember it being available before that but my googlefu is failing me right now.) cf http://www.perl.com/pub/2001/01/tt2.html > If these tags are replaced with [%- -%] then the preceding or following linefeed is suppressed.

Nice, thanks for the history lesson. Now I wonder whether Armin Ronacher got it from there or independently reinvented it.

Re: The State of Go: Where we are in February 2016

#74

Post by Jach »

martijn_himself wrote: post #17

A Golang beginner's question: do these GC improvements make Golang a suitable language/ platform for writing games? EDIT: I realise this is a vague question. I suppose I was wondering if the order of magnitude GC performance in Go is likely to interfere with game loops you might find in reasonably CPU/ GPU intensive Indie games (i.e. NOT Crysis).

Lots of neat and profitable games have been made in slower languages, so you should be fine, though in some cases you might have to replicate an entire engine... Not being real familiar with Go, the thing you'll want to look out for if your game gets "big" is unpredictable GC events, more-so even than the absolute max duration of any particular GC event. If Go (or whatever else) doesn't provide enough tuning to support "soft" realtime systems, you'll end up structuring your program to allocate in pools and release all references only at certain points to try and make the GC predictable, which is a common pattern for non-GC languages in games, so you've all but lost the let-me-not-care-about-memory-management justification for the language except for the safety aspects, which don't tend to be high priority for games...

Re: The State of Go: Where we are in February 2016

#75

Post by ianopolous »

voidlogic wrote: post #64
vardump wrote: post #28

Earlier quoted context omitted.

JVM's gc is most likely significantly better. On the other hand golang's gc needs to collect less objects, in some cases orders of magnitude less. If you compare a slice of structs with 1000 elements, it'll be one object (and allocation) in golang. Equivalent array in JVM requires the array itself + 1000 Objects, 1001 allocations. In this case, golang has lot less object graph to gc. Of course slice of 1000 interface…

Go is also better about allocating on the stack (vs heap) and provides a very solid pool implementation (sync.Pool). Both of these can dramatically reduce GC pressure too.

I'd like to see evidence for this. the JVM has been great at stack allocation for over a decade [1][2].

[1] http://www.stefankrause.net/wp/?p=64 [2] http://www.ibm.com/developerworks/library/j-jtp09275/

Re: The State of Go: Where we are in February 2016

#76

Post by pcwalton »

dantillberg wrote: post #16

The concurrent map access checks in Go1.6rc1 have already uncovered one such bug in my code. Love it! Oh, and I've already made use of the whitespace-stripping in text templates, too! :) One thing I was worried about from the focus on reducing maximum GC pause times (i.e. latency) was that this might negatively affect GC throughput . For example, maybe the pauses are shorter but there are many more of them. The proje…

Aggressive GC latency improvements, like the ones Go is making, virtually always negatively affect throughput. For example, Azul C4 has lower throughput than HotSpot (at least per the numbers cited in the paper). There's no free lunch in GC.

Re: The State of Go: Where we are in February 2016

#77

Post by pcwalton »

voidlogic wrote: post #71
kasey_junk wrote: post #68

Earlier quoted context omitted.

The golang object pool is a bit of a problem (compared to the JVM alternatives) due to lack of generics. You tend to need to do object pooling when you have tight performance requirements which is at odds with the type manipulation you have to do with the sync.Pool. So the golang pool is good for the case where you have GC heavy but non-latency sensitive operations, but not the more general performance sensitive prob…

Have you benched "myPool.Get()" vs "myPool.Get().(*myStruct)" ? I don't think the "type manipulation" is the problem you think it is.

At the x86 level, myPool.Get(Index) is going to be at least as expensive as cmp/jae/mov (3 cycles), and myPool.Get().(myStruct) is going to be at least as expensive as cmp/jae/cmp/jne/mov (5 cycles). So unless you have some way of hiding the latency, the type check is 67% slower by cycle count.

The experience of every JIT developer is that dynamic type checks do matter a lot in hot paths.

Re: The State of Go: Where we are in February 2016

#78

Post by geodel »

ianopolous wrote: post #75
voidlogic wrote: post #64

Earlier quoted context omitted.

Go is also better about allocating on the stack (vs heap) and provides a very solid pool implementation (sync.Pool). Both of these can dramatically reduce GC pressure too.

I'd like to see evidence for this. the JVM has been great at stack allocation for over a decade [1][2]. [1] http://www.stefankrause.net/wp/?p=64 [2] http://www.ibm.com/developerworks/library/j-jtp09275/

It is straightforward because Go has first class value types which are most likely to be on stack vs Java where everything except primitives are reference type which are most likely to be on heap. Also Java data structures are really bloated.

https://www.cs.virginia.edu/kim/publicity/pldi09tutorials/me...

Re: The State of Go: Where we are in February 2016

#79

Post by schmichael »

At work (Lytics) 100% of our backend code has been in Go since the beginning over 3 years ago, so slide #6 highlights one of the most things with nearly every Go release:

> Changes to the language: None

https://talks.golang.org/2016/state-of-go.slide#6

We generally get our entire stack upgraded to the latest release within 1-3 months with little effort. It wouldn't be much more work to be ready to upgrade on release day, but we haven't found a reason to worry about it.

Go is such a breath of fresh air compared to past Java and Python jobs where production was usually at least a major release version behind the latest and there was extra effort spent getting everyone using the same implementation (Oracle Java v OpenJDK or Ubuntu's Python v CentOS's -- there are differences!).

Conservative releases aren't a must-have for a language, but I do appreciate having one less operational headache to consider.

Re: The State of Go: Where we are in February 2016

#80

Post by martijn_himself »

espadrine wrote: post #69
martijn_himself wrote: post #17

A Golang beginner's question: do these GC improvements make Golang a suitable language/ platform for writing games? EDIT: I realise this is a vague question. I suppose I was wondering if the order of magnitude GC performance in Go is likely to interfere with game loops you might find in reasonably CPU/ GPU intensive Indie games (i.e. NOT Crysis).

You have to ensure that the GC never makes you drop a frame. For 60Hz, that means staying below 16.7ms. Given that a Go 1.6 GC will still take about 4ms, you have 12.7ms to generate a frame, which can be too limiting for some CPU-intensive games, but is perfectly acceptable for many games. (In Go 1.5, a GC was much more likely to make you drop a frame, as it could easily average 40ms.) On the other hand, there are le…

I just have to say this is a great answer. Thanks.
Post reply on HN