Zkuq said:
Isn't the main problem with garbage-collected languages unpredictable and possibly noticeable GC pauses? Obviously languages with a runtime get other performance penalty as well, but I'm still under the impression that the biggest culprits are bad software design and GC pauses. |
Yeah, GC pauses result in terrible performance until they finish. Most GC implementations require all threads to sleep while GC is taking place (they can't handle simultaneous changes to the graph of program memory while walking said graph to find memory islands). The bad software design angle the result of bad programming/bad management. What you have to watch out for is twisting your program's design to avoid the garbage collector (preallocating arrays/objects, etc.). C# just isn't a good language for high performance (AAA/AA) games because of said garbage collector. Indie games may get away with it, but you really have to know unity to make a good, performant game in it (many don't, which is why poor performing Unity games get released all the time). That said, there is something to heap compaction. On the other hand, needing to use new (which allocates memory) everywhere is definitely a bad thing.
Handle tables are pretty cool though. You can do that in C/C++ just fine. C++ is another bag of worms all together. Not a fan of C++ to say the least. If I had a say, I'd just use plain C. Easier to parse (meta-programming), easier to use, and easier to estimate the performance of resulting assembly code.
Currently (Re-)Playing: Starcraft 2: Legacy of the Void Multiplayer, The Legend of Zelda: A Link to the Past
Currently Watching: The Shield, Stein's;Gate, Narcos







