티스토리 뷰
오늘, 우리는 .NET 6의 첫 번째 미리보기를 제공하고 새 릴리스에서 기대할 수있는 사항을 공유하게되어 기쁩니다. 우리는 새로운 경험과 기능을 포함하여 지난 몇 달 동안 릴리스의 전체적인 형태를 정의했습니다. .NET 6의 핵심은 .NET 5부터 시작된 .NET 통합 계획의 마지막 부분을 제공하는 것입니다. 이 릴리스에는 클라우드, 데스크톱 및 모바일 앱을 포함하여 .NET의 모든 부분에 대한 주요 개선 사항도 포함됩니다. .NET 6 빌드에서 완전히 사용할 수 있으려면 릴리스의 더 큰 범위에 대해 여러 미리보기가 필요합니다.
내용이 너무 길어서 2번에 나누어서 작성합니다.
Announcing .NET 6 Preview 1 (2/2) (tistory.com)
Windows, macOS 및 Linux 용 .NET 6 Preview 1을 다운로드 할 수 있습니다.
- Installers and binaries
- Container images
- Linux packages
- Release notes
- Known issues
- GitHub issue tracker
웹 및 데이터 액세스 시나리오의 새로운 기능에 대한 자세한 내용은 ASP.NET Core 및 EF Core 게시물을 참조하세요.
.NET 6은 Visual Studio 16.9 Preview 4 및 Mac 용 Visual Studio 8.9에서 테스트되었습니다. .NET 6을 사용해보고 싶다면 이러한 빌드를 사용하는 것이 좋습니다.
나머지 두 섹션은 두 섹션으로 나뉩니다. 일반적으로 .NET 6 용으로 제공되는 항목 (11 월에 제공 될 항목)과 특히 미리보기의 새로운 기능에 대해 살펴 봅니다.
Unified and extended
.NET 6을 사용하면 빌드하려는 앱, 대상으로 지정하려는 플랫폼 및 개발에 사용하려는 운영 체제에서 빌드 할 수 있습니다. .NET으로 수행 할 수있는 작업과 나머지 .NET 통합 비전을 제공하여 수행 할 수있는 영역을 확장하고 있습니다. Xamarin의 일부인 Android, iOS 및 macOS 기능을 .NET 6에 통합하고 있습니다. 또한 Blazor로 수행 할 수있는 작업을 웹과 기본 UI를 함께 결합하는 새로운 종류의 하이브리드 클라이언트 앱으로 확장하고 있습니다. 데스크톱 및 모바일 시나리오에 사용할 수 있습니다. 이러한 새로운 기능은 이 게시물의 뒷부분과 후속 미리보기에서 설명합니다.
우리 모든 .NET 개발자에게 무언가를 제공하기 위해 노력하고 있습니다. 데스크톱 앱 개발자라면 새로운 사용자에게 다가 갈 수있는 새로운 기회가 열립니다. 모바일 앱 개발자인 경우 iOS 및 Android 플랫폼을 타겟팅하는 동안 기본 .NET 도구 및 API를 사용하여 이점을 얻을 수 있습니다. 웹 또는 클라우드 개발자인 경우 서비스를 .NET 모바일 앱에 노출하고 코드를 공유하는 것이 더 쉽습니다.
우리는 .NET 5부터 통합 프로세스를 시작했습니다. 이 릴리스에서는 Blazor WebAssembly를 최초의 통합 플랫폼 결과물로 선택했습니다. Mono 런타임을 기반으로 .NET 클래스 라이브러리 및 .NET SDK 도구를 사용합니다. Xamarin을 통합 할 때 iOS 및 Android에 동일한 모델을 사용합니다. 통합 플랫폼을 통해 모든 개발자가 새로운 API와 성능 향상을 당일에 이용할 수 있으며, 모든 앱에서 사용할 수 있게됩니다.
.NET SDK를 설치하면 모바일 플랫폼용 앱 빌드를 시작할 수 있습니다. 즉, dotnet new android를 입력 한 다음 dotnet이 실행되고 Android 에뮬레이터에서 .NET 앱 실행을 시작할 수 있습니다. iOS 앱도 마찬가지입니다. Visual Studio 및 Visual Studio Code에서도 비슷한 경험을 할 수 있습니다. 지원되는 모바일 워크로드로 인해 .NET SDK가 훨씬 더 커질 것이라고 걱정하지 마십시오. 모바일 워크로드는 선택 사항입니다. 실제로 .NET SDK는 기존 워크로드도 선택 사항이되면서 더 작아 질 것입니다. 새로운 선택적 SDK 워크로드 환경은 .NET 6의 일부가 될 것이며 .NET 7에서 완료 될 것입니다.
통합을 통해 Xamarin Forms 앱 빌드 경험을 단순화하고 확장 할 수있는 기회를 잡고 있습니다. 이 프로젝트를 .NET 다중 플랫폼 앱 UI(MAUI)라고합니다. 이 프로젝트는 데스크톱 및 모바일 개발자 모두의 플랫폼 범위를 확장하는 많은 개선 사항과 기능을 제공 할 것입니다.
Open planning
우리는 .NET 6에서보다 개방적인 계획 프로세스를 채택했습니다. 우리는 우선 순위와 범주가있는 테마, 에픽, 사용자 스토리의 계층적 모델을 사용하여 .NET 릴리스를 계획합니다. 이 모델을 사용하면 더 넓은 범위에서 릴리스를 볼 수 있고 어떤 기능이 가장 중요한지에 대한 통찰력을 제공하며 참여 및 기여 기회를 쉽게 찾을 수 있습니다.
.NET 6에 대한 GitHub theme와 epic 문제가 9 월에 나타나기 시작했음을 알 수 있습니다. 이전에 제품 출시를 여러 번 계획했지만 GitHub 문제로 그렇게 한 적이 없습니다. .NET 5의 경우 Azure DevOps를 사용했습니다. 계획을 전체적으로 볼 수있는 가장 좋은 방법은 Blazor 기반 themesof.net 앱을 사용하는 것입니다.
우리는 아직 프로세스와 모델을 파악하고 있었으며 아직 할 이야기가 없었기 때문에, 이 프로세스를 시작할 때 큰 발표를하지 않았습니다. 그러나, 우리가 하고 있는 일에 대해 몇몇 사람들을 선제적으로 지목했습니다. 우리는 Red Hat에 있는 친구들과 처음 이야기를 나눴습니다. 그들은 이미 우리의 활동을 지켜보고 있었고 우리가 무엇을 하고 있는지 알고 있었습니다. 그들은 우리가 프로젝트 개방성의 다음 단계를 밟고 있다는 사실에 기뻐했습니다. 다음으로 우리는 새로운 개방형 계획 접근 방식을 .NET Foundation 보드와 공유했습니다. 또한 개방형 계획을 통해 Microsoft의 다른 팀이 .NET 팀이 다음으로 향하는 방향을 쉽게 알 수 있습니다.
GitHub에 나와 있는 계획은 이제 우리 엔지니어링 프로세스의 기본 부분입니다. 이러한 문제를 최신 상태로 유지하고 문제를 관련 활동 및 문서에 연결하여 프로젝트의 깊이와 범위를 더 잘 이해할 수 있도록 최선을 다할 것입니다. 참여하시고, 질문하고, 의견을 제시해 주시기 바랍니다.
Support
.NET 6은 2021년 11월에 출시 될 예정이며 LTS(장기 지원) 릴리스로 3 년 동안 지원 될 예정입니다. 플랫폼 매트릭스는 .NET 5에 비해 크게 확장되었습니다.
- Android.
- iOS.
- Mac and Mac Catalyst, for x64 and Apple Silicon “M1”.
- Windows Arm64 (specifically Windows Desktop).
.NET Multi-platform App UI
.NET 다중 플랫폼 앱 UI는 .NET 6 통합의 일부로 Xamarin을 빌드하고 확장하는 최신 UI 도구 키트입니다. 여러 플랫폼과 장치에 걸쳐 아름답고 일관된 앱 환경을 제공하고 모바일 및 데스크톱 앱에서 더 많은 코드를 공유하고자 한다는 이야기를 많은 분들께 들었습니다. Android, iOS, macOS 및 Windows를 타겟팅 할 수 있습니다. .NET 6 다중 플랫폼 모바일 및 교차 플랫폼 지원은 지난 7년 동안 적용되어 많은 고객의 변화하는 요구를 충족시켜 온 Xamarin.Forms 도구 키트의 통합 및 확장을 기반으로 합니다. .NET 6의 주요 key focus는 앱 성능, 새로운 제어 테마 추가 및 더 빠른 개발자 환경입니다.
통합 프로세스의 일부로 Xamarin.Essentials 라이브러리를 .NET 다중 플랫폼 앱 UI에 병합하는 것이 합리적이라고 결정했습니다. 교차 플랫폼 UI 제어 외에도 장치 센서와 같은 장치 기능, 사진 및 연락처와 같은 공통 기능, 인증 및 보안 저장소와 같이 정기적으로 사용하는 많은 서비스를 쉽게 사용할 수 있습니다.
.NET 6 Preview 1에는 .NET 다중 플랫폼 앱 UI의 처음 두 플랫폼인 Android 및 iOS가 도입되었습니다. .NET 6 샘플 모바일 프로젝트 및 설치 지침은 Android 및 iOS 앱 빌드를 시작하는 데 도움이됩니다. 향후 미리보기에서는 macOS 및 Windows 데스크톱에 대한 지원을 추가하고, 더 빠른 개발 환경을 위해 기존 XAML 지원에 C# Hot Reload를 추가하고, 단일 위치에서 자산 및 플랫폼 별 요구 사항을 관리하기위한 새로운 프로젝트 기능을 도입합니다.
현재 Xamarin을 사용하는 개발자는 Xamarin 및 Xamarin.Forms 프로젝트에서 .NET 6 사용을 시작할 수 있습니다. .NET 6 사용으로 전환하는 데 도움이되는 변환 도구 및 마이그레이션 가이드를 제공합니다.
이 이미지는 macOS 터미널에서 dotnet으로 시작되는 Android 및 iOS 앱을 보여줍니다. 물리적 모바일 하드웨어에서도 동일하게 실행될 수 있습니다. 앱에는 dotnet-runtimeinfo에서 조정 된 코드가 포함되어 있으며 디버그 출력 창에 Debug.WriteLine 추적과 함께 결과가 표시됩니다. 이 앱은 .NET SDK로 실행되는 .NET 라이브러리를 사용하여 Mono 런타임에서 실행됩니다.
Blazor desktop apps
Blazor는 .NET 웹 앱을 작성하는 매우 인기있는 방법이 되었습니다. 먼저 서버에서 Blazor를 지원한 다음 WebAssembly가있는 브라우저에서 Blazor를 지원했으며, 이제는 Blazor 데스크톱 앱을 작성할 수 있도록 다시 확장하고 있습니다. Blazor 데스크톱을 사용하면 네이티브 클라이언트 애플리케이션에서 웹과 네이티브 UI를 함께 결합하는 하이브리드 클라이언트 앱을 만들 수 있습니다. 주로 사용자에게 풍부한 클라이언트 및 오프라인 경험을 제공하려는 웹 개발자를 대상으로합니다.
업데이트 : 내가받은 몇 가지 질문을 바탕으로 더 많은 컨텍스트를 제공 할 것입니다. Blazor는 애플리케이션 프로그래밍 모델입니다. 매우 적응력이 뛰어나며 필요에 따라 여러 가지 방법으로 실행할 수 있습니다. Blazor 데스크톱은 Electron이 작동하는 방식과 유사하게 구성됩니다. Blazor 웹 서버에서 콘텐츠를 렌더링하는 WebView 컨트롤이 있으며, Blazor와 다른 웹 콘텐츠(JavaScript, CSS 등)를 모두 지원할 수 있습니다. 적어도 기본 구성에서는 Blazor 데스크톱이 Blazor Web Assembly를 사용하지 않습니다. 간단히 말해서 데스크톱 앱에 WebAssembly를 사용해야하는 명백한 기술적 또는 사용자 경험의 이유가 없습니다. 일부 사람들은 Blazor WebAssembly가 너무 느리다고 지적했습니다. 한편으로는 사실입니다. 그러나 사람들은 우리가 Blazor WebAssembly 성능을 위해 노력하고 있다는 것을 알아야합니다.
Blazor 데스크톱은 애플리케이션을 구성하는 방법에 대한 많은 선택권을 제공합니다. 애플리케이션 스펙트럼의 한쪽 끝에서 가장 바깥쪽에있는 기본 애플리케이션 컨테이너 (예 : 제목 표시 줄)를 제외하고 클라이언트 애플리케이션 환경의 모든 측면에 Blazor 및 웹 기술을 사용할 수 있습니다. 스펙트럼의 다른 쪽 끝에서는 Blazor 기반 웹 사이트에 대해 이미 구현 한 사용자 프로필 페이지와 같은 다른 기본 앱 (예 : WPF) 내에서 대상 기능에 Blazor 데스크톱을 사용할 수 있습니다. 그 사이의 모든 선택이 똑같이 가능합니다. 처음에는 .NET 앱용으로 Blazor 데스크톱을 구축하고 있지만, Swift와 같은 다른 앱 스택으로 빌드된 데스크톱 앱에서도 사용이 가능할 것입니다.
Blazor 데스크톱은 .NET 다중 플랫폼 앱 UI를 기반으로 구축되었습니다. 네이티브 애플리케이션 컨테이너 및 네이티브 컨트롤에 대한 UI 스택에 의존합니다(이 스택을 사용하려는 경우). 다른 데스크톱 솔루션과 동등한 시작 및 처리 성능을 갖도록 Blazor를 구축하고 있습니다. Blazor를 좋아하고 웹 기술을 좋아하는 개발자에게는 Blazor가 데스크톱 앱 구축에 탁월한 선택이 될 것이라고 생각합니다.
위의 이미지는 macOS에서 실행되는 Blazor 데스크톱 앱을 보여줍니다. 이 예제에서는 Mac 애플리케이션 컨테이너에서 제공하는 외부 크롬을 제외하고 전체 앱이 Blazor로 빌드되었음을 확인할 수 있습니다.
위의 이미지는 Windows에서 실행되는 다른 Blazor 데스크톱 앱을 보여줍니다. 이 예제에서는 WPF 컨트롤이있는 WPF 앱과 WPF와 상호 작용할 수있는 Blazor island가 표시됩니다.(이 경우 WPF 메시지 상자)
Fast inner loop
빠른 반복 개발은 즐겁고 생산적인 개발 플랫폼의 특징입니다. 우리는 빠른 내부 루프라고 부르는 새로운 프로젝트를 시작했습니다. 프로젝트의 첫 번째 부분은 성능 관련 프로젝트 세트를 사용하여 빌드를 훨씬 빠르게 실행하는 것입니다. 똑같이 중요한 또 다른 부분은 빌드를 완전히 건너 뛰고 코드 편집을 다시 시작하지 않고도 라이브 프로세스에 적용 할 수있는 새로운 시스템을 만드는 것입니다.
우리는 지난 몇 년 동안 Xamarin 팀이 XAML Hot Reload 경험을 통해 혁신하는 것을 지켜보고 있으며, XAML뿐만 아니라 C#/IL을위한 일반적인 .NET 기능으로 hot reload를 활성화하는 것을 상상하기 시작했습니다. 모든 앱 유형에 제공 할 수있는 새로운 핫 코드 다시로드 모델을 정의하고 있습니다. 이 기능 중 적어도 일부는 런타임에 구현 될 가능성이 높으며 CoreCLR 및 Mono 모두에서 이를 수행하기 위해 최선을 다하고 있습니다. .NET의 새로운 표준 기능으로 빌드를 완전히 건너 뛸 수있는 코드 변경에 대해 매우 빠른 빌드와 더 빠른 작업을 지원하고자 합니다.
Arm64
Arm64는 계속해서 우리와 업계에 큰 초점을 맞추고 있습니다. .NET 5.0을 통해 Arm64 성능을 크게 개선했으며 Arm64 성능에 계속 투자 할 것입니다. 이 릴리스에서는 기능 활성화에 가장 중점을 둘 것입니다.
Windows에서는 Preview 1의 초기 지원과 함께 Windows Forms 및 WPF (Windows Presentation Framework)에 대한 지원을 추가하고 있습니다. 이는 .NET 5에서 제공한 Windows Arm64 기능에 추가 된 것입니다. 우리는 피드백을 바탕으로 각 프리뷰를 계속 개선해 나갈 것입니다. 앞에서 Windows Desktop 앱 기능을 초기 .NET 6 빌드에서 사용하도록 설정한 후 .NET 5에 백업할 계획이라고 말했습니다. 아직 계획이지만, 아직 정해진 날짜는 없습니다. 우리는 올 상반기를 목표로 하고 있습니다.
이 이미지는 dotnet-runtimeinfo에서 조정 된 코드를 사용하여 Windows Arm64 시스템에서 실행되는 WPF를 보여줍니다. 이는 .NET 5로 시연 한 Windows Forms 예제와 매우 유사합니다 (지금까지는 지원하지 않았습니다).
Mac에서는 Preview 1의 초기 지원과 함께 Apple Silicon (Arm64) 칩 (네이티브 및 에뮬레이션)에 대한 지원을 추가하고 있습니다. 콘솔 앱, ASP.NET Core, Mac 클라이언트 앱 (Mac 및 Mac Catalyst) 및 .NET SDK. .NET 5 및 이전 .NET Core 릴리스의 경우 x64 에뮬레이션을 사용합니다. Apple Silicon은 게시물 뒷부분에서 자세히 설명합니다.
이 이미지는 ASP.NET 샘플 중 하나를 사용하여 Apple Silicon에 대한 지원을 보여줍니다. 보시다시피 macOS에서 .NET 6.0 Arm64를 실행하고 있습니다 (Darwin은 macOS이고 xnu는 커널입니다).
Containers
컨테이너는 빌드 인프라의 기반이자 제품 시나리오로서 팀이 집중하는 부분입니다. .NET 성능 테스트는 컨테이너에서도 수행됩니다. .NET 6에서 컨테이너를 개선하기 위해 계획된 여러 프로젝트가 있습니다.
- 컨테이너의 확장을 개선하고 Windows process-isolated containers에 대한 지원을 개선합니다. 또한 밀도 및 집계 기계 성능에 초점을 맞춘 새로운 형태의 컨테이너 성능 테스트를 계획하고 있습니다.
- PGO를 사용하여 컨테이너 이미지 크기를 줄입니다 (나중에 자세히 설명합니다. "very cold" 분할 참조).
- Ready to run version bubbles을 사용하여 시작 및 처리량 성능을 향상시킵니다.
- 기본적으로 modern vector instructions를 사용하여 시작 및 처리량 성능을 높입니다.
- [고급 시나리오] Ready to run composite images로 대형 페이지 지원을 활성화합니다.
이러한 기능 중 첫 번째 기능을 제외한 모든 기능은 나중에 설명하는 crossgen2에 종속됩니다. 이러한 기능의 대부분은 컨테이너 전용이 아니지만 컨테이너에서 사용할 것으로 예상됩니다. 버전 버블과 같은 경우에 컨테이너는 기본적으로 기능이 활성화되는 유일한 배포 수단 일 수 있습니다. 컨테이너의 중요한 이점은 일반적인 .tar.gz, .deb 또는 .msi 결과물보다 더 독단적인 구성으로 .NET을 제공 할 수 있다는 것입니다. 모든 시나리오에서 사용할 수 없는 단점이 있는 고성능 구성으로 컨테이너를 제공하는 것이 좋습니다.(오래된 하드웨어의 경우)
새 릴리스를 시작할 때마다 Linux 배포판의 환경을 살펴보고 최상의 기본 이미지 버전을 선택하고 있는지 확인합니다. .NET 6 이미지는 Alpine 3.13 (이상), Debian 11 ( "bullseye") 및 Ubuntu 20.04를 기반으로합니다. Ubuntu 22.04가 출시 될 때까지 새로운 Ubuntu 버전 (컨테이너)을 채택하지 않습니다.
Debian Bullseye 선택은 더 많은 설명이 필요합니다. 현재 테스트 단계에 있으며 언제 배송 될지 알 수 없습니다. Debian과 .NET 릴리스 사이에는 조정되지 않은 경쟁이 있으며 .NET 6이 경쟁에서 패할 것이라고 확신합니다. 새로운 .NET 릴리스 용 이미지 릴리스를 시작하면 사용하는 기본 이미지를 변경하지 않습니다. 우리는 현재 여러 릴리스에 Debian 10 ( "buster")을 사용하고 있습니다. 3 년 동안 .NET 6을 지원한다는 점을 감안할 때 이제는 버스터와 작별 할 시간입니다.
Preview 1부터 6.0 태그를 당기면 bullseye 이미지를 사용하게됩니다. Bullseye는 아직 CI 환경에 통합되지 않았지만 수동 테스트에 따르면 이미 견고한 릴리스이며 버스터와 호환됩니다. 문제가 있으면 의견을 보내주세요.
rich@mazama:~$ docker run --rm mcr.microsoft.com/dotnet/sdk:6.0 cat /etc/debian_version
bullseye/sid
rich@mazama:~$ docker run --rm mcr.microsoft.com/dotnet/sdk:5.0 cat /etc/debian_version
10.8
rich@mazama:~$ docker run --rm mcr.microsoft.com/dotnet/sdk:3.1 cat /etc/debian_version
10.8
rich@mazama:~$ docker run --rm mcr.microsoft.com/dotnet/sdk:2.1 cat /etc/debian_version
9.13
이 일련의 명령은 이전 .NET 버전에 대해 선택한 것과는 대조적으로 더 명확하게 채택해야 합니다. Bullseye가 해제되면 첫 번째 명령의 출력은 11.0이됩니다.
Apple Silicon의 사례를 계속 살펴보겠습니다. .Net 5를 실행하려면 x64 에뮬레이션이 Apple Silicon 기계에서 실행되어야 한다는 것을 알고 기존 .NET 5 컨테이너 샘플을 꺼낼 때 어떤 일이 발생할까요? 한번 보시죠.
Arm64 이미지입니다. 그것은 당신을 놀라게 할 것입니다. .NET 5는 이미 Linux에서 Arm64를 지원하며, 이것이 이 이미지에서 보여주는 것입니다. 그래서 놀랍지 않습니다. Linux 컨테이너를 실행하는 경우 macOS가 아닌 Linux를 실행하는 것입니다. Apple Silicon에서 amd64 .NET 이미지를 실행 해 보았지만 아직 제대로 작동하지 않는 것 같습니다.
참고로 2021년 컨테이너 이미지에 대한 새로운 블로그 게시물 시리즈를 시작했습니다. 첫 번째는 Staying safe with .NET containers 입니다.
Theme: Improve startup and throughput using runtime execution information (PGO)
이러한 각 미리보기를 통해 하나 또는 두 개의 .NET 6 테마를 설명하겠습니다. 런타임 실행 정보 (PGO)를 사용하여 시작 및 처리량 향상부터 시작하겠습니다.
우리는 .NET 초기부터 PGO를 사용해 왔습니다. PGO의 목표는 바이너리의 네이티브 코드를 최적화하여 CPU 및 컴퓨터의 다른 측면에서보다 효율적으로 실행되도록하는 것입니다. 최적화 된 코드를 사용하면 앱을 더 빠르게 시작하고 실행할 수 있으며 메모리 사용량과 디스크 공간까지 줄일 수 있습니다. 이를 위해 사용할 수있는 많은 기술이 있습니다. Windows, macOS 및 Linux에서 사용하는 C++ 컴파일러가 제공하는 PGO (기본 런타임 용)를 활용합니다. 그것은 매우 관련이 있고 중요하지만이 주제의 내용은 아닙니다.
이 테마는 RyuJIT 컴파일러가 런타임시 또는 crossgen 도구를 통해 (즉시 실행 가능한 네이티브 코드 형식으로) 생성하는 네이티브 코드와 관련이 있습니다. Crossgen과 RyuJIT는 이미 PGO를 지원하지만 우리는 유용성과 성능 측면에서 이 기능을 크게 개선하고자합니다. RyuJIT는 C++ 컴파일러 위에 빌드되지 않았기 때문에 RyuJIT 또는 확장 crossgen에 대해 C++ 컴파일러 PGO 기능을 사용할 수 없습니다.
프로파일 기반 최적화 (PGO)에는 많은 것이 있습니다. 비유로 시작하겠습니다. 이미 집에 있기를 바라면서 큰 고속도로를 천천히 운전하고 있습니다. 당신은 이렇게 생각합니다. "이러한 교통 체증의 원인은 대부분 차량 증가가 원인이 아니라 자동차 한 대 앞에 있는 브레이크 조명의 관점에서만 국지적으로 최적화하고 있는 일련의 운전자들의 결과이고, 그게 전부야!" 트래픽이 프로필로 안내되고 최적화되는 세상에서 컴퓨터는 매일의 교통 패턴을 기록한 다음, 이전에 관찰된 교통 패턴을 기반으로 각 자동차별로 최적의 미터 단위 경로를 계산하여 각 자율주행차 컴퓨터에 대한 지침을 지속적으로 제공합니다. 교통은 효율성과 안전을 위해 전 세계적으로 최적화 될 것입니다. 그 때문에 매일 적어도 30 분 일찍 집에 도착할 것입니다. 정부는 고속도로 확장 프로젝트를 연기하고 대신 돈을 학교와 공원 자금으로 사용할 수 있습니다.
하나의 PGO 기술은 hot-cold splitting입니다. 바이너리에서 가장 자주 호출되는 코드는 함께 배치되고 자주 사용되지 않는 코드는 별도의 그룹에 배치됩니다. 이상적으로는 일련의 메서드 호출 (또는 기본 블록 액세스)에서 다음에 필요한 코드가 디스크에서로드 된 페이지의 동일한 물리적 시퀀스에 있기 때문에 CPU 캐시에 이미로드되어 있습니다. 이 경우 메서드 또는 기본 블록 호출은 매우 빠릅니다 (CPU가 허용하는 한 빠름). 또한, 예를 들어 예외를 발생시키는 else 절과 같이 사전 컴파일 된 네이티브 코드가 전혀없는 세 번째 분할 ("very cold"그룹화)도 있습니다. 매우 차가운 코드는 필요할 경우 JIT 처리되므로 성능 문제가되지 않을 수 있습니다. 매우 차가운 상태에 대한 후보를 많이 식별 할 수 있다면 훨씬 더 작은 바이너리를 생성 할 수 있습니다.
PGO (일반적인 경우 .NET뿐만 아니라)는 일반적으로 인기가 없습니다. 적어도 기존 모델에서는 잘 수행하기가 매우 어렵기 때문입니다. 툴은 투박하며, 프로세스는 세부 사항에 대한 엄청난 주의를 필요로 합니다. 도구가 앱에 대한 데이터를 수집하는 동안 다양한 시나리오를 통해 앱을 실행하는 "교육"연습을 정기적으로 수행해야합니다. 그런 다음 해당 데이터를 컴파일러 (이 경우 crossgen)에 공급합니다. 그런 다음 결과에 만족하는지 확인해야합니다. 그런 다음 훈련하는 시나리오 세트를 개선하고 개발 중에 앱이 변경되는 것을 고려하여 헹구고 반복해야합니다. 최적의 결과를 얻으려면 PGO로 규정 된 모든 단계를 체계적으로 따라야합니다. 그 것은 매우 피곤하고 힘든 과정입니다.
지금까지 .NET 용 PGO에 대한 설명입니다. .NET 6에서는 다음을 수행 할 계획입니다.
- 사용 편의성을 지향하는 PGO 교육 및 데이터 조작을 위한 새로운 도구 세트를 만듭니다.
- .NET 라이브러리에 대한 교육 데이터를 게시하여 다른 사용자 (예 : Red Hat)가 교육 데이터를 사용, 보강 및 공유 할 수 있도록 합니다.
- 프로덕션에서 실행되는 앱에 대한 교육 데이터 수집을 활성화합니다.
- 런타임에 정적 학습 데이터를 사용하려면 JIT를 활성화합니다.
- JIT를 활성화하여 런타임에 동적 학습 데이터를 생성하고 사용합니다 (학습이 필요없는 시나리오).
우리는 PGO가 시작 및 처리량에 대해 10% 정도의 성과를 거둘 수있을 것으로 기대합니다. 컴퓨팅 집약적인 워크로드의 경우 이점이 더 클 수 있습니다. 우리가 비전의 전체 범위를 제공하려면 두 번의 릴리스가 필요합니다. 우리는 여전히 PGO에 대한 정확한 .NET 6 결과물 세트를 정의하고 있습니다. 우리는 이 릴리스에서 매력적인 새로운 가치를 제공하는 동시에 적절한 장기 아키텍처 (앞으로 재 작업하거나 미래의 기회를 차단하는 것을 방지)를 구축하고자 합니다. 이번 릴리스에서 새로운 PGO 도구(자체)를 사용하도록 전환 할 수 있기를 바랍니다. .NET의 표준 기능으로 PGO를 활성화하는 것은 생태계의 중요한 진전이 될 것입니다.
게시물의 나머지 부분에서는 미리보기 1에 포함 된 기능에 대해 설명합니다.
References:
Announcing .NET 6 Preview 1 | .NET Blog (microsoft.com)
'.NET 5, 6, 7' 카테고리의 다른 글
Separation of concerns (관심사의 분리) (2) | 2021.04.06 |
---|---|
Announcing .NET 6 Preview 1 (2/2) (0) | 2021.03.19 |
Working with large .NET 5 solutions in Visual Studio 2019 16.8 (0) | 2021.02.17 |
The New .NET Multi-platform App UI (0) | 2021.02.05 |
MAUI in .NET 6: Xamarin.Forms Does Desktop, but Not Linux or VS Code (0) | 2021.01.26 |
- Total
- Today
- Yesterday
- visual studio 2019
- IOT
- LINQ
- ef core
- MVVM
- ComboBox
- Microsoft
- WPF
- uno-platform
- windows 11
- Behavior
- Visual Studio 2022
- XAML
- dotNETconf
- Build 2016
- Cross-platform
- uno platform
- #prism
- Bot Framework
- Always Encrypted
- .net 5.0
- #MVVM
- PRISM
- UWP
- kiosk
- #Windows Template Studio
- .net
- Windows 10
- #uwp
- C#
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |