Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Xamarin now free (and supposedly open source)

Discussion in 'General Discussion' started by Acissathar, Mar 31, 2016.

  1. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    .NET Native is a pretty cool piece of technology. It beats IL2CPP in some areas (notably generics performance and virtual/interface calls) and loses to IL2CPP in others (math heavy code, interop). At least that was the case last time I checked, which was around a year ago. Since we support UWP with both .NET Native and IL2CPP, I guess you can test it out yourself and tell us which one you line more :).

    It would be interesting to compare its performance vs Unity with IL2CPP.
     
  2. mdrotar

    mdrotar

    Joined:
    Aug 26, 2013
    Posts:
    377
    Well, I said in an earlier post:
    "let WebGL be the one under constant development with IL2CPP and let everything else get the upgrade now."

    You could upgrade .NET for everything that supports it already and then focus IL2CPP on the rest of the platforms (WiiU/3DS, WebGL) to bring the .NET upgrade sooner. Now that Xamarin is free, I just don't see the need to get all platforms working with IL2CPP before a .NET upgrade can occur. Especially since 1) IL2CPP is already "done", and 2) it's been promised that all platforms that support .NET/mono runtime will also have the option to use mono in addition to IL2CPP.

    I get a bad feeling when reading this. The .NET upgrade has been on Unity's radar for about 5 years now.
     
    Qbit86 likes this.
  3. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,946
    Wouldn't that slow development even further than it already has been? ;)
     
  4. mdrotar

    mdrotar

    Joined:
    Aug 26, 2013
    Posts:
    377
    What do you mean exactly?
     
  5. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,946
    Doesn't it go without saying that maintaining both IL2CPP and the framework separately is more work? :p
     
  6. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    That's why I said "help improve"... I wasn't meaning to replace IL2CPP from .NET Native, I just meant that since you're part of the .NET Foundation maybe the two technologies can benefit from eachother.
     
  7. mdrotar

    mdrotar

    Joined:
    Aug 26, 2013
    Posts:
    377
    I'm not a mind reader. There are several things you could've been alluding to and I wasn't going to guess or respond to them all.
    They have to do that anyway. So, no.
     
  8. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,946
    No, they have to maintain the current code base. They aren't exactly upgrading the framework itself right now.
     
  9. mdrotar

    mdrotar

    Joined:
    Aug 26, 2013
    Posts:
    377
    ...
     
  10. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,946
    You're neglecting to take the remainder of his post into context. An earlier section of the same post pointed out that without the progress IL2CPP has made the profile upgrade would be blocked from continuing. Therefore your suggestion that they do it as a separate path most likely wouldn't work.
     
  11. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    Kind of. They only have to maintain one instance of the framework and it's portability to IL2CPP whereas before not all platforms natively supported Mono so they had to maintain customized versions on a per-platform basis. That will no longer be necessary. Any time they upgrade a profile, they will be able to upgrade IL2CPP to support it and that will be all that's necessary to make it portable to other platforms.

    Personally, I think the next .NET Profile upgrade should take a strong look at the new Net Standard profile that's in RC2 (part of Core CLI). This will help to maintain compatibility moving forward and should also help make porting platform upgrades to IL2CPP easier and more of an iterative process.

    It was only really ever blocked because of Xamarin licensing. It's technically no longer "blocked" by that since Xamarin is free.

    However, the points I outlined above as were previously stated by @Tautvydas Zilys, technically are a blocker as they make platform migrations more painful when sticking with Mono, so the native build toolchain (IL2CPP) is the right path as it will help Unity stay fresh and current in terms of platform technology once it's ready for that upgrade.
     
    Ryiah, Paulohmm and elbows like this.
  12. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    That would make Unity projects less cross platform, and it would essentially mean fragmented user base, plugins etc. It's terrible as it is already for platforms using .NET scripting backend. We definitely don't want to go there again. It's not going to happen.
     
    Ryiah and angrypenguin like this.
  13. mdrotar

    mdrotar

    Joined:
    Aug 26, 2013
    Posts:
    377
    What about the platforms which still support/require the regular .NET (or mono) runtime, such as Windows Store and the Unity Editor?
     
  14. Qbit86

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    487
    In my case (Android, iOS, WSA) that would immediately make project more cross platform, actually, since there would be smaller gap between modern Xamarin and .NET (that flavour for WSA).
     
    darkhog likes this.
  15. mdrotar

    mdrotar

    Joined:
    Aug 26, 2013
    Posts:
    377
    I meant still have IL2CPP work with new .NET. For example, Unity already supports an option between IL2CPP and Mono for Android. Wouldn't it have been quicker to skip IL2CPP for Android, instead focusing that effort toward IL2CPP for WiiU. Then when IL2CPP is working with WiiU, WebGL and the other platforms that Xamarin doesn't support, upgrade the .NET profile. Then bring IL2CPP to the remaining platforms.

    Not that you can go back in time and undo IL2CPP for Android. What I'm getting at is, it seems like IL2CPP itself is more of a priority than upgrading .NET. Long-term, IL2CPP does sound like the best option, but it sucks building a codebase that's outdated as soon as it's written because it's based on .NET 2.0.
     
    darkhog and Qbit86 like this.
  16. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,568
    But once IL2CPP is solid on all platforms, the .NET version will be upgraded.
     
  17. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    For Mono platforms, we'd update Mono profile together with IL2CPP. For .NET on Windows Store... we aren't in the position to update - Microsoft dictates what kind of .NET version and libraries these applications can use. That's why we're working on getting rid of it.

    There's not much code in IL2CPP that depends on a particular .NET profile. Most of that are internal call implementations. Certainly no platform specific code knows about the profile it's running.
     
    Ryiah likes this.
  18. mdrotar

    mdrotar

    Joined:
    Aug 26, 2013
    Posts:
    377
    Oh, I meant my codebase. But that's good to hear.
     
  19. darkhog

    darkhog

    Joined:
    Dec 4, 2012
    Posts:
    2,218
    I don't think IL2CPP will bring any *noticeable* performance gains over Mono 4 (or newer) and their improved GC (which is main problem regarding performance in Unity). Sure, it is better than antiquated Mono 2.x, anything really is, but performance gains over just utilizing Mono 4 now that it's free to do so will be minimal and not worth increased build time.

    IL2CPP makes only sense (and really, minimal one at that) on platforms that for whatever reasons can't or won't support managed code. For platforms that support Mono/.NET upgrading to Mono 4 makes more sense - IL2CPP in case of Mono-supported platforms makes as much sense as Unity's flash exporter.
     
  20. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    I just want speed. I don't give a rats ass about fancy language features as I make video games. Would hate to have to switch to another engine just because script perf sucked.

    Pretty sure lots of people think exactly that. Speed = more visuals, more everything, easier.
     
    Brity and ZJP like this.
  21. darkhog

    darkhog

    Joined:
    Dec 4, 2012
    Posts:
    2,218
    And Mono4 will give you exactly that. There are benchmarks online, between good, handwritten Mono 4 C# and handwritten C++ and differences are either miniscule or in favor of Mono 4/.net 4.6. And remember that IL2ASM will generate C++ code from IL assembly, and generated code isn't as fast as handcrafted one.

    IMO, isn't worth increased built times if you get say 72 fps (IL2ASM) instead of 71 (Mono4) or other similarly low and laughable difference. That being said, IL2ASM still is needed for platforms that can't use Mono/.NET for technical (consoles other than XBone) or political (Apple devices) reasons. But other platforms would be satisfied with Mono 4 and then IL2ASM can arrive at a latter date.
     
    Qbit86 likes this.
  22. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Of course it's worth it, since build times on device are much less frequent than editor testing, which is instant. Particularly with fixed platforms like consoles, it matters.
     
  23. Qbit86

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    487
    I just want comfort. Life is too short to spend it coding in unenjoyable Cobol, C#−− or Fortran. I feel disadvantage comparing to those my colleagues (not game makers) who use up-to-date technologies. Because they are satisfied by both result of programming and entire process.

    It's not only about language, but about library too. Tired to back-port or reimplement standard classes like CancellationToken, Lazy<T>, Task<T>, IObservable<T>, etc. Many of them are not just only utils, but rather part of patterns and architectural approaches. BTW, knowing these approaches is prerequisite for applying for a job as C# developer in majority of companies (not game maker companies, alas). It won't work if you say that you have 8 years of C#−− experience with no understanding, how modern development occurs.

    Unreal Engine has already offered better performance. But performance isn't the only thing, is it?
     
  24. yoonitee

    yoonitee

    Joined:
    Jun 27, 2013
    Posts:
    2,363
    My guess is what's probably happening is this:

    Unity will replace IL2CPP with a modified version Xamarin with Microsoft's help and expertise.

    They will then "rebrand" the modified Xamarin-for-Unity as "IL2CPP".

    So that way they can complete project a year-or-two faster while using the more tested Xamarin while still claiming to have stuck to their path on IL2CPP.

    At least that would make the most sense.
     
    darkhog likes this.
  25. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,946
    Except IL2CPP supports far more platforms. It wouldn't make sense in the slightest unless they were planning to ditch support for the majority of their platforms and at that point they may as well have used Mono directly.
     
    Deleted User likes this.
  26. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Yep but you guys have already littered this thread with your benefits. I'm offering the other side of the coin, and that is many want ease of use AND speed. You're already going to get it, you just have to wait a little bit. I don't see the fuss in waiting a few months.
     
  27. mdrotar

    mdrotar

    Joined:
    Aug 26, 2013
    Posts:
    377
    Do you have information the rest of us don't? Because according to the roadmap the .NET Profile Upgrade is a loooong ways off. Definitely not a few months.
     
    Qbit86 likes this.
  28. Qbit86

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    487
    I don't have too many of them :)
     
    rakkarage likes this.
  29. darkhog

    darkhog

    Joined:
    Dec 4, 2012
    Posts:
    2,218
    Exactly. On top of that with performance improvements of C++ over just using Mono 4 being so miniscule (again, google c++ vs. Mono 4 benchmarks - mostly you'll find either comparable performance, very small improvement over Mono4 or Mono4 being straight up faster. And that is for handwritten code, generated c++, which is the case for IL2CPP, will be slower), there's also issue of debugging as the IL2CPP, due to its native nature, can't produce as complete stack traces and so on the way Mono can.
     
    Qbit86 likes this.
  30. JasonBricco

    JasonBricco

    Joined:
    Jul 15, 2013
    Posts:
    956
  31. darkhog

    darkhog

    Joined:
    Dec 4, 2012
    Posts:
    2,218
    Look for those that shows sources for either. In this one code on C# side could even be
    Code (csharp):
    1. for (int i=0; i<1000000;i++) {
    2. //some long operation unrelated to the benchmark
    3. }
    4. //actual benchmark code
    for all we know. Or time was measured in the wrong way.

    //edit: Something like this: http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET

    Also please remember than generated C++ will be ALWAYS less performant than handwritten one, so also take correction for that when comparing results.
     
  32. rakkarage

    rakkarage

    Joined:
    Feb 3, 2014
    Posts:
    683
    when will we be able to use the 5 year old new csharp features?
     
  33. darkhog

    darkhog

    Joined:
    Dec 4, 2012
    Posts:
    2,218
    OK, so this is c# code for one of their benchmarks (fannkuch-redux). So many things wrong with this.

    First of all, ? operator in Mono is slower than just using if (something) someInt = 4; else someInt=5; construct. Next, look at the NextPermutation function (pun not intended). For starters, it always return true. So why even return value? Not performance thing per se, but bad coding practice, it should be void instead and all ifs dependend of NextPermutation's return value should be optimized away, since it'll be always true anyway.

    More I think about this, it seems like the code was just translated using some kind of automatic tool (hint, hint), which affected the results. Give me one that does same task for both C++ and C#, but which has finetuned C# code to the way .NET does things (esp. regarding mem management) and finetuned C++ code to the way C++ does things and then results will be more reliable.
     
  34. JasonBricco

    JasonBricco

    Joined:
    Jul 15, 2013
    Posts:
    956
    I didn't read much into it. I have seen benchmarks that show the performance to be a lot closer as well, so I was a bit surprised at first to see those results. My understanding in general is that C++ is quite a bit superior for math-heavy code (which I write a lot of), but maybe not so much for other areas.

    Edit: but I can't really see much that would really explain those performance differences in there.
     
    Last edited: May 1, 2016
  35. Qbit86

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    487
    Something strange. My comparison shows huge difference between IL2CPP (Unity 5.3.4f1) and Xamarin (Xenko 1.6.3-beta), much bigger than I expected.

    I've taken this n-body program:
    http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=csharp&id=1
    (Can add adapters for other benchmarks.)

    Implemented simple playground on both engines with FPS output and difficulty input (as you change difficulty linearly, algorithm parameter changes exponentially). On my Android device (Xiaomi Mi4-c) the result is like following:
    Difficulty: 23, IL2CPP FPS: 3, Xamarin FPS: 14
    Difficulty: 22, IL2CPP FPS: 4, Xamarin FPS: 15
    Difficulty: 21, IL2CPP FPS: 6, Xamarin FPS: 20
    Difficulty: 20, IL2CPP FPS: 9, Xamarin FPS: 27
    Difficulty: 19, IL2CPP FPS: 13, Xamarin FPS: 28

    Git repo: https://bitbucket.org/biqt/tinhola
     
  36. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    Can you retest with Unity 5.3.4p1 or later? Up until that version (including 5.3.4f1) on Android we would compile generated C++ in debug configuration, that means no optimization and a lot of debugging stuff that would slow down the code. This was fixed in 5.3.4p1.
     
  37. darkhog

    darkhog

    Joined:
    Dec 4, 2012
    Posts:
    2,218
    Violet dot.
     
  38. Qbit86

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    487
    Now much better on Unity 5.3.4p5! I even had to remove lighting and objects from Xenko default scene, and switch off Debug configuration.

    Code (csharp):
    1. | Diff | IL2CPP | Xamarin |
    2. |------|--------|---------|
    3. | 20   | 60     | 60      |
    4. | 21   | 54     | 50      |
    5. | 22   | 35     | 34      |
    6. | 23   | 21     | 22      |
    7. | 24   | 13     | 13      |
    Looks like Xamarin is quite close; but it's better if someone double-check benchmarks in case if I'm biased.

    In repository linked above: `Agnostic\` contains engine-independent classes (should be identical for both engines); `Scripts\` contains engine-specific code with the same functionality; `ProblemBase` is interface adapting different benchmarks, one could implement it to test another problem.
     
    Ryiah, zyzyx, Paulohmm and 1 other person like this.
  39. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,946
    You have a lot of faith in people. :p
     
    Deleted User and Dustin-Horne like this.
  40. igouy2

    igouy2

    Joined:
    May 2, 2016
    Posts:
    2
    Ryiah likes this.
  41. igouy2

    igouy2

    Joined:
    May 2, 2016
    Posts:
    2
    You only mention two things wrong, and you say one of those does not effect performance.

    Do you claim that explains why the C# program took 86 seconds CPU but the C++ program only took 51 seconds CPU ?

    Show you can do better, contribute your best C# programs -- http://benchmarksgame.alioth.debian.org/u64q/play.html
     
    JasonBricco likes this.
  42. Qbit86

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    487
    But, if I understood correctly from the link below, Unity Technologies actually are going to use latest Xamarin for updating compiler, language, libraries, and runtime? Had something changed, or I've just misinterpreted that thread?

    https://forum.unity3d.com/threads/some-questions-about-the-new-mono-compiler.433666/
     
  43. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    Yes, we are going to take class libraries and compiler from Mono, and we're going to use their runtime for Mono scripting backend. Also, we might reuse parts of it for il2cpp runtime.
     
    JamesArndt, MV10 and Qbit86 like this.
  44. Qbit86

    Qbit86

    Joined:
    Sep 2, 2013
    Posts:
    487
    Why did you decide to reconsider this: “We definitely don't want to go there again. It's not going to happen.”? Could you please write a post to Unity blog about technical details of migrating to updated Mono on different platforms (including Android, Editor and PC)? It would be very interesting!
     
  45. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    There's some misunderstanding. The thing that I said isn't going to happen was this:

    It's still going not going to happen. All platforms will get .NET upgrade at the same time: some through the help of IL2CPP (mobile platforms), some through the help of new mono runtime (editor, standalone).
     
  46. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    Are there plans to also get IL2CPP support for standalone builds?
     
  47. MV10

    MV10

    Joined:
    Nov 6, 2015
    Posts:
    1,889
    It has become a little murky to me who's driving IL2CPP at this point, but Microsoft types have made recent MSDN blog posts indicating full-native compiles are part of their big new .NET Core cross-platform roadmap, so I wouldn't be surprised if that's on the radar.
     
  48. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    Unfortunately same answer as before remains: it's lower priority than the stuff we're doing right now (mostly .NET profile upgrade).
     
  49. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    That's fine, I'd just like to know it'll eventually happen.
     
    JasonBricco likes this.
  50. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,644
    It's on our radar, but I think promises today are pointless as we have no idea when we'll be getting to it.