Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mono for Unreal Engine

tirania.org

Post reply on HN
Print view View original

41–50 of 94 posts

Re: Mono for Unreal Engine

#41

Post by Skinney »

azakai wrote: post #39
migueldeicaza wrote: post #35

Earlier quoted context omitted.

Small clarification. It is faster than the old Mono they ship. Their Mono is at best Mono 2.10, about three years old, without any of our optimization work for three years, very notably, a lot of the LLVM support, or the new garbage collector. That said, the il2cpp looks like a very promising an interesting project, so kudos for that!

Yes, I think those benchmarks are based on the Mono they use, which is indeed old. I would be very curious to see benchmarks compared to trunk Mono - should be interesting. My information may be out of date, but typically people tell me that Mono tends to not match Microsoft's .NET implementation in speed, and in turn, .NET tends to not match native C++ either. So I would still guess il2cpp can win here. Or are there…

It's important to consider that C++ code, is not the same as C# to C++ code. The Facebook guys originally converted PHP to C++ code for speed, just like il2cpp, but eventually they wrote a JIT because it was faster AND they could keep the dynamic features like code generation and dynamic loading.

C# is ment to be a safe language, unlike C++ which has, among other things, the notion of undefined behaviour and manual memory management. This is what makes C# initially slower than C++. You might be able to compensate with a JIT, but safety still costs. Not to mention, the Unity guys will still probably have to implement their own GC and spend years on optimisations.

Also, several games are using dynamic loading for things like plugins and mods, as far as I know, il2cpp will force them to change how this is implemented.

From my standpoint. The cheapest option, and best option for everyone really, is to continue using (an up-to-date) Mono and instead allow for writing games in C++ as well.

Re: Mono for Unreal Engine

#42

Post by azakai »

Skinney wrote: post #41
azakai wrote: post #39

Earlier quoted context omitted.

Yes, I think those benchmarks are based on the Mono they use, which is indeed old. I would be very curious to see benchmarks compared to trunk Mono - should be interesting. My information may be out of date, but typically people tell me that Mono tends to not match Microsoft's .NET implementation in speed, and in turn, .NET tends to not match native C++ either. So I would still guess il2cpp can win here. Or are there…

It's important to consider that C++ code, is not the same as C# to C++ code. The Facebook guys originally converted PHP to C++ code for speed, just like il2cpp, but eventually they wrote a JIT because it was faster AND they could keep the dynamic features like code generation and dynamic loading. C# is ment to be a safe language, unlike C++ which has, among other things, the notion of undefined behaviour and manual m…

Good point about code compiled to C++ not being the same as idiomatic C++ code.

However, unlike PHP which is dynamic, C# is statically typed. It is a much more direct match for C++, and performance should be pretty good.

But with that said, I think your point still stands, as there are still things like bounds checks in C# which would need to remain when compiled to C++, while idiomatic C# might not have those checks.

I wonder though if those bounds checks couldn't be disabled in some cases. Sandboxing isn't a concern on the Unity WebGL port, for example, since the browser provides that, so il2cpp code doesn't need to be safe in that sense.

Re: Mono for Unreal Engine

#43

Post by eropple »

migueldeicaza wrote: post #35
azakai wrote: post #31

Earlier quoted context omitted.

Unity is writing a C#-to-C++ compiler, il2cpp, see http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-... it's much faster that Mono on some things currently, http://blogs.unity3d.com/2014/10/07/benchmarking-unity-perfo... but it is so far only used in the WebGL port. Long-term, il2cpp is meant to replace Mono in Unity, according to the first of those links.

Small clarification. It is faster than the old Mono they ship. Their Mono is at best Mono 2.10, about three years old, without any of our optimization work for three years, very notably, a lot of the LLVM support, or the new garbage collector. That said, the il2cpp looks like a very promising an interesting project, so kudos for that!

Can't be understated - I've benchmarked my current MonoGame stuff with 2.10 and 3.10 and the modern stuff is leaps and bounds better in terms of GC performance (that alone being my biggest hurdle). Perf improvements have been coming very steadily and while there are areas I wouldn't recommend it for I wouldn't hesitate in recommending it for the logic level of many games.

Re: Mono for Unreal Engine

#44

Post by HeshamA »

Xelom wrote: post #13

This means a lot to me. I will try to contribute to this one, nice kickstart guys! I don't have much C++ experience and I had doubts about getting into UE only with blueprints. It feels like there will be cases that I won't able to cover just with blueprints. I was experimenting Unity just because of their C# support but now I can gladly turn back to UE and it is more exciting for me.

