Runtime: 계층형 JIT 도입

@GSPP 계층화는 계획 대화에서 끊임없는 주제입니다. 내 인상은 그것이 어떤 위안을 제공한다면 _if_가 아니라 _언제_의 문제라는 것입니다. 그것이 아직 존재하지 않는 _이유_에 관해서는, 역사적으로 인지된 잠재적 이득이 다중 codegen 모드의 증가된 복잡성과 위험을 관리하는 데 필요한 추가 개발 자원을 정당화하지 못했기 때문이라고 생각합니다. 전문가들이 이에 대해 이야기하도록 해야 하므로 추가하겠습니다.

/cc @dotnet/jit-contrib @russellhadley

어쨌든 이것이 crossgen/ngen, Ready to Run 및 corert의 세계에서 여전히 관련성이 있는지 의심스럽습니다.

이들 중 어느 것도 현재 대부분의 웹 앱에 중요한 높은 안정적인 상태 처리량을 제공하지 않습니다. 만약 그들이 그렇게 한다면 나는 개인적으로 시작 시간에 신경 쓰지 않기 때문에 그것에 만족합니다.

그러나 지금까지 .NET용 모든 코드 생성기는 두 목표 사이에서 불가능한 균형을 이루려고 시도했지만 둘 다 잘 수행되지 않았습니다. 최적화를 11로 설정할 수 있도록 균형 조정을 제거합시다.

그러나 지금까지 .NET용 모든 코드 생성기는 두 목표 사이에서 불가능한 균형을 이루려고 시도했지만 둘 다 잘 수행되지 않았습니다. 최적화를 11로 설정할 수 있도록 균형 조정을 제거합시다.

동의하지만 이 문제를 해결하는 데 통역사 같은 것은 필요하지 않습니다. 더 나은 RyuJIT 또는 LLILC가 될 수 있는 좋은 크로스젠 컴파일러일 뿐입니다.

가장 큰 장점은 런타임에 코드를 생성해야 하는 애플리케이션에 있다고 생각합니다. 여기에는 동적 언어와 서버 컨테이너가 포함됩니다.

동적으로 생성된 코드가 하나의 동기인 것은 사실이지만 정적 컴파일러가 런타임에 사용할 수 있는 모든 정보에 액세스할 수 없다는 것도 사실입니다. 뿐만 아니라(예: 프로필 정보를 기반으로) 추측하는 경우에도 정적 컴파일러가 모달 또는 외부 컨텍스트 종속 동작이 있는 경우 그렇게 하는 것이 훨씬 더 어렵습니다.

웹 앱은 ngen 스타일 처리가 필요하지 않아야 합니다. 배포 파이프라인에 잘 맞지 않습니다. 큰 바이너리를 생성하는 데 많은 시간이 걸립니다(거의 모든 코드가 동적으로 죽거나 차갑더라도).

또한 웹 앱을 디버깅하고 테스트할 때 실제 성능을 제공하기 위해 ngen에 의존할 수 없습니다.

또한, 나는 캐롤의 동적 정보 사용의 2번째 포인트입니다. 해석 계층은 코드(분기, 루프 트립 횟수, 동적 디스패치 대상)를 프로파일링할 수 있습니다. 완벽한 일치입니다! 먼저 프로필을 수집한 다음 최적화합니다.

계층화는 모든 시나리오의 모든 것을 영원히 해결합니다. 대략적으로 말하자면 :) 이것은 실제로 JIT의 약속에 도달할 수 있습니다.

현재의 RyuJIT 구현은 Tier 1에 충분합니다... 질문은 다음과 같습니다. 사실 이후에 실행할 수 있는 핫 경로에 대해 Tier 2 극한 최적화 JIT를 갖는 것이 의미가 있습니까? 본질적으로 무언가가 뜨겁다는 것을 알기에 충분한 런타임 정보가 감지되거나 있을 때 또는 처음부터 이를 대신 사용하도록 요청할 때.

RyuJIT는 티어 1에 충분히 적합합니다. 문제는 인터프리터가 (내 추정으로는) _훨씬_ 빠른 시작 시간을 가질 수 있다는 것입니다. 두 번째 문제는 Tier 2로 진행하기 위해 Tier 1 코드를 실행하는 로컬 상태가 새로운 Tier 2 코드(OSR)로 이전될 수 있어야 한다는 것입니다. RyuJIT 변경이 필요합니다. 인터프리터를 추가하는 것은 동시에 더 나은 시작 대기 시간을 제공하는 더 저렴한 경로가 될 것이라고 생각합니다.

더 저렴한 변형은 실행 중인 코드를 Tier 2 코드로 교체하지 않는 것입니다. 대신 Tier 1 코드가 자연스럽게 반환될 때까지 기다리세요. 코드가 장기 실행 핫 루프에 들어가면 문제가 될 수 있습니다. 그런 식으로 Tier 2 성능에 도달하지 않습니다.

나는 그것이 너무 나쁘지 않고 v1 전략으로 사용될 수 있다고 생각합니다. 메서드를 핫으로 표시하는 속성과 같은 완화 아이디어를 사용할 수 있습니다(이는 현재 JIT 전략에서도 어쨌든 존재해야 함).

@GSPP 그것은 사실이지만 이것이 다음 실행에서 그것을 알지 못한다는 것을 의미하지는 않습니다. Jitted 코드 및 계측이 지속되면 두 번째 실행은 여전히 ​​Tier 2 코드(일부 시작 시간을 희생하여)를 얻게 됩니다.

통역사를 작성하는 것은 JIT에 비해 저렴해 보입니다.

새로운 인터프리터를 작성하는 대신 최적화를 비활성화한 상태에서 RyuJIT를 실행하는 것이 합리적일 수 있습니까? 시작 시간을 충분히 개선할 수 있습니까?

고품질 코드 생성기를 만들어야 합니다. 이것은 VC가 될 수 있습니다.

Visual C++ 백엔드인 C2를 말씀하시는 건가요? 그것은 크로스 플랫폼이 아니며 오픈 소스가 아닙니다. 나는 두 가지 모두를 수정하는 것이 조만간 일어날 것이라고 의심합니다.

