Unity Is Growing Their LLVM Compiler Team As They Try To Make C# Faster Than C++

[wizard69]

You guys are off on a tangent here with memory management, I’m rather shocked that a company like Unity would even bother with C#. Maybe it is the circles I travel in but C# seems to be very dead as a language. I can’t imagine that they will get a rush of developers to work on C#.

[computerquip]

Memory management is hard to get perfect. It shouldn't be hard to do it well and I wouldn't say it's particularly hard.

I have no problem with garbage collection itself. it can actually be pretty cool in that it *can* be easier to debug memory leaks, it *can* be faster, and it *can* be easier to manage (among a few other things).

It's just never that way in reality. Because of the way garbage collection gets advertised, the people who use garbage collected languages basically think memory management is no longer a thing and end up doing ridiculous things with memory. In some cases, the language prefers/encourages it as well, making matters worse. It's gone from, "Here's a way to make memory management easy" to "Here's a way to be as inefficient as possible with memory".

For the main topic, C# can be a fine language. I've used it in personal projects a handful of times frankly. I like it.

[Guest]

Um, no... There is -no- garbage collector that can manage memory... GC is -not- memory management. There is -no- possible way for any GC mechanism to perform decent let alone well. And it far, far worse in memory constrained scenarios. I'm pretty sure Google has already proved to billions of people worldwide how terrible garbage collection is with android.

Uhm.. No,.. The problem with Android apps is that they are bloated,.. if Google had picked c++ as the primary language for Android alps, then it would have proved how c++ is unstable, buggy, and memory eater (due to memory leaks). I personally saw android developers who don't care to write sane code even in Java.. I wouldn't like to see them writing c++ apps..

[fuzz]

Maybe it is the circles I travel in but C# seems to be very dead as a language. I can’t imagine that they will get a rush of developers to work on C#.

It is very, very far from dead with a huge pool of developers. But they are mostly "dark matter" developers that the rest of the dev community ignores, and they tend to go on without much fanfare.

It's also one of the better languages out there, in my opinion.

[kpedersen]

Wrong. Ada predates C++ and Rust's borrow checker is something totally different..

That's kinda my point. If Ada predates C++ and Ada is stated to have RAII in a number of literature... how is RAII a C++ only "feature"?

The phrase Resource acquisition is initialization... is there anything in there that suggests it is impossible in any other language?
So long as you have access to knowledge about deterministic lifetime of the scope of an object, it is possible.

Microsoft has even shown that a purely garbage collected language "C++/clr:safe" can still utilize RAII.
If you reverse this generated code using ILDASM, you can see it really is just a try / catch statement within every function.
Heck, with a try / catch in every function you could do this in Java.

Now I am more than happy for RAII to be quite unique to C++. In fact C++ is the only language I would recommend because the solutions provided to a lot of problems *are* elegant and fairly portable compared to massive bloated GC languages like Java or .NET.
But in practice, I do understand that most technology (not even language at this point) is quite easy to share between languages.

[ypnos]

Of course, you could actually take a look at -any- code..... But that's probably way beyond you.....

Sure mate, you won this argument easily, how can you be so smart?

[Weasel]

You guys are off on a tangent here with memory management, I’m rather shocked that a company like Unity would even bother with C#.

What's "a company like Unity" supposed to mean here? It's already trash tier among the relevant engines.

[kpedersen]

I originally (yesterday) wanted to post a longer response. That didn't work out. The short version is as follows:

I am hesitant to use std::weak_ptr because composition of std::weak_ptr is impossible. If the programmer puts a graph of std::shared_ptr behind std::weak_ptr, and the graph entrance is reachable only via weak pointers, then all the std::shared_ptr in the graph effectively become std::weak_ptr. The contradiction is:

• The programmer cannot use std::weak_ptr in the graph because constructing/initializing the graph requires std::shared_ptr
• The programmer cannot use std::shared_ptr in the graph because that would lead to a memory leak
  
  Solution with current state of C++ STL: The programmer has to manually write code computing the liveliness of the mentioned graph

This parent child relationship with reference counting is fairly well explored; the main solutions are:

1) In a hierarchical structure you would use std::shared_ptr downwards and std::weak_ptr upwards. That way you can have the graph "hanging off" the shared pointer root and individual branches.

2) a single flat list of shared_ptrs *and* then a graph structure, all of weak pointers.

Or am I missing what you mean?

Some might say that stating this "ownership" of data is manual memory management. I personally think that shared / weak pointers in the header just seem like useful annotation. One that I would even do in Lua scripts.

That said, the hybrid approach of reference counting *and* limited garbage collection would be the ideal case, then you could just use something like shared_ptr.
There are already some "stubs" in the standard to help facilitate this garbage collection (https://en.cppreference.com/w/cpp/me...lare_reachable) but no formal garbage collector yet.
The closest to this hybrid approach is probably UE4; although they err on the side of GC a little too much IMO.

Slightly off topic but I would also note that locking a weak pointer to get a shared pointer to go up the hierarchy is often cited to be "slow". However I find this quite amusing because in my tests, it is quite a bit faster to trivially increment a reference count and create a stack object than it is to go through all that machinery in C# to even call *any* managed function by the VM; and yet Java and .NET developers are always trying to suggest that non-native / jit languages can be on par with native C++ :/

[duby229]

Uhm.. No,.. The problem with Android apps is that they are bloated,.. if Google had picked c++ as the primary language for Android alps, then it would have proved how c++ is unstable, buggy, and memory eater (due to memory leaks). I personally saw android developers who don't care to write sane code even in Java.. I wouldn't like to see them writing c++ apps..

I think your premise is wrong, but I can't argue with your points, you're right.

[oleid]

Uhm.. No,.. The problem with Android apps is that they are bloated,.. if Google had picked c++ as the primary language for Android alps, then it would have proved how c++ is unstable, buggy, and memory eater (due to memory leaks). I personally saw android developers who don't care to write sane code even in Java.. I wouldn't like to see them writing c++ apps..

I wouldn't like to see C++ to be the main language for Android development, either. But it's really hard to accidentally program a memory leak in C++14, unless you use archaic memory management stuff. Crashes due to poor thread management is what I'd expect more.