As a long time Unity developer that hasn't touched C++ in years, I can say that I have been experimenting a lot with UE4 and I haven't really needed to touch C++. Blueprints are really powerful.

Having said that, I'm really excited to see c# supported.

Re: Mono for Unreal Engine

#46

Post by general_failure »

forgotAgain wrote: post #21
AlexeyBrin wrote: post #4

Hopefully, Xamarin will add Visual Studio support in the Indie dev plan at some point. Currently, if you want to support iOS, Android and use Visual Studio you need to pay $1798 per year which is a bit more for a one man shop.

Or you could look at Apache Cordova. Support is in CTP now and full release in Visual Studio 2014 hopefully.

Have you shipped an app with Cordova?

Thought so.

I always recommend Cordova to my competitors

Re: Mono for Unreal Engine

#47

Post by drawkbox »

Definitely game changing. The barrier to move from Unity to Unreal is really low if this works out. Still best to do C++ where possible but this opens up Unreal drastically.

Re: Mono for Unreal Engine

#48

Post by tormeh »

azakai wrote: post #31
TillE wrote: post #17

Earlier quoted context omitted.

That was my number one reason for moving to UE4; announcing Unity 5 with no Mono runtime update was the last straw. Current versions of Mono could probably do a serviceable job with simulation-heavy games, but not Unity's ancient one. Bizarrely, they don't even have a C or C++ API. You can add native code libraries to your project in Unity Pro, but you always have to go through Mono to interact with the engine.

Unity is writing a C#-to-C++ compiler, il2cpp, see http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-... it's much faster that Mono on some things currently, http://blogs.unity3d.com/2014/10/07/benchmarking-unity-perfo... but it is so far only used in the WebGL port. Long-term, il2cpp is meant to replace Mono in Unity, according to the first of those links.

But why? Why not directly compile it by implementing an LLVM frontend? And if you're going to transpile like this, I would assume translating to Java would be easier, since the languages are really similar. The JVM is, depending on task, as much as four times faster than Mono, and that's the official Mono, not Unity's stagnated one.

Re: Mono for Unreal Engine

#49

Post by yulaow »

cpayne wrote: post #40
AlexeyBrin wrote: post #4

Hopefully, Xamarin will add Visual Studio support in the Indie dev plan at some point. Currently, if you want to support iOS, Android and use Visual Studio you need to pay $1798 per year which is a bit more for a one man shop.

For a larger corporate, ~$1,800 is very reasonable. Xamarin have a tough line to walk - larger companies will happily pay that price, while still being reasonable for indie developers. Xamarin support is excellent - their forums, twitter etc. I haven't worked with a vendor before that has been that helpful. Xamarin need to cover their costs. I've been using Xamarin Studio for a while now for both iOS & Android and it…

They just need to make two different price plans: you are a corporation? Here the corporation pack. You are a alone dev? Here a very lowered-price alone dev pack.

It is not that hard, just put a clause in the license that oblige the corporations to buy their related pack

Re: Mono for Unreal Engine

#50

Post by virtue3 »

azakai wrote: post #42
Skinney wrote: post #41

Earlier quoted context omitted.

It's important to consider that C++ code, is not the same as C# to C++ code. The Facebook guys originally converted PHP to C++ code for speed, just like il2cpp, but eventually they wrote a JIT because it was faster AND they could keep the dynamic features like code generation and dynamic loading. C# is ment to be a safe language, unlike C++ which has, among other things, the notion of undefined behaviour and manual m…

Good point about code compiled to C++ not being the same as idiomatic C++ code. However, unlike PHP which is dynamic, C# is statically typed. It is a much more direct match for C++, and performance should be pretty good. But with that said, I think your point still stands, as there are still things like bounds checks in C# which would need to remain when compiled to C++, while idiomatic C# might not have those checks…

C# has very defined behaviour that when "ported" to C++ is going to result in similar speed hits. Allocations are zero'd out. boxing/unboxing objects, array bounds checking.

GC is going to be the big hit as you're still going to need to pay for that even in C++ land. I'm not really seeing what you'd get over just C# with a more modern JIT unless you start converting to non-safe C code and doing sneaky c stuff behind the scenes (and I'm sure absolutely nothing will go wrong*).

The webgl stuff is fine to not be bound (I'm assuming it's being converted to js anyway?) but anything running in the plugin better be.

Post reply on HN