최적화를 비활성화하는 것이 좋습니다. 그러나 OSR 문제는 여전히 남아 있습니다. 런타임이 안전한 지점에서 런타임 시 IL 아키텍처 상태(로컬 및 스택)를 파생하도록 허용하는 코드를 생성하고 이를 계층 2 jitted 코드에 복사하고 기능 중간에 계층 2 실행을 재개할 수 있도록 하는 코드를 생성하는 것이 얼마나 어려운지 잘 모르겠습니다. JVM이 그것을 수행하지만 그것을 구현하는 데 얼마나 많은 시간이 걸렸는지 누가 압니까?

예, C2에 대해 이야기하고 있었습니다. Desktop JIT 중 적어도 하나는 C2 코드를 기반으로 한다는 것을 기억합니다. CoreCLR에서는 작동하지 않지만 데스크탑에서는 작동하지 않을 수 있습니다. 마이크로소프트가 코드 베이스를 정렬하는 데 관심이 있다고 확신합니다. LLVM은 훌륭한 선택인 것 같습니다. 현재 여러 언어가 LLVM이 GC 및 일반적으로 관리되는 런타임과 함께 작동하도록 하는 데 관심이 있다고 생각합니다.

LLVM은 훌륭한 선택인 것 같습니다. 현재 여러 언어가 LLVM이 GC 및 일반적으로 관리되는 런타임과 함께 작동하도록 하는 데 관심이 있다고 생각합니다.

이 주제에 대한 흥미로운 기사: Apple은 최근 JavaScript JIT의 최종 계층을 LLVM( https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ )에서 멀리 옮겼습니다. 느린 컴파일 시간과 LLVM의 소스 언어 지식 부족과 같은 문제와 유사한 문제가 발생할 수 있습니다.

RyuJIT보다 10배 느린 2계층에서는 완전히 허용됩니다.

나는 소스 언어에 대한 지식 부족(진정한 관심사)이 LLVM 아키텍처에 내재되어 있다고 생각하지 않습니다. 여러 팀이 LLVM을 소스 언어 지식을 더 쉽게 활용할 수 있는 상태로 옮기느라 바쁘다고 생각합니다. _All_ C가 아닌 고급 언어는 LLVM에서 컴파일할 때 이 문제가 있습니다.

WebKIT FTL/B3 프로젝트는 .NET보다 성공하기 어려운 위치에 있습니다. _전체적으로_ 수백 밀리초의 시간을 소비한 다음 종료되는 코드를 실행할 때 탁월해야 하기 때문입니다. 이것이 웹 페이지를 구동하는 JavaScript 워크로드의 특성입니다. .NET은 그 자리에 없습니다.

@GSPP 아마도 LLILC 에 대해 알고 있을 것입니다. 그렇지 않은 경우 살펴보십시오.

우리는 CLR 개념에 대한 LLVM 지원에 대해 한동안 작업해 왔으며 EH 및 GC 개선에 투자했습니다. 아직 둘 다 할 일이 꽤 많습니다. 그 외에도 GC가 있는 상태에서 최적화가 제대로 작동하는지 알 수 없는 작업량이 있습니다.

LLILC가 멈춘 것 같습니다. 그렇습니까?
2016년 4월 18일 오후 7시 32분에 "Andy Ayers" [email protected] 이 다음과 같이 썼습니다.

@GSPP https://github.com/GSPP 아마도 LLILC에 대해 알고 있을 것입니다
https://github.com/dotnet/lllc. 그렇지 않은 경우 살펴보십시오.

우리는 CLR 개념에 대한 LLVM 지원에 대해 한동안 작업해 왔으며
EH 및 GC 개선에 투자했습니다. 아직 할 일이 꽤 많다
둘 다. 그 외에는 알 수 없는 작업량이 있습니다.
GC가 있는 상태에서 제대로 작동합니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/dotnet/coreclr/issues/4331#issuecomment -211630483

@drbo - LLILC는 현재 백 버너에 있습니다. MS 팀은 RyuJIT에서 더 많은 대상을 가져오고 CoreCLR 드라이브를 출시할 때 발생하는 문제를 수정하는 데 집중하고 있으며 이는 거의 모든 시간이 소요됩니다. 우리가 (현재) LLILC를 얼마나 많이 사용했는지에 따라 교훈을 얻은 게시물을 작성하는 것이 내 TODO 목록(많은 자유 시간에)에 있지만 아직 도달하지 못했습니다.
계층화에서 이 주제는 수년 동안 많은 토론을 불러일으켰습니다. 몇 가지 새로운 워크로드와 이미지를 실행할 준비가 된 버전 관리가 새로 추가된 점을 감안할 때 계층화 방법과 위치를 새롭게 살펴볼 것입니다.

@russellhadley 글을 쓸 시간이 있으셨나요?

나는 승격되지 않은 스택 슬롯과 gcroots가 최적화를 깨고 지팅 시간이 느려진다는 가정하에... 프로젝트 코드를 살펴보는 것이 좋을 것입니다.

또한 SelectionDAG로 직접 이동하여 LLVM 백엔드의 일부를 수행하는 것이 가능하고 수익성이 있는지 궁금합니다. 최소한 일부 엿보기 및 복사 전파 ... 예를 들어 레지스터에 대한 gcroot 승격이 LLILC에서 지원되는 경우

현재 병목 현상을 포함하여 LLILC의 상태와 RyuJIT에 대해 어떻게 대처하고 있는지 궁금합니다. 본격적인 "산업용" 컴파일러인 LLVM은 OSS에서 사용할 수 있는 최적화가 매우 풍부해야 합니다. 메일링 리스트에서 비트코드 형식의 보다 효율적이고 빠른 직렬화/역직렬화에 대한 논의가 있었습니다. 이것이 LLILC에 유용한 것인지 궁금합니다.

이에 대한 생각이 더 이상 없었습니까? @russellhadley CoreCLR이 출시되었고 RyuJIT가 (최소한) x86으로 이식되었습니다. 로드맵의 다음 단계는 무엇입니까?

이에 대한 작업 시작은 dotnet/coreclr#10478을 참조하세요.

또한 dotnet/coreclr#12193

@noahfalk , 런타임에 관리 코드 자체에서 즉시 Tier 2 컴파일을 강제 실행하도록 지시할 수 있는 방법을 제공해 주시겠습니까? 계층형 컴파일은 대부분의 사용 사례에서 매우 좋은 아이디어이지만 시작 시간은 관련이 없지만 처리량 과 안정적인 대기 시간이 필수적인 프로젝트에서 작업하고 있습니다.

