Search Unity

  1. Calling all beginners! Join the FPS Beginners Mods Challenge until December 13.
    Dismiss Notice
  2. It's Cyber Week at the Asset Store!
    Dismiss Notice

[Official] The collected il2cpp forum topic.

Discussion in 'General Discussion' started by RalphH, May 20, 2014.

  1. RalphH

    RalphH

    Unity Technologies

    Joined:
    Dec 22, 2011
    Posts:
    591
    Assuming you are talking about a C++ compiler overoptimizing; rearranging api calls with sideeffects that would affect control flow; that would be a very broken C++ compiler. In IL2CPP we won't be doing any rearranging of API calls. To the second part of your question; I'm not sure how that changes the situation from now ? The path is the same, yet we switch out the codegen for the platform away from Mono JIT/Mono AOT, and move it into our own.
     
  2. Metron

    Metron

    Joined:
    Aug 24, 2009
    Posts:
    982
    So, this doesn't change in the future since you'll have the same problems with the implementation of you target specific VM. (Well, I assume that it won't take a year anymore for an *expert*; btw.. that's why I said "team" ;) )

    So, ... 10 platforms 3 months? 6 months? 12 months? Dangerous statement ;)




    As I said... hopefully, we don't have to *buy* those compilers :) Current state is that we can "just work out of the box"... Future state is that we most likely have to install a specific version of the SDK/compiler (as with Android -> no support for latest SDK). But that is OK, if we can be sure that it's hazzle free...


    Don't get me wrong: I didn't say you are wrong by doing this... I'm just telling my concerns and my views on the topic... It's funny to see companies go from native to cross to (pseudo) native...

    At one point, from a business standpoint, it will make sense to switch all platforms to the same model. In terms of maintanability, robustness, bug analysis,...

    Let's see how it will work out...
     
  3. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    I am curious to hear how advanced IL2CPP already is. E.g. do you already support multithreaded code?
     
  4. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    420
    Cool feature. but you need to think about patches and modding with il2cpp along side it development.

    I want to allow end users to use Unity to create mods for our game.
    So they just duplicate and open our Unity mod project inside game folder and have all stuff already there.
    Than they create mod and ship it.
     
    Last edited: May 20, 2014
  5. RalphH

    RalphH

    Unity Technologies

    Joined:
    Dec 22, 2011
    Posts:
    591
    Today, .NET threads are not supported today and work has just started on it. Partial reason for this has been that WebGL doesn't need it (as it cannot utilise it today). But it's actually 1 of 2 larger new features that are now being worked on. The other large feature in progress right now is C# debugger support.
     
  6. RalphH

    RalphH

    Unity Technologies

    Joined:
    Dec 22, 2011
    Posts:
    591
    I'm not entirely sure what you are trying to convey / ask ? Could you rephrase ?
     
  7. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,163
    What no direct to C++ coding that could open up Unity to a rich diversity of third party libraries?! :(
     
  8. Woodlauncher

    Woodlauncher

    Joined:
    Nov 23, 2012
    Posts:
    173
    Thank you Unity for the transparency! It's been great seeing so many interesting blog posts.
     
  9. RalphH

    RalphH

    Unity Technologies

    Joined:
    Dec 22, 2011
    Posts:
    591
    I'm not sure how you are stopped from using c++ libraries; using native plugins this is possible today.
     
  10. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    420
    Unity do not support ability to create mods for game and also don't support ability to create patches.

    Now we have third party solutions that allow to load mod logic from additional .net dll and everything work.
    But with il2cpp we can't do this.

    While il2cpp only on iOS and browsers it not a problem, but when you port standalone to it it will be problem.
    So you need to think about modding and patching ability from now to immediately take it into architecture
     
  11. Noisecrime

    Noisecrime

    Joined:
    Apr 7, 2010
    Posts:
    1,521
    Out of interest its mentioned that il2cpp can gain 2 or 3 times performance over c# which is great, but i'm wondering what if any other oppertunities might exist for further optimising?

    Specifically well in most cases I find c# fast enough and could move to C++ plugin if necessary, there are times where I'd love to get some additional performance whilst coding in c#. For example code that loops through several large arrays, performing complex operations. As I understand it in c# there is constant bounds checking going on and other niceties, some of this can be removed by using unsafe mode, but that doesn't work in Unity.

    Is there the possibility for il2cpp to generate code from c# that does away with some of these checks to provide additional performance benefits but at the developers own risk (i.e no bound checks). This is of course assuming (i've not been able to test) that such safe guards do impact performance in these specific cases.
     
  12. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    251
    I am not a lawyer. Definitely, not a lawyer. That being said.

    Yes, the Mono runtime is released via the LGPL.

    However, it's not just linking mechanism per se. It's (AFAICT) intent is to allow users to replace the LGPL component within an application with their own version. You could still do static linking by providing users with object files. The point is that this burden wouldn't just be on Unity but on everyone shipping a game/application with Unity. They would also fall under the LGPL and have to make available object files, etc. to all their customers.

    Again, not a lawyer. And that's just my personal interpretation not Unity's, blah blah blah
     
    FuzzyQuills likes this.
  13. AnomalusUndrdog

    AnomalusUndrdog

    Joined:
    Jul 3, 2009
    Posts:
    1,494
    It's planned to be optional to use IL2CPP for standalone:

    I'm planning on using KopiLuaInterface (it's a complete rewrite of Lua in C# code) for user mod scripts. I believe it's possible to use it without relying on Emit and dynamic compilation.
     
  14. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    251
    First, people love to talk performance. Which is cool ;) That being said, scripting is rarely the bottleneck in the applications I have seen. Perhaps incorrect or bad scripting, but we don't see complaints coming in saying 'method calls in C# are too slow'. The GC is another story, but we'll leave that for later.

    IMO, IL2CPP will actually alleviate the need for user written C++ in many cases. It will allow for things previously thought of as 'too heavyweight' for scripting. Things like AI, physics, etc. will probably see the greatest improvement and thus have the most potential for new things being done.

    Off the top of my head, optimizations could include:
    • Array bounds check elimination
    • Removal of exception support (this adds varying amounts of overhead depending on the platform)
    • Static initialization removal; any object instantiation or static field/method access needs a check currently to ensure that the static constructor has been run for types that have one. We could do that all up front
    • SIMD Support
    • Interop optimizations. There is some overhead when transitioning from managed<->native. We could look to alleviate that as much as possible, potentially by allowing you to opt into additional restrictions.

    These are just random thoughts. I think once we have feature parity and stability, we'll quickly iterate on performance where it's needed most.
     
  15. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    4,765
    On Mac/Linux/Win Standalone players and the editor we will support mono as an option for a very long time, and we will upgrade to a new version of mono. So thats overall a big win. We have gotten a lot of feedback from customers that they want us to upgrade to the latest version of Mono.

    So if you make a moddable game for PC platforms, then you can just continue to use Mono on those platforms. No problem.
    Cross deployment for Mac / Linux / Win Standalone will also continue to work with the same setup.

    On other platforms like iOS consoles, Unity already uses Mono AOT, thus loading dll's and Reflection.Emit is not supported today and impossible to support due to platform requirements anyway. Thus nothing lost there.

    What is so exciting about IL2CPP is the big performance speedups however. We have seen 2-3x speedups on math heavy code.
    This is huge! On top of it, it gives us much easier to maintain optimize codebase too. For example having an optimization flag to remove all array bounds checks is straightforward for us to do in IL2CPP. So if in your game you know you don't write out of bounds and you just want the best performance you can turn that bounds check off.


    IL2CPP is being introduced step by step. That is why we start with WebGL, for which using mono is impossible. Basically using IL2CPP is the only way to do it for us.

    And then next up we will support iOS, The limitations you have on iOS (eg. reflection.emit) are already present there thus upgrading to IL2CPP will be straightforward for most of our users. In the first release, IL2CPP for iOS will be an option, so you can choose until we make it rock solid.

    So we are really setting this up in a way that the upgrade path optional until it is solid. We are making it as pain free as possible.
     
  16. Thavron

    Thavron

    Joined:
    Aug 29, 2012
    Posts:
    361
    Sounds great!
    Thanks for sharing all that info.
     
  17. liortal

    liortal

    Joined:
    Oct 17, 2012
    Posts:
    3,333
    Is there any plan to involve the new .NET Native initiative from Microsoft for this?

    For those who are not familiar, MSFT announced they were working on tooling that will take your C# code and generate native code from it (sounds similar to the scenario here): http://blogs.msdn.com/b/dotnet/archive/2014/04/02/announcing-net-native-preview.aspx

    They also discussed how they were going to do it: http://blogs.msdn.com/b/dotnet/archive/2014/05/09/the-net-native-tool-chain.aspx

    Can it be that some of this will somehow be leveraged on the supported platforms?
     
  18. SeanPollman

    SeanPollman

    Joined:
    Jul 10, 2012
    Posts:
    55
    I just want a clarification. Is mono being updated for Unity 5? This is a huge deal to my team, and one of the deciding factors on if we continue to use Unity past our current project. I dislike that it is so hard to get a clear answer on these kinds of things. I have seen vague confirmation that we will get an updated mono, but no mention of when.
     
  19. superpig

    superpig

    Quis aedificabit ipsos aedificatores? Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,215
    What I understand is going to happen is:

    1) IL2CPP is going to be made to work properly for WebGL, which is shipping in Unity 5
    2) After that they're going to make it work properly for iOS
    3) After that they're going to upgrade to the latest Mono on all other platforms

    No idea exactly when these things will happen in relation to the Unity 5 release date. Maybe WebGL will be stable long before Unity 5 comes out and they'll be able to get iOS done quickly, or maybe they'll be stuck fixing WebGL issues until after release and won't be able to start on iOS until later. I think the reason it's not too clear is because they don't actually know very clearly themselves right now.
     
  20. SeanPollman

    SeanPollman

    Joined:
    Jul 10, 2012
    Posts:
    55
    If this is accurate, its not a good sign, and frankly not acceptable.
     
  21. wccrawford

    wccrawford

    Joined:
    Sep 30, 2011
    Posts:
    2,038
    Which part is not acceptable? That they're going to add a faster, better compiling option? Or that they're going to update mono on all platforms?

    Or perhaps you're upset that time and money isn't infinite, and they can't release on all platforms at the same time?

    If you want to wait until it's available on all platforms, go ahead. That would be ready at the same time no matter if they released all-at-once or one at a time. But this way, they get extra testing done before they get to that point and likely have a much more solid product.
     
  22. SeanPollman

    SeanPollman

    Joined:
    Jul 10, 2012
    Posts:
    55
    Not having mono updated at the launch of Unity5 is unacceptable to me. I have a business to run and employees that need to be able to utilize everything in their toolsets. If they cannot I need to move to an engine that will allow this. Your condescending statements and implications are unwarranted and immature.
     
  23. NLSC-E-MS

    NLSC-E-MS

    Joined:
    Jul 22, 2010
    Posts:
    593
    I think SeanPollman is referring to the Mono upgrade (point #3) being delivered after #2 and #1. Which I don't understand why superpig would imply, as I haven't read anything that would suggest that (#1 #2) isn't being worked on parallel to #3.

    So the mono upgrade could happen at any time before #1 #2.

    Edit; Yup. ^
     
  24. RalphH

    RalphH

    Unity Technologies

    Joined:
    Dec 22, 2011
    Posts:
    591
    I'm sorry but to have to bring you bad news, but this is the case. Unity 5 will not have an updated Mono in the 5.0 release version. If we could give you more precise details on when we will be able to do so, we would, believe me. Right now we have shared everything we know today in the blogpost.

    The reason we share this is to give you a clear insight on what we are doing, why we are doing it. There will be a lot of motion within the 5.x cycle as we start rolling out platforms with il2cpp; however, we don't have certainties to share on exact dates there.
     
  25. RalphH

    RalphH

    Unity Technologies

    Joined:
    Dec 22, 2011
    Posts:
    591
    While the work can be done concurrently, roll out of both has dependencies between one another.
     
  26. holyfuzz

    holyfuzz

    Joined:
    Nov 16, 2010
    Posts:
    21
    Can you please elaborate on how garbage collection will work on platforms that use IL2CPP? Will you be using the (upgraded) Mono GC, a custom GC, or a 3rd-party GC? Thanks!
     
  27. NLSC-E-MS

    NLSC-E-MS

    Joined:
    Jul 22, 2010
    Posts:
    593
    I understand. Thanks for clarifying.
     
  28. RalphH

    RalphH

    Unity Technologies

    Joined:
    Dec 22, 2011
    Posts:
    591
    (from the blogpost)
    We really don't have much more to say then that there, so for now you can assume we will be using https://github.com/ivmai/bdwgc/ for both webgl and later, iOS.
     
  29. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    So, am I to understand that Mac and PC export options will (at some point) feature a "native" IL2CPP export option alongside regular Mono export option?
    I'm hoping this is the case, sooner rather than later.
    I think a lot of Unity developers, myself included, would be perfectly happy to exchange some features of .NET in order to take advantage of what basically amounts to fully native speed (especially if that means Unity optimizes out the boundary between script code <--> engine code, which would be a nice performance savings I think)
     
  30. ZimM

    ZimM

    Joined:
    Dec 24, 2012
    Posts:
    945
    Well, if I'm getting things right, the biggest reason for not updating Mono are AOT platforms. What about upgrading Mono for all other platforms and editor, and just leaving iOS/consoles with old mono (as it is now) until there are better options? I understand that resources aren't infinite, but really, outdated Mono is a source of many problems these days...
     
  31. SeanPollman

    SeanPollman

    Joined:
    Jul 10, 2012
    Posts:
    55
    Thank you for the response, this is very disappointing, but I understand, I only wish the resolution to these issues were timed to release at the same point.
     
  32. Pi_3-14

    Pi_3-14

    Joined:
    May 9, 2012
    Posts:
    168
    Someone has already asked "Surely, if Unity is moving to include a C++ step, it should allow native C++ code, which would allow existing C++ code-bases to be used."

    Someone else answered to say that native plug-ins have always been allowed. But that doesn't address the point. The point is that entire C++ libraries could be included, without having to create platform dependency (which native plug-ins would create).

    Could someone give a logic behind this decision?

    As far as I can see, it would significantly increase the power of Unity by allowing tighter / optimised code and allowing people to pull over existing C++ projects, but maybe it would allow people to code their way around ever needing to buy the Pro version.

    If this is the case, then might Unity consider redesigning their moneymaking model, so that it aligns with the technology rather than fighting against it? I believe this model was created even before the asset-store -- it may no longer be the most sensible model...

    There is some self-interest here -- I write low level audio processing code (musical trainer game), and my project is at a hobby/non-commercial level, so using Pro to allow OSX native plug-ins isn't a viable option. I would love to be able to do my real time DSP in C++.

    I'm very happy to see Unity flow around the seemingly intractable LGPL issue; I was thinking I may have to jump a sinking ship, and this embracing of new approaches has restored my confidence! I look forward to seeing what comes out of it!
     
  33. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    They mentioned already that they wouldn't be directly supporting C++ as a scripting option.
    The reason being it's much easier to support compiling MSIL to C++ and have it work with the Unity engine and GC and all of that jazz than it is to directly support raw C++ code.
    I think they mentioned that "it's much harder to write C++ that plays by the rules" or something to that effect.

    That said, your C# would still be compiled down to C++ and then to native code so that may allow you to just write the whole thing in C# without worrying about performance so much.

    EDIT: I don't actually know this for a fact, that's just my own interpretation of what they said.
     
  34. Breyer

    Breyer

    Joined:
    Nov 10, 2012
    Posts:
    412
    so as far as i understand AOT dont allow dynamic generation code including generation into memory? (Microsoft.CSharp namespace and CsharpCodeProvider class i have mean with GenerateInMemory parameter)? if yes this will be small impact on my project but potentially benefit will be far far bigger deal than problems if mono will be updated to 3.x.x version (async feature, built-in text-to-speech, SIMD etc.)
     
  35. MatthewW

    MatthewW

    Joined:
    Nov 30, 2006
    Posts:
    1,355
    One quick thought:

    If a project is targeting PC/Mac and AOT targets like consoles, it may as well use the IL2CPP standalone player (assuming there are performance benefits there too). I know with Aztez I'm just keeping the code AOT friendly across the board rather than platform #ifs or anything...
     
  36. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,633
    Yes, it is dangerous to make predictions here, which is why we don't. But it is important to notice that once we have AOT platforms moved to IL2CPP, we have no remaining restrictions to update mono for other platforms, so even if it may take quite a while to move all platforms over to IL2CPP, it is likely that you will see an updated mono (which solves many of the issues people have) for all non-IL2CPP platforms much earlier.

    That may vary by platforms. But: for any platform which is AOT now, you already need a compiler toolchain to publish right now (like needing xcode for iOS). That will not change. For all other platforms, IL2CPP will remain an option for the foreseeable future, as they will also have updated mono, so you won't be forced to buy any compilers for platforms where you don't need that now.

    While that is true, I don't see us dropping mono, even if we have all other platforms on IL2CPP in some time. That's because we need mono for the editor - if we relied on il2cpp there we'd have very bad iteration times, and issues hot reloading c++ code (like UE4), which is not acceptable to us.
     
  37. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,633
    As mentioned before, we don't see opening up our scripting API to C++ (so you could write MonoBehaviours in C++) to be a very good idea for various reasons (easy of writing C++ code against GC'd object, hot-reloadability in the editor, etc).

    That said, interacting with existing C++ code bases may indeed become easier with il2cpp. In WebGL, we currently allow dropping .cpp files into your Asset folder and they will be compiled along with other sources, and you can call functions in them from your scripts. I think it's likely that we will allow that on all il2cpp platforms.
     
  38. Pi_3-14

    Pi_3-14

    Joined:
    May 9, 2012
    Posts:
    168
    Fantastic! That's exactly what I was hoping for! Might be worth stating this explicitly in the blog post and/or making some noise about this!
     
    Last edited: May 20, 2014
  39. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    Ooooh now that's actually pretty cool.
     
  40. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,301
    Ugh. Just... ugh. I haven't yet read this whole thread but I read the blog post and a few things jumped out at me. First, the "benefits" list:

    1) "C++ is magic and always faster and just even saying the name C++ makes everything magically high performance!" This is, to use a technical term, a bunch of total crap. C++ is occasionally faster for certain things if and only if the developer coding in C++ is both an expert in C++ and C#. When people just randomly claim that C++ is magic and will make C# faster, it makes them sound like they don't actually know anything about how the two languages work.

    2) "We wrote our own VM!" And then in the comments, "Well it's not really a VM" "OK, it's nothing at all like a VM, I don't know why we said that." This does not fill me with confidence.

    3) Benefit: Now everything is AOT! That is NOT a benefit. AOT is a limitation. JIT is better; that is why JIT was invented. Again, people who think AOT is magic and that JIT just "accidentally" happened and only exists to make things slower and less magical than C++ tend to demonstrate that they don't really know what they're talking about. Losing JIT will hurt.

    4) "Now we are no longer tied to Mono! ...Except where we are. Which is almost everywhere. But maybe one day we won't be, maybe!" This also does not fill me with confidence. The only possible good thing I see from a cobbled together man-in-the-middle .NET decompiler/recompiler is that it might let you guys avoid paying Xamarin's license upgrade fee, but apparently you still have zero progress actually upgrading .NET, you're actually moving backwards with the GC implementation, and you will be removing compatibility from all platforms. In addition, we will now be depending on a closed-source black box implementation of .NET rather than Mono or MS, which can only mean more bugs and harder debugging. You're signing up to reinvent the wheel when the wheel is a constantly moving target that is being coded by the biggest software company in the world and a fully-funded open source megacorp with close ties to that first biggest software company in the world. I'm sure you guys have some skills, but there is no way you are going to write a better runtime than MS or Mono.
     
  41. snoopbaron

    snoopbaron

    Joined:
    Mar 21, 2009
    Posts:
    88
    I'm happy to read this, having to deal with hot reloading of C++ would be a pain. I think upgraded Mono in the editor with faster iteration times and IL2CPP or Mono for deployment gives us the best of both worlds. I'm really happy with this solution and I can see why the platform teams are exited about it. If only we could have had this back in 4.0 instead of waiting for 5.x :-D, regardless I'm really looking forward to it when it does arrive! The option to switch on IL2CPP for some standalone releases for added performance and dropping .cpp files to include with the build in Assets folder sounds promising.
     
  42. minionnz

    minionnz

    Joined:
    Jan 29, 2013
    Posts:
    391
    Wow, I think a lot of us had a feeling it was coming (the IL2CPP has been talked about before), but I was still hoping for a Mono upgrade in v5 - I was hoping Xamarin/Unity had worked out some kind of deal..

    I'm worried (like some other people on here) that UT has bitten off more than it can chew with this, as it's now another (quite large) project to maintain - to me, it makes more sense to use a third-party library whenever possible.. But I don't know the capabilities of your team, and it seems Mono was quite a bit of work anyway. I certainly don't know enough to make that judgement yet.

    From the blog post/this thread, it sounds as though everyone at UT are pretty excited about this. I definitely think you need to dedicate a blog post to showcasing this properly though - running a full game, showing performance differences and compatibility with existing code.

    Oh also - does this mean deployed packages will be a lot smaller??

    Anyway well done. We now have an answer to that Mono question and I'm hoping that the IL2CPP project is a huge success. I'd suggest open sourcing it as you would benefit from community/non-unity fixes/enhancements/forks etc, but I know you're against that idea for this component.
     
  43. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,301
    I don't see that at all. The blog post says you will be replacing the current buggy GC with a slower, untested, custom GC that doesn't actually work yet, and that you will be replacing the current .NET version with an untested, unfinished custom .NET version that is worse than the current one, removes all JIT features, and only works on one platform. The blog implies that "maybe" you "might" be able to figure out how to get a generational GC in there some day (though of course it can't be an actual .NET GC since you're going to be trying to collect garbage from C++ objects wrapped in .NET objects wrapped in C++ objects), and that maybe some day you might try to upgrade .NET, if you can somehow rewrite all of it yourself. It sounds like maybe, possibly this will pay off five years down the road, but it could have been fixed much more easily if you guys just paid Xamarin off.
     
  44. snoopbaron

    snoopbaron

    Joined:
    Mar 21, 2009
    Posts:
    88
    Read the thread I think these points have already been addressed. The proposed solution will really give us the best of both worlds. Up to date Mono and a better solution for AOT deployments.
     
  45. Woodlauncher

    Woodlauncher

    Joined:
    Nov 23, 2012
    Posts:
    173
    Isn't it the same GC as in the Unity version of Mono, just a lot newer?

    EDIT: It is.
     
  46. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,301
    No, there is currently no updated Mono, and no estimate for when/if it will ever actually appear. And "AOT deployment", aka iOS, already works. I don't think we need a better solution for iOS, especially when it means a worse solution for every other platform.
     
  47. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,301
    It's their custom implementation of libGC, which is similar to the current Unity one. The main problem is that both MS and Mono have moved on to generational and parallel GC's, which are much better, and solve the hitching problem that gets the most complaints from Unity users. Switching to libGC won't solve the hitching, it's still a slow and conservative GC that has to scan the entire memory when doing a collect sweep. The blog says that maybe they will eventually write their own better GC, but again, this is reinventing the wheel and will just be an endless game of catch-up vs the Microsoft and Xamarin GC's.
     
  48. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    251
    You're making up your own quotes and then arguing that it's not true. We said in the post that "We’ve seen 2x-3x performance improvements in some of our script-heavy benchmarks." We then explain why that is. We don't make a universal claim, nor advocate magic. We are generating a fixed set of C++ (almost C in fact) meaning we are in control of what the compiler will encounter.

    We qualified our statements, to clarify things. VM (Virtual Machine) is a term that can mean more than one thing, and beyond that is open to even more interpretation by the reader. We do not provide machine level emulation of the instructions. However, we do provide a virtual execution environment for the process to run in. This environment provides things like garbage collection, metadata, and abstractions of platform specific resources like the filesystem, networking, or threading.

    Again, more things we did not say. We are initially targeting platforms that are AOT already, and have said repeatedly that platforms like Standalone will have an option (as numerous people have been excited to use it on Standalone, converse to your argument). JIT has usefulness in some scenarios. However, we have a) feedback from many customers who are willing to trade JIT functionality for AOT improvements b) many platforms are AOT only c) even Microsoft is realizing advantages that AOT compilation can bring in .Net

    Wow. A lot in there. We are not longer tied to the negative aspects that the Mono project brought to Unity. Porting and maintenance of the runtime and JIT/AOT compilers of Mono was a net value loss for us. Using C# for development, the Mono C# compiler and class libraries, and all the .Net community is a net win. We are seeking to maximize the value Mono/.Net/C# provides us and our users while ameliorating the situation with the runtime.

    The GC is not a step backwards. The newer version of Boehm we are using is already an improvement over what we had, and provides a working solution while we integrate and evaluate other options.

    We are bringing compatibility to all platforms with IL2CPP, with a uniform set of supported functionality.

    And we are collaborating with MS and Mono going forward (to an extent we always have) to provide the best experience across all .Net environments.
     
  49. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    251
    Again, making up quotes. The blog post specifically says "In its current iteration IL2CPP uses an upgraded version of libgc, even as we look at multiple options." libgc being widely used, stable, and in development for a long time. It gives us *at least* the same performance we have today and provides a good platform for us going forward.
     
  50. jmatthews

    jmatthews

    Joined:
    Jul 27, 2011
    Posts:
    199
    You guys decided to go for it. Kudos. With all of the new announcements recently it must be an interesting time around the office. A new acquisition, new middleware, re-writing the renderer, re-surfacing your toolchain...

    Did you guys change what brand of coffee you drink at the office as well?

    These are some very deep changes and will change the face of Unity for some time to come. I'm super happy that you are minding the end user's needs.(Not requiring a thousand mini-compiles ala UE). I feel like your winning market differentiation is the ease of use and productivity that Unity allows. Please remain as mindful of this as you guys appear to be today.