The JIT compiler translates the MSIL code of an assembly to native code and uses the CPU architecture of the target machine to execute a .NET application.
It also stores the resulting native code so that it is accessible for subsequent calls.
If a code executing on a target machine calls a non-native method, the JIT compiler converts the MSIL of that method into native code.
NGen
does JIT after instalation or during deployment. Also called pre-JIT.
Econo
when runned only excecuted methods are JITed and after closing program everything is dropped.
Standard JIT
The compiler compiles only those methods called at run time.
After executing this method, compiled methods are stored in a memory cache.
Now further calls to compiled methods will execute the methods from the memory cache.
New JIT architeture partialy shared.
Targerts not only Intel architectures but also ARM.
Multiple code generation targets (instruction sets and operating systems),
Improved optimizations,
Better and more flexible code generation, and
Open, flexible, and robust design and implementation.
Difereneces from JIT32 and JIT64
Allowing .NET to have multiple compilations for the same method that can be hot-swapped at runtime. This separates the decision making so that we can pick a technique that is best for startup, pick a second technique that is best for steady-state and then deliver great performance on both.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharp.html
and we have crossgen
Most of .NET Core is using JIT compilation.
JITs are well suited for long-running scenarios. They generate code that targets a specific machine configuration, including specific CPU instructions.
A JIT can also re-generate methods at runtime to achieve a highly-tuned version of the frequently used method.
MONO is using LLVM to do AOT compilation. The same is for Blazor Framework.
The goal of .NET 5 is to use AOT compilation in most cases but use JIT in cases where AOT performance is not great (= generics).
AOT provides fast startup, low footprint, and lower memory usage
This is the base library for .NET Core. It includes the garbage collector, JIT compiler, base .NET types, and many of the low-level classes. The runtime provides the bridge between the .NET Core framework libraries (CoreFX) and the underlying operating systems.
This is the set of .NET Core foundational libraries and includes classes for collections, file systems, the console, XML, async, and many other base items. These libraries build on CoreCLR and provide the interface points for other frameworks into the runtime.
Has CLR and Base Class Library
In .NET Framework, the project was set up using Visual Studio and it's template.
In .NET Core Microsoft inspired in JavaScript world and created .NET CLI. The you can completly control your project/solution setup.
dotnet new -l
dotnet new console
dotnet build
dotnet run
dotnet watch
dotnet add package <package name>
project file should now contain
<PackageReference Include="<package name>" Version="<package version>" />
dotnet add app/app.csproj reference lib1/lib1.csproj lib2/lib2.csproj
project file should now contain
<ItemGroup>
<ProjectReference Include="app.csproj" />
<ProjectReference Include="..\lib2\lib2.csproj" />
<ProjectReference Include="..\lib1\lib1.csproj" />
</ItemGroup>
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="9.0.1" />
</ItemGroup>
</Project>
In .NET FW everything is solution-centric. Solution is in root folder and projects are directly in subfolders.
When generated with Docker build there is additional folder for Docker.
Files had to be added to project file. This leads to conflicts in merges.
When .NET Core came the need to add files to project was dropped. Only references, dependencies and build configs remain. This leads to less conflicts.
Since .NET Core is not solution-centric. You do your repo like in other languages by creating src folder.
Into src you put your projects.
In root you have also solution file, docker file, build files and others.
This leads to much cleaner structure.
Only in Core we have this namespace. It can use directly specific CPU instructions for heavu workloads.
Does your CPU supports AVX or AES on hardware level? Yes? Fine, let's use it.
Use .NET Core for your server application when:
Use .NET Framework for your server application when:
Entity Framework
ASP.NET
IIS Web Server
SimpleInjector / AutoFac / Castle
Entity Framework
ASP.NET Core
self-hosted / Kesterel
Dapper
It is self-hosted. Hosted on one of best performing web servers (build into app)
https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=fortune
Dependency injection build in.
Much diferent approach to setup and startup of application
Version on Core is more performant.
Runs on Linux and Mac.
Support not only full CMS but also decoupled CMS and headless CMS.
Supports GraphQL out of the box.
Well, it is dead.
As a replacement check UNO platform.
https://platform.uno
This is a tool used by data scientists.
You can quickly build something there.
From .NET Core 3 you can have not only Python kernel but also C# and F#.
https://www.hanselman.com/blog/AnnouncingNETJupyterNotebooks.aspx
.NET Core only. The way how to build destop app using ASP.NET Core.
Future how to build apps. Build on WASM.
Now we have also Blazor Bindings for Xamarin.