Hacker News Reader

Comment by gary_0 | Hacker News Reader

C# is very fast on average, but due to its runtime/GC it won't give you the consistent performance you need for game engine internals, which is what they meant by "slow".

View on HN

Unless we are talking about Assembly, all languages have runtimes.

As for the GC, it can be turned on in critical code paths, C# supports manual and stack memory allocation.

Profilers exist, many console games have been shipped in C#, besides Unity, there are Xenko, FNA and MonoGame custom builds for game consoles.

Compare the demo on the blog with,

https://store.steampowered.com/app/236090/Dust_An_Elysian_Ta...

https://store.steampowered.com/app/985890/Streets_of_Rage_4

https://store.steampowered.com/app/107100/Bastion

https://www.pcgames.de/Arena-Wars-Spiel-18141/Tests/Arena-Wa...

All of them done in regular C#, not even taking into account Unity and its DOTS/Burst C# subset.

> Unless we are talking about Assembly, all languages have runtimes.

My point was that some languages have heavier runtimes than others (out of the box, at least).

And yes, C# is very popular for gameplay code, but I'm talking about the parts of an engine that typically use systems programming languages. Even then, you can shoehorn C# into that role with some tweaking and AoT compilation (which is a testament to the C# ecosystem's versatility). But I was just explaining why I think the word "slow" was used regarding the C# language in general, even though it's not perfectly technically correct.

There's also Terraria, which is the 15th best-selling game of all time. Written in C# (XNA).

Mentioned elsewhere in the thread, the author might be alluding to the quickly-aging Mono implementation as that's common in game engines with C# support (e.g. Unity and Godot).

What happens when a best seller loses its language support? Isn't XNA deprecated?

There's always FNA.

My last 8 yrs of game development have been in a good part about how to make c# go fast, and it is definitely possible, but you will have to write in a style that is different from the norm.

Before C and C++ became widely acceptable for game development, we used to read these bibles like these,

https://www.jagregory.com/abrash-black-book

https://www.amazon.com/PC-Intern-Encyclopedia-Programming-De...

https://www.amazon.com/Black-Art-Game-Programming-High-Speed...

Very little regular C and C++ code, plenty of inline Assembly.

Can you please elaborate on that, or provide some links?

A few other commenters hit the points better, but mostly it comes down to avoiding allocating objects every frame/tick. In part this is through avoiding LINQ, lambdas, yield return, async etc. (fine to use in code that is run once like startup, or on relatively rare triggers) Using struct, arrays of struct/value, Span<>, ref, fixed etc. to keep memory access sequential or on stack. Use mutable structs, avoiding properties, avoiding struct constructors, moving throws into utility methods, etc. to support (the rather weak) optimizer to do more inlining. And move data processing of arrays of struct with tight loops, like compression, lighting, meshing, pathfinding into a native c++ dll/so or if applicable gpu. (c++ autovec/simd optimizations or much better than what the clr optimizer currently provides)

Ok, I see, thanks. Why then using C#/.NET at all if you have to do without many (most?) of the conveniences of this technology, and even have to consider to implement parts in C++ for performance reason? Why not directly e.g. C++?

For the same reason that many C and C++ games were actually using them as high level macro processors full of inline Assembly a couple of decades ago.

There are some conveniences that come with the technology and not every code path on the game engine is screaming for perfomance.

If you are on the path for the ultimate performance like some console titles, the C and C++ code on those engines will be very alien to most developers as well, yet you don't seem many discussing that.

Just on the subject, here is a talk I saw recently on the theme,

"Beyond the Remake of 'Shadow of the Colossus': A Technical Perspective"

https://www.youtube.com/watch?v=fcBZEZWGYek

However not every single game out there is trying to fit Shadow of the Colossus into a PS 2 or XBox 360.

Because the hot paths in the code are not the majority of the code. C# is (for me) much more productive to write than c++. More powerful refactoring tooling due syntax that is much easier for tooling to process. Powerful autocomplete, autorefactoring tooling. Easy code navigation due to easy to process syntax. The tooling also responds much faster, c++ refactoring tools seem to take a long time to process code. Big reduction in footguns/UB etc. Very quick iteration cycles, edit-and-continue in sub second, stop-edit-restart cycles in the low single second range. Very good debugging, objects are inspectable and editable, stacktraces reliable. Edit-and-continue makes for very quick probing of internal state. The c++ code is around 1% of LOC and 20% of cpu cycles, seems like a good balance. Bounds checking, lack of dangling pointers/use after free, removes a whole class of hard to debug bugs.

Reply on news.ycombinator.com