Layered compilation in. NET Core 2.1 (preview)

if you are. NET performance fans, there has been a lot of good news recently, such as the performance improvements in. NET Core 2.1 and the announcement of. NET Core 2.1, but we have more good news. Layered Compilation is an important feature of new features that we can use as a preview for anyone to try, starting with. NET Core 2.1. in Many of the scenarios we tested, applications started faster and ran faster in a stable state. a project that runs on. NET Core 2.1 and makes insignificant changes to the environment variable or project file to enable it. in the remainder of this article, we will describe what it is, how to use it, and why it is a 2.1 version of hidden skills!

What is layered compilation?

starting with the. NET framework, each method in the code is usually compiled one time. However, tradeoffs are needed when deciding how to make a compilation that affects the performance of your application. For example, the JIT can be very aggressive optimizations and get good stability, but optimizing the code is not an easy task, so your application starts very slowly. or the JIT can use a very simple compilation algorithm, which can run quickly, so your application can start quickly, but the code quality will be worse and application throughput will be affected. . NET has been trying to adopt a balanced approach that makes sense for starting and stabilizing performance, but using a single compilation means compromise.

The Layered compilation feature is enabled by allowing runtime heat exchange technology to. NET for multiple compilations the same method changes the above premise. Two sets of mechanisms are separated so that we can choose the technology that best fits the startup, the second technique of choosing the most stable state and showing better performance on both (layered compilation). in . NET Core 2.1, this is what tiered compilation is designed to do for your application:

• faster application Start-up time -When the application starts, it waits for some MSIL code to be JIT. layered compilation requires JIT to generate initial compilation quickly, sacrificing code quality optimization if needed. later, if the method is called frequently, more optimized code is generated on the background thread and the initial code is replaced to maintain the stable performance of the application.
• faster performance in a stable state -for typical. NET core applications, most of the framework code will be compiled from precompiled ( Readytorun) image loading . This is useful for booting, but precompiled images have versioning constraints and prohibit certain types of optimizations for CPU instruction constraints. for any of the methods that are called frequently in these mirrors, the hierarchical compilation request JIT creates the optimization code on the background thread to replace the precompiled version.

faster? How fast is it?

part of the reason we publish this as a preview is to understand how it performs for your application, but here are some examples of how we tested it. Although very dependent on the scenario, we hope that these results are typical for your work-like scenario, and that as the functionality matures, the results will continue to improve. The benchmark is the. NET Core 2.1 RTM that runs under the default configuration, and all the numbers are scaled so that the benchmark is always 1.0. In the first group, we have several tech empower tests and musicstore (projects for specialized testing), which are examples of our common ASP.

While some of our ASP. NET benchmarks benefit from exceptionally good (mvcplaintext RPS over 60%-wow!). ), but layered compilation is not specific to ASP. Here are some examples of the. NET Core command-line applications that you may encounter in your daily development:

How will your application work? It's much easier to measure than to predict, but we can provide some broad rules of thumb.

1. startup improvements are primarily useful for reducing the time to manage managed code. You can use tools such as PerfView to determine how long your application will take. in our tests, the time spent by jitting is typically reduced by about 35%.
2. the improvement of the steady state is mainly applied to CPU bound applications, some of which are from the hot code. NET or ASP. For example , PerfView can help you determine if your application is in this category.

Try

a small disclaimer, the feature is still a preview. We've done a lot of testing on it, but this feature is not enabled by default because we want to collect feedback and continue to adjust. opening it may not make your application faster, or you may encounter places where we are not covered. If you're having trouble, Microsoft is here to help, and you can easily disable it at any time. If you prefer, you can enable this feature in production, but we strongly recommend that you test it beforehand.

There are several ways to opt in to this feature, and all of these methods have the same effect:

• if you use the. NET 2.1 SDK Self Build the application- add MSBuild Properties <TieredCompilation> true </tieredcompilation> To the default property group in the project file. For example:
  

This github link will find the following code

<ProjectSDK= "MICROSOFT.NET.SDK">    <PropertyGroup>      <OutputType>Exe</OutputType>      <targetframework>netcoreapp2.1</targetframework>      <tieredcompilation>True</tieredcompilation>    </PropertyGroup></Project>

• If you are running a built application, edit the Runtimeconfig.json to System.Runtime.TieredCompilation = True Add to configproperties. For example:

  {      "runtimeoptions": {        "configproperties  ": {          "System.Runtime.TieredCompilation "  True        }      },      "framework": {        ...      }    } 

• Set environment variables if you want to run the application but do not want to modify any files

complus_tieredcompilation=1

For more details on trying and measuring performance, see the layered compilation demo

Get this technology

curious about how it works? Don't be afraid to understand that these internal details are not required to use layered compilation, and you can skip this section if you prefer. at a glance, this feature can be divided into four different sections:

• The JIT compiler can be configured to generate different quality assembly code-Many people are surprised that this is not the focus of the feature so far. back to. NET, JIT supports the default compilation mode and the No-optimized compilation mode for debugging. Normal mode produces better code quality and requires more time to compile, whereas the "No optimization" mode is the opposite. for layered compilation, we created the new configuration name "Tier0" and "Tier1", but these configurations generated code that is roughly the same as the "No optimization" and "normal" modes we have been using. so far , most of the JIT changes involve making JIT-generated code faster when the "TIER0" code is requested. We hope to continue to improve TIER0 compilation speed in the future,
• Codeversionmanager (code versioning) tracks different code compilations (versions) of the same method-most fundamentally a large memory dictionary, which is stored in the application. NET methods can be used to execute the method when the list runs between the mappings and different assembly implementations. We use some techniques to optimize this data structure, but if you want to delve into this aspect of the project, you can refer to the very good specifications that we provide .
• The mechanism of hot updating in runtime state between different assembly code compilations of the same method-when method A calls method B, the call will depend on the JMP directive. you can control which implementation of B is performed by adjusting the runtime's jmp directives.
• The policy that determines which code versions to create and when to switch between them-the runtime always first creates Tier0, which is the code loaded from the Readytorun image, or code that uses minimized optimizations. Call counters are used to determine which methods are frequently run and use timers to avoid the work of creating Tier1 prematurely during startup. Once the counters and timers are satisfied, the method is queued, and the background line routines compiles the Tier1 version. For more information, see the specification .

Where do we start?

Layered Compilation creates a variety of possibilities, and we can continue to make the most of future time. Now that the runtime can take advantage of more extreme situations, we have the power and power to extend the boundaries, both to speed up compilation and to generate higher-quality code. Run-time hot update through code. NET can perform more detailed analysis and then use run-time feedback for better optimization (profile-guided optimizations). These techniques can allow code generators to even exceed the best static optimizer that cannot access profile data. or there are other options, such as dynamic de-optimization for better diagnostics, a collection of code to reduce memory usage, and a hot patch for performance testing or services. at the moment, our most immediate goal is still close to the actual-ensuring that the functionality in the preview works well, responds to your feedback, and completes the first iteration of the work.

Summary

we want tiered compilation to provide your application with the same significant improvements as our benchmarks, and we know there is more untapped potential. try It, then visit GitHub, giveus feedback, discuss, ask questions, and even contribute some of your own code. Thank you!

Original: Layered compilation in. NET Core 2.1 (preview)

Layered compilation in. NET Core 2.1 (preview)