The future of scripts in unity 3d
We recently wrote an article about WebGL support in Unity . In it, we briefly talked about how the scripts will work in WebGL using the new IL2CPP technology. However, IL2CPP is something much more ambitious than just a new script 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 Windows Store and Windows Phone applications) to bring C # ease of use, access to third-party libraries, and near-binary speed to Unity. But there are several difficulties:
')
- C # runtime performance is still inferior to C / C ++
- the latest and best features of languages ​​and the .Net runtime are not supported by the Mono version currently used in Unity
- with about 23 platforms and architecture options, it takes a lot of effort to port the code and maintain its quality at the same level
- garbage collection may cause delays during execution
For the past few years, we have been constantly thinking about how to handle this. At the same time, research was going on in support of scripts for WebGL. As they moved 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 were not. But in the end we found an innovative way to solve our problems.
This is an IL2CPP.
IL2CPP consists of two parts: Ahead of Time (AOT) compiler and virtual machine (VM)
They are our Common Language Infrastructure implementation, 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. It then uses the standard C ++ compiler for this platform to create native binaries.
The code runs simultaneously with additional services (such as the garbage collector, platform-specific metadata resources) provided by the IL2CCP VM.
Let's take a look at each of the above difficulties and how IL2CPP handles it.
In IL2CPP, we strive to combine ease of use and speed of writing code with C ++ performance.
With it, we can save the speed of the current process of writing scripts and supplement it with instant performance improvements. We saw a 2-3-fold increase in the speed of execution of some of our tests with complex scripts. This performance increase occurs for several reasons:
- C ++ compilers and linkers give us a large number of previously inaccessible optimization methods.
- Your code is subject to static analysis for both speed and size.
- Unity-based script runtime optimizations
And although the work on the IL2CPP is still far from complete, this early performance increase clearly indicates a great future for our project.
We very often receive requests for updating the runtime environment. In recent years, .Net has been developing very rapidly, and Unity currently supports only .NET 2.0 / 3.5 era functionality for both the C # compiler and third-party libraries. Many users 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 environment for the editor (the editor will not be translated to IL2CPP in order to maintain the speed of script development). The combination of these two processes will bring a modern version of .Net into Unity.
It is worth noting that we are working with Microsoft to ensure quality and stability when adding current and future .Net features to Unity.
While this may seem like an internal Unity problem, it also applies to you. The Mono virtual machine contains a huge amount of code specific to a particular platform and architecture. When transferring Unity to a new platform, we spend a lot of effort on the transfer and support of Mono VM for this platform. Some features (and bugs) can exist only on separate 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 the machine code specific to this architecture. The cost of porting and supporting code generation for each specific architecture is markedly reduced.
- Development of new features and correction of errors is markedly accelerated. For us, the days of picking in the architecture-specific code are replaced with C ++ editing minutes. New features and bug fixes are immediately available for all platforms. The current version of the IL2CPP is very quickly transferred to new platforms.
In addition, platform-specific or architecture-specific compilers are usually optimized much better than a single code generator. This will allow us to reuse all the efforts that went into developing C ++ compilers without reinventing them 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 various options. At the same time, we are exploring the possibility of reducing pressure from the GC side using the analysis performed in the IL2CPP compiler.
Although at the moment we have nothing more to tell, research continues. We know that this is important to you, so we will continue to work and will inform you about it in future posts. In the context of garbage collection, it's worth noting that, regardless of IL2CPP, in Unity 5 you will see a lot more allocation-free APIs.
IL2CPP is not an attempt to recreate the 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 existing capabilities and third-party libraries that are compatible with Mono AOT will work with IL2CPP. We are going to replace only the Mono VM and AOT compiler, while continuing to use the wonderful Mono project.
We hope that by this time the opportunity to try IL2CPP is worrying you as much as us, and you are wondering when will you be able to try it out 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 platforms supported by us. 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.
A scheduled update of the Mono environment will occur after IL2CPP has been supported on more platforms and has matured a bit.
The only platform that will never support IL2CPP is WebPlayer, due to security constraints. As noted earlier, the editor will continue to work on Mono.
You can see the IL2CPP runtime in action right now. The two WebGL demonstrations that we posted earlier work on it.
We continue to work hard on IL2CPP: we 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 developers' answers to questions in English-language comments and a special topic on the Unity forum :
The term “virtual machine” can be a bit deceptive. 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 runtime and implementing the functionality needed by managed code, such as system services or garbage collection, which we call in this case a virtual machine.
***
Writing scripts in C ++ is not the official goal of IL2CPP and in the near future nothing of the kind will appear, although this may happen sometime in the future as a side effect of the decisions made.
***
Source codes will not be opened yet, we have been discussing a similar opportunity for a long time and have not yet made such a decision. There are both advantages and disadvantages to opening source codes, so there must be good reasons for making such a serious decision.
***
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 no. 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 the AoT and LGPL limitations, we cannot use Mono on iOS, which prevents us from updating the Mono version for the editor and other platforms.
***
I am not a lawyer. Not exactly a lawyer. But regarding the legal restrictions related to Mono and the 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 of our customers making games and apps on Unity. They will also fall under the restrictions of the LGPL will be forced to provide object files to all their customers. Once again, I’m 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 perform just a huge amount of work, since in fact we had to write our own JIT tools for each platform from scratch. For some platforms, we spent on carrying the Mono three times more power than the rest of the work. With IL2CPP, instead of writing JIT tools, we can simply use the existing C ++ compiler, it's much easier.
***
I worked on Mono for 9 years and I can say with confidence that it takes about a year of work of a real expert on Mono and on this platform to transfer Mono to a new platform, if you can find one and keep it to add all the features that require implementation, specific to this platform. It is difficult to describe in words how happy our experts on new technology platforms are. They bargain for the right to generate, debug, and maintain build code in C ++. The entries 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. Having a little limited opportunities at runtime (no dynamic generation), you get a lot of advantages. No one forces you to use this for stand alone applications on a PC. They will receive an updated version of Mono with the editor as soon as the IL2CPP becomes fairly stable on platforms with AoT. The main goal of IL2CPP is those platforms where AoT really makes sense.
***
We understand that not at all scripts are usually a bottleneck in terms of performance, usually problems arise in the case of incorrect or bad scripts. Nobody has complained to us about the slow implementation of C # methods. Garbage collection a separate conversation, let's leave it for later. But people like to discuss performance. It seems to me that IL2CPP in many cases will make senseful use of scripts for those things that were previously considered too heavy and were executed in C ++. AI, physics and everything in this spirit will accelerate most of all and there will be new, interesting possibilities.
Personally, I can immediately recall the following optimizations
- refusal to check the boundaries of arrays
- elimination of 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 check that for all types with a static constructor it was executed
- SIMD support
- optimization of the interaction between binary and managed code. We will try to fulfill it to the maximum and most likely we 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 the new version. So if you make a game with mod support for these platforms, you can continue to use Mono. No problem. Cross publishing for Mac / Linux / Win will also continue to work without changes.
On other platforms like iOS and consoles, Unity already uses Mono AoT, so loading dlls is 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 Windows Store and Windows Phone applications) to bring C # ease of use, access to third-party libraries, and near-binary speed to Unity. But there are several difficulties:
')
- C # runtime performance is still inferior to C / C ++
- the latest and best features of languages ​​and the .Net runtime are not supported by the Mono version currently used in Unity
- with about 23 platforms and architecture options, it takes a lot of effort to port the code and maintain its quality at the same level
- garbage collection may cause delays during execution
For the past few years, we have been constantly thinking about how to handle this. At the same time, research was going on in support of scripts for WebGL. As they moved 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 were not. But in the end we found an innovative way to solve our problems.
This is an IL2CPP.
IL2CPP: quick and short introduction
IL2CPP consists of two parts: Ahead of Time (AOT) compiler and virtual machine (VM)
They are our Common Language Infrastructure implementation, 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. It then uses the standard C ++ compiler for this platform to create native binaries.
The code runs simultaneously with additional services (such as the garbage collector, platform-specific metadata resources) provided by the IL2CCP VM.
Benefits of IL2CPP
Let's take a look at each of the above difficulties and how IL2CPP handles it.
Performance
In IL2CPP, we strive to combine ease of use and speed of writing code with C ++ performance.
With it, we can save the speed of the current process of writing scripts and supplement it with instant performance improvements. We saw a 2-3-fold increase in the speed of execution of some of our tests with complex scripts. This performance increase occurs for several reasons:
- C ++ compilers and linkers give us a large number of previously inaccessible optimization methods.
- Your code is subject to static analysis for both speed and size.
- Unity-based script runtime optimizations
And although the work on the IL2CPP is still far from complete, this early performance increase clearly indicates a great future for our project.
.Net update
We very often receive requests for updating the runtime environment. In recent years, .Net has been developing very rapidly, and Unity currently supports only .NET 2.0 / 3.5 era functionality for both the C # compiler and third-party libraries. Many users 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 environment for the editor (the editor will not be translated to IL2CPP in order to maintain the speed of script development). The combination of these two processes will bring a modern version of .Net into Unity.
It is worth noting that we are working with Microsoft to ensure quality and stability when adding current and future .Net features to Unity.
Portability and support
While this may seem like an internal Unity problem, it also applies to you. The Mono virtual machine contains a huge amount of code specific to a particular platform and architecture. When transferring Unity to a new platform, we spend a lot of effort on the transfer and support of Mono VM for this platform. Some features (and bugs) can exist only on separate 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 the machine code specific to this architecture. The cost of porting and supporting code generation for each specific architecture is markedly reduced.
- Development of new features and correction of errors is markedly accelerated. For us, the days of picking in the architecture-specific code are replaced with C ++ editing minutes. New features and bug fixes are immediately available for all platforms. The current version of the IL2CPP is very quickly transferred to new platforms.
In addition, platform-specific or architecture-specific compilers are usually optimized much better than a single code generator. This will allow us to reuse all the efforts that went into developing C ++ compilers without reinventing them 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 various options. At the same time, we are exploring the possibility of reducing pressure from the GC side using the analysis performed in the IL2CPP compiler.
Although at the moment we have nothing more to tell, research continues. We know that this is important to you, so we will continue to work and will inform you about it in future posts. In the context of garbage collection, it's worth noting that, regardless of IL2CPP, in Unity 5 you will see a lot more allocation-free APIs.
What is not IL2CPP
IL2CPP is not an attempt to recreate the 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 existing capabilities and third-party libraries that are compatible with Mono AOT will work with IL2CPP. We are going to replace only the Mono VM and AOT compiler, while continuing to use the wonderful Mono project.
When can I try IL2CPP?
We hope that by this time the opportunity to try IL2CPP is worrying you as much as us, and you are wondering when will you be able to try it out 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 platforms supported by us. 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.
A scheduled update of the Mono environment will occur after IL2CPP has been supported on more platforms and has matured a bit.
The only platform that will never support IL2CPP is WebPlayer, due to security constraints. As noted earlier, the editor will continue to work on Mono.
You can see the IL2CPP runtime in action right now. The two WebGL demonstrations that we posted earlier work on it.
What's next?
We continue to work hard on IL2CPP: we 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 developers' answers to questions in English-language comments and a special topic on the Unity forum :
The term “virtual machine” can be a bit deceptive. 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 runtime and implementing the functionality needed by managed code, such as system services or garbage collection, which we call in this case a virtual machine.
***
Writing scripts in C ++ is not the official goal of IL2CPP and in the near future nothing of the kind will appear, although this may happen sometime in the future as a side effect of the decisions made.
***
Source codes will not be opened yet, we have been discussing a similar opportunity for a long time and have not yet made such a decision. There are both advantages and disadvantages to opening source codes, so there must be good reasons for making such a serious decision.
***
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 no. 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 the AoT and LGPL limitations, we cannot use Mono on iOS, which prevents us from updating the Mono version for the editor and other platforms.
***
I am not a lawyer. Not exactly a lawyer. But regarding the legal restrictions related to Mono and the 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 of our customers making games and apps on Unity. They will also fall under the restrictions of the LGPL will be forced to provide object files to all their customers. Once again, I’m 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 perform just a huge amount of work, since in fact we had to write our own JIT tools for each platform from scratch. For some platforms, we spent on carrying the Mono three times more power than the rest of the work. With IL2CPP, instead of writing JIT tools, we can simply use the existing C ++ compiler, it's much easier.
***
I worked on Mono for 9 years and I can say with confidence that it takes about a year of work of a real expert on Mono and on this platform to transfer Mono to a new platform, if you can find one and keep it to add all the features that require implementation, specific to this platform. It is difficult to describe in words how happy our experts on new technology platforms are. They bargain for the right to generate, debug, and maintain build code in C ++. The entries 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. Having a little limited opportunities at runtime (no dynamic generation), you get a lot of advantages. No one forces you to use this for stand alone applications on a PC. They will receive an updated version of Mono with the editor as soon as the IL2CPP becomes fairly stable on platforms with AoT. The main goal of IL2CPP is those platforms where AoT really makes sense.
***
We understand that not at all scripts are usually a bottleneck in terms of performance, usually problems arise in the case of incorrect or bad scripts. Nobody has complained to us about the slow implementation of C # methods. Garbage collection a separate conversation, let's leave it for later. But people like to discuss performance. It seems to me that IL2CPP in many cases will make senseful use of scripts for those things that were previously considered too heavy and were executed in C ++. AI, physics and everything in this spirit will accelerate most of all and there will be new, interesting possibilities.
Personally, I can immediately recall the following optimizations
- refusal to check the boundaries of arrays
- elimination of 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 check that for all types with a static constructor it was executed
- SIMD support
- optimization of the interaction between binary and managed code. We will try to fulfill it to the maximum and most likely we 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 you still can't make patches anyway). But with IL2CPP we can’t do that 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 the new version. So if you make a game with mod support for these platforms, you can continue to use Mono. No problem. Cross publishing for Mac / Linux / Win will also continue to work without changes.
On other platforms like iOS and consoles, Unity already uses Mono AoT, so loading dlls is impossible and will never be possible due to the limitations of the platforms themselves. Here you will not lose anything.
Source: https://habr.com/ru/post/224447/
All Articles