내 머리 꼭대기에서 이것은 다음 중 하나 일 수 있습니다.

• 구성 파일의 새 설정, JIT가 항상 계층 1을 건너뛰도록 하는 <gcServer enabled="true" /> 와 같은 스위치
• 또는 RuntimeHelpers.PrepareMethod 와 같이 핫 경로의 일부인 모든 메서드의 코드에 의해 호출됩니다(시작 시 코드를 사전 JIT하는 데 이것을 사용합니다). 이것은 핫 패스가 무엇인지 알아야 하는 개발자에게 더 큰 자유도를 제공하는 이점이 있습니다. 이 메서드의 추가 오버로드는 괜찮습니다.

물론, 이로부터 혜택을 받는 프로젝트는 거의 없지만 기본적으로 최적화를 건너뛰는 JIT 에 대해 걱정이 됩니다.

나는 당신이 디자인 문서에 다음과 같이 썼다는 것을 알고 있습니다.

관리 코드 API에서 액세스할 수 있는 새 빌드 파이프라인 단계를 추가하여 자체 수정 코드를 수행합니다.

매우 흥미롭게 들립니다 😁 하지만 여기에서 내가 묻는 내용이 여기에 포함되는지 확신할 수 없습니다.

또한 관련 질문: 두 번째 JIT 패스는 언제 시작됩니까? 메소드가 n 번째로 호출될 예정은 언제입니까? 메서드가 실행되어야 하는 스레드에서 JIT가 발생합니까? 그렇다면 메서드 호출 전에 지연이 발생합니다. 보다 적극적인 최적화를 구현하면 이 지연이 현재 JIT 시간보다 길어져 문제가 될 수 있습니다.

메서드가 충분히 호출되거나 루프가
충분한 반복을 실행합니다(단계별 교체). 그것은 일어나야 한다
백그라운드 스레드에서 비동기적으로

2017년 6월 29일 오후 7시 1분, "Lucas Trzesniewski" 알림 @github.com
썼다:

@noahfalk https://github.com/noahfalk , 방법을 알려주시겠습니까?
런타임에 계층 2 컴파일을 강제로 실행하도록 지시합니다.
관리 코드 자체? 계층화 된 컴파일은 대부분의 경우 매우 좋은 아이디어입니다.
사용 사례이지만 시작 시간이 관련이 없는 프로젝트에서 작업 중입니다.
그러나 처리량 과 안정적인 대기 시간이 필수적입니다.

내 머리 꼭대기에서 이것은 다음 중 하나 일 수 있습니다.

• 구성 파일의 새 설정, 다음과 같은 스위치 enable="true" /> JIT가 항상 계층 1을 건너뛰도록 하려면
• 또는 RuntimeHelpers.PrepareMethod와 같은 것입니다.
  핫 경로의 일부인 모든 메서드에서 코드에 의해 호출됩니다(우리는
  이것을 사용하여 시작 시 코드를 사전 JIT합니다). 이것은 장점이 있습니다
  무엇을 알아야 하는 개발자에게 더 많은 자유를 제공합니다.
  핫패스다. 이 메서드의 추가 오버로드는 괜찮습니다.

물론 이로부터 혜택을 볼 수 있는 프로젝트는 거의 없지만
JIT는 기본적으로 최적화를 건너뛰고 이에 대해 말할 수 없습니다.
대신 코드를 많이 최적화하는 것이 좋습니다.

나는 당신이 디자인 문서에 다음과 같이 썼다는 것을 알고 있습니다.

관리 코드 API에서 액세스할 수 있는 새 빌드 파이프라인 단계를 추가하여 수행
자체 수정 코드.

아주 흥미롭게 들리네요 😁 하지만 그것이 무엇을 다루고 있는지 확실하지 않습니다

여기에 묻습니다.

또한 관련 질문: 두 번째 JIT 패스는 언제 시작됩니까? 언제
메소드가 n 번째로 호출될 예정입니까? JIT가 발생합니까?
메서드가 실행되어야 하는 스레드? 그렇다면 소개할
메서드 호출 전 지연 더 공격적으로 구현하면
최적화 이 지연은 현재 JIT 시간보다 길어집니다.
문제가 될 수 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/dotnet/coreclr/issues/4331#issuecomment-312130920 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AGGWB2WbZ2qVBjRIQWS86MStTSa1ODfoks5sJCzOgaJpZM4IHWs8
.

@ltrzesniewski - 피드백 주셔서 감사합니다! 확실히 나는 계층화된 컴파일이 대다수의 프로젝트에 유용하기를 희망하지만 트레이드오프는 모든 프로젝트에 이상적이지 않을 수 있습니다. 나는 우리가 계층형 지팅을 비활성화하기 위해 환경 변수를 그대로 둘 것이라고 추측해 왔습니다. 이 경우 지금의 런타임 동작을 더 높은 품질(그러나 생성 속도는 느림) 지팅으로 유지합니다. 환경 변수를 설정하는 것이 앱에서 수행하기에 합당한 일입니까? 다른 옵션도 가능합니다. 저는 환경 변수가 우리가 사용할 수 있는 가장 간단한 구성 옵션 중 하나이기 때문에 관심을 갖습니다.

또한 관련 질문: 두 번째 JIT 패스는 언제 시작됩니까?

이것은 시간이 지남에 따라 발전할 가능성이 매우 높은 정책입니다. 현재 프로토타입 구현은 "메소드가 >= 30번 호출되었습니까?"라는 단순한 정책을 사용합니다.
https://github.com/dotnet/coreclr/blob/master/src/vm/tieredcompilation.cpp#L89
https://github.com/dotnet/coreclr/blob/master/src/vm/tieredcompilation.cpp#L122

편리하게도 이 매우 간단한 정책은 그것이 단지 추측일지라도 내 컴퓨터에서 훌륭한 성능 향상을 제안합니다. 더 나은 정책을 만들려면 실제 사용에 대한 피드백을 얻어야 하며 이러한 피드백을 얻으려면 핵심 메커니즘이 다양한 시나리오에서 합리적으로 강력해야 합니다. 그래서 내 계획은 먼저 견고성/호환성을 개선한 다음 조정 정책에 대해 더 많은 탐색을 수행하는 것입니다.

