Hacker News Reader

Comment by crowhack | Hacker News Reader

Rendering text at 60fps is a far cry from rendering a dynamic scene at 60fps.

Any examples of this being used for something non-trivial? I'm generally curious because I figured Golang would be a no-go due to the GC...

View on HN

The biggest problem with doing CPU-intensive work in Go is not the latency of the GC but rather the lack of maturity of the optimization pipeline compared to GCC and LLVM, the lack of good support for things like SIMD, the relatively poor throughput of the GC, the large overhead of cgo (which matters quite a lot for graphics!), etc.

I didn’t realise that Go didn’t use LLVM when Swift a much complex language uses it. Is there any specific reason for Go not using LLVM.

fast compile times is a core value for Go would be one reason.

The Go FAQ says they are working on it, and they mention the difficultly making some changes from C conventions leading them to not use it initially. https://golang.org/doc/faq#What_compiler_technology_is_used_...

The reason the Go developers cited is fast compile times, as well as the belief that LLVM is "too big". I don't agree with these: LLVM compile times are fine for ahead-of-time compilation, and LLVM is big because it does important things.

I do have mixed feelings about LLVM for safe GC'd languages, though. LLVM is full of undefined behavior, and its support for precise moving tracing GC is not widely used. So I can definitely sympathize with not wanting to use LLVM for Go, but not for the reasons they cited.

>LLVM compile times are fine

What constitutes 'fine' depends on workflow, size of project, machine horsepower, and personal preference. Some projects require a bit more compile -> experiment -> change -> compile -> experiment -> change than others.

I would recommend a language with a repl for that kind of project

Its my understanding that the throughput was intentionally sacrificed for low GC pause times.

Correct. That is not the decision I would have made, and it's especially relevant for CPU-intensive workloads.

>? I'm generally curious because I figured Golang would be a no-go due to the GC...

Huh? Tons of GC languages are used for games. Heck, web games use JS. Not to mention the whole C#/Unity thing that even powers AAA games...

Yeah that's true but I disagree it's a good idea. Most AAA shops still use non-GC languages because they need the full control/cannot waste ms on random GC pass.

Game dev here. Unless you are making GTA or some high fidelity 3D game. You are wasting your time using a language like C++. You are going to spend more time dealing with memory than actually making your game which is pointless in a 2D game.

Yep. I'm always more curious about how I can get back milliseconds based on 2D rendering techniques and GPU-related concerns. I'm almost never thinking about memory consumption. It's always stunningly low, even for games doing a ton of things.

You'd almost truly have to go out of your way to consume browser-levels of memory.

If they use Unreal, they are using C++ with GC.

Once you get past a certain point of developing a complex game in Unity, one of the optimization techniques is to keep runtime allocations at 0 bytes in order to prevent a GC pause from ever happening. This was a huge pain back when Unity was on Mono 2.10.8 (released Dec 2011) but it's a bit better now.

It's a fight against the GC typically

Unfamiliar with any game codebases or much C++, but I know in C we'd do zero-allocation or controlled arena allocation for "embedded" uses. I'd imagine Allocation tuning is always present. Was it much harder in C#?

.NET has support for stack allocation and manual management of native memory.

Many forget that MSIL is rich enough to support C++, initially via Managed C++, later replaced by C++/CLI.

The major features in C# 7.3 are related to slices, improved stack allocation and reducing copies of value types.

>Once you get past a certain point of developing a complex game in Unity, one of the optimization techniques is to keep runtime allocations at 0 bytes in order to prevent a GC pause from ever happening.

It is, but it's still an option. It's not like "language with GC" == no-go for games, as the parent implied.

Just like it is a fight against malloc() if the game's architecture is not done properly.

No idea why this is getting downvoted. You'll naturally need more control over memory when building AAA high-performance 3D games, but there's tons of great 2D games made with GC languages (see: Love2D, OpenFL, HaxeFlixel, ImpactJS, Unity).

In a lot of 2D games, simple patterns like object pooling are more than enough to squash any GC problems. There's a whole spectrum of performance requirements out there -- no need to discount a framework due to it's language.

Interestingly enough, many times GC tricks like object pooling aren't even the first concern; it's usually proper utilization of GPU buffers and understanding pixel fill-rate more than anything.

It's truly wonderful time for all programming languages in this space.

The current Go is great for writing a 60fps game server. The pauses are very low, and the qualities that make it great for a server also make it great for a game server.

I'm close to implementing hot code update -- in my Go game servers!

For a 2d game engine like this, there's no problem with a GC based language, people write 60fps 2d games in lua/python (which Go easily outperforms), C# and even 3d games like Minecraft in Java.

Unreal and Unity use a GC.

It is a matter how it gets used, not that it is present.

Go’s GC is extremely low latency and you can pretty easily avoid allocating using the same techniques as you would in C++.

How low latency are we talkin? 1ms , 10ms ?

Sub-millisecond STWs.

https://blog.golang.org/ismmkeynote

Thanks for this link.

Sub-1ms STW pauses, even for very large heaps.

https://blog.golang.org/ismmkeynote

Seems like it can go sub 1ms

You can't avoid allocating using the same techniques as in C++. In Go you have to know the intricacies of escape analysis to avoid allocation: objects are heap allocated "by default" and sometimes optimized to be stack allocated. In C++ there is no implicit heap allocation and usually no need for escape analysis.

As a practical example, capturing variables in a closure will usually cause them to be heap allocated in Go, but in C++ capturing has no effect on variable storage.

It seems to me that you're not really taking a charitable interpretation of GP's comment. For example, in my game development experience (granted, I'm 6 years removed from that industry) we often relied on object pools to avoid allocation. You don't need to know anything about Go's escape analysis to use a pool to avoid allocation, as far as I can tell. Could you explain your position further?

Go language constructs allocate in ways that are not immediately obvious. So using object pools is not sufficient to avoid allocation in Go as compared to, say, C++.

In my view (which is the dominant view among compiler engineers for GC'd languages), spending a lot of effort to avoid allocation is a poor use of programmer time in a GC'd language. It is better to just improve the GC to make allocation fast. In a properly designed generational GC like that of Java HotSpot, allocation is about 5 instructions. That is a game changer: allocation is as cheap as a function call plus the prologue.

Unfortunately, Go's designers have so far not deployed generational GC, which is why we keep having these threads about avoiding allocation. (I've seen indications in the last couple of weeks that Go may finally be moving to a generational GC, though, and I hope they do.)

Anyone doing HTML 5/Flash like games in Go doesn't need to worry like if they are writting the next Fortnight in Vulkan.

This is why I've been careful to say "CPU-intensive workloads" and not "games", because not all games are CPU-intensive workloads.

Ah, sorry I missed it.

Then I fully agree with you.

You weren't careful to say it in this subthread though. I had a whole response written up to talk about how you're being completely unreasonable with regards to most gaming projects before I saw this clarification. Now all that effort is wasted! ;)

You’re splitting hairs. Yes, you need to reason about escape analysis. This is pretty easy, especially since the compiler will tell you when things escape. It’s certainly easier than... well, pretty much anything in C++. :)

Reply on news.ycombinator.com