Announcing .NET 6 Preview 1 (2/2)

 

2021.03.12 - [.NET 5, 6 and .NET Conf 2020] - Announcing .NET 6 Preview 1 (1/2)

Targeting .NET 6

.NET 6 용 TFM (대상 프레임워크 모니커)은 .NET 5에서 채택한 접근 방식을 따릅니다. 새 플랫폼에 대한 지원을 추가 한 결과 새 TFM이 추가되었습니다.

 

.NET 6을 타겟팅하려면 .NET 6 TFM을 사용해야합니다. 예를 들면 다음과 같습니다.

<TargetFramework>net6.0</TargetFramework>

운영별 TFM을 포함한 전체 .NET 6 TFM 세트는 다음과 같습니다.

• net6.0
• net6.0-android
• net6.0-ios
• net6.0-maccatalyst
• net6.0-macos
• net6.0-tvos
• net6.0-windows

이 세트와 기존 TFM 모두에서 이러한 TFM에 대한 호환성 관계는 .NET 6.0 Target Frameworks에서 설명합니다.

 

.NET 5에서 .NET 6으로의 업그레이드는 간단해야합니다. .NET 6으로 기존 앱을 테스트하는 과정에서 발견 한 주요 변경 사항을 보고하십시오.

.NET CLI

.NET CLI는 System.CommandLine 라이브러리 채택의 결과로 추가적인 편의성을 경험할 수 있습니다.

Response files

응답 파일은 도구에 대한 명령 줄 인수 집합이 포함 된 파일입니다. 응답 파일은 두 가지 주요 사용 사례를 충족합니다. 명령 줄 호출이 터미널의 문자 제한을 넘어 확장 되도록하고 동일한 명령을 반복적으로 입력하는 것보다 편리합니다. .NET CLI에 대한 응답 파일 지원이 추가되었습니다. 구문은 @file.rsp입니다. 응답 파일의 형식은 터미널에서 구조화되는 것처럼 한 줄의 텍스트입니다.

 

다음 애니메이션은 dotnet build와 함께 응답 파일을 사용하는 방법을 보여줍니다. dotnet build @demo.rsp

Directives

Directives은 명령과 직접 상호 작용하기 위한 System.CommandLine 환경입니다. System.CommandLine 모델 내에서 명령은 연결된 동작이 있는 데이터로 호출하거나 탐색 할 수있는 개체 집합을 이야기합니다.

 

제안 directive을 사용하면 정확한 명령을 모르는 경우 명령을 검색 할 수 있습니다. 이 directive은 dotnet-suggest 전역 도구를 활성화하기 위해 존재합니다.

dotnet [suggest] buil
build
build-server
msbuild

parse directive는 CLI가 명령을 구문 분석하는 방식을 보여줍니다. 명령이 작동하지 않거나 예상과 다른 결과가 나오는 이유를 이해하는 것이 유용 할 수 있습니다.

dotnet [parse] build -f net5.0
[ dotnet [ build [ -f <net5.0> ] ] ]

Libraries

.NET 라이브러리에 다음 API가 추가되었습니다.

New math APIs

다음과 같은 성능 지향 수학 API가 System.Math에 추가되었습니다. 기본 하드웨어가 지원하는 경우 구현이 하드웨어 가속화됩니다.

New APIs:

• SinCos for simultaneously computing Sin and Cos
• ReciprocalEstimate for computing an approximate of 1 / x
• ReciprocalSqrtEstimate for computing an approximate of 1 / Sqrt(x)

New overloads:

• Clamp, DivRem, Min, and Max supporting nint and nuint
• Abs and Sign supporting nint
• DivRem variants which return a tuple

Improved support for Windows ACLs

System.Threading.AccessControl에는 이제 Windows Access Control(ACLs)의 상호 작용을 위한 향상된 지원이 포함됩니다. EventWaitHandle, Mutex 및 Semaphore에 대한 OpenExisting 및 TryOpenExisting 메서드에 새로운 오버로드가 추가되었습니다. 이러한 오버로드("보안 권한"인스턴스 포함)를 통해 특수 Windows 보안 특성으로 생성된 스레딩 동기화 개체의 기존 인스턴스를 열 수 있습니다. 이 업데이트는 .NET Framework에서 이미 사용 가능한 API와 일치하며 동일한 동작을합니다.