@DemiMarie - 현재 정책의 일부로 루프 반복을 추적하는 것은 없지만 미래에 대한 흥미로운 전망입니다.

프로파일링, 추측 최적화 및
최적화 해제? JVM은 이 모든 작업을 수행합니다.

2017년 6월 29일 오후 8시 58분에 "Noah Falk" [email protected] 이 작성했습니다.

@ltrzesniewski https://github.com/ltrzesniewski - 감사합니다
피드백! 확실히 나는 계층화된 컴파일이 광대한
대부분의 프로젝트에 적용되지만 절충안은 모든 프로젝트에 이상적이지 않을 수 있습니다.
나는 우리가 환경 변수를 그대로 둘 것이라고 추측했습니다.
계층형 지팅을 비활성화합니다. 이 경우 런타임 동작을 유지합니다.
이제 더 높은 품질(그러나 생성 속도는 더 느림)을 전면에 내세우고 있습니다. ~이다
앱이 할 수 있는 적절한 환경 변수를 설정하시겠습니까?
다른 옵션도 가능합니다 그냥 환경에 끌립니다
우리가 사용할 수 있는 가장 간단한 구성 옵션 중 하나이기 때문입니다.

또한 관련 질문: 두 번째 JIT 패스는 언제 시작됩니까?

이것은 시간이 지남에 따라 발전할 가능성이 매우 높은 정책입니다. 현재
프로토타입 구현은 다음과 같은 단순한 정책을 사용합니다.
>= 30번 호출"
https://github.com/dotnet/coreclr/blob/master/src/vm/
tieredcompilation.cpp#L89
https://github.com/dotnet/coreclr/blob/master/src/vm/
tieredcompilation.cpp#L122

편리하게도 이 매우 간단한 정책은
내 기계, 그것이 단지 추측일지라도. 더 나은 정책을 만들기 위해
우리는 실제 사용에 대한 피드백을 받아야 하고 그 피드백을 받아야 합니다.
핵심 역학은 다양한 분야에서 합리적으로 견고해야 합니다.
시나리오. 그래서 내 계획은 먼저 견고성/호환성을 개선한 다음
조정 정책에 대한 더 많은 탐색.

@DemiMarie https://github.com/demimarie - 우리는 아무것도 가지고 있지 않습니다
지금은 정책의 일부로 루프 반복을 추적하지만 흥미로운
미래에 대한 전망.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/dotnet/coreclr/issues/4331#issuecomment-312146470 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AGGWB5m2qCnOKJsaXFCFigI3J6Ql8PMQks5sJEgZgaJpZM4IHWs8
.

@noahfalk 환경 변수는 확실히 애플리케이션별로 이 애플리케이션을 제어할 수 있는 솔루션이 아닙니다. 서버/서비스 앱의 경우 일반적으로 애플리케이션이 시작하는 데 걸리는 시간에 신경 쓰지 않습니다(성능을 희생시키면서 그렇지 않다는 것을 알고 있습니다). 데이터베이스 엔진을 개발할 때 처음부터 가능한 한 빨리 작동하고 잠재적인 신규 고객이 수행한 예외적인 경로나 벤치마크에서도 데이터베이스 엔진이 필요하다는 것을 직접 말씀드릴 수 있습니다.

반면에 일반적인 환경에서 가동 시간은 한 번에 몇 주 단위로 측정할 수 있으므로 30초가 걸리더라도 상관하지 않습니다. 우리가 신경쓰는 것은 사용자가 일반 스위치(전부 또는 전무)를 실행하도록 강제하거나 심지어 사용자가 이에 대해 신경쓰도록 하는 것(예: 구성 파일에서 기본적으로 설정됨)은 10단계 후퇴한다는 것입니다.

오해하지 마세요. JIT 수준에서 최적화를 위한 코드 경로가 필요한 만큼 많은 시간이 소요되는 고성능의 길을 열 수 있기 때문에 Tiered JIT를 기대하고 있습니다. 나는 오래전에 JIT 엔지니어들과의 비공식적인 대화에서 나 자신을 제안하기도 했고, 당신은 이미 그것을 인지하고 있었습니다. 그러나 동작 애플리케이션 전체(시스템 전체가 아님)를 사용자 지정하는 방법은 (적어도 우리에게는) 이 특정 기능에 대한 중요한 품질 지표입니다.

편집: 일부 스타일 문제.

@redknightlois - 후속 조치에 감사드립니다

환경 변수는 응용 프로그램별로 이 응용 프로그램을 제어할 수 있는 솔루션이 아닙니다.

이 부분에서 약간 혼란스럽습니다... 환경 변수에는 시스템 단위가 아닌 프로세스 단위가 있습니다. 적어도 제가 알고 있는 플랫폼에서는 그렇습니다. 예를 들어 오늘 내가 실행하는 단 하나의 애플리케이션에서 테스트를 위해 계층화된 컴파일을 켜려면 다음을 수행합니다.

set COMPLUS_EXPERIMENTAL_TieredCompilation=1
MyApp.exe
set COMPLUS_EXPERIMENTAL_TieredCompilation=0

우리가 신경 쓰는 것은 사용자에게 ... 신경쓰도록 강요하지 않는다는 것입니다.

앱을 실행하는 사람이 아니라 앱 개발자가 지정할 수 있는 구성 설정을 원하십니까? env var의 한 가지 가능성은 사용자가 coreclr 앱을 시작하는 간단한 래퍼(배치 스크립트와 같은)를 시작하도록 만드는 것입니다. 나는 대안에 열려 있고 환경 변수에 설정되어 있지 않습니다. 기대치를 설정하기 위해 이것은 가까운 장래에 적극적인 디자인 노력을 기울일 영역이 아니지만 적절한 구성을 갖는 것이 중요하다는 데 동의합니다.

또한 주의하십시오. 계층화된 컴파일 경로를 적절한 방법으로 계속 진행한다고 가정하면 계층화된 컴파일을 활성화하는 것이 가장 빠른 시작일 뿐만 아니라 현재의 정상 상태 성능을 능가하는 지점에 도달했다고 쉽게 상상할 수 있습니다. 지금은 시작 성능이 목표지만 우리가 할 수 있는 일의 한계는 아닙니다. :)

