Shulou(Shulou.com)06/01 Report--

This article will explain in detail the meaning of hierarchical compilation in .NET Core 2.1. the content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

If you are a fan of .NET performance, 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. Hierarchical compilation is an important new feature that we can use as a preview for anyone to try out, starting with .NET Core 2.1. In many of the scenarios we tested, the application started faster and ran faster in a steady state. A project running on .NET Core 2.1and minor changes to the environment variable or project file to enable it. In the rest of the article, we will cover what it is, how to use it, and why it is a hidden skill in version 2.1!

What is hierarchical compilation?

Starting with the .NET Framework, each method in the code is usually compiled once. However, there is a tradeoff when deciding how to compile that affects the performance of the application. For example, JIT can optimize very aggressively and achieve good stable performance, but optimizing code is not an easy task, so your application starts very slowly. Or JIT can use very simple compilation algorithms that 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 in terms of startup and stable performance, but using a single compilation means compromise.

The hierarchical compilation feature changes the above premise by allowing runtime heat exchange technology to compile .NET multiple times in the same method. The separation of the two mechanisms so that we can choose the technology that is most suitable for startup, the second technology (hierarchical compilation) that is the most stable state and shows better performance on both. In .NET Core 2.1, this is what Tiered Compilation aims to do for your application:

Faster application startup time-when the application starts, it waits for some MSIL code to JIT. Hierarchical compilation requires JIT to generate initial compilation quickly, at the expense of code quality optimization if necessary. After that, 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 steady-state performance-for a typical .NET Core application, most of the framework code will be loaded from a precompiled (ReadyToRun) image. This is useful for startup, but precompiled images have version control constraints and CPU directive constraints that prohibit some types of optimization. For any of the methods in these images that are called frequently, hierarchical compilation requests JIT to create optimized code on the background thread to replace the precompiled version.

Faster? How fast is it?

Part of the reason we released this as a preview is to see how it works 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 of you in similar work scenarios, and the results will continue to improve as the functionality matures. The benchmark is run in the default configuration. NET Core 2.1 RTM, and all numbers are scaled, so 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 commonly used ASP.NET applications.

Although some of our ASP.NET benchmarks benefit from being particularly good (MvcPlaintext RPS is over 60%-wow! But hierarchical compilation is not specific to ASP.NET Here are some sample .NET Core command line applications that you may encounter in your daily development:

How will your application work? Measurement is much easier than prediction, but we can provide some broad rules of thumb.

Startup improvements are mainly used to reduce the time it takes to manage managed code. You can use tools such as PerfView to determine how much time your application takes. In our tests, the time spent by jitting is usually reduced by about 35%.

Steady-state improvements mainly apply to CPU-bound applications, with some hot code coming from .NET or ASP.NET precompiled libraries. For example, PerfView can help you determine that your application is in this category.

Give it a try

A small disclaimer, the feature is still a preview. We have 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 we don't cover. If you encounter a problem, Microsoft is ready to help you, and you can easily disable it at any time. You can enable this feature in production if you like, but we strongly recommend that you test it in advance.

There are several ways to add this feature, all of which have the same effect:

If you build your application using .NET 2.1 SDK-add the MSBuild property true to the default property group in the project file. For example:

This GitHub link can find the following code

Exe netcoreapp2.1 true

If you are running a built application, edit runtimeconfig.json to add System.Runtime.TieredCompilation = true to configProperties. For example:

{"runtimeOptions": {"configProperties": {"System.Runtime.TieredCompilation": true}}, "framework": {.}}

If you want to run the application but do not want to modify any files, set the environment variable

COMPlus_TieredCompilation=1

For more details on trying and measuring performance, check out the hierarchical compilation demonstration

To get this technology.

Wonder how it works? Don't be afraid, understanding these internal details is not necessary to use hierarchical compilation, and you can skip this section if you like. It is clear at a glance that this feature can be divided into four different parts:

The JIT compiler can be configured to generate assembly code of different quality-to many people's surprise, this is not the focus of this feature so far. Going back to the beginning of .NET, JIT supports the default compilation mode and the non-optimized compilation mode for debugging. Normal mode produces better code quality and takes longer to compile, while the "no optimization" mode is the opposite. For hierarchical compilation, we created new configuration names "Tier0" and "Tier1", but the code generated by these configurations is roughly the same as the "no optimization" and "normal" modes we have been using. So far, most JIT changes have involved making JIT generate code faster when requesting "Tier0" code. We hope to continue to improve the compilation speed of Tier0 in the future

CodeVersionManager (Code versioning) tracks different code compilations (versions) of the same method-the most basic is a large memory dictionary that stores mappings between .NET methods in the application and list implementations of different assembly implementations that can be used by the runtime to execute the method. We use some techniques to optimize this data structure, but if you want to delve deeper into this aspect of the project, you can refer to the very good specifications we provide.

The mechanism of hot update at runtime between assemblers of different assemblers of the same method-when method A calls method B, the call depends on the jmp instruction. Which implementation of B is executed can be controlled by adjusting the runtime jmp instructions.

A strategy for deciding which versions of code to create and when to switch between them-the runtime always creates the Tier0 first, which is the code loaded from the ReadyToRun image, or using minimized optimized code. Call counters are used to determine which methods are run frequently and to use timers to avoid the work of creating Tier1 prematurely during startup. Once the counter and timer are met, the method is queued and the background thread compiles the Tier1 version. For more information, see the specification.

Where do we start?

Hierarchical 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 motivation and motivation to extend boundaries, both to speed up compilation and to generate higher-quality code. With run-time hot updates of the code, .NET can do more detailed analysis and then use run-time feedback for better optimization (profile-guided optimization). These techniques can allow code generators to exceed even the best static optimizer that cannot access profile data. Or there are other options, such as dynamic de-optimization for better diagnosis, collectable code to reduce memory usage, and hot patches for performance testing or services. For now, our most immediate goal is still close to reality-to make sure that the functionality in the preview works well, respond to your feedback, and complete the first iteration of the work.

So much for sharing the meaning of hierarchical compilation in .NET Core 2.1. I hope the above content can be helpful to you and you can learn more. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.