namespace System.Threading
{
    public static partial class EventWaitHandleAcl
    {
        public static EventWaitHandle OpenExisting(string name, EventWaitHandleRights rights);
        public static bool TryOpenExisting(string name, EventWaitHandleRights rights, out EventWaitHandle result);
    }
    public static partial class MutexAcl
    {
        public static Mutex OpenExisting(string name, MutexRights rights);
        public static bool TryOpenExisting(string name, MutexRights rights, out Mutex result);
    }
    public static partial class SemaphoreAcl
    {
        public static Semaphore OpenExisting(string name, SemaphoreRights rights);
        public static bool TryOpenExisting(string name, SemaphoreRights rights, out Semaphore result);
    }
}

Portable thread pool

.NET thread pool은 managed implementation으로 다시 구현되었으며 이제 .NET 6에서 기본 스레드 풀로 사용됩니다. 우리는 애플리케이션이 CoreCLR, Mono 또는 다른 런타임이 사용되었는지 여부에 관계없이 동일한 스레드 풀에 액세스할 수 있도록 변경했습니다. 우리는 이 스레드 풀을 향후 NET의 표준으로 간주할 것이나, 이러한 변화가 기능적 또는 성능에 미치는 영향을 지켜볼 예정입니다.

 

이제 스레드 풀이 C#으로 작성되어 실험이나 사용자 정의에서 더 쉽게 액세스 할 수있을 것으로 기대합니다.

 

COMPlus_ThreadPool_UsePortableThreadPool = 0을 사용하여 기본 구현 런타임 스레드 풀을 사용하도록 되돌릴 수 있습니다. 이전 스레드 풀을 얼마나 오래 유지할지는 아직 결정하지 않았습니다.

Runtime

미리보기 1의 일부인 몇 가지 새로운 런타임 기능이 있습니다. 여기에는 Apple Silicon 지원, crossgen 2 및 앞서 설명한 PGO 테마 제공 시작이 포함됩니다.

Support for Apple Silicon

새로운 Apple M1 Arm64 칩은 올해 초 많은 업계 팡파르를 받았습니다. Apple Silicon 지원은 .NET 6의 주요 결과물입니다. 팀은 2020 년 Apple로부터 DTK (개발자 전환 키트)를 받은 이후로 Apple Silicon 칩에 대한 지원을 활성화하기 위해 노력해 왔습니다. .NET 6 Preview 1에는 Apple Silicon의 첫 번째 구현이 포함되어 있습니다. 그러나, 이 단계에서는 알파 품질을 가지고 있다는 점을 고려해야합니다. 우리는 고품질 제품을 보장하기 위해 작업해야 할 몇 가지 설계 문제와 중요한 검증들이 남아있습니다.

 

참고 : 이 게시물과 GitHub의 문제에서는 "Apple Silicon", "Apple M1"및 "Apple Arm64"라는 용어를 대체로 같은 의미로 사용합니다. 특정 칩의 기능을 구체적으로 언급하지 않는 한 "Apple Silicon"을 최상의 일반 용어로 간주합니다. 이는 Apple이 나중에 칩 변형 (예 : "M2")을 출시하면 더 의미가있을 것입니다.

 

Apple Silicon 칩에는 기본 모드와 (x64) 에뮬레이션의 두 가지 모드가 있습니다. 에뮬레이션은 Rosetta 2 구성 요소에서 부분적으로 구현됩니다. x64 에뮬레이션은 Apple M1 장치에서 매우 우수한 것으로 널리 보고되었습니다.

 

.NET 6의 경우 macOS 용 Arm64 및 x64 빌드를 모두 제공합니다. 이전 버전 .NET 및 .NET Core 릴리스에서는 x64 빌드만 계속 제공 할 것이며, Apple Silicon 컴퓨터에서는 Rosetta 2 에뮬레이션을 사용할 것입니다. Apple Silicon 지원을 활성화하기 위한 프로젝트는 중요했으며 .NET 5 또는 이전 .NET Core 버전으로 역포팅하는 것을 고려하지 못 할만큼 많은 코드 변경이 있었기 때문입니다.

 

