Hacker News Reader

Comment by 0x0 | Hacker News Reader

This should be good news for Unity3d, didn't they hold back on upgrading to modern mono versions for some sort of licensing issue?

View on HN

Yes this is correct. The worst part is currently the mono version Unity uses has a 'stop the world' garbage collector, the worse kind for a game as at 60 fps allocations quickly add up and the game can constantly freeze frame. The hoops you have to jump through to work around this make for some ugly code.

So everybody using Unity makes their games in a way so the GC never stop the game?

Yes, and it's a huge pain! We have to pool game object instances, and sometimes even have to attempt to force GC to prevent things from freezing every few seconds.

I've got a little secret: We do the same thing in native code.

malloc() and free() can be almost as expensive as a GC in aggregate(it's a matter of paying the cost at creation vs GC time). Pooling is a really nice performance tool, just requires a bit of hand tuning to the scenario.

So Pooling is a performance tool for both cases? Native and GC.

Pooling has a lot of nice properties, like data locality that games can benefit from greatly especially in situations relying on tight loop like calling update on every game component or particle.

Yup, sadly that's something you lose in GC'd languages.

It's really not that different from how games written in languages like C++ are implemented though. It's impossible to avoid the object pooling idea if you want maximum performance.

That's horrifying. Is there any way to disable the GC and manually manage memory? I don't remember if the C# spec supports this, because it's been years since I've written in it (and Mono didn't exist back then).

So there is... using the "unsafe" pointers and fixed keyword, etc. The Unity interfaces don't support that, though, so for things like dynamically updating textures and vertex data, you're pretty much stuck with GC.

You "disable" the GC in Unity by never allocating anything new after initializing the game. It's a great learning experience to update code to this and it's practically required for mobile.

There was a Squeak based game emulator/debugger shown at one Smalltalk Solutions. The developer talked about doing tricks, like turning off the GC. You'd know which objects were persistent, and which weren't, and at the beginning of the game tick, everything that wasn't persistent was assumed to go away. No scanning the heap at all.

That could have even been a factor in the decision. Microsoft wants people to use C#, but one of the most popular C# platforms (Unity 3D) is stuck in the dark ages, so to speak. Even conservative enterprise .NET shops probably have better tooling and workflows than your average Unity developer starting a new project. At least Unity bundles Visual Studio these days.

[deleted]

If this thread WAS about Windows (and not Unity), I have a feeling that the steam hardware survey is not a good indicator of how many potential C# users are using Windows. Maybe something like the Stack Overflow survey would be better - http://stackoverflow.com/research/developer-survey-2016#tech...

50% are Windows users according to that survey. Still a significant amount for sure, but not really the same thing as 95%.

Calm down, I think he was saying Unity. It's stuck on an old version of Mono.

This thread is about Unity, so obviously he was referencing Unity as the popular C# platform that's been stuck.

Yes, they rather spend developer salaries implementing IL2CPP, which is still work in progress, instead of paying for new licenses.

I do wonder if $developer_salaries < $Xamarin_licenses, specially taken into account most of the team is on Danish salaries.

I think about this and then think about what happens when you let a supplier drink of your milkshake. Which is when they use control of something you depend on to demand a share of your profits. It's worth money to not to be in that situation.

Are you sure they are on Danish salaries? Isn't the most of the company in San Francisco?

Might be, the point I was trying to make was that the cost per month for IL2CPP development isn't insignificant.

Being US salaries in SF doesn't change that much.

Reply on news.ycombinator.com