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

Show HN: Strife, a 2D game library for Go

github.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Show HN: Strife, a 2D game library for Go

#31

Post by pjmlp »

robmaister wrote: post #17
coldtea wrote: post #11

Earlier quoted context omitted.

> ? 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...

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

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

Re: Show HN: Strife, a 2D game library for Go

#32

Post by pjmlp »

kjeetgill wrote: post #21
robmaister wrote: post #17

Earlier quoted context omitted.

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.

Re: Show HN: Strife, a 2D game library for Go

#33

Post by pjmlp »

crowhack wrote: post #12
coldtea wrote: post #11

Earlier quoted context omitted.

> ? 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.

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

Re: Show HN: Strife, a 2D game library for Go

#34

Post by pcwalton »

galangalalgol wrote: post #29
pcwalton wrote: post #15

Earlier quoted context omitted.

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.

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.

Re: Show HN: Strife, a 2D game library for Go

#35

Post by pjmlp »

pcwalton wrote: post #13
weberc2 wrote: post #5

Earlier quoted context omitted.

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

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…

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

Re: Show HN: Strife, a 2D game library for Go

#36

Post by pcwalton »

nullstyle wrote: post #26
pcwalton wrote: post #13

Earlier quoted context omitted.

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…

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.)

Re: Show HN: Strife, a 2D game library for Go

#37

Post by pcwalton »

pjmlp wrote: post #35
pcwalton wrote: post #13

Earlier quoted context omitted.

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…

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.

Re: Show HN: Strife, a 2D game library for Go

#38

Post by BurningCycles »

crowhack wrote: post #4

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...

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.

Re: Show HN: Strife, a 2D game library for Go

#39

Post by [deleted] »

coldtea wrote: post #11
crowhack wrote: post #4

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...

> ? 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...

[deleted]

Re: Show HN: Strife, a 2D game library for Go

#40

Post by pjmlp »

pcwalton wrote: post #37
pjmlp wrote: post #35

Earlier quoted context omitted.

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.

Post reply on HN