8 ms·
There will be some crossover since Go's AOT compilation and low latency pause times will make some things that needed to be done in C++ or Rust viable in Go.
by jackmott 9y ago
There will be some crossover since Go's AOT compilation and low latency pause times will make some things that needed to be done in C++ or Rust viable in Go.
- themihai 9y ago>> make some things that needed to be done in C++ or Rust viable in Go. like "micro controllers, AAA game engines, and web rendering engines"? I highly doubt it! Swift 5+ might have a chance but Go has none(as it is now).
- AlexeyBrin 9y ago> Swift 5+ might have a chance but Go has none(as it is now) As long as it lacks Windows support Swift has no chance to be even considered for an AAA game engine.
- iainmerrick 9y agoThat seems relatively easily fixed, if any biggish company cared enough to do it?
- vvanders 9y agoYup, like the post about Discord processing images from yesterday underscored. If you need top tier performance you're going to have to reach for a language like Rust, C or C++ because without discrete control over your allocations and memory placement you will have something slower. C# is about the closest thing these days thanks to value types but even then Unity had to drop down to C++ to really get the performance they needed at the engine level.
- moomin 9y agoYeah, but it seems to be fine for something like Docker.
- eric-hu 9y agoSounds like you're advocating a Rocker project.
- solidsnack9000 9y agoDocker could also have been written in Java or Python, though, because most of the heavy lifting is provided by the kernel.
- perfmode 9y agoDocker is more I/O bound than CPU bound, so Go is just fine.
- jeremiep 9y agoI wrote the most non-idiomatic C# in Unity to create a lighting fast 2D skeletal animation system (100-1000x the performance of the closest competitor) and I'm certain I could've gained yet another order of magnitude had I access to C++ instead of C#. C# is fine for scripting, but absolutely terrible for performance critical batching where branch predictions and cache misses are your main optimization points. Also the lack of array slices make it really hard to avoid memory allocations.
- vvanders 9y agoYeah, that's my biggest gripe with the "GC'd language are as fast as native" crowd. You end up doing all sorts of contortions in order to get the allocation/cache coherency that you need that you're better off using a language that has proper support for it. I love scripting languages for orchestrating logic(luaJIT!) but when you need to massively vectorize your data so that you get full utilization of the prefetcher there really is no substitute.
- abiox 9y agoc++ is used in a lot more than just "micro controllers, AAA game engines, and web rendering engines".
- nine_k 9y agoMany controllers are not hard-realtime. Think e.g. of microwave ovens or smart locks. Often you might be willing to trade a 10ms GC pause of Go for much lower chances of memory corruption or crashing compared to C.
- vvanders 9y agoMany controllers have almost zero memory headroom meaning your GC pauses get an order of magnitude slower if not more as you have less than 2x your working set. Also, most of the applications never allocate because they can't even afford the overhead of pooling/freelists that come with a stock malloc implementation.
- abiox 9y agois a gc all that relevant if you're not dynamically allocating in either case?
- vvanders 9y agoGarbage collection by its nature implies dynamic allocation. You're using value types and raw pointers in those targets because even the memory overhead of a heap/freelist/etc can be too much. With things like AVR you're looking at 512B to 16kB of total memory(part of which includes the code you write).
- abiox 9y ago> Garbage collection by its nature implies dynamic allocation i'm not sure i follow - you're saying that a gc existing implies that one cannot preallocate and avoid dynamic allocation?
- vvanders 9y ago> preallocate This will still use dynamic allocation to do the preallocation. You'll have a heap to track this which comes with its own overhead.
- jackmott 9y agoLike AA games/game engines, and some micro controllers sure. Desktop applications like text editors where waiting for JITs and high pause times are annoying unlike things running on server as well.
- jeremiep 9y agoI don't see Rust as ready for AAA game engines, not by a long shot. Last I checked it had absolutely terrible reflection capabilities and meta-programming; both of which are used as the foundations of modern engines. A game engine is also radically different than your usual use of Rust; its almost impossible to model with borrows without going dynamic and those come with runtime overhead; something not acceptable when you're used to zero-cost abstractions. A web rendering engine has ridiculously less state and moving parts than a game engine. D would be a much better fit for game engines than Rust.