9 ms·
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
by crowhack 8y ago
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...
- weberc2 8y agoGo’s GC is extremely low latency and you can pretty easily avoid allocating using the same techniques as you would in C++.
- crowhack 8y agoHow low latency are we talkin? 1ms , 10ms ?
- tptacek 8y agoSub-millisecond STWs. https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote
- crowhack 8y agoThanks for this link.
- acln 8y agoSub-1ms STW pauses, even for very large heaps.
- NikolaeVarius 8y agohttps://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote Seems like it can go sub 1ms
- pcwalton 8y agoYou 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.
- nullstyle 8y agoIt 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?
- pcwalton 8y agoGo 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.)
- pjmlp 8y agoAnyone doing HTML 5/Flash like games in Go doesn't need to worry like if they are writting the next Fortnight in Vulkan.
- coldtea 8y ago>? 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...
- crowhack 8y agoYeah 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.
- BoysenberryPi 8y agoGame 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.
- andrewmcwatters 8y agoYep. 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.
- pjmlp 8y agoIf they use Unreal, they are using C++ with GC.
- robmaister 8y agoOnce 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
- pcwalton 8y agoThe 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.
- andy_ppp 8y agoI 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.
- gameswithgo 8y agofast compile times is a core value for Go would be one reason.
- mattnewton 8y agoThe 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_to_build_the_compilers https://golang.org/doc/faq#What_compiler_technology_is_used_...
- pcwalton 8y agoThe 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.
- gameswithgo 8y ago>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.
- stcredzero 8y agoThe 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!
- pjmlp 8y agoUnreal and Unity use a GC. It is a matter how it gets used, not that it is present.
- BurningCycles 8y agoFor 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.