다음은 Apple Silicon 시스템에서 실행되는 .NET 5 및 .NET 6의 예입니다.

rich@MacBook-Air dotnet-runtimeinfo % pwd
/Users/rich/git/core/samples/dotnet-runtimeinfo
rich@MacBook-Air dotnet-runtimeinfo % dotnet run
**.NET information
Version: 5.0.3
FrameworkDescription: .NET 5.0.3
Libraries version: 5.0.3
Libraries hash: c636bbdc8a2d393d07c0e9407a4f8923ba1a21cb

**Environment information
OSDescription: Darwin 20.4.0 Darwin Kernel Version 20.4.0: Fri Jan 22 03:28:00 PST 2021; root:xnu-7195.100.296.111.3~3/RELEASE_ARM64_T8101
OSVersion: Unix 11.0.0
OSArchitecture: X64
ProcessorCount: 8
rich@MacBook-Air dotnet-runtimeinfo % export DOTNET_ROLL_FORWARD=Major
rich@MacBook-Air dotnet-runtimeinfo % export DOTNET_ROLL_TO_PRERELEASE=1
rich@MacBook-Air dotnet-runtimeinfo % dotnet run
**.NET information
Version: 6.0.0
FrameworkDescription: .NET 6.0.0-preview.1.21102.12
Libraries version: 6.0.0-preview.1.21102.12
Libraries hash: 9b2776d48183632662e0be873cef029cdb57f8d6

**Environment information
OSDescription: Darwin 20.4.0 Darwin Kernel Version 20.4.0: Fri Jan 22 03:28:00 PST 2021; root:xnu-7195.100.296.111.3~3/RELEASE_ARM64_T8101
OSVersion: Unix 11.3.0
OSArchitecture: Arm64
ProcessorCount: 8

이 예는 오해의 소지가 있습니다. 알려진 문제 섹션에서 이유를 설명하겠습니다.

 

또한 .NET 컨테이너 이미지 (x64 및 Arm64 모두)가 Apple Silicon 시스템에서 올바르게 작동하는지 확인하고 있습니다. 그 게시물의 앞부분에서 그 예를 보셨습니다.

 

Apple은 Apple Silicon 작업의 훌륭한 파트너였습니다. 그들은 여러 가지 방법으로 우리를 도왔으며 .NET 개발자와 사용자가 Apple Silicon 장치에서 생산적이고 행복하기를 원한다고 표현했습니다. 감사합니다 Apple 여러분!

Native Apple Silicon

새로운 Apple 칩은 우리가 지원하는 다른 Arm64 칩보다 더 엄격한 요구 사항을 가지고 있습니다. Apple은 JIT 컴파일러에 의존하는 애플리케이션 런타임에 변경이 필요하다는 사실을 깨닫고 Just-In-Time 컴파일러를 Apple Silicon으로 포팅 및 관련 새 API를 게시했습니다. Apple과의 논의 중 최소 절반은 이 문서에 설명 된 주제를 중심으로 이루어졌습니다. 이러한 새로운 요구 사항은 .NET 6 Preview 1 빌드에서 충족됩니다.

 

범용 바이너리는 Mac 앱 스토어를 통해 게시되는 앱에 대한 또 다른 새로운 요구 사항입니다. 스토어를 통한 게시는 현재 우리가 지원하는 기능이 아니며 .NET 개발자로부터 많은 요청을받은 것도 아닙니다. 이번 릴리스에서는 .NET 앱용 범용 바이너리를 게시하는 워크 플로를 활성화하지 않습니다. .NET 7에서 이러한 요구를 재고 할 것입니다.

 

참고 : Mac은 동시에 실행되는 네이티브 및 에뮬레이트 된 앱을 모두 지원하지만 단일 프로세스는 항상 네이티브 또는 에뮬레이션입니다. 이는 .NET 앱의 문제는 아니지만 모든 앱 플랫폼에서 알아야 할 사항입니다. Activity Monitor는 Mac에서 각 프로세스의 아키텍처를 표시하므로 앱이 기본으로 이식되었는지 또는 에뮬레이션에 의존하는지 쉽게 알 수 있습니다.

Apple Silicon ABI 요구 사항은 Mac Intel 및 우리가 지원하는 다른 Arm64 플랫폼과 다릅니다. .NET 런타임은 ABI 차이로 인해 여러 다른 호출 규칙을 지원하므로 Apple Silicon ABI 요구 사항을 지원하는 것은 고유 한 문제가 아닙니다.

 

Apple Silicon Arm64 ABI 요구 사항을 지원하기 위해 다음 사항이 변경되었습니다.

• Use bytes in fgArgTabEntry
• Support byte sizes from lowering to codegen
• Preserve precise argument sizes
• Use 4-byte stack alignment for hfa<float>
• Arg alignment

Debugging

기본적으로 실행되는 .NET 앱 디버깅은 현재 모든 Visual Studio 제품에서 로컬 또는 원격으로 작동하지 않습니다. 디버깅은 나중에 미리보기에서 활성화됩니다 (미리보기 3을 희망합니다).

 

네이티브 디버깅을 사용할 수없는 경우 다음 해결 방법 중 하나를 사용할 수 있습니다.

• Rosetta 2 에뮬레이션을 사용하여 x64 런타임을 사용하여 앱을 시작하고 디버그합니다.
• Intel Mac 또는 Linux Arm64와 같은 다른 플랫폼에서 디버그합니다.

고급 사용자의 경우 : sos-debugging-extension과 함께 lldb 네이티브 디버거를 사용합니다. 다음과 같이 dotnet/diagnostics 저장소에서 확장을 빌드 한 다음 lldb 플러그인으로로드해야합니다.

(lldb) plugin load /Users/stmaclea/git/diagnostics/artifacts/bin/OSX.arm64.Debug/libsosplugin.dylib

Known issues

다음 문제는 미리보기 1에 있으며 이후 미리보기에서 해결 될 것입니다.

• 대용량 스택 할당의 경우 Apple Silicon 페이지 크기가 16K이므로 JIT가 스택 지우기 코드를 생성하지 못할 수 있습니다.
• 안정성은 아직 x64와 동등하지 않습니다.
  • 소수의 테스트가 GC 스트레스 테스트에 실패했습니다.
  • 적은 수의 테스트에서 간헐적인 실패가 나타납니다.
• 머신 가용성으로 인해 CI 테스트가 활성화되지 않았으므로 테스트 범위는 수동 테스트에서 가져온 것입니다.
• 우리는 아직 Apple Silicon에서 에뮬레이트 된 네이티브 .NET 버전을 함께 사용하는 경험을 설계하지 않았습니다. 예를 들어 동일한 시스템에서 .NET 6 및 .NET 5를 사용하려면 .tar.gz를 사용해야합니다. 경로에있는 버전 (있는 경우)을 제어 할 수 있도록 .pkg가 아닌 배포.
• .tar.gz. 패키지는 악성 소프트웨어로 보고됩니다.

이전에 표시된 예에서 .NET 5와 .NET 6이 동일한 흐름에있는 경우 .NET 5 .pkg를 설치하고 예제를 실행하고 전체 시스템 전체 dotnet 디렉터리를 삭제 한 다음 .NET 6 .pkg를 설치했습니다. 컴퓨터에 하나의 dotnet 실행 파일만 있고 기본 프로세스와 에뮬레이트 된 프로세스 모두에 로드되어야 한다는 주요 문제 중 하나입니다. 아직 활성화하지 않았지만 조사 중입니다.

.NET Rosetta 2 Emulation

Apple과 Microsoft의 공통된 목표는 .NET x64 제품이 변경없이 Rosetta 2 에뮬레이션에서 실행된다는 것입니다. .NET 5 macOS x64 빌드가 Big Sur 11.2 이상에서 잘 작동하는 것으로 나타났습니다. 에뮬레이션과 함께 .NET을 사용하는 경우 Big Sur의 최신 빌드가 있는지 확인하십시오. 이전 Big Sur 빌드는 문제가있는 것으로 확인되었습니다.

 

Microsoft, Apple 및 커뮤니티에서 테스트 한 .NET 5 x64는 다음을 보여줍니다.

• 안정성과 성능이 좋습니다.
• 디버깅은 완벽하게 작동합니다.
• 디버깅 할 때 성능이 느립니다.

Rosetta 2 에뮬레이션에서 실행되는 .NET 및 .NET Core x64 버전에 대한 전체 테스트 통과가 완료되지 않았습니다. 현재 동작을 검증하는 프로세스를 통해 작업한 다음 필요에 따라 문제를 해결하는 방법을 결정하여 Apple Silicon에서 고품질 및 고성능 x64 제품 경험을 보장합니다.

 

Rosetta 2 에뮬레이션이 Apple Silicon에서 영원히 지원 될 것으로 기대하지는 않지만 Arm64로의 임시 마이그레이션 브리지로 사용됩니다. 우리의 주요 초점은 Apple Silicon에서 경쟁력있는 Arm64 경험을 가능하게하는 것입니다. Apple이 지원하는 한 Mac Intel 컴퓨터에서 .NET을 계속 지원할 것입니다.

Improving single file apps

.NET 6에서는 Windows 및 macOS 용 단일 파일 앱이 활성화되었습니다. .NET 5에서 단일 파일 앱은 Linux로 제한되었습니다. .NET 6에서는 지원되는 모든 운영 체제에 대해 디스크에 정확히 하나의 파일이 있고 핵심 런타임 어셈블리를 임시 디렉터리로 추출 할 필요가 없는 단일 파일 바이너리를 게시 할 수 있습니다.

 

이 기능은 "superhost"라는 빌딩 블록을 기반으로합니다. 일반적인 "apphost"는 myapp.exe 또는 ./myapp과 같이 응용 프로그램을 시작하는 실행 파일입니다. Apphost에는 런타임을 찾고,로드하고, 해당 런타임으로 앱을 시작하는 코드가 포함되어 있습니다. Superhost는 여전히 이러한 작업을 수행하지만 모든 CoreCLR 기본 바이너리의 정적으로 연결된 복사본도 포함합니다. 따라서 CoreCLR 네이티브 바이너리를 다른 곳에서 사용할 필요가 없습니다.

 

단일 파일 앱에 둘 이상의 파일이 있는 경우가 있습니다. WPF 네이티브 종속성은 슈퍼 호스트의 일부가 아니므로 단일 파일 앱 옆에 추가 파일이 생깁니다. 의존하는 다른 기본 바이너리도 마찬가지입니다.

Single-file signing on macOS

단일 파일 앱은 이제 macOS에서 Apple 공증 및 서명 요구 사항을 충족합니다. 구체적인 변경 사항은 개별 파일 레이아웃 측면에서 단일 파일 앱을 구성하는 방식과 관련이 있습니다.

 

Apple은 macOS Catalina를 사용한 서명 및 공증에 대한 새로운 요구 사항을 시행하기 시작했습니다. 우리는 Apple과 긴밀히 협력하여 요구 사항을 이해하고 .NET과 같은 개발 플랫폼이 해당 환경에서 잘 작동 할 수 있도록하는 솔루션을 찾고 있습니다. 지난 몇 차례의 .NET 릴리스 각각에서 Apple 요구 사항을 충족하는 데 필요한 제품을 변경하고 사용자 워크 플로를 문서화했습니다. 나머지 차이 중 하나는 단일 파일 서명으로, macOS 스토어를 포함하여 macOS에 .NET 앱을 배포하는 데 필요합니다.

Crossgen2