프로파일링, 추측 최적화 및
최적화 해제?

@DemiMarie - 그들은 확실히 대화에 나왔고 많은 사람들이 계층화된 컴파일이 이러한 가능성을 열어준다는 사실에 흥분하고 있다고 생각합니다. 나 자신을 위해 말해서, 나는 내 목표를 더 높게 설정하기 전에 기초적인 계층화된 컴파일 기능을 제공하는 데 계속 집중하려고 노력하고 있습니다. 우리 커뮤니티의 다른 사람들은 이미 다른 응용 프로그램에서 저를 앞서고 있을 것입니다.

@noahfalk 예, 우아하지 않다는 것은 실행하는 일반적인 프로세스가 오류가 발생하기 쉬우며 (그리고 매우 그럴 가능성이 높음) 본질적으로 문제라는 것을 의미합니다. 작동하는 것으로 알고 있는 대안은 app.config 항목과 함께 서버 GC를 사용하려는 경우 구성할 수 있는 것과 동일한 방식으로 계층화된 컴파일에서도 동일한 작업을 수행할 수 있다는 것입니다(적어도 Tiered는 지속적으로 정상 상태 성능을 능가할 수 있습니다). JIT이기 때문에 assembly.config 를 사용하여 어셈블리별로 이를 수행할 수도 있으며 다른 노브도 그런 방식으로 선택할 수 있는 경우 현재 존재하지 않는 기능을 제공합니다.

환경 변수는 사용자 또는 시스템별로 설정되는 경우가 많으며 런타임의 여러 버전에서 이러한 모든 프로세스에 잠재적으로 부정적인 영향을 미칠 수 있습니다. 앱별 구성 파일은 훨씬 더 나은 솔루션인 것 같습니다(사용자별/시스템별도 사용 가능하더라도) -- app.config에서 설정할 수 있는 데스크탑 구성 값과 같지만 env vars 또는 레지스트리도 사용 .

나는 우리가 응용 프로그램 당 가장 일반적인 경로를 구현할 것이라고 생각합니다. 시스템 전체 설정도 유용할 수 있지만 기능이 구현되기 전에 그것에 대해 생각할 필요는 없다고 생각합니다.

몇 가지 아이디어가 있지만 최적화를 위해 두 번째 계층 지트가 수행해야 하는 작업에 대해 자세히 알아보지 못했습니다. 오늘날 jit가 하는 일을 할 수도 있지만 더 많은 일을 할 가능성이 큽니다.

그래서 몇 가지 잠재적인 합병증을 지적하겠습니다....

두 번째 계층 지트는 첫 번째 계층에 의해 생성된 코드의 동작에 대한 관찰을 기반으로 자체적으로 부트스트랩될 수 있습니다. 따라서 첫 번째 계층을 건너뛰고 두 번째 계층을 직접 요청하는 것은 계층화 과정을 그대로 두는 것처럼 전혀 작동하지 않거나 제대로 작동하지 않을 수 있습니다. "계층화 우회" 옵션이 구현되더라도 결국 2차 계층 jit가 생성할 수 있는 코드가 아니라 jit이 기본적으로 생성하는 코드와 같은 코드를 제공하게 될 것입니다.

두 번째 계층 jit는 많은 방법 집합에서 실행하면 상대적으로 느린 jit 시간이 발생하는 방식으로 조정될 수 있습니다. 두 번째 계층 지트가 더 철저한 최적화를 수행합니다. 우리는 아직 여기서 적절한 절충안을 알지 못합니다.

그말이...

"공격적 최적화" 메서드 속성이 의미가 있다고 생각합니다. jit이 특정 메서드에 대해 동작할 수 있는 두 번째 계층 jit처럼 다소 동작하도록 요청하고 prejitting 중에 이러한 메서드를 건너뛸 수 있습니다(prejitted 코드가 jitted 코드보다 느리게 실행되기 때문에 특히 R2R의 경우). 그러나 이 개념을 전체 어셈블리 또는 응용 프로그램의 모든 어셈블리에 적용하는 것은 그다지 매력적이지 않은 것 같습니다.

네이티브 컴파일러에서 일어나는 일을 적절한 비유로 생각하면 성능 대 컴파일 시간/코드 크기 트레이드오프가 더 높은 최적화 수준에서 상당히 나빠질 수 있습니다. 퍼즐의 핵심은 어떤 방법이 중요한지 아는 것이며 이를 수행하는 유일한 방법은 프로그래머가 알거나 시스템이 스스로 알아내는 것입니다.

@AndyAyersMS 나는 당신이 거기에 못을 박았다고 생각합니다. "적극적 최적화" 속성을 처리하는 JIT는 첫 번째 계층 지트가 해당 피드백을 제공할 시간이 없는 상태에서 격리에서 더 나은 코드를 생성할 수 있는 충분한 정보를 가질 수 없는 문제의 대부분을 해결할 수 있습니다.

@redknightlois 속성은 더 많은 계층화를 원하면 작동하지 않습니다. - T3 JIT, T4 JIT, ... 두 수준이 충분하지 않은지 확실하지 않지만 적어도 이 가능성을 고려해야 합니다.

MPGO 와 유사한 것을 사용하여 두 번째 계층 jitted 코드로 실행을 시작할 수 있다면 좋을 것입니다. 첫 번째 계층을 완전히 우회하는 대신 빨리 감기.

@AndyAyersMS , Azul이 LLVM을 사용하여 JVM용 관리 JIT를 구현했기 때문에 CLR에 LLVM을 더 쉽게 통합할 수 있습니까? 분명히 변경 사항은 프로세스에서 LLVM으로 업스트림으로 푸시되었습니다.

