The future of scripts in Unity 3D
- Transfer
Recently, we wrote an article about WebGL support in Unity . In it, we briefly talked about how scripts will work in WebGL using the new IL2CPP technology. However, IL2CPP is something much larger than just a new scripting solution in WebGL, it is our own, high-performance implementation of .Net Runtime, which will be released on many platforms.
But before diving into the future it is worth talking about the present.
We use Mono (and WinRT for the Windows Store and Windows Phone applications) to bring Unity the ease of use of C #, access to third-party libraries, and virtually binary performance. But there are several difficulties:
- the performance of the C # runtime environment is still inferior to C / C ++
- the latest and best features of the languages and the .Net runtime environment are not supported by the version of Mono currently in use in Unity
- with about 23 platforms and architecture options, a lot of porting effort is required code and maintaining its quality at the same level
- garbage collection can cause delays in execution
Over the past few years, we have been constantly thinking about how to deal with all this. At the same time, research was ongoing in the area of scripting support for WebGL. As they move in both directions, they merged into one approach.
Realizing the scale of the problem, we began to experiment with different ways to solve it. Some were promising, some not. But in the end, we found an innovative way to solve our problems.
This is IL2CPP.
IL2CPP consists of two parts: Ahead of Time (AOT) compiler and virtual machine (VM)
They are our implementation of Common Language Infrastructure , similar to .Net and Mono. It is compatible with the current implementation of scripts in Unity.
Its main difference from the current implementation is that the IL2CPP compiler converts assemblies into C ++ source code. He then uses the standard C ++ compiler for this platform to create native binaries.
The code runs at the same time as the additional services (such as the garbage collector, metadata, platform-specific resources) that IL2CCP VM provides.
Let's look at each of the above difficulties and how IL2CPP deals with it.
At IL2CPP, we strive to combine ease of use and coding speed with C ++ performance.
With it, we can maintain the speed of the current scripting process and complement it with an instant increase in productivity. We saw a 2-3-fold increase in the execution speed of some of our tests with complex scripts. This performance boost arises for several reasons:
- C ++ compilers and linkers give us a large number of previously unavailable optimization methods.
- Your code is subjected to static analysis for both speed and size
- Unity-oriented optimizations of the script execution environment
Although the work on IL2CPP is still far from complete, this early increase in productivity clearly indicates the great future of our project.
We very often receive requests to update the runtime. In recent years, .Net has developed very rapidly, and Unity currently only supports the functionality of the .NET 2.0 / 3.5 era for both the C # compiler and third-party libraries. Many users have requested access to new features for both their code and third-party libraries.
As IL2CPP grows older, we will update the versions of the Mono C # compiler, the base class libraries and the runtime for the editor (the editor will not be translated into IL2CPP in order to maintain the speed of script development). The combination of these two processes will bring a modern version of .Net to Unity.
It is worth noting that we are working with Microsoftto ensure quality and stability while adding current and future .Net features to Unity.
While this may seem like Unity’s internal problems, they also concern you. The Mono virtual machine contains a huge amount of code specific to a specific platform and architecture. When porting Unity to a new platform, we spend a lot of effort on porting and supporting Mono VM for this platform. Some features (and errors) may exist only on specific platforms. This affects the values that Unity is trying to provide for you - the ease of transferring content between platforms.
IL2CPP solves this problem in several ways:
- The code is converted to C ++, and not machine-specific code specific to this architecture. The cost of porting and supporting code generation for each specific architecture is markedly reduced
- The development of new features and bug fixes are noticeably accelerated. For us, days of picking in an architecture-specific code are replaced by minutes of editing C ++. New features and bug fixes are immediately available for all platforms. The current version of IL2CPP is moving very quickly to new platforms.
In addition to this, platform or architecture-specific compilers are usually much better optimized than a single code generator. This will allow us to reuse all the efforts that went into developing C ++ compilers without reinventing them again within the company.
IL2CPP is not tied to any particular garbage collector; instead, it connects them through a special API. The current version of IL2CPP uses an improved version of libgc , although we are considering different options. At the same time, we are exploring the possibilities of reducing pressure from the GC using analysis performed in the IL2CPP compiler.
Although at the moment we have nothing more to say, research is ongoing. We know that this is important for you, so we will continue to work and will inform you about it in future entries. In the context of garbage collection, it is worth noting that regardless of IL2CPP, in Unity 5 you will see much more allocation free APIs.
IL2CPP is not an attempt to recreate an entire .Net or Mono environment. We will continue to use the C # compiler from Mono (and in the future, Roslyn is also possible ). We will continue to use the Mono class libraries. All currently available features and third-party libraries compatible with Mono AOT will work with IL2CPP. We are going to replace only the Mono VM and AOT compiler, continuing to use the wonderful Mono project.
We hope that by this moment the opportunity to try IL2CPP excites you as much as we do, and you are wondering - when will you be able to try it personally? An early version of IL2CPP will be part of WebGL support in Unity 5.
After WebGL, we will continue to develop IL2CPP for other platforms. In fact, we already have implementations for a number of the platforms we support. We expect to release at least one more platform this year. At the moment, we plan to make iOS the next platform with IL2CPP support.
The planned upgrade of the Mono environment will happen after IL2CPP is supported on more platforms and grows a little older.
The only platform that will never support IL2CPP is WebPlayer, due to security restrictions. As noted earlier, the editor will continue to work on Mono.
You can see the IL2CPP runtime in action right now. The two WebGL demos we posted earlier work on it.
We continue to work hard on IL2CPP: add new features, optimize code generation, fix bugs and add support for new platforms. We will publish more detailed articles as our work progresses and continue to discuss it with you in the forums.
Unity Script Team
A small addition from the answers of developers to questions in English comments and a special topic on the Unity forum :
The term “virtual machine” can be a little misleading. In fact, there will be no real virtual machine, everything will be in binary code, but there will be a number of functions available at run time and implementing the functionality needed by the managed code, such as system services or garbage collection, which we call a virtual machine in this case.
***
Writing scripts in C ++ is not an official goal of IL2CPP and nothing of the kind will appear in the near future, although this may happen sometime in the future as a side effect of decisions made.
***
The source codes will not open until we have been discussing a similar opportunity for a long time and have not yet made a similar decision. There are both advantages for us and disadvantages in opening the source, so there must be good reasons for making such a serious decision.
*** The
restrictions on dynamic code generation are completely analogous to the restrictions in Mono AoT , the code compatible with it will work with IL2CPP. Reflection will work. Things like System.Reflection.Emit not. No dynamic code generation at runtime.
***
iOS will be the first platform with IL2CPP support because AoT is already used there, so the transition will be smoother. Then there will be support for other platforms including PC, Mac and Linux.
***
Due to AoT and LGPL limitations, we cannot use Mono on iOS, which prevents us from updating Mono for the editor and other platforms
***
I'm not a lawyer. Definitely not a lawyer. But regarding the legal restrictions associated with Mono and LGPL, I can say the following. The problem is not in the layout, you can make the layout by providing users with additional data (object files). The problem is that the restrictions will affect all our customers who make games and applications on Unity. They, too, will fall under the restrictions. LGPL will be forced to provide object files to all their customers. Once again I note that I am not a lawyer, this is not the official position of Unity and only reflects my understanding of the situation as a programmer and stuff like that.
***
With Mono, we had to keep a team of specialists for each new platform. If Mono did not support this platform, we had to do a huge amount of work, as in fact we had to write our own JIT tools from scratch for each platform. For some platforms, we spent on transferring Mono three times more power than on all the rest of the work. With IL2CPP, instead of writing JIT tools, we can simply use the existing C ++ compiler, which is much simpler.
***
I’ve been working on Mono for 9 years and I can say with confidence that it takes about a year of work of a real expert on both Mono and this platform to transfer Mono to a new platform, if at all you can find and hold it to add all the features that require implementation, specific to this platform. It is difficult to describe in words how glad our experts on the new technology platforms are. They trade for the right to generate, debug, and maintain assembly code in C ++. The notes should have mentioned that porting now takes days, instead of months and years. It seems to me that many are moving in this direction. We started work before Microsoft announced .Net Native, but this only confirms the correctness of our chosen strategy. By limiting the possibilities a bit at runtime (no dynamic generation) you get a lot of advantages. No one forces you to use this for standalone PC applications. They will receive an updated version of Mono along with the editor as soon as IL2CPP becomes stable enough on platforms with AoT. The main goal of IL2CPP is those platforms where AoT really makes sense.
***
We understand that it’s not scripts at all that are usually a performance bottleneck, usually problems arise in case of incorrect or bad scripts. Nobody has complained to us yet that C # methods are not running too slowly. Garbage collection a separate conversation, leave it for later. But people like to discuss performance. It seems to me that IL2CPP in many cases will make meaningful use of scripts for those things that used to be considered too heavy and performed in C ++. AI, physics, and things like that will accelerate most of all and new, interesting possibilities will appear.
Personally, I can immediately recall the following optimizations
- refusing to check the boundaries of arrays
- eliminating support for exceptions (the load from them varies depending on the platform)
- elimination of static initialization, now every time you create an instance or access a static method / property, you need to verify that for all types with a static constructor it was executed
- SIMD support
- optimizing the interaction between binary and managed code. We will try to fulfill it to the maximum and most likely will give you the opportunity to strengthen it by voluntarily agreeing to additional restrictions.
All this is a random list of what I remembered right now. Later we will publish more detailed information.
***
On Mac / Linux / Windows and in the editor, we will support Mono as one of the options for a very, very long time and after some time we will update it to a new version. So if you are making a mod-enabled game for these platforms, you can continue to use Mono. No problem. Cross-publishing for Mac / Linux / Win will also continue to work unchanged.
On other platforms like iOS and Unity consoles, Unity already uses Mono AoT, so loading a dll is already impossible and will never be possible due to the limitations of the platforms themselves. Here you will not lose anything.
But before diving into the future it is worth talking about the present.
Scripts in Unity today
We use Mono (and WinRT for the Windows Store and Windows Phone applications) to bring Unity the ease of use of C #, access to third-party libraries, and virtually binary performance. But there are several difficulties:
- the performance of the C # runtime environment is still inferior to C / C ++
- the latest and best features of the languages and the .Net runtime environment are not supported by the version of Mono currently in use in Unity
- with about 23 platforms and architecture options, a lot of porting effort is required code and maintaining its quality at the same level
- garbage collection can cause delays in execution
Over the past few years, we have been constantly thinking about how to deal with all this. At the same time, research was ongoing in the area of scripting support for WebGL. As they move in both directions, they merged into one approach.
Realizing the scale of the problem, we began to experiment with different ways to solve it. Some were promising, some not. But in the end, we found an innovative way to solve our problems.
This is IL2CPP.
IL2CPP: quick and short introduction
IL2CPP consists of two parts: Ahead of Time (AOT) compiler and virtual machine (VM)
They are our implementation of Common Language Infrastructure , similar to .Net and Mono. It is compatible with the current implementation of scripts in Unity.
Its main difference from the current implementation is that the IL2CPP compiler converts assemblies into C ++ source code. He then uses the standard C ++ compiler for this platform to create native binaries.
The code runs at the same time as the additional services (such as the garbage collector, metadata, platform-specific resources) that IL2CCP VM provides.
Benefits of IL2CPP
Let's look at each of the above difficulties and how IL2CPP deals with it.
Performance
At IL2CPP, we strive to combine ease of use and coding speed with C ++ performance.
With it, we can maintain the speed of the current scripting process and complement it with an instant increase in productivity. We saw a 2-3-fold increase in the execution speed of some of our tests with complex scripts. This performance boost arises for several reasons:
- C ++ compilers and linkers give us a large number of previously unavailable optimization methods.
- Your code is subjected to static analysis for both speed and size
- Unity-oriented optimizations of the script execution environment
Although the work on IL2CPP is still far from complete, this early increase in productivity clearly indicates the great future of our project.
Update .Net
We very often receive requests to update the runtime. In recent years, .Net has developed very rapidly, and Unity currently only supports the functionality of the .NET 2.0 / 3.5 era for both the C # compiler and third-party libraries. Many users have requested access to new features for both their code and third-party libraries.
As IL2CPP grows older, we will update the versions of the Mono C # compiler, the base class libraries and the runtime for the editor (the editor will not be translated into IL2CPP in order to maintain the speed of script development). The combination of these two processes will bring a modern version of .Net to Unity.
It is worth noting that we are working with Microsoftto ensure quality and stability while adding current and future .Net features to Unity.
Portability and Support
While this may seem like Unity’s internal problems, they also concern you. The Mono virtual machine contains a huge amount of code specific to a specific platform and architecture. When porting Unity to a new platform, we spend a lot of effort on porting and supporting Mono VM for this platform. Some features (and errors) may exist only on specific platforms. This affects the values that Unity is trying to provide for you - the ease of transferring content between platforms.
IL2CPP solves this problem in several ways:
- The code is converted to C ++, and not machine-specific code specific to this architecture. The cost of porting and supporting code generation for each specific architecture is markedly reduced
- The development of new features and bug fixes are noticeably accelerated. For us, days of picking in an architecture-specific code are replaced by minutes of editing C ++. New features and bug fixes are immediately available for all platforms. The current version of IL2CPP is moving very quickly to new platforms.
In addition to this, platform or architecture-specific compilers are usually much better optimized than a single code generator. This will allow us to reuse all the efforts that went into developing C ++ compilers without reinventing them again within the company.
Garbage collection
IL2CPP is not tied to any particular garbage collector; instead, it connects them through a special API. The current version of IL2CPP uses an improved version of libgc , although we are considering different options. At the same time, we are exploring the possibilities of reducing pressure from the GC using analysis performed in the IL2CPP compiler.
Although at the moment we have nothing more to say, research is ongoing. We know that this is important for you, so we will continue to work and will inform you about it in future entries. In the context of garbage collection, it is worth noting that regardless of IL2CPP, in Unity 5 you will see much more allocation free APIs.
What IL2CPP Is Not
IL2CPP is not an attempt to recreate an entire .Net or Mono environment. We will continue to use the C # compiler from Mono (and in the future, Roslyn is also possible ). We will continue to use the Mono class libraries. All currently available features and third-party libraries compatible with Mono AOT will work with IL2CPP. We are going to replace only the Mono VM and AOT compiler, continuing to use the wonderful Mono project.
When can I try IL2CPP?
We hope that by this moment the opportunity to try IL2CPP excites you as much as we do, and you are wondering - when will you be able to try it personally? An early version of IL2CPP will be part of WebGL support in Unity 5.
After WebGL, we will continue to develop IL2CPP for other platforms. In fact, we already have implementations for a number of the platforms we support. We expect to release at least one more platform this year. At the moment, we plan to make iOS the next platform with IL2CPP support.
The planned upgrade of the Mono environment will happen after IL2CPP is supported on more platforms and grows a little older.
The only platform that will never support IL2CPP is WebPlayer, due to security restrictions. As noted earlier, the editor will continue to work on Mono.
You can see the IL2CPP runtime in action right now. The two WebGL demos we posted earlier work on it.
What's next?
We continue to work hard on IL2CPP: add new features, optimize code generation, fix bugs and add support for new platforms. We will publish more detailed articles as our work progresses and continue to discuss it with you in the forums.
Unity Script Team
A small addition from the answers of developers to questions in English comments and a special topic on the Unity forum :
The term “virtual machine” can be a little misleading. In fact, there will be no real virtual machine, everything will be in binary code, but there will be a number of functions available at run time and implementing the functionality needed by the managed code, such as system services or garbage collection, which we call a virtual machine in this case.
***
Writing scripts in C ++ is not an official goal of IL2CPP and nothing of the kind will appear in the near future, although this may happen sometime in the future as a side effect of decisions made.
***
The source codes will not open until we have been discussing a similar opportunity for a long time and have not yet made a similar decision. There are both advantages for us and disadvantages in opening the source, so there must be good reasons for making such a serious decision.
*** The
restrictions on dynamic code generation are completely analogous to the restrictions in Mono AoT , the code compatible with it will work with IL2CPP. Reflection will work. Things like System.Reflection.Emit not. No dynamic code generation at runtime.
***
iOS will be the first platform with IL2CPP support because AoT is already used there, so the transition will be smoother. Then there will be support for other platforms including PC, Mac and Linux.
***
Due to AoT and LGPL limitations, we cannot use Mono on iOS, which prevents us from updating Mono for the editor and other platforms
***
I'm not a lawyer. Definitely not a lawyer. But regarding the legal restrictions associated with Mono and LGPL, I can say the following. The problem is not in the layout, you can make the layout by providing users with additional data (object files). The problem is that the restrictions will affect all our customers who make games and applications on Unity. They, too, will fall under the restrictions. LGPL will be forced to provide object files to all their customers. Once again I note that I am not a lawyer, this is not the official position of Unity and only reflects my understanding of the situation as a programmer and stuff like that.
***
With Mono, we had to keep a team of specialists for each new platform. If Mono did not support this platform, we had to do a huge amount of work, as in fact we had to write our own JIT tools from scratch for each platform. For some platforms, we spent on transferring Mono three times more power than on all the rest of the work. With IL2CPP, instead of writing JIT tools, we can simply use the existing C ++ compiler, which is much simpler.
***
I’ve been working on Mono for 9 years and I can say with confidence that it takes about a year of work of a real expert on both Mono and this platform to transfer Mono to a new platform, if at all you can find and hold it to add all the features that require implementation, specific to this platform. It is difficult to describe in words how glad our experts on the new technology platforms are. They trade for the right to generate, debug, and maintain assembly code in C ++. The notes should have mentioned that porting now takes days, instead of months and years. It seems to me that many are moving in this direction. We started work before Microsoft announced .Net Native, but this only confirms the correctness of our chosen strategy. By limiting the possibilities a bit at runtime (no dynamic generation) you get a lot of advantages. No one forces you to use this for standalone PC applications. They will receive an updated version of Mono along with the editor as soon as IL2CPP becomes stable enough on platforms with AoT. The main goal of IL2CPP is those platforms where AoT really makes sense.
***
We understand that it’s not scripts at all that are usually a performance bottleneck, usually problems arise in case of incorrect or bad scripts. Nobody has complained to us yet that C # methods are not running too slowly. Garbage collection a separate conversation, leave it for later. But people like to discuss performance. It seems to me that IL2CPP in many cases will make meaningful use of scripts for those things that used to be considered too heavy and performed in C ++. AI, physics, and things like that will accelerate most of all and new, interesting possibilities will appear.
Personally, I can immediately recall the following optimizations
- refusing to check the boundaries of arrays
- eliminating support for exceptions (the load from them varies depending on the platform)
- elimination of static initialization, now every time you create an instance or access a static method / property, you need to verify that for all types with a static constructor it was executed
- SIMD support
- optimizing the interaction between binary and managed code. We will try to fulfill it to the maximum and most likely will give you the opportunity to strengthen it by voluntarily agreeing to additional restrictions.
All this is a random list of what I remembered right now. Later we will publish more detailed information.
***
Unity does not support the ability to create mods for the game and does not support the ability to create patches. Now we have third-party solutions that allow us to load mods from additional .Net dlls (though patches cannot be done this way anyway). But with IL2CPP we cannot do this either.
On Mac / Linux / Windows and in the editor, we will support Mono as one of the options for a very, very long time and after some time we will update it to a new version. So if you are making a mod-enabled game for these platforms, you can continue to use Mono. No problem. Cross-publishing for Mac / Linux / Win will also continue to work unchanged.
On other platforms like iOS and Unity consoles, Unity already uses Mono AoT, so loading a dll is already impossible and will never be possible due to the limitations of the platforms themselves. Here you will not lose anything.