Crossgen2는 crossgen 도구를 대체합니다. 이는 두 가지 결과를 만족시키기 위한 것입니다. 즉, crossgen 개발을 보다 효율적으로 만들고 현재 crossgen에서는 불가능한 기능 집합을 활성화하는 것입니다. 이 전환은 관리 코드 Roslyn 기반 컴파일러에 대한 네이티브 코드 csc.exe와 다소 유사합니다 (Roslyn 프로젝트를 기억하는 경우). Crossgen2는 C#으로 작성되었지만 Roslyn처럼 멋진 API를 제공하지는 않습니다.

 

우리가 가지고있는 PGO 계획은 바로 실행할 수있는 코드 생성에 영향을 미치는 다른 계획과 마찬가지로 crossgen2를 조건으로 합니다. crossgen2에 의존하는 .NET 6용으로 계획 한 프로젝트가 6개 정도있을 것입니다. 나중에 미리보기에서 설명하겠습니다. 말하자면, crossgen2는 매우 중요한 프로젝트입니다.

 

Crossgen2는 운영 체제 및 아키텍처 차원에서 교차 컴파일 (따라서 "crossgen"이라고 함)을 지원합니다. 즉, 최소한 바로 실행 가능한 코드와 관련하여 모든 대상에 대한 네이티브 코드를 생성하기 위해 단일 빌드 머신을 사용할 수 있습니다. 그러나 해당 코드를 실행하고 테스트하는 것은 다른 이야기이며 이를 위해서는 적절한 하드웨어와 운영 체제가 필요합니다.

 

첫 번째 단계 (및 테스트)는 crossgen2로 플랫폼 자체를 컴파일하는 것입니다. System.Private.Corelib 어셈블리는 미리보기 1에서 crossgen2에 의해 컴파일됩니다. 후속 미리보기에서는 전체 .NET SDK가 모든 플랫폼 및 아키텍처에 대해 crossgen2로 컴파일 될 때까지 제품의 점진적으로 더 넓은 부분을 대상으로합니다. 이것이 출시에 대한 우리의 목표이며 기존 crossgen을 폐기하는 데 필요한 전제 조건입니다. crossgen2는 CoreCLR에만 적용되며 Mono 기반 애플리케이션 (기본 코드 도구의 분리 세트가 있음)에는 적용되지 않습니다.

 

이 프로젝트는 적어도 처음에는 성능을 지향하지 않습니다. 목표는 RyuJIT (또는 기타) 컴파일러를 호스팅하는 훨씬 더 나은 아키텍처를 사용하여 오프라인 방식 (런타임을 요구하거나 시작하지 않음)으로 코드를 생성하는 것입니다. 초기 테스트에서 정확히 예상되는 성능 차이를 관찰하지 못했습니다.

 

"C#으로 작성된 경우 crossgen2를 실행하기 위해 런타임을 시작할 필요가 없습니까?"라고 말할 수 있습니다. 예,하지만이 문맥에서 "오프라인"이 의미하는 것은 아닙니다. crossgen2가 실행될 때 crossgen2가 실행중인 런타임과 함께 제공되는 JIT를 사용하여 R2R (Ready-to-Run) 코드를 생성하지 않습니다. 적어도 우리가 가지고있는 목표로는 효과가 없습니다. crossgen2가 x64 시스템에서 실행 중이고 Arm64 용 코드를 생성해야 한다고 가정 해보십시오. Crossgen2는 x64 용으로 컴파일 된 Arm64 RyuJIT를 네이티브 플러그인으로 로드한 다음 이를 사용하여 Arm64 R2R 코드를 생성합니다. 기계 명령어는 파일에 저장되는 바이트 스트림 일뿐입니다. 반대 방향으로도 작동 할 수 있습니다. Arm64에서 crossgen2는 Arm64로 컴파일 된 x64 RyuJIT를 사용하여 x64 코드를 생성 할 수 있습니다. x64 시스템에서 x64 코드를 대상으로하는 동일한 접근 방식을 사용합니다. Crossgen2는 해당 구성을 위해 구축 된 RyuJIT를 로드합니다. 복잡해 보일 수 있지만 원활한 사용자 경험을 제공하려는 경우 필요한 유형의 시스템이며 이것이 바로 우리가 원하는 것입니다.

 

현재 SDK는 기본적으로 기존 crossgen을 사용합니다. 기본값은 향후 미리보기에서 crossgen2로 변경됩니다.

 

하나의 릴리스에만 'crossgen2'라는 용어를 사용하기를 바라며, 그 이후에는 기존 crossgen을 대체 한 다음 'crossgen2'에 대해 'crossgen'용어를 다시 사용하겠습니다. 드물게 필요한 경우 "the old crossgen"또는 "crossgen1"이라고 말하여 이전 버전을 나타냅니다.

Dynamic PGO

동적 PGO는 우리가 탐색하고 활성화하는 PGO 양식 중 하나입니다. 한편으로는 "훈련이 필요없는"PGO로 생각할 수 있습니다. 게시물의 앞부분에서 PGO의 도전적인 프로세스에 대해 설명했습니다. 동적 PGO의 장점은 어떤 것도 필요하지 않다는 것입니다. 단점은 프로세스가 최적의 성능을 얻는데 더 오래 걸린다는 것입니다. 반면에 동적 PGO는 오늘날 계층화된 컴파일에서 사용되는 훨씬 더 간단하고 덜 효과적인 정책을 대체하는 것으로 생각할 수 있습니다.

 

가장 매력적인 경우에는 동적 및 정적 PGO가 함께 구성됩니다. 런타임시 JIT는 정적으로 컴파일 된 PGO 최적화 코드의 작은 하위 집합을 정제하여 가장 높은 가치의 이점을 제공 할 수 있습니다. 예를 들어 JIT는 주어진 인터페이스를 구현하는 프로세스 (지금까지로드 됨)에 클래스가 하나만 있음을 알 수 있습니다. 그런 다음 JIT는 인터페이스를 통한 간접 호출 대신 클래스를 통해 직접 호출을 생성 할 수 있습니다. 이 고전적인 컴파일러 기술을 devirtualizion이라고하며 메서드 호출 (작은 승리)에서 간접적인 요소를 제거하고 인라인 (큰 승리)을 활성화하여 성능을 향상시킵니다.

 

동적 PGO를 활성화하는 과정에서 다음과 같이 변경되었습니다.

• 보호 된 비 가상화 — 클래스 프로필 및 클래스 유형에 대한 프로브를 통해 보호된 비 가상화를 활성화합니다.
• 플로우 그래프 시각화 — 프로필 데이터가 있는 플로우 그래프의 그래픽 덤프.
• 중복 분기 제거 — 분기 결과가 완전히 결정되는 분기를 최적화합니다.
• PGO 시나리오에 CSE 활성화 — PGO 도입 유형 테스트의 CSE를 활성화합니다.

Arm64 performance

.NET 5의 Arm64 성능에 추가하기 위해 .NET 6의 Arm64 성능 개선의 또 다른 라운드를 계획하고 있습니다.

 

Preview 1에는 다음 변경 사항이 포함되어 있습니다.

스택 프레임 제로화 — SIMD 레지스터를 사용하여 초기화 프레임을 제로화

이 이미지는 일반적인 작업인 스택 프레임의 내용을 0으로 만드는 개선 사항을 보여줍니다. 녹색 선은 새로운 동작이고 주황색 선은 다른 (덜 유익한) 실험으로, 둘 다 파란색 선으로 표시되는 기준선에 비해 향상됩니다. 이 테스트에서는 낮을수록 좋습니다.

Hardware-accelerating structs

구조체는 CLR 유형 시스템의 중요한 부분입니다. 최근 몇 년 동안 C# 수준에서 성능 도구로 자주 사용되었습니다. 예로는 ValueTask, ValueTuple 및 Span<T>가 있습니다. 슬프게도 구조체는 JIT에서 마땅히 받아야 할 성능에 대한 사랑을 받지 못했습니다. .NET 5 및 .NET 6에서는 부분적으로는 메서드의 인수로 CPU 레지스터에서로드 및 액세스 할 수 있도록하여 구조체의 성능을 개선했습니다.

 

Preview 1에는 다음 변경 사항이 포함되어 있습니다.