참고로 저는 몇 가지 특정 작업을 위해 몇 가지 작업 항목을 만들었습니다(#12609, dotnet/coreclr#12610, dotnet/coreclr#12611, dotnet/coreclr#12612, dotnet/coreclr #12617). 귀하의 관심이 그 중 하나와 직접적인 관련이 있는 경우 자유롭게 의견을 추가할 수 있습니다. 다른 주제에 대해서는 토론이 여기에서 계속될 것이라고 가정합니다. 또는 특정 하위 주제에 대한 관심이 충분하다면 독자적으로 특정 하위 주제에 대한 문제를 생성할 수 있습니다.

@MendelMonteiro 지팅 할 때 MPGO 스타일 피드백 데이터를 사용할 수 있도록 하는 것은 확실히 옵션입니다(현재는 사전 지팅할 때만 이 데이터를 다시 읽을 수 있음). 계측할 수 있는 항목에는 다양한 제한이 있으므로 모든 방법을 이 방식으로 처리할 수 있는 것은 아니며 살펴봐야 하는 다른 제한 사항(예: 인라인에 대해 피드백 데이터를 사용할 수 없음), 생성하는 데 필요한 계측 및 교육 실행이 있습니다. MPGO 데이터는 많은 사용자에게 장벽이며 MPGO 데이터는 첫 번째 계층에서 부트스트랩할 때 가진 것과 일치하거나 일치하지 않을 수 있지만 아이디어는 확실히 장점이 있습니다.

LLVM 기반 상위 계층이 진행되는 한 -- 분명히 우리는 LLILC로 이 문제를 어느 정도 조사했으며 당시 Azul 사람들과 자주 접촉했기 때문에 그들이 하고 있던 많은 일에 익숙합니다. LLVM을 사용하면 정확한 GC로 언어를 컴파일하기가 더 쉬워집니다.

CLR에 필요한 LLVM 지원과 GC 및 EH 모두에서 Java에 필요한 지원 및 최적화 프로그램에 적용해야 하는 제한에 상당한 차이가 있었습니다(그리고 여전히 있을 수 있음). 한 가지 예를 들자면 CLR GC는 현재 개체 끝을 가리키는 관리 포인터를 허용하지 않습니다. Java는 기본/파생 쌍을 이루는 보고 메커니즘을 통해 이를 처리합니다. 우리는 이러한 종류의 쌍을 이루는 보고에 대한 지원을 CLR로 연결하거나 LLVM의 옵티마이저 패스를 제한하여 이러한 종류의 포인터를 생성하지 않도록 해야 합니다. 게다가 LLILC jit은 느리고 궁극적으로 어떤 종류의 코드 품질을 생성할지 확신할 수 없었습니다.

따라서 LLILC가 아직 존재하지 않는 잠재적인 다중 계층 접근 방식에 어떻게 적합할 수 있는지 파악하는 것은 시기상조처럼 보였습니다. 지금 아이디어는 프레임워크에 계층화하고 두 번째 계층 지트에 RyuJit을 사용하는 것입니다. 더 많이 배우면 실제로 더 높은 계층의 지트를 위한 여지가 있음을 발견하거나 적어도 그러한 일이 이해되기 전에 해야 할 다른 작업을 더 잘 이해할 수 있습니다.

@AndyAyersMS LLVM의 제한 사항을 해결하는 것보다 필요한 변경 사항을 도입할 수도 있습니다.

Multicore JIT 및 해당 프로필 최적화가 coreclr과 함께 작동합니까?

@benaadams - 네, 멀티코어 JIT가 작동합니다. 어떤 시나리오(있는 경우)가 기본적으로 활성화되어 있는지 기억나지 않지만 구성을 통해 설정할 수 있습니다. https://github.com/dotnet/coreclr/blob/master/src/inc/clrconfigvalues.h# L548

나는 반쪽짜리 컴파일러를 작성했고 대부분의 경우 하드 히팅 최적화가 동일한 인프라에서 상당히 괜찮게 수행될 수 있으며 상위 계층 최적화 프로그램에서 수행할 수 있는 작업은 거의 없다는 것을 알았습니다.

내 말은: 함수가 여러 번 적중되면 매개변수는 다음과 같습니다.

• 인라인 명령어 수 증가
• 보다 "고급" 레지스터 할당자 사용(LLVM과 유사한 역추적 착색기 또는 전체 착색기)
• 더 많은 최적화 단계를 수행하십시오. 일부는 현지 지식에 특화되어 있을 수 있습니다. 예: 개체가 메서드에서 선언되고 더 큰 인라인 함수의 본문에 할당되지 않은 경우 전체 개체 할당을 스택 할당으로 바꾸는 것을 허용합니다.
• CHA가 불가능한 대부분의 적중 개체에 PIC를 사용합니다. 예를 들어 StringBuilder도 재정의되지 않을 가능성이 매우 높으며, 코드가 StringBuilder로 적중될 때마다 로 표시되면 내부에서 호출된 모든 메서드를 안전하게 가상화할 수 있고 유형 보호 장치가 SB의 액세스 앞에 설정될 수 있습니다.

그것은 또한 매우 좋을 것이지만 아마도 이것은 CompilerServices가 코드나 메타데이터를 통해 액세스할 수 있도록 노출되는 "고급 컴파일러"를 제공하여 게임이나 거래 플랫폼과 같은 장소에서 "더 깊이 컴파일"할 클래스와 메서드를 미리 컴파일합니다. 이것은 NGen은 아니지만 계층화되지 않은 컴파일러가 반드시 가능하지 않은 경우(바람직한 경우) 최소한 이 추가 성능이 필요한 중요한 부분에 더 무거운 최적화된 코드를 사용할 수 있어야 합니다. 물론 플랫폼이 무거운 최적화를 제공하지 않는다면(Mono라고 가정해 봅시다) API 호출은 기본적으로 NO-OP가 될 것입니다.

@noahfalk , @kouvel 등의 노력 덕분에 이제 계층화를 위한 견고한 기반이 마련되었습니다.

이 문제를 닫고 "계층형 지팅을 개선하는 방법" 문제를 여는 것이 좋습니다. 이 주제에 관심이 있는 사람이라면 누구나 현재 계층이 현재 어떤 상황인지 아이디어를 얻을 수 있도록 하는 것이 좋습니다. 우리는 좋든 나쁘든 실제 행동에 대한 피드백을 받고 싶습니다.

현재 동작이 어딘가에 설명되어 있습니까? 나는 이것을 발견했지만 구체적으로 계층화하기보다는 구현 세부 사항에 관한 것입니다.

나는 우리가 수집한 일부 데이터를 가지고 곧 어떤 종류의 요약 글을 사용할 수 있을 것이라고 믿습니다.

COMPlus_TieredCompilation=1 를 설정하여 2.1에서 계층화를 활성화할 수 있습니다. 시도하시면 발견한 내용을 다시 알려주세요....

최근 PR(https://github.com/dotnet/coreclr/pull/17840, https://github.com/dotnet/sdk/pull/2201)을 사용하면 계층화된 컴파일을 런타임 구성으로 지정할 수도 있습니다. json 속성 또는 msbuild 프로젝트 속성입니다. 이 기능을 사용하려면 최근 빌드가 필요하지만 환경 변수는 한동안 사용되었습니다.

@jkotas 에서 이전에 논의한 것처럼 계층형 JIT는 시작 시간을 개선할 수 있습니다. 네이티브 이미지를 사용할 때 작동합니까?
Tizen 휴대전화에서 여러 앱을 측정한 결과 다음과 같습니다.

시스템 DLL|앱 DLL|계층화|시간, s
-----------|--------|------|--------
R2R |R2R |아니요 |2.68
R2R |R2R |예 |2.61 (-3%)
R2R |아니요 |아니요 |4.40
R2R |아니요 |예 |3.63 (-17%)

FNV 모드도 확인해 보겠습니다만, 이미지가 없을 때는 잘 되는 것 같습니다.

cc @gbalykov @nkaretnikov2

참고로 계층화된 컴파일은 이제 .NET Core의 기본값입니다. https://github.com/dotnet/coreclr/pull/19525

@alpencolt , R2R과 같은 AOT 컴파일을 사용할 때 시작 시간 개선이 덜할 수 있습니다. 시작 시간 개선은 현재 더 적은 수의 최적화로 더 빠르게 지팅하는 데서 비롯되며, AOT 컴파일을 사용할 때 JIT에 덜 필요할 것입니다. 일부 제네릭, IL 스텁 및 기타 동적 메서드와 같은 일부 메서드는 미리 생성되지 않습니다. 일부 제네릭은 AOT 컴파일을 사용하는 경우에도 시작하는 동안 계층화의 이점을 얻을 수 있습니다.

@kouvel 의 커밋을 통해 제목의 요청을 달성했다고 생각하기 때문에 이 문제를 마무리하겠습니다. D 사람들은 요청된 개선 사항, 질문 또는 특정 조사. 누군가가 그것이 조기에 닫혔다고 생각한다면 물론 저희에게 알려주십시오.

@kouvel 마감된 문제에 대해 논평을 해서 죄송합니다. crossgen과 같은 AOT 컴파일을 사용할 때 애플리케이션이 여전히 핫스팟 코드 경로에 대한 두 번째 계층 컴파일의 이점을 얻을 수 있는지 궁금합니다.

@daxian-dbw 네, 그렇습니다. 런타임에 Jit는 크로스 어셈블리 인라인(dll 간)을 수행할 수 있습니다. 런타임 상수에 기반한 분기 제거( readonly static ); 등

@benaadams 그리고 잘 설계된 AOT 컴파일러는 할 수 없었습니까?

https://blogs.msdn.microsoft.com/dotnet/2018/08/02/tiered-compilation-preview-in-net-core-2-1/ 에서 이에 대한 정보를 찾았습니다.

미리 컴파일된 이미지에는 일부 유형의 최적화를 금지하는 버전 지정 제약 조건 및 CPU 명령 제약 조건이 있습니다. 자주 Tiered Compilation이라고 하는 이러한 이미지의 메서드에 대해 JIT는 미리 컴파일된 버전을 대체할 최적화된 코드를 백그라운드 스레드에서 생성하도록 요청합니다.

예, "잘 설계된 AOT가 아님"의 예입니다. 😛

미리 컴파일된 이미지에는 일부 유형의 최적화를 금지하는 버전 지정 제약 조건 및 CPU 명령 제약 조건이 있습니다.

예 중 하나는 하드웨어 내장을 사용하는 방법입니다. AOT 컴파일러(crossgen)는 x86/x64의 codegen 대상으로 SSE2를 가정하므로 하드웨어 내장을 사용하는 모든 메서드는 기본 하드웨어 정보를 알고 있는 JIT에 의해 크로스젠에 의해 거부되고 컴파일됩니다.

그리고 잘 설계된 AOT 컴파일러는 할 수 없습니까?

AOT 컴파일러는 링크 시간 최적화(교차 어셈블리 인라이닝의 경우) 및 프로필 기반 최적화(런타임 상수의 경우)가 필요합니다. 한편 AOT 컴파일러는 SIMD 코드를 빌드할 때 "최종선" 하드웨어 정보(gcc/clang의 -mavx2 와 같은)가 필요합니다.

예 중 하나는 하드웨어 내장을 사용하는 방법입니다. AOT 컴파일러(crossgen)는 x86/x64의 codegen 대상으로 SSE2를 가정하므로 하드웨어 내장을 사용하는 모든 메서드는 기본 하드웨어 정보를 알고 있는 JIT에 의해 크로스젠에 의해 거부되고 컴파일됩니다.

무엇을 기다립니다? 나는 여기를 잘 따르지 않는다. AOT 컴파일러가 내장 함수를 거부하는 이유는 무엇입니까?

그리고 잘 설계된 AOT 컴파일러는 할 수 없습니까?

AOT 컴파일러는 링크 시간 최적화(교차 어셈블리 인라이닝의 경우) 및 프로필 기반 최적화(런타임 상수의 경우)가 필요합니다. 한편, AOT 컴파일러는 SIMD 코드를 빌드할 때 "최종선" 하드웨어 정보(예: gcc/clang의 -mavx2)가 필요합니다.

네, 제가 말했듯이 "잘 설계된 AOT 컴파일러"입니다. 😁

@masonwheeler 다른 시나리오; crossgen은 Jit과 함께 작동하는 AoT이며 전체 애플리케이션 재컴파일 및 재배포 없이 dll의 서비스/패칭을 허용합니다. Tier1보다 더 빠른 시작과 함께 Tier0보다 더 나은 코드 생성을 제공합니다. 그러나 플랫폼 중립적이지는 않습니다.

Tier0, crossgen 및 Tier1은 모두 coreclr 에서 응집력 있는 모델로 함께 작동합니다.

교차 어셈블리 인라인(Jit이 아님)을 위해서는 정적으로 연결된 단일 파일 실행 파일의 컴파일이 필요하며 사용된 라이브러리를 패치하고 특정 플랫폼(어떤 버전의 사용할 SSE, Avx 등, 가장 낮은 공통 또는 모두를 위한 생산 버전?).

corert 은 이 스타일의 응용 프로그램을 AoT합니다.

하지만; Jit이 수행할 수 있는 특정 유형의 분기 제거를 수행하면 대체 경로에 대해 많은 양의 추가 asm 생성이 필요합니다. 올바른 트리의 런타임 패치

예를 들어 다음과 같은 방법을 사용하는 모든 코드(Tier1 Jit은 모든 if s를 제거함)

readonly static _numProcs = Environment.ProcessorCount;

public void DoThing()
{
    if (_numProcs == 1) 
    {
       // Single proc path
    }
    else if (_numProcs == 2) 
    {
       // Two proc path
    }
    else
    {
       // Multi proc path
    }
}

@benaadams

교차 어셈블리 인라인(Jit이 아님)을 위해서는 정적으로 연결된 단일 파일 실행 파일의 컴파일이 필요하며 사용된 라이브러리를 패치하고 특정 플랫폼(어떤 버전의 사용할 SSE, Avx 등, 가장 낮은 공통 또는 모두를 위한 생산 버전?).

애플리케이션의 전체 재배포가 필요하지 않아야 합니다. Android의 ART 컴파일 시스템을 살펴보세요. 애플리케이션을 관리 코드(Java의 경우 Java, 동일한 원칙이 적용됨)로 배포하고 로컬 시스템에 있는 컴파일러인 AOT는 관리 코드를 최적화된 기본 실행 파일로 컴파일합니다.

약간의 라이브러리를 변경하면 모든 관리 코드가 여전히 존재하며 모든 것을 다시 배포할 필요가 없습니다. 패치만 있으면 AOT를 다시 실행하여 새 실행 파일을 생성할 수 있습니다. (분명히 이것은 Android의 APK 앱 배포 모델로 인해 Android 비유가 깨지는 부분이지만 데스크톱/서버 개발에는 적용되지 않습니다.)

로컬 시스템에 있는 컴파일러는 AOT가 관리 코드를 컴파일합니다...

이것은 전체 프레임워크가 사용한 이전 NGen 모델입니다. 프레임워크 코드를 애플리케이션 코드에 인라인하는 단일 어셈블리를 생성했다고 생각하지 않습니까? .NET Core 2.1에서 실행되는 Bing.com에서 두 접근 방식의 차이점이 강조되었습니다! 블로그 포스트

ReadyToRun 이미지

관리되는 응용 프로그램은 먼저 메서드를 기계 코드로 JIT 컴파일해야 하므로 시작 성능이 좋지 않을 수 있습니다. .NET Framework에는 NGEN이라는 사전 컴파일 기술이 있습니다. 그러나 NGEN을 사용하려면 코드가 실행될 시스템에서 사전 컴파일 단계가 수행되어야 합니다. Bing의 경우 이는 수천 대의 컴퓨터에서 NGENing을 의미합니다. 이는 공격적인 배포 주기와 결합되어 응용 프로그램이 웹 서비스 시스템에서 사전 컴파일될 때 상당한 서비스 용량 감소를 초래합니다. 또한 NGEN을 실행하려면 관리 권한이 필요하며, 이는 종종 데이터 센터 설정에서 사용할 수 없거나 철저히 조사됩니다. .NET Core에서 crossgen 도구를 사용하면 빌드 랩에서와 같이 사전 배포 단계로 코드를 미리 컴파일할 수 있으며 프로덕션에 배포된 이미지는 바로 실행할 수 있습니다!

@masonwheeler AOT는 .Net 프로세스의 동적 특성으로 인해 전체 .Net에서 역풍에 직면해 있습니다. 예를 들어 .Net의 메서드 본문은 언제든지 프로파일러를 통해 수정할 수 있고, 클래스를 로드하거나 리플렉션을 통해 만들 수 있으며, interop과 같은 작업에 필요한 대로 런타임에서 새 코드를 만들 수 있으므로 절차 간 분석 정보는 기껏해야 반영됩니다. 실행 중인 프로세스가 일시적인 상태입니다. .Net의 모든 절차 간 분석 또는 최적화(인라이닝 포함)는 런타임에 실행 취소할 수 있어야 합니다.

AOT는 AOT 시간과 런타임 사이에 변경될 수 있는 항목의 집합이 작고 이러한 변경의 영향이 지역화되어 AOT 최적화에 사용할 수 있는 확장 범위가 항상 참이어야 하는 항목을 크게 반영할 때 가장 잘 작동합니다. 대안의 수).

.Net 프로세스의 동적 특성에 대처하거나 제한하기 위한 메커니즘을 구축할 수 있다면 순수한 AOT는 꽤 잘 할 수 있습니다. 예를 들어 .Net Native는 반사 및 상호 운용성의 영향을 고려하고 어셈블리 로딩, 반사 방출 및 ( 나는 추정) 프로필 첨부. 하지만 간단하지 않습니다.

모든 핵심 프레임워크(또는 모든 asp.net 어셈블리)를 번들로 AOT 컴파일할 수 있도록 crossgen의 범위를 여러 어셈블리로 확장하는 작업이 진행 중입니다. 그러나 상황이 변경될 때 코드 생성을 다시 실행하기 위한 폴백으로 jit가 있기 때문에 실행 가능합니다.

@AndyAyersMS 나는 .NET AOT 솔루션이 "순수한 AOT 전용" 솔루션이어야 한다고 결코 믿지 않았습니다. 바로 여기에서 설명하는 이유 때문입니다. JIT를 사용하여 필요에 따라 새 코드를 생성하는 것은 매우 중요합니다. 그러나 소수의 상황에서 매우 많이 필요한 상황이므로 유형 시스템에 대한 Anders Hejlsberg의 규칙이 여기에 유용하게 적용될 수 있다고 생각합니다.

가능하면 정적, 필요한 경우 동적.

System.Linq.Expressions에서
공개 TDelegate 컴파일(bool 우선 해석);

PreferInterpretation이 true인 경우 계층화된 컴파일이 계속 작동합니까?