Search Unity

[Official] The collected il2cpp forum topic.

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

  1. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,311
    Well, I believe that you guys have seen improvements compared to the existing Unity runtime; I don't necessarily believe that the improvements are just because you're going from IL -> C++ -> Native instead of IL -> Runtime. How is the performance of a C# function through your compiler vs a C# function compiled with MS's compiler and running in .NET 4.5? Or through the latest Mono? I'm concerned that you could get the same (or better) performance increase by just updating to a newer compiler and runtime rather than writing your own.

    I guess that's fine; I was hoping that this announcement was going to finally be the announcement about the solution to the Mono problem, but I guess this isn't it. This doesn't really solve anything from your users' perspective as far as garbage collection, incompatibility, or being long overdue for a .NET upgrade. To me, it just seems to introduce even more instability and unknowns into garbage collection, incompatibility, and the potential of ever seeing a .NET upgrade.

    I get this, but the solution I was hoping for was that you guys would leverage the decade's worth of work that Microsoft and Mono have put into .NET, not write your own from scratch.
     
  2. bigdaddy

    bigdaddy

    Joined:
    May 24, 2011
    Posts:
    153
    I may be wrong, but it seems from this post:
    that once iOS has il2cpp, then UT can update to the latest mono.
     
  3. jmatthews

    jmatthews

    Joined:
    Jul 27, 2011
    Posts:
    199
    I'm not trying to agitate you but you do realize that what you'd hoped for is exactly what's happening right?

    Environments requiring AOT is what's holding back the mono upgrade. This announcement is the first step in removing the dependency on Mono AOT. Once this solution is in place they are free to upgrade Mono.

    Unless I misunderstand you that is exactly what you wished for.
     
  4. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,311
    Sorry for all the ranting. Let me try and clarify my thoughts. Here are the problems I've had as a Unity developer with Mono and the things I wanted to see:

    1) I want a garbage collector that is fast and lets me do many small allocations often without worrying too much about it. The current MS and Mono GC's are good at this, mostly due to being generational and parallel.

    2) I want to be able to stay current with .NET, and use the existing .NET 4.5 features, and ideally be able to keep up with new .NET releases at a decent pace.

    3) I want to be able to use current and future third party .NET libraries and code without worrying about compatibility.


    Those are the main things that the Mono problem was holding back for me, and the main things I was hoping to see solved. This blog post doesn't solve any of those, and to me just puts up a roadmap that will make it so that now there is another year or two of development work just getting this new .NET solution in line with what we have now before we even think about solving problem number 1, and it pretty much guarantees that problems 2 and 3 will never be solved due to dropping JIT.
     
  5. Ostwind

    Ostwind

    Joined:
    Mar 22, 2011
    Posts:
    2,804
    How about you re-read this thread from the start and also check the blog again and the comments in there...
     
  6. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,311
    You're right, I did miss that. If that's indeed what they do then I would be ok with it. But they've talked about using il2cpp and AOT on all platforms, which is not what I want. If they limit it to iPhone and WebGL but let us use JIT and a normal runtime on Windows it would be great.
     
    Last edited: May 20, 2014
  7. thxfoo

    thxfoo

    Joined:
    Apr 4, 2014
    Posts:
    515
    For anything serious it is much faster, always. I don't link benchmarks this time, makes no sense with you. Just see other posts of people porting their game to UE4, same code is 300%-1300% faster in C++ for them.
    Yes it is a limitation. But it is faster without JIT (see previous point). And for certain people being able to drop a CPP-file as a resource makes Unity 1000 times better. And I don't know if you really read the blog post (or understood what it says). You do not lose your JIT if you don't want to. And this stunt of Unity even gives you/Unity the newest Mono for free down the road.

    So I think this is a smart move to out-play Xamarin (if they implement it well and can solve the debugability problem).

    ---

    I don't know if your love for JIT comes from missing knowledge (disclaimer: I coded for Java compilers and Java JIT compilers). The base intermediate language that is run by the baseline compiler before a JIT compilation is triggered is of poorest quality (from speed view). Just analyze .NET assembly intermediate code, you would cry. For hotspots the JIT compiler does optimize that, but the JIT must be fast still, it cannot do many things a standalone compiler would do. And certain language features prevent a lot of other optimizations you can do for C++. Of course a JIT can pull certain tricks that you cannot do with static compilation, but that does not change the fact about what each serious benchmark will tell you.
     
    Last edited: May 20, 2014
  8. RalphH

    RalphH

    Unity Technologies

    Joined:
    Dec 22, 2011
    Posts:
    591
    As for the benefits of an AOT feeding an existing C++ compiler performance wise, as long as we haven't posted benchmarks (and you are right, it's fair to compare to newer implementations of .NET runtimes too) it's hard for us to convince sceptics. As said, we will follow up with more blogpost that go more technically in depth on development and exactly these type of topics ("how can it be faster?").

    What I can tell you is that over the benchmarks that we did do we see performance gains as a constant factor.

    Of course, a math heavy benchmark alone doesn't prove this to be true for all code, but we did a few differing benchmarks over time and saw these performance increases constantly. And adding to that; we know that we can gain even more, because we do control the code-generating we can do unity specific optimisations. A funny one that is implemented today; fast paths for UnityEngine.Mathf. That's just one tiny example of course, but it is indicative of how we can speed up existing code with a very specific optimisation.

    As my closing thought for you on this is; we are not the only ones going down this path of an AOT compiler linked to a "native compiler"; as you might know, Microsoft is going down a similar path with .NET Native.Equally, Mono is (in some cases) able to leverage optimisations in LLVM. Here's a take from Microsoft on it; http://blogs.msdn.com/b/dotnet/archive/2014/04/24/dotnetnative-performance.aspx

    I think we outlined in the blog quite well that while we are still researching GC (which is a general statement, not one only applying to il2cpp, or just confined to the actual runtime, but also the pressure our api's potentially create), that's on a path forward and we realize the importance.

    As for .NET upgrade compatibility, it has been explained in the post and in this thread, so I'm not sure what information you are looking for, but I'll be happy to provide what I know both on this and your questions/conceptions about our GC statement.

    We are not writing everything from scratch, are working with Microsoft to ensure fidelity on this front and equally will remain to be heavily leveraging all the great work that went into Mono. We are however implementing an AOT compiler and runtime environment (which we call a VM in this case), that we believe, after a *lot* of research, is the right way forward to support a large number of platforms in Unity, while also upgrading platforms to the latest Mono.
     
    Last edited: May 20, 2014
    twobob and JaredThirsk like this.
  9. lilymontoute

    lilymontoute

    Joined:
    Feb 8, 2011
    Posts:
    1,179
    The reason that is a problem is because it causes a huge feature gap (iOS would be stuck on the old class libraries and you'd end up with more incompatibility issues). Replacing Mono AOT with IL2CPP on IOS will allow them to update the class libraries (getting all the newer .NET features within the same limitations that exist today on IOS), AND on standalone, a newer version of Mono will be available.

    So that solves issue #1 (non-AOT platforms will get a new version of Mono, with its newer GC - AOT platforms will get IL2CPP, which will also have a better GC), #2 (class libraries will be updated for both) and #3 (as long as the C# library supports Mono AOT, it should support IL2CPP's AOT... and on standalones dynamic code generation will still be available).
     
  10. jmatthews

    jmatthews

    Joined:
    Jul 27, 2011
    Posts:
    199
    Would be nice to swap Mono sooner rather than later, but this comes from a desktop developer, not an IOS developer. :)
     
  11. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,311
    Thanks for responding to my ranting calmly; I know if I was you guys I would probably just tell me to shut up. ;)

    I have read about .NET Native but even MS says that it is a tradeoff; they are not just planning on replacing .NET entirely with .NET Native. As they say, it's a useful tool on mobile platforms where CPU and memory are constrained, and where devs are willing to accept limitations on features to eke out more performance. But on PC and consoles, we don't need the performance boost and I'd much rather retain JIT features and compatibility. I guess all I can ask is that you guys try to find a way to allow non-mobile platforms to use JIT and leverage the existing MS or Mono runtimes. I know it fractures the cross-platform compatibility a bit but IMHO it is worth it.
     
  12. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    251
    At least for Standalone we are planning on allowing both an upgraded Mono and IL2CPP.
     
    JaredThirsk likes this.
  13. thxfoo

    thxfoo

    Joined:
    Apr 4, 2014
    Posts:
    515
    Man, read the blog post again. That is exactly what they are doing. You do not lose your JIT if you don't want.
     
  14. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,185
    @Makeshiftwings it's good that you've identified you've been ranting, I don't think overall we can allow a constant barrage from any member on these forums. We would like to keep the forums civil and logical - that is - don't let emotion get *too* involved. It's clear that with testing, Unity found this method to be beneficial at many things, presumably because what we're doing is comparing mono compiler, not the ms .net compiler. There's a pretty big gulf in optimisation here which the web doesn't pick up on.

    So please - act with restraint, as this is far from your usual manner.
     
  15. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    I'd just like to say, there's quite a few reasons native C++ code can end up faster than .NET/Mono code:

    * No JIT compilation, it's all compiled already. JIT does have some amount of overhead. Once everything's been compiled it pretty much goes away, but you still have to go through that first compilation step for every section of code.
    * Eliminating the script <--> engine boundary. There's overhead in going back and forth between C# and C++. But, since everything gets compiled down to C++, you can pretty much get rid of that boundary altogether.
    * UT staff mentioned earlier in this thread that there could potentially be a lot of optimizing options here, for instance getting rid of array bounds checking and disabling runtime exception handling. Both of these could result in minor performance boosts.

    So this announcement is really quite a big deal.

    EDIT: Plus, for platforms where Mono is already supported out of the box, they did say IL2CPP would be entirely optional.
     
    Last edited: May 20, 2014
  16. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,311
    That actually puts most of my fears to rest... I just wish I didn't have to wait until IL2CPP was done before finally getting an update. It sounds like the Mono update is planned for Unity 6 or at best late in the Unity 5 lifecycle, which is potentially quite a ways off, and we'll probably be seeing .NET 5 by then.

    I'LL RESTRAIN YOUR FACE! ...sorry, sorry. Ok, I think my ranting is done now. ;) Carry on.
     
  17. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,185
  18. charmandermon

    charmandermon

    Joined:
    Dec 4, 2011
    Posts:
    351
    @ Unity Engineers:

    This seems like a great time to support other .net Languages like VB! :)
     
  19. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    People use VB for game dev? ಠ_ಠ
     
  20. TylerPerry

    TylerPerry

    Joined:
    May 29, 2011
    Posts:
    5,577
    Can Unity share some early performance? It would be cool to get a desktop test build of Angry Bots or something using il2cpp and one with mono, I loved the way Unity has demos of Web GL... but the performance wasn't the best their.
     
  21. sandboxgod

    sandboxgod

    Joined:
    Sep 27, 2013
    Posts:
    366
    I am glad this has been made official but I am surprised Windows/Mac/Linux is most likely not supported at the first release. This is still good news and a great step in the right direction for Unity 5.
     
  22. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    251
    This was just our announcement/overview blog post. We hope to get more out following this one, with details on performance, debugging, GC, etc.
     
  23. Limyc

    Limyc

    Joined:
    Jan 27, 2013
    Posts:
    28
    I don't know about VB for game dev, but I could definitely get behind official F# support.
     
  24. superpig

    superpig

    Quis aedificabit ipsos aedificatores? Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,249
    Well, IL2CPP isn't really concerned with that point in the pipeline, I think? It's already possible for you to use VB.NET or F# with Unity, you just have to compile assemblies yourself against CLR 2.0, then feed those assemblies to Unity. At the moment it loads and JITs them with the Mono runtime; in the future it'll process them with IL2CPP and native-compile them.
     
  25. Lucas-Meijer

    Lucas-Meijer

    Unity Technologies

    Joined:
    Nov 26, 2012
    Posts:
    157
    We did not, but boy let me tell you we should! thankfully we have a wonderful coffee collective around the corner in copenhagen. (allthough most of the scripting team is actually remote spread around the world).

    :), L
     
    twobob likes this.
  26. techmage

    techmage

    Joined:
    Oct 31, 2009
    Posts:
    2,085
    What I would really like to hear from one of the Unity Engineers, or anyone really, is why C#?

    All this work to convert C# code into C++, when we could just be writing C++, right now even. Being able to write C++ plugins is not the same as having the language integrated into the engine, and the editor, the way that c# is. I'm talking about extending from Monobehavior in C++ and dropping .H files on game objects.

    I like C# and all, but another one of the developers in my office, who is a big native-code guy, not a Unity programmer. He really had to pose the question, why doesn't unity just let you put CPP or .H files on GameObjects? What benefit does C# really offer? It seems to be alot of runaround to provide C# for no reason other than to not alienate a user base and code base.

    And you know when he told me this, it really did make me think. Why so much effort for C#? Is it really doing anything other than just offering backward compatibility at this point?

    It initially seemed to me that Unity jumped on Mono VM because it offered the most ideal way to make a web player at the time, otherwise they would of had to write there own VM. And then that brought C# which was cool.

    But now that whole initial reason is gone. We no longer need a VM for a web players. But everything is bound to C#. So now this big huge runaround is taking place to make a design decision work, for which if the design decision were to be made again with no prior constraints, then it wouldn't be done.

    So you break compatibility with all prior projects. You break compatibility with all asset store assets. Basically would be an entirely new system. But you know, Apple has done that before. It's why OSX is so good now.

    I think its better to do just do what the absolute most intelligent thing is to do, even if it s a bit more painful, difficult and a struggle. In a most ideal world and platform, does Unity being bound to C# rather than just straight CPP really offer anything that great anymore? Seems to me like it's becoming a big messy drag for no reason other than to keep incapable programmers, who probably weren't even doing that good on C#, from feeling more alienated.
     
    Last edited: May 20, 2014
  27. superpig

    superpig

    Quis aedificabit ipsos aedificatores? Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,249
    This conversation has been had approximately 1.1 x 10^26 times already, so I'm just going to summarize for you:

    Yes.
     
  28. Lucas-Meijer

    Lucas-Meijer

    Unity Technologies

    Joined:
    Nov 26, 2012
    Posts:
    157
    A few more random notes on IL2CPP, AOT / JIT etc,

    AOT lets us do some optimizations that you cannot do with JIT. for instance, because we now are 100% sure that we have all code at buildtime,
    we can analyze the code, and look for virtual call sites, that call a virtual/interface method, that we know is only implemented by one type. we can then replace the virtual call with a direct call. and because you can replace it with a direct call, that gives the c++ compiler much more "grip" to make further optimizations. that direct call can now be inlined. and once it's inlined, maybe some if statements can be proven to always be true or false, so can the check can be removed completely. including the body of the if, which in turn reduces codesize, makes it more cache friendly to run. I've spent a lot of time in the inner bowels of LLVM lately (the thing that powers the osx c++ compiler, the emscripten compiler. our "turn unity c++ sourcecode into actionscript so we can target flash" was powered by llvm too), and the optimizations it is able to make when you give it some more information are just amazing. sometimes I have to actually single step through the llvm linker to figure out why it removed my complete function with a constant, to then later realize how it was able to prove that the result was that constant all the time anyway.
    I'll get off my llvm-crush-soapbox for now :)

    Sometimes JIT is great. Like in the editor when you don't want to spend 20 seconds waiting for a compiler to make your transform.Rotate(1,2,3) compile really really fast. you want to compile it as soon as possible, and not really care all that much about its performance. you care about iteration time, and about not having to close down the entire editor when you add/change some code.
     
    twobob, JaredThirsk and codestage like this.
  29. charmandermon

    charmandermon

    Joined:
    Dec 4, 2011
    Posts:
    351
    You are right you can use the VB dlls, but that is because the .net DLLs are not language dependent as they have already been converted to IL. Its just not the same though as actually being able to script live with VB or other .Net languages. Mono already supports VB so it shouldn't be a huge leap, in fact I bet it would be more work just to update the docs than to actually support VB.
     
  30. JasonBricco

    JasonBricco

    Joined:
    Jul 15, 2013
    Posts:
    936
    I really, really like C#. And I would really hate to have to use C++. C# is so much more productive for me to code in without all the hassle C++ provides.

    I think being able to drop C++ files in your project and call them from C# scripts (without actually scripting with Unity's API using C++) is a great idea. And that's coming (or likely coming)? I believe I heard something along those lines in here.

    That would make me happy. But I do like C# and .NET, and I think many other people do as well. It wouldn't be nice losing that great convenience.
     
  31. charmandermon

    charmandermon

    Joined:
    Dec 4, 2011
    Posts:
    351
    No where did they say they will be changing their scripting engine... I think you may need to reread the blog post bro, don't fret.
     
  32. minionnz

    minionnz

    Joined:
    Jan 29, 2013
    Posts:
    391
    I think makeshiftwings summarized what a lot of us were thinking when we first read the announcement, but we'll get over it :) I trust UTs judgement - I'm sure they've had plenty of internal discussions/experimentation around IL2CPP vs .NET Native etc.
    It's a little strange to me, but now that Unity is no longer tied to a third party system we should see some great improvements. Looking forward to any benchmarks/in-depth posts you have to share
     
  33. Lucas-Meijer

    Lucas-Meijer

    Unity Technologies

    Joined:
    Nov 26, 2012
    Posts:
    157
    I have never been happier with our choice of C#/Mono.

    - Automatic Memory Management. This alone makes prevents a ton of bugs, and makes programming a lot easier.

    - Base Class Libraries. C# actually comes with a comparatively nice library of a lot useful libraries, that work together nicely. In C++, in general
    it's a pain to find 3rd party libraries and integrate them. they each typedef their own types etc. There are some exceptions to this rule, most notably
    the wonderful 1 header libraries of Sean Barret. (http://www.nothings.org/stb_image.c as an example). C++ libraries often pull in dependencies that you do not want. (boost anyone?)

    - Code Editing tools. While I'm the first to admit that we have not done a good job on shipping a MonoDevelop that is a pleasure to use (which is largely our own fault for shipping of a fork with custom changes, making it non trivial to update to upstream monodevelop frequently), the code editing experience for C# can be amazing. Whenever I work with someone new, I try to convert them to like Visual Studio Resharper. Especially Resharper makes C# editing such a pleasure, and much more productive than writing code in c++. (at least for me, and I spend most of my time in c++, only a fraction in c#)

    - the .NET Intermediate Language byte code format. This is what your C# turns into when the mono c# compiler compiles it. This IL describes the logic of your program at "just the right level" imo. It makes it very easy to write Cecil based tools that analyze your compiled code. One example is automatic script updating which I'll blog about in the next few days. Another example is IL2CPP itself. that uses Cecil to read the instructions in the assembly, and the scriptingteam will yell at me for saying this, but it is a relatively simple process. we had a first game working after 3 days of experiments. obviously getting it to be actually ship ready takes orders of magnitude more time, but the IL format in itself enables us to do so much analysis about your code, and use that to help you, that we're very pleased with it :)

    - It can be made secure. In the webplayer for instance, you dont want rogue games trying to read datafiles from the gameplayers machine. so we have to analyze guarantee that your C# code cannot do anything naughty. being able to do this has allowed us to have a webplayer at all, and we actually use this security feature on some console platforms too.

    Offcourse you can say "well, I wont shoot myself in the foot, and I know how to use malloc/free just fine thank you very much, just let me write fast c++ code". Today you can already do this. It's trivial to call into c++ code from c#, and from that c++ code you can do whatever you want.
    As Jonas mentioned earlier, it is very likely that we will add support to drop .cpp files into your assetsfolder that we just add to the c++ files il2cpp made, and then compile them together. This is basically usability sugar that lets you ship .cpp files instead of having to compile the .cpp files yourself.

    So with the "but but but you can already write C++ in unity" out of the way, what some people want is to actually talk to the Unity API from c++.
    This is where things get tricky. There's two ways we could make this. either we let you talk directly to our C++ objects like our C++ gameobject,
    or we turn the existing C# api into something that is relatively easy to use from c++. This is much more tricky. It's something we think about quite a bit, and experiment with from time to time, but it's defenitely very non trivial on how to do a good job with this.

    One problem I think we have is that we dont have great docs on how to do c++ code inside native plugins and still talk to the api. (you can do things like pass a c# delegate to c++, and then in c++ that turns into a functionpointer that you can just invoke.)

    minddump over, bedtime, thanks for making it to the bottom of the post :)
     
  34. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    I think that was in response to someone else who said that they couldn't see what benefits C# had over replacing the scripting with straight C++
    Which, frankly, I find a ridiculous notion. But maybe that's just me.
     
  35. thxfoo

    thxfoo

    Joined:
    Apr 4, 2014
    Posts:
    515
    .NET Native is no option. It is windows only. You would have to adapt it to each supported platform. It would be 1000 times more work. With IL2CPP, you do this once and just use the the platforms C++ compiler (and implement the platform abstractions in the "pseudo VM").
     
  36. Silly_Rollo

    Silly_Rollo

    Joined:
    Dec 21, 2012
    Posts:
    486
    Most games have a lot of non performance sensitive code it seems overkill to write in C++. You could implement another language (LUA or something) for it but they've already got C#.

    A similar question to me is why continue supporting anything except C#. The other two languages are so much less productive it seems like the inevitable life cycle of a new Unity dev is to end up writing C# code even if they start somewhere else. Might as well make it easier on noobs and start them with C#. For "designer friendly" rather than a language marginally more friendly than C# some native visual coding tools would work better. Unless supporting the other languages is trivial in which case I guess its a great marketing blurb.
     
  37. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    I think the issue is that with the position they're in now, it would be difficult to remove the other two options without upsetting massive amounts of people.
    I personally am totally in favor of it as well - there's a lot of cases for it:

    * Asset store package interoperability. It's nigh on impossible to get asset store packages working together when one is UnityScript and the other is C#
    * Supporting said interoperability. On the flip side, there's also the asset makers - and it's frustrating to say the least to have to deal with the fact that many of your customers insist on you supporting languages which have absolutely no real benefit and require you to jump through hoops to ensure support.
    * Maintenance. I'm sure UT engineers would appreciate not having to touch their UnityScript code ever again - opting instead to just let the Mono team deal with C#

    But then again, think about how many UnityScript users you see on the forums. I'm sure they wouldn't be happy about it - they can and potentially should learn C#, but probably wouldn't be very happy about it at all.
     
  38. minionnz

    minionnz

    Joined:
    Jan 29, 2013
    Posts:
    391
    Good point - still, I think they have weighed up any other options themselves. We just have to trust their judgement.
     
  39. Pi_3-14

    Pi_3-14

    Joined:
    May 9, 2012
    Posts:
    168
    I can think of one thing we could do with... a tree-based discussion forum.

    This thread has already reached the length where people are jumping in with brash and loud opinions without having read from the beginning, creating escalation of spam.

    While it is annoying, it is also an inevitable consequence of the existing structure.

    Would that it were a tree, then I could collapse the rotten branches.

    An intelligent mechanism for organising information would pay dividends over time.
     
  40. Silly_Rollo

    Silly_Rollo

    Joined:
    Dec 21, 2012
    Posts:
    486
    Agreed
     
    Last edited: May 21, 2014
  41. superpig

    superpig

    Quis aedificabit ipsos aedificatores? Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,249
    I don't think C# vs UnityScript vs Boo is on-topic for this thread, folks.
     
  42. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,359
    The blog post mentions that the Editor will use the Mono runtime rather than IL2CPP. Could this instead be made optional once IL2CPP is ready for PC/Mac platforms? I see it as being pretty important for when we're optimising high-performance code areas, because the workflow for that is going to be super painful if we have to make a whole build just to clock some changes in the target runtime. (In some cases we'll need to do this anyway because the physical hardware is different or whatever, but it'd be nice not to have to where it can be avoided.)
     
  43. joncham

    joncham

    Unity Technologies

    Joined:
    Dec 1, 2011
    Posts:
    251
    You really shouldn't be profiling in the Editor today, as the characteristics of it are different than players. Editor should be for rapid iteration and debugging. The players should be used for profiling and optimization. As mentioned, we'll probably ship IL2CPP based Standalones as an option. This will allow you to profile an IL2CPP target with the fairly quick build and run occurring on a desktop. And again, final profiling should occur on the actual target device.
     
  44. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,185
    I agree, it's trivial to hit shortcut to build and autoconnect the profiler - doesn't take any longer than pressing play if there's just the single scene in build settings. Benchmarking within the editor has always been a bit hit and miss with editor overhead, sporadic updating and so on... I mean you still could, but knowing the target build is likely to be faster probably reduces your need to worry about it further still.

    Another reason to keep with JIT/Mono for editor is that it really helps with those fast coding iteration times. Unity's ruined me in the sense that I can be so creative as a programmer play-test-play. That's gone with AOT. Also I would really hate to have to reboot the editor each time I make an editor script.

    If you've a game which requires going through menus to playtest a level, you're definitely doing it wrong.
     
  45. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    I highly doubt it would be feasible. You know how the UE4 editor has to be restarted when you make changes to your C++ code?
    It's because you can't really hot-reload C++. So if they added IL2CPP to the editor, you'd have to restart the editor every time you need to recompile your code.
    So really, it wouldn't solve anything.
     
  46. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,359
    Absolutely.

    To be clear, I'm not talking about profiling the whole scene or even using Unity's built in Profiler. The particular use case I had in mind when writing that was a recent one where an operation on a large data set was being optimised, which was implemented as a single loop called in a single function. Changes inside that seemed to have a similar effect whether run in Editor or in build, which I wouldn't expect to be the case if there's a different toolchain and runtime between the two.
     
    Last edited: May 21, 2014
  47. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,359
    Isn't it the same as hot-reloading any other DLL?
     
  48. PhobicGunner

    PhobicGunner

    Joined:
    Jun 28, 2011
    Posts:
    1,813
    If it was that easy, don't you think Epic would have just chucked the game code into a DLL?

    EDIT: Here's a pretty good answer to that provided on GameDev StackExchange:
     
  49. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,359
    I don't know. Hence the question. ;)
     
  50. thxfoo

    thxfoo

    Joined:
    Apr 4, 2014
    Posts:
    515
    UE4 can hot-reload C++ code. Not all code, it depends on what and how you do it (if I remember correctly you cannot change interfaces in header files). But just changing something in the implementation is no problem.

    Edit: from UE4 about page:
    Make updates to your gameplay code while the game is running using Unreal Engine 4's popular Hot Reload feature. This tool allows you to edit C++ code and see those changes reflected immediately in-game without ever pausing gameplay.
     
    Last edited: May 21, 2014
unityunity