• HFA에 대한 구조 승격 — x64 및 Arm64에서 HFA 및 비 HFA multireg 인수에 대한 구조 승격
• HFA 등록 — 일치하는 필드에 HFA 및 기타 구조체를 등록합니다.

Stabilize performance measurements

블로그에 나타나지 않는 엄청난 양의 엔지니어링 시스템 작업이 팀에 있습니다. 사용하는 모든 하드웨어 또는 소프트웨어 제품에 해당됩니다. JIT 팀은 최근 내부 성능 실험실 자동화에 의해 자동보고되는 회귀 값을 높이는 목표로 성능 측정을 안정화하는 프로젝트를 수행했습니다. 이 프로젝트는 안정성을 위해 필요한 심층 조사와 제품 변경으로 인해 흥미 롭습니다. 또한 성능을 유지하고 개선하기 위해 측정해야 하는 규모를 보여줍니다.

이 이미지는 불안정한 성능 측정을 보여줍니다. 스케일은 100 분의 1 나노초입니다. 차트가 끝날 무렵 (이러한 변경 사항이 커밋 된 후) 측정이 안정화되었음을 알 수 있습니다. 이 이미지는 단일 테스트를 보여줍니다. dotnet/runtime # 43227에서 유사한 동작을 보이는 것으로 입증 된 더 많은 테스트가 있습니다.

Closing

.NET 6은 주목할만한 개선 사항이 많이있는 또 다른 흥미로운 릴리스가 될 것입니다. 이 릴리스는 외부 중심 운영 체제 진화에 적응해야하고 .NET 플랫폼 자체 내에서 계속해서 혁신해야 하기 때문에 특히 흥미로운 릴리스입니다. 또한 개방형 계획뿐 아니라 이전에 독점적인 성능 도구를 공유하는 측면에서도 .NET 팀의 개방성이 향상되었습니다. 아직 달성하지는 못했지만 .NET 6은 새로운 연간 주기로 11 월 두 번째 릴리스가 될 것입니다. 매우 까다로운 환경에서 2020 년 11 월에 .NET 5를 성공적으로 출시했음을 감안할 때 .NET 6도 제 시간에 출시 될 것으로 예상하는 모든 이유가 있습니다.

 

지난 릴리스에서는 릴리스의 실제 이름에 대해 블로그 게시물, 문서 및 기타 웹 사이트에 약간의 모호성이 있었습니다. 이제 연간 주기로 전환했으며 그 사이에 부 릴리스를 릴리스 할 가능성이 별로 보이지 않으므로 릴리스의 ".0"브랜딩 사용을 중지했습니다. .NET 5 블로그 게시물에서는 "5.0"브랜딩을 전체적으로 사용했습니다. 앞으로는 .NET 6을 ".NET 6.0"이 아닌 ".NET 6"이라고 부르려고합니다. 나는 당신이 똑같이 할 것을 권장합니다. 큰 문제는 아니지만 우리의 의도를 명확히하고 싶었습니다.

 

이번 릴리스에서 큰 변화는 Android와 iOS를 기존 Xamarin 워크로드의 일부로 완전히 통합하는 것입니다. 이를 위해서는 코드, 빌드 시스템 및 기타 기술을 통합하기위한 분명한 요구 사항이 필요합니다. 또한 블로그, 문서 및 샘플을 통합해야합니다. 우리는 수년 동안 Xamarin 팀과 함께 일해 왔지만 모든 Xamarin 친구가 .NET 6 프로젝트에 참여한 것을 환영합니다. 또한 Xamarin 사용자가 .NET 6의 일부가 된 것을 환영합니다. 이러한 릴리스는 상당히 쾌적합니다. 한 달에 한 번 시계처럼 새로운 미리보기를 기대할 수 있습니다. 이 여정을 함께 진행하면서 각 월간 게시물에 점점 더 많은 모바일 관련 콘텐츠를 포함하도록 노력하겠습니다. 재미있을 것입니다. 게시물 시작 부분에서 말씀 드린 것처럼 .NET 통합은 이번 릴리스의 핵심입니다.