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

141–150 of 224 posts

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

#141

Post by FraaJad »

iends wrote: post #57
armitron wrote: post #36

Am I in the minority to think of Go as a completely unnecessary move-along-now-nothing-to-see-here project? (as if we didn't have enough of that already). The only niche I see for it is for those poor souls who are still wasting their time with Python/Ruby but that by itself surely can't lead to great things for the language, especially since it's riding on air. More dense air than Python but air nonetheless. Also Ro…

The value of Go is: 1) Reasonably fast (better than Node at CPU bound tasks, faster than Ruby/Python) 2) Statically compiled 3) Great tooling (except package management, but it's getting better) If you want a reasonably fast statically compiled language, what would you use? Java? Lots of JEE/App server issues to consider TypeScript? I'm a fan, but it's compile time type checking and not runtime type checking. TypeClo…

D.

* C/C++ like familiar syntax. * as fast as C++ (faster in some, slower in others) * type inference (auto keyword) * Garbage collected language by default. * Multiple compiler implementation (DMD, GDC, LDC) * Debugging symbol support * Package management with versioning and pkg repo * IDE/Editor support - Visual studio/xamarin/emacs * Very easy C FFI * compile type function evaluation * meta programming * The concurrency story is more "mainstream" than Go's (no "goroutine" and other fancy stuff). * Multiple new books on the topic

D has a lot going for it, except for breathless fans :) (not knocking breathless fans here. D can use some)

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

#142

Post by djur »

blakeyrat wrote: post #137
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).

There are a heck of a lot games written in C#, which is not only interpreted, but probably has a less-tuned GC. Including heavy-processors like Kerbal Space Program. If KSP works in C#, you can write a game in Go no problem.

C# is not interpreted, and the CLR has a generational GC on par with the JVM. Many C# games are built on game engines like Unity which are implemented in C++, anyway.

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

#143

Post by mike_hearn »

_ph_ wrote: post #119
mike_hearn wrote: post #111

Earlier quoted context omitted.

You have to be very careful about these sorts of GC statistics. Things are often not quite what they seem and they depend a lot on the type of app you run. The first thing to be aware of is that with modern collectors (I have no idea how modern Go's new collector is though), GC pause time depends on how much live data there is in the young generation. So you can easily have enormous heaps with very low pause times if…

The GO gc is not generational, those 20ms are for a full gc. Certainly the details of the heap usage of the application is going to affect gc times, but this is not the time for just a nursery collection.

OK, the tradeoff they're making that I missed is that it's not a compacting collector. So eventually your heap can fragment to the point where allocation gets expensive or impossible. Unusual design choice.

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

#144

Post by notacoward »

aikah wrote: post #131
notacoward wrote: post #113

Earlier quoted context omitted.

> If you want a reasonably fast statically compiled language, what would you use? Nim. More similar to Go than most languages are to each other, but Nim has (a) more modern features, (b) better compatibility/integration with C libraries, and (c) an amazing macro system. The only thing in Go's favor is the size of its community/ecosystem, which seems to be an accident of timing and most definitely not about inherent q…

Nim doesn't have interfaces. The amount of plumbing required to implement them is ridiculous. It has generics though. My point is how can recent OO languages miss this kind of stuff when designing their type system ? Crystal looks like a better bet, unfortunately it doesn't run on Windows.

At risk of sounding like a Go advocate when generics come up, the lack of interfaces doesn't bother me because interfaces themselves are a bit of a hack. When you have inheritance, object variants, generics, and a strong template/macro system, what's left for interfaces to do? I'd much rather have all of these other things than interfaces alone.

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

#145

Post by mike_hearn »

leaveyou wrote: post #34
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…

Could you explain what essential things JVM does better than Go at this point ? Does it stop the world less ? Or does it do more things in parallel ? Thanks

With respect to garbage collection only and ignoring things like reliable debugging support, the primary thing it does is compaction.

If your memory manager does not compact the heap (i.e. never moves anything), then this implies a couple of things:

1. You can run out of memory whilst still technically having enough bytes available for a requested allocation, if those bytes are not contiguous. Most allocators bucket allocations by size to try and avoid the worst of this, but ultimately if you don't move things around it can always bite you.

2. The allocator has to go find a space for something when you request space. As the heap gets more and more fragmented this can slow down. If your collector is able to move objects then you can do things generationally which means allocation is effectively free (just bump a pointer).

In the JVM world there are two state of the art collectors, the open source G1 and Azul's commercial C4 collector (C4 == continuous compacting concurrent collector). Both can compact the heap concurrently. It is considered an important feature for reliability because otherwise big programs can get into a state where they can't stay up forever because eventually their heap gets so fragmented that they have to restart. Note that not all programs suffer from this. It depends a lot on how a program uses memory, the types of allocations they do, their predictability, etc. But if your program does start to suffer from heap fragmentation then oh boy, is it ever painful to fix.

The Go team have made a collector that does not move things. This means it can superficially look very good compared to other runtimes, but it's comparing apples to oranges: the collectors aren't doing the same amount of work.

The two JVM collectors have a few other tricks up their sleeves. G1 can deduplicate strings on the heap. If you have a string like "GET" or "index.html" 1000 times in your heap, G1 can rewrite the pointers so there's only a single copy instead. C4's stand-out feature is that your app doesn't pause for GC ever, all collection is done whilst the app is running, and Azul's custom JVM is tuned to keep all other pause times absolutely minimal as well. However IIRC it needs some kernel patches in order to do this, due to the unique stresses it places on the Linux VMM subsystem.

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

#146

Post by mike_hearn »

geodel wrote: post #108
pcwalton wrote: post #94

Earlier quoted context omitted.

Latency isn't the only concern; you also have to look at throughput. The JVM's GC has been carefully tuned to strike a balance here. In particular, Go's GC is not yet generational from the talks I've seen, which is a large throughput loss compared to the GC of the JVM.

If it is carefully tuned why it needs such a big GC tuning guide and 100s of JVM flags to tune runtime. Any Java product of consequence comes with custom GC settings meaning they do not find default ones suitable. https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc...

The G1 collector has a single knob that is supposed to be a master knob: you pick your pause time goal. Lower means shorter pauses but overall more CPU time spent on collection. Higher means longer pauses but less time spent on collection and thus more CPU time spent on your app. Batch job? Give it a high goal. Latency sensitive game or server? Give it a low goal.

There are many other flags too, and you can tune them if you want to squeeze more performance out of your system, but you don't have to use them if you don't want to.

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

#147

Post by mike_hearn »

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/

"Great" is pushing it a bit. The JVM will not do inter-procedural escape analysis unless the called method is inlined into the callee and so the compiler can treat it as a single method for optimisation purposes. So forget about stack allocating an object high up the call stack even if it's only used lower down and could theoretically have been done so.

That said, JVMs do not actually stack allocate anything. They do a smarter optimisation called scalar replacement. The object is effectively decomposed into local variables that are then subject to further optimisation, for instance, completely deleting a field that isn't used.

Value types will be added to the JVM eventually in the Valhalla project. Go fans may note here that Go has value types, but this is a dodge - the bulk of the work being done so far in Valhalla is a major upgrade of the support for generics, because the Java (and .NET) teams believe that value types without generic specialisation is a fairly useless feature. If they didn't do that you could have MyValueType[] as an array, but not a List or Map which would make it fairly useless. Go gets around this problem by simply not letting users define their own generic data structures and baking a few simple ones into the language itself. This is hardly a solution.

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

#148

Post by mike_hearn »

FooBarWidget wrote: post #134
pcwalton wrote: post #76

Earlier quoted context omitted.

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.

But I would argue that most people who use Go, use it to write user-facing server apps, or at least server apps in which response time is an important metric. I don't know anybody who uses Go to primarily write batch jobs where throughput matters more than latency.

Yeah, but that's circular - if you did want to write a high performance batch job, maybe you wouldn't use Go because of the GC.

And hi by the way ;)

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

#149

Post by mike_hearn »

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…

Interesting fact: Unreal Engine uses a GCd heap (or used to at least) for its core game state, so that means many AAA games use GC. And you can hit 60fps with it.

Their secret is they keep the game state heap really small. Like, 50 megabytes, maybe.

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

#150

Post by geodel »

mike_hearn wrote: post #143
_ph_ wrote: post #119

Earlier quoted context omitted.

The GO gc is not generational, those 20ms are for a full gc. Certainly the details of the heap usage of the application is going to affect gc times, but this is not the time for just a nursery collection.

OK, the tradeoff they're making that I missed is that it's not a compacting collector. So eventually your heap can fragment to the point where allocation gets expensive or impossible. Unusual design choice.

Unlike Java Go has first class value types and memory layout can be controlled by developers. So it leads to much less objects on heap and compact layouts both will lead to far less fragmentation. As you can see here Go apps use quite less memory than Java. https://benchmarksgame.alioth.debian.org/u64q/go.html
Post reply on HN