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

21–30 of 48 posts

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

#21

Post by kjeetgill »

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

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

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

#22

Post by gameswithgo »

andy_ppp wrote: post #19
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.

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.

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

#23

Post by mattnewton »

andy_ppp wrote: post #19
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.

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.

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

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

#24

Post by pcwalton »

andy_ppp wrote: post #19
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.

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.

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.

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

#25

Post by gameswithgo »

pcwalton wrote: post #24
andy_ppp wrote: post #19

Earlier quoted context omitted.

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.

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 d…

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

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

#26

Post by nullstyle »

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…

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?

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

#27

Post by coldtea »

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

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

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

#28

Post by greysonp »

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

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.

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

#29

Post by galangalalgol »

pcwalton wrote: post #15
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...

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.

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

#30

Post by pjmlp »

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

Unreal and Unity use a GC.

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

Post reply on HN