Runtime: 설문조사: 네이티브 AOT

이 문제에 추가할 최적의 지역 레이블을 찾지 못했습니다. 쓰기 권한이 있는 경우 정확히 하나의 영역 레이블 을 추가하여 배울 수 있도록 도와주세요.

오타처럼 보입니다. - * 9. Which of these tasks are apart of your production debugging workflow? (Please select all that apply) "~의 일부"라고 해야 할까요?

이 문제를 보게 되어 정말 기쁩니다! 😄🚀

질문: .NET 네이티브 도구 체인으로 작업한 UWP 개발자의 경우 이전에 CoreRT를 사용하지 않았다고 말하거나 .NET 네이티브가 CoreRT와 많은 유사점(일부 공유 코드도 포함)을 가지고 있기 때문에 설문조사에 응답해야 합니다. 우리는 노트에서 이것을 언급한 다음 .NET Native에 대한 경험과 관련하여 다른 CoreRT 질문에 답합니다. 🤔

@ Sergio0694 UWP 질문에 감사드립니다. 동의합니다. 참고로 언급하고 오픈 소스 버전을 사용한 경우 사용 corert에 회신하는 것이 합리적이라고 생각합니다.

이 설문 조사를 게시해 주셔서 감사합니다!

.NET 네이티브만 사용해 온 UWP 개발자로서 특정 질문에 어떻게 대답해야 할지 혼란스럽기도 했습니다. UWP의 .NET 네이티브 도구 모음에 대해 여러 가지 의견이 있지만 실제로 적어 둘 곳이 없습니다. 그것이 이 설문조사의 범위를 벗어나는 것이면 괜찮지만 명확히 할 가치가 있습니다.

나는 또한 ".NET Native가 UWP 릴리스 빌드의 기본값이고 Store에서 필요하기 때문에"가 아마도 사람들이 AOT를 사용하는 가장 일반적인 이유일 것이라고 생각하지만 질문 5에 대해 미리 채워진 답변 중 하나는 아닙니다.

GUI 옵션에 Avalonia를 포함시켜 주셔서 감사합니다 :) 우리는 이전에 CoreRT+Avalonia를 실험했고 그 결과는 멋진 네이티브 GUI 앱이었습니다.

.net에서 종종 잊혀지는 부분은 게임 개발입니다. 많은 플랫폼에서 JIT 실행을 허용하지 않고 콘솔이나 IOS 장치를 생각할 수 있습니다.
.net 생태계의 일등 시민으로서 .net 네이티브 AOT를 얻는 것은 게임 개발의 미래를 위해 매우 중요합니다.
일부 게임 엔진은 자체 AOT를 실행했지만(예를 들어 Unity는 il2cpp로 수행), 이는 절대적인 난파선입니다.
따라서 공식 솔루션은 환영할 만한 것 이상입니다. 업계를 바꾸는 이벤트가 될 수 있습니다.
게임 산업이 수익과 매출 모두에서 영화 산업을 추월하고 있음을 잊지 마십시오.
콘솔은 주요 수익이 발생하는 곳입니다.

게시된 애플리케이션을 최적화하기 위한 기존 옵션은 오늘날 .NET이 대상으로 하는 대부분의 시나리오에서 잘 작동합니다.

...

AOT는 주로 GUI 앱에서 중요합니다. 집중이 필요한 부분입니다. 나는 그것을 필요로하는 webapp, 서비스 등이 보이지 않습니다.

나는 동의하지 않는다. 최고의 최종 사용자 UX를 위해서는 게임 엔진 , 서버리스 마이크로서비스 , 데스크탑 GUI 애플리케이션 , iOS 및 Android 애플리케이션, WASM 기반 클라이언트 측 SPA/라이브러리 및 기본 CLI 도구 (~몇 MB)에 정적 링크가 포함된 AOT가 필요합니다.

지난 몇 년 동안 C#에서 위의 모든 시나리오를 시도하면서 내 코드를 쉽게 AOT 컴파일할 수 있기를 바랐고 Rust와 같은 LLVM 기반 언어에 비해 .NET이 많이 부족하다고 느낍니다.

현재 게시 옵션이 "잘 작동"하는 것처럼 보이는 이유는 .NET이 역사적으로 위의 시나리오에 적합하지 않았고 사람들이 C#을 사용할 때 자체 AOT(예: Unity, UWP, Mono)를 구현하기 때문입니다. 기본 이미지(예: ReadyToRun)는 모놀리식 서버 응용 프로그램 또는 대규모 데스크톱 클라이언트 응용 프로그램의 콜드 스타트 ​​시나리오에서 "도움"이 될 수 있지만 바이너리 크기는 여전히 전체 AOT 런타임이 생성하는 것보다 몇 배 더 큽니다.

.NET은 이미 서버리스/컨테이너화된 마이크로서비스에 대해 "잘 작동"하지 않습니다. 이러한 마이크로서비스는 AOT 컴파일, 감소된 바이너리 크기 및 최소한의 종속성으로 상당한 이점을 얻을 수 있습니다 .
현재 ReadyToRun + Tiered Compilation + IL Linker 솔루션은 블로그 게시물에서 AWS Lambda가 권장하는 것과 같이 자체 포함된 배포에 성가신 파일 크기 제한에 이미 도달했습니다.

진짜 문제는 IL2CPP/Burst(Unity), Mono의 AOT 백엔드(Xamarin/Blazor/Uno), .NET Native/CoreRT(UWP), Mono의 LLVM 백엔드, CrossGen/ReadyToRun(.NET Core) 등이며 .NET에 표준화된 AOT 컴파일 도구 모음이 없다는 것은 단순히 받아들일 수 없습니다.

이 모든 팀이 CoreRT, Mono LLVM 백엔드 또는 현재 버려진 dotnet/lilic 과 같은 일반적인 것에 대한 엔지니어링 노력을 결합했다면 AOT는 .NET 개발자에게 훨씬 더 나은 경험이 되었을 것입니다.

AOT w/ static linking은 이제 대중을 위한 CI/CD를 통해 많은 개발자가 액세스할 수 있으며 더 이상 성능이 미미한 증가에 대한 성가심이 아닙니다.

C# endgame: 기본 코드, 기본 UI, 빠르고 쉬운 상호 운용성, 기본 내보내기 및 성능 지향 API(예: System.IO.Pipelines, System.Text.Json).

나는 webapps가 이것으로부터 이익을 얻지 못할 것이라는 진술에 동의하지 않습니다. AOT는 서버리스 워크로드(Azure Functions라고도 함)에 큰 도움이 됩니다. CLI 도구에 대한 시작 시간의 이점은 말할 것도 없습니다.

설문 조사에 답변했지만 솔직히 말해서 .NET Core 1.0이 시작된 이후로 진행 상황에 대한 명확한 방향 없이는 이러한 지속적인 설문 조사를 받지 못했습니다.

.NET 네이티브는 Ext-VOS 프로젝트가 시작되었을 때 .NET이 있어야 하는 것이었고, Singularity와 Midori의 경험이 있어 여러분이 확실히 공감하거나 내부 서버를 확보할 수도 있습니다.

Java조차도 팀에서 누락된 AOT 기능을 따라잡기 위해 어떤 워크로드가 작동하기를 원하는지 묻지 않기로 결정했습니다.

.NET 릴리스 이후 코드 품질 생성이 개선되지 않았고 배포 워크플로가 다른 AOT 컴파일 언어에 비해 고통스럽기 때문에 NGEN을 거의 사용하지 않습니다.

따라서 앞으로 AOT가 .NET에서 다시 삭제되면 관리되는 언어의 모든 경쟁이 이제 AOT 도구 체인에 초점을 맞추고 있으며 컴파일러를 사용하려는 워크플로도 묻지 않습니다.

저는 .NET이 계속해서 번창하고 시나리오에 관계없이 첫 번째 옵션이 되는 것을 보고 싶습니다. 그리고 Microsoft가 여전히 다른 AOT 컴파일 언어에는 문제가 없는 C++를 .NET과 함께 사용하도록 강요하는 워크플로를 인수하는 것을 보고 싶습니다.

설문 조사에 답변했지만 솔직히 말해서 .NET Core 1.0이 시작된 이후로 진행 상황에 대한 명확한 방향 없이는 이러한 지속적인 설문 조사를 받지 못했습니다.

MS가 우리가 원하는 것을 지시하기 보다는 커뮤니티의 소리에 귀를 기울이려고 하는 것은 대단한 일이라고 생각합니다.

@jkotas 이 설문조사에 대한 두 개의 다른 링크가 퍼진 것을 확인했습니다. 괜찮습니까?
https://www.surveymonkey.com/r/7THQK5K
https://www.surveymonkey.com/r/SQV8JQK

@texasbruce 는 크로스 플랫폼 GUI, WCF 및 EF 도구 지원에 관한 유사한 설문 조사에 응답한 동료 개발자에게 이것이 얼마나 도움이 되었는지 묻습니다.

그래서 그들이 우리에게 묻는 것도 좋지만 실제로 행동이 일어날 때 더 좋을 것입니다. 크로스 플랫폼 GUI의 경우에도 MAUI가 실제로 발생하는지 아니면 Web Widgets의 Blazor가 솔루션으로 밀려날지는 두고 봐야 합니다.

나에게 허용되는 유일한 AOT 솔루션은 릴리스 모드에서 JIT가 전혀 없는 진정한 네이티브 애플리케이션을 생성하고(병렬 솔루션 별칭이 실행 준비가 되지 않음) 모든¹ .NET 프로젝트에서 작동할 때 개발자가 작업하는 것입니다. 켜짐. 여기에는 특히 Winforms 및 WPF가 포함됩니다. 가장 좋은 경우에는 3MB에서 80MB로 확장되지 않고 런타임 종속성 없이 독립 실행형으로도 작동해야 합니다.

¹ 기술적인 이유로 AOT가 지원하지 않는 사례/apis가 있을 수 있습니다. "모두에"라는 것은 모든 API를 지원하는 것이 아니라 모든 프로젝트 종류를 지원한다는 의미입니다. .NET Core는 다음을 지원합니다. dll / winforms / wpf / winui / console / maui / ... 개발자가 기존 응용 프로그램을 인수하는 것이 제가 염두에 두고 있는 것입니다.

_또한 Delphi로 응용 프로그램을 작성했는데 단일 Delphi 실행 파일을 컴파일한 다음 다른 곳으로 내보내면 그냥 실행되는 것을 보고 버그가 발생했습니다. 그리고 더 빠릅니다. 특정 방식으로 컴파일할 때 C++ 응용 프로그램에도 동일하게 적용됩니다. 그리고 여전히 두 애플리케이션을 모두 디버그할 수 있으며 PDB를 포함하기로 결정할 때 두 애플리케이션 모두 여전히 유용한 스택 추적/덤프를 제공합니다. 그러나 보안상의 이유로 포함하지 않도록 결정할 수도 있습니다. 그러면 잘 작동합니다. 왜 우리는 C#으로 그것을 가질 수 없는지 스스로에게 묻는 것이 곤혹스럽습니다. AOT 계획을 들었을 때 나는 이것을 예상했습니다._

저는 항상 리플렉션 문제가 많이 언급되는 것을 보고 ASP.net 코어가 큰 실행 파일을 생성하는 경우 실제로 그렇게 많이 중요하지 않다고 생각합니다.

AOT가 어려운 요구 사항인 대부분의 장소는 CLI 도구, 게임 및 UI 응용 프로그램과 같은 것입니다. 포함할 라이브러리에 대해 까다로울 수 있으며 일부 반사 문제를 피할 수 있습니다. 우선 순위는 "클린 슬레이트" 애플리케이션을 활성화하는 것입니다.

저는 항상 리플렉션 문제가 많이 언급되는 것을 보고 ASP.net 코어가 큰 실행 파일을 생성하는 경우 실제로 그렇게 많이 중요하지 않다고 생각합니다.

Blazor WebAssembly가 출시되면서 실행 파일 크기와 실행 속도가 매우 중요해질 것이며 AOT의 이점을 크게 누릴 수 있을 것이라고 생각합니다. 그러나 어떤 이유로 든 설문 조사에서 구체적으로 언급되지 않았습니다.

예, 이쁘게 주세요! 메모리 안전을 유지하고 기본 속도를 얻고 내 코드를 기본 호출 가능하게 하기 위해 Rust 또는 CoreRT를 사용하는 것을 고려하고 있었습니다. 그러나 .NET에서 AOT를 사용하는 것은 매우 풍부하고 강력하며 Rust가 환상적이지만 전환하기 쉽지 않기 때문에 환상적일 것입니다.

@jkotas 이 설문조사에 대한 두 개의 다른 링크가 퍼진 것을 확인했습니다. 괜찮습니까?

예, 다른 게시물에 대해 다른 SurveyMonkey 링크를 사용합니다. 모든 링크는 동일한 설문조사를 가리킵니다. 이를 통해 사람들이 설문조사를 찾은 위치에 따라 응답 분포가 어떻게 달라지는지 확인할 수 있습니다.

gamedev를 위해 우리는 이것을 필요로 합니다. 저는 C++를 사용하는 네이티브 엔진에 찬성하여 내 게임 엔진 https://github.com/amerkoleci/alimer_sharp 작업을 일시 중단했습니다. DirectX 및 vulkan에 대한 바인딩도 유지합니다. 여기에 성능이 필요합니다.

gamedev를 위해 우리는 이것을 필요로 합니다. 저는 C++를 사용하는 네이티브 엔진에 찬성하여 내 게임 엔진 https://github.com/amerkoleci/alimer_sharp 작업을 일시 중단했습니다. DirectX 및 vulkan에 대한 바인딩도 유지합니다. 여기에 성능이 필요합니다.

일시 중단하지 않았다는 점을 제외하면 여기 😄와 동일한 시나리오입니다. 나는 더 나은 시작 시간을 위해 AOT를 좋아하지만(내 경우에는 더 중요하게도) 더 최적화된 코드를 가질 수 있는 기회를 좋아합니다. t 정말 JIT의 태도

10% 속도 향상을 위해 빌드 시간이 50% 증가해도 괜찮습니다. 이는 분명히 JIT의 태도가 아닙니다.

이것은 실제로 다른 생태계로 전환하는 대신 .NET에서 AOT를 원하는 큰 부차적인 이유 중 하나입니다. 대규모 C++ 또는 Rust 프로젝트와 비교하여 대규모 .NET 프로젝트의 빠른 컴파일 시간에 완전히 망쳤습니다.

개발 중 빠른 반복을 위해 JIT를 원하지만 일단 고객에게 무언가를 배송하면 AOT가 필요합니다.

CoreRT를 사용하여 크로스 플랫폼(및 크로스 플랫폼) 네이티브 라이브러리를 생성했습니다.

AOT w/ static linking은 jit를 비활성화하고 여러 aot 컴파일 모드를 원하는 iOS 및 콘솔 플랫폼의 게임 엔진에 긴급히 필요합니다.

1. 완전한
2. jit + aot 또는 인터프리터 + aot 실행 모드를 지원하는 하이브리드 aot
   하이브리드 ot는 게임 산업에 정말 중요하며 게임 체인저가 될 수 있습니다.

AOT w/ static linking은 jit를 비활성화하고 여러 aot 컴파일 모드를 원하는 iOS 및 콘솔 플랫폼의 게임 엔진에 긴급히 필요합니다.

1. 완전한
2. jit + aot 또는 인터프리터 + aot 실행 모드를 지원하는 하이브리드 aot
   하이브리드 ot는 게임 산업에 정말 중요하며 게임 체인저가 될 수 있습니다.

iOS 플랫폼의 모노, ot+인터프리터 실행 모드와 같습니다.

Full Aot, 단일 exe, 독립 런타임 및 불필요한 코드 클리핑으로 인해 확실히 kreygasm XD

나는 10년 동안 이 질문을 기다려왔다. 젠장, 나는 하드 드라이브에 먼지를 모으는 5개의 멋진 프로젝트를 가지고 있습니다. 왜냐하면 내가 그것들을 공개하면 어떤 어린이라도 그것을 되돌릴 수 있고 GUI에 약간의 변경을 추가하고 자신의 것으로 판매할 수 있기 때문입니다.

저는 PC 플랫폼에서 Unity를 사용하여 Robocraft, Cardlife 및 Gamecraft를 개발했으며 게임 서버에서도 필요하지 않은 한(Xbox one 읽기) 필요하지 않는 한 IL2CPP를 사용할 필요가 없었습니다. 나는 개인적으로 성능이 필요할 때 JIT 컴파일과 버스트(명시적 내장 함수를 사용하여 할 수 있는 것보다 더 나은 작업을 수행함)와 같은 솔루션이 혼합되어 있다고 생각합니다. 그러나 AOT는 완전한 네이티브 코드가 필요한 플랫폼과 하드웨어 리소스가 소중한 플랫폼에 필요하다는 것을 이해합니다. .net 플랫폼 개발자가 AOT에 대해 어떻게 엇갈릴 수 있는지 이해하지만 게임 개발에서 더 광범위하게 채택되기를 원한다면 선택 사항이 아니라고 생각합니다. 솔직히 말해서 Unity가 IL2CPP 및 Burst와 같은 기술을 독점한다는 사실이 조금 두렵습니다.

고성능, 고확장성 금융/과학 시뮬레이터를 개발합니다. 시뮬레이션은 사용자가 생성하는 모델의 복잡성에 따라 몇 분에서 며칠까지 실행할 수 있습니다.

시뮬레이션 소프트웨어의 특성 때문에 시작 시간과 소프트웨어/바이너리 크기는 거의 문제가 되지 않습니다. 그런 점에서 제품을 설치하는 데 걸리는 시간도 아닙니다. 예를 들어 컴파일이 설치의 일부인 경우 이러한 프로세스가 오랜 시간이 걸리더라도 완전히 수용할 수 있습니다.

실행 중 코드의 약 25%가 동적으로 생성되므로 하이브리드 방식이 선호됩니다. AOT와 JIT 컴파일의 일부 조합. 동적 비트를 해석해야 하는 경우 적어도 우리의 사용 사례에서는 AOT의 이점이 많이 줄어들 것이라고 생각합니다.

GC는 더 높은 확장성을 달성하는 데 방해가 되는 가장 큰 문제입니다(예: 약 44개의 코어를 확보한 경우). 컴파일러가 더 심도 있는 어셈블리 간 최적화, 적극적인 인라인 및 이스케이프 분석을 수행할 수 있게 하면 힙 대신 스택에 더 짧은 수명의 개체를 할당할 수 있습니다.

우리 코드 기반에는 JIT 코드 품질이 특히 레지스터 할당과 많은 구조를 다룰 때 병목 현상이 발생하는 곳이 많이 있습니다. 이로 인해 JIT 컴파일러를 조작하여 올바른 일을 하거나(연약하고, 난독화되며, 유지하기 어려운 줄다리기) 네이티브 코드로 전환하는 코드를 작성해야 합니다. 및 GC/PInvoke 전환의 오버헤드).

때로는 코드 품질의 작은 개선이 수많은 코어에서 몇 시간 동안 실행되는 모델 과정에서 엄청난 승리를 거둘 수 있습니다. 우리에게 JIT는 개발과 함께 코드 기반이 변경됨에 따라 성능에 있어 약간 취약해졌습니다(심지어 덜 결정적임). 우리의 희망은 AOT 컴파일러가 훨씬 더 높은 품질의 코드를 컴파일하고 생성하는 데 훨씬 더 많은 시간이 걸리고 불필요한 성능 변동을 줄이고 C#에서 더 많은 코드 기반을 유지할 수 있기를 바랍니다.

일반적으로 JIT와 AOT 기술 모두에 더 많은 투자를 했으면 합니다.

cc @AndyAyersMS

AOT w/ static linking은 jit를 비활성화하는 iOS 및 콘솔 플랫폼의 게임 엔진에 시급합니다.

여기에 전적으로 동의합니다. 이 문제에 대한 솔루션이 필요하기 때문에(비 Unity 프로젝트의 경우 게임 콘솔에서 실행되는 C# 코드) Mono-AOT 기반 도구 체인을 사용하고 있습니다. 그러나 몇 가지 심각한 제한 사항이 있으며 성능이 좋지 않습니다.

따라서 우리는 3개의 포플러 게임 콘솔(XBox One, PlayStation 4 및 Nintendo Switch)에서 CoreRT를 실행하는 방법을 찾고 있습니다. 개념의 초기 교수는 그것이 실제로 작동하지만(여전히 몇 가지 제한 사항이 있음) Mono 기반 솔루션과 비교하여 이미 상당한 런타임 성능 개선이 있음을 보여줍니다.

그러나 게임 콘솔을 둘러싼 NDA 상황에서 이 사용 원인에 대한 공식 지원은 처음부터 공식 네이티브 AOT를 얻는 것보다 훨씬 더 적절합니다.

우리에게 JIT는 개발과 함께 코드 기반이 변경됨에 따라 성능에 있어 약간 취약해졌습니다(심지어 덜 결정적임).

@jpapp05 귀하의 앱, 특히 위의 문제에 대해 자세히 듣고 싶습니다. 이 문제는 제 주요 관심사 중 하나이기 때문입니다. 도움이 되시면 언제든지 오프라인으로(프로필의 이메일을 통해) 저에게 연락해 주십시오.

안녕하세요 @AndyAyersMS 입니다. 좀 더 자유롭게 이야기할 수 있으므로 오프라인에서 연락을 드리겠습니다. 하지만 다른 사람들의 이익을 위해 토론의 요약을 다시 게시하게 되어 기쁩니다.

이것이 문제인지는 모르겠지만 여기에서 언급하기만 하면 됩니다.
우리에게 중요한 기능은 런타임에 네이티브 어셈블리를 동적으로 로드 및 언로드하는 기능입니다.

@movedoa NativeLibrary API 참조 https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.nativelibrary?view=netcore-3.1

내 가장 큰 문제는 UWP Native를 제외하고 적어도 내가 테스트한 한 .NET은 일반적으로 쉽게 디컴파일될 수 있다는 것입니다. "정상적인" 회사 사고 방식이 아닌 누군가는 쉽게 디컴파일할 수 있는 프로젝트에 많은 IP를 넣을 것입니다.
Linux는 괜찮지만 모든 데스크톱 응용 프로그램은 엔터프라이즈 환경의 Windows용입니다.

삶을 더 쉽게 만들기 위해 다음과 같은 확인란을 추가하십시오.
기본 컴파일(Windows 10 데스크탑에서만 작동합니다!)
그렇게 하면 더 이상 AOT에 관심이 없습니다. ASP.NET Core에서 작동한다면 멋지다! 그렇지 않다면 나는 정말로 상관하지 않습니다.

그건 그렇고, 질문을 만들고 설문 조사를 만들어 주셔서 감사합니다. 업무에서 기술을 사용하는 사람들에게 의견을 묻기 때문에 수고하셨습니다. 내 생각에 (사실 나는 확신합니다) 당신은 여전히 ​​Github에서 이런 일에 관여하지 않는 수많은 데스크탑 개발자 의견을 그리워하고 있습니다. 모든 사람이 .NET 코드를 쉽게 디컴파일할 수 있다는 사실을 기억(또는 알고) 있지는 않으며 상사가 다음과 같은 사실을 알면 미쳐버릴 것이라고 확신합니다 .

모든 사람이 .NET 코드를 쉽게 디컴파일할 수 있다는 것을 기억하거나 아는 것은 아닙니다.

쉿... Unity 또는 타사 패키지의 배후에서 무언가가 어떻게 작동하는지 알아내려고 할 때 Rider가 자동으로 이 작업을 수행한다는 사실은 놀랍습니다. 많은 코드가 처음에 오픈 소스로 제공되기 때문에 지금은 그다지 중요하지 않지만, 제 말을 이해하게 될 것입니다.

@jcbeppler 당신은 틀렸습니다. 그것은 바이트 코드와 네이티브에 대한 일반적인 오해입니다. 올바른 도구를 갖는 것입니다.

https://www.hex-rays.com/products/decompiler/compare/compare_vs_disassembly/

Hex-Rays는 가능한 솔루션일 뿐이며 선택할 수 있는 다른 솔루션이 있습니다.

@MostHated 예, 알았습니다. 사실 .NET에서 소프트웨어를 디컴파일하는 것은 매우 간단하여 마치 오픈 소스와 같으며 많은 회사에서 소프트웨어가 오픈 소스가 되는 것을 원하지 않습니다. "공짜 점심은 없다" 😄

@pjmlp 디컴파일과 디스어셈블리의 차이점을 알고 있습니다. 나는 내 소프트웨어를 디스어셈블리하는 것에 대해 아무 것도 할 수 없지만 사람이 매우 간단한 디컴파일을 할 수 없기 때문에 기본 컴파일은 소프트웨어를 훨씬 더 안전하게 만들 수 있습니다. 디스어셈블된 소프트웨어는 확실히 이상하게 보이고 디스어셈블된 코드는 제대로 실행되지 않을 수도 있습니다.

@jcbeppler 당신은 틀렸습니다. 그것은 바이트 코드와 네이티브에 대한 일반적인 오해입니다. 올바른 도구를 갖는 것입니다.

현재 디컴파일된 .NET 프로그램은 전체 소스 코드를 드러냅니다. 여기에는 모든 메서드 이름과 변수 이름도 포함됩니다. 이것은 디버깅에 유용하며 예외가 발생할 때 "읽을 수 있는" 스택 추적을 가질 수 있습니다. 그러나 엄청난 보안 결함과 .NET 난독화 장치에 대한 거대한 시장이 있는 이유입니다.

네이티브 애플리케이션은 디스어셈블될 수 있습니다. 그러나 전체 C++/델파이 등의 소스 코드를 공개하지 않습니다(이 소스 코드를 다시 빌드하려고 시도하는 일부 도구가 있지만 결과는 끔찍합니다). 얻을 수 있는 것은 기껏해야 어셈블러 코드와 제어 순서도입니다. 운이 좋고 기호 파일과 함께 제공되는 경우 기능 이름도 얻을 수 있지만 릴리스 모드에서 이 기호 파일은 일반적으로 보안을 위해 포함되지 않습니다.

네이티브 코드가 실제 보호 기능인 방법에 대해 이야기하는 세부 사항에 빠져들 수 있습니다. 제 생각에는 크래킹(전체 메서드/변수 이름 및 전체 C# 소스 생성 덕분에 특별한 지식 없이 라이선스 확인을 제거할 수 있음) 또는 디버깅 측면에서 보호가 아니라 스틸러에 대한 보호입니다. dnSpy와 같은 도구는 한 번의 클릭으로 .NET 응용 프로그램을 전체 VS 프로젝트로 내보낼 수도 있습니다. 네이티브 코드에 대해 동일한 방식으로 작동하는 도구는 없습니다. 따라서 상용 응용 프로그램의 경우 기본 코드를 생성하는 것이 큰 승리가 될 것입니다. 게다가 최종 응용 프로그램의 모든 메서드와 변수의 이름을 바꾸는 데 연간 수천 달러를 지불할 필요가 없다는 사실 외에도 말입니다.

이번 설문조사 결과가 궁금합니다. 사람들이 어떻게 투표했는지 공개할 계획이 있습니까?

@Symbai IP를 보호하기 위한 수단으로 NDK를 사용하려고 시도한 Android 개발자가 알려줄 것이기 때문에 어떤 것에 대한 보호도 아닙니다. 간단히 언급한 응용 프로그램은 한 번의 클릭으로 동일한 작업을 수행할 수 있으며 일반적으로 C 또는 C++ 코드를 원본 소스 코드로 가정하지만 알고리즘을 도용하기에 충분합니다.

시작 시간이 정말 중요한 Rust, Go, Swift, C++, Java(GraalVM), 데스크톱, 콘솔 및 모바일/IoT 애플리케이션에 대해 .NET이 장기적으로 손실되는 시나리오의 경우 AOT를 원합니다. 메모리 사용에 대한 제약이 높습니다. 일부 ASP.NET 시나리오에서와 마찬가지로 어셈블리 로드 시 JIT로 인한 속도 손실은 100개의 K8S 포드 인스턴스를 확장할 때 AOT 코드가 관련될 수 있는 것처럼 허용되지 않습니다.

다른 한편으로는 JIT 기능을 유지하고 JIT를 사용해야 하는 시나리오에서 개선하는 것과 관련이 있음을 알게 되었습니다.

두 컴파일 모델을 모두 제공하는 언어가 많이 있으므로 사용자가 상황에 따라 선택하고 선택할 수 있으므로 기본적으로 JIT를 유지하고 AOT 스토리를 .NET 네이티브 방향으로 개선하면서 NGEN이라는 소심한 시도를 잊어버리도록 합니다.

@Symbai IP를 보호하기 위한 수단으로 NDK를 사용하려고 시도한 Android 개발자가 알려줄 것이기 때문에 어떤 것에 대한 보호도 아닙니다. 간단히 언급한 응용 프로그램은 한 번의 클릭으로 동일한 작업을 수행할 수 있으며 일반적으로 C 또는 C++ 코드를 원본 소스 코드로 가정하지만 알고리즘을 도용하기에 충분합니다.

내가 살 수는 있지만 오늘날 .NET이 허용하지 않는 알고리즘을 훔치는 것(예: WPF), 누군가가 VS 프로젝트로 실행하기 위해 아름답고 쉽게 완전한 애플리케이션을 준비하는 곳. 네이티브 컴파일이 포함된 UWP는 누군가가 그것을 디스어셈블하려는 경우 좋은 일을 한다고 생각합니다. 좋아요, 행운을 빕니다! 나는 무슨 일이 있어도 항상 네이티브 컴파일을 사용할 것입니다. 말할 수 없는 Android 세계, Xamarin Forms로 AOT를 한 번 시도했지만 실제로 예상대로 작동하지 않았습니다.

네이티브 컴파일이 포함된 UWP는 누군가가 그것을 디스어셈블하려는 경우 좋은 일을 한다고 생각합니다. 좋아요, 행운을 빕니다! 나는 무슨 일이 있어도 항상 네이티브 컴파일을 사용할 것입니다. 말할 수 없는 Android 세계, Xamarin Forms로 AOT를 한 번 시도했지만 실제로 예상대로 작동하지 않았습니다.

스포일러 - 소스를 얻으려는 사람들은 아마도 당신을 깎아내리지 않고 개선/확장/통합하려고 할 것입니다. 그들이 당신을 찢어 버리려고한다면, 당신의 메트릭은 정말 어리석은 것입니다.

내가 책을 쓴다면 출판하기 전에 누군가 그것을 일본어로 번역해 줄 것을 요청하십시오. 나는 일본어를 이해하지 못하고 내 친구도 이해하지 못하기 때문에 내가 정말 똑똑하다고 생각할 수도 있습니다. 하지만 현실은 그 책을 읽을 수 있는 나라가 전세계에 있다는 것입니다. 그리고 다른 척 하면 스스로를 속일 뿐입니다.

디스어셈블된 네이티브 바이너리에 대한 경험이 없고 Star Citizen에서 암호화 및 데이터 형식을 리버스 엔지니어링하기로 결정한 개발자로서 이 말을 합니다.

사전 경험이 전혀 없는 저에게 암호화된 데이터 파일을 해독할 수 있을 뿐만 아니라 독점 데이터 형식을 XML/JSON으로 변환할 수 있는 프로그램을 갖추는 데 2주가 걸렸습니다.

그 2주가 지나면 VS 프로젝트로 실행할 수 있는 완전한 응용 프로그램이 없을 수도 있지만 그럴 필요가 없다는 것도 알고 있습니다. 기존 애플리케이션에 내 자신의 코드를 삽입하는 것이 훨씬 간단하고 모든 코드를 처리할 필요가 없습니다.

암호화된 데이터 파일을 해독할 수 있을 뿐만 아니라

암호화는 완전히 다른 것입니다. 모드를 만들기 위해 비디오 게임을 디컴파일하는 것은 완전히 다릅니다. 대부분의 게임 개발자는 팬이 모드를 만드는 데 신경 쓰지 않고 게임에 대한 열정과 사랑을 보여줍니다. 그리고 아마도 "암호화"는 전혀 암호화가 아니었지만 파일은 더 작은 크기로 압축되었을 뿐입니다. 수천 개의 단일 파일을 디스크에 저장할 필요가 없습니다. 성능도 이유가 될 수 있습니다... 디스크에서 많은 작은 파일을 읽는 것은 하나의 큰 파일을 읽는 것보다 느립니다. 그리고 2주 후에 포장된 이미지의 압축을 풀 수 있었습니다. 일부 데이터 파일 내에서 텍스트를 변경할 수 있었습니다. 이것은 훌륭하지만 나 같은 사람들이 JIT를 없애고 싶어하는 이유는 아닙니다.

우리가 지금 가지고 있는 문제는 JIT 코드가 완전한 소스 코드로 완전히 디컴파일될 수 있고 Java는 다른 JIT 언어와 동일한 문제가 있다는 것입니다. 네이티브 코드는 디스어셈블될 수 있고(이렇게 하면 기계어 코드가 어셈블리 코드로 바뀝니다), 네이티브 애플리케이션은 충분한 여유가 있으면 크랙될 수 있습니다. 이 모든 것이 사실이지만 네이티브 코드를 컴파일하여 소스 코드를 완성할 수는 없습니다. C++ 코드용 dnSpy와 같은 도구를 본 적이 있습니까? 델파이 코드? 나는하지 않았다. 변수 및 메서드 이름을 얻을 수 없기 때문에 올바르게 컴파일되면 더 이상 존재하지 않습니다. 디스어셈블리를 C++로 변환하고 컴파일할 수 있는 완전히 작동하는 프로젝트를 생성하는 것은 불가능합니다. 이것은 당신에게 그다지 중요하지 않은 것처럼 들릴 것입니다. 그러나 상업용 응용 프로그램에는 엄청난 것입니다. 우리는 .NET 응용 프로그램이 지식이 전혀 없는 모든 사람이 읽을 수 있는 공개 책이라는 사실을 없애고 싶을 뿐입니다. 우리가 연구에 수천 달러를 투자할 때 우리는 모든 사람이 그것을 보고 몇 초 안에 복사하는 것을 원하지 않습니다. 우리는 사람들이 더 이상 애플리케이션을 열고 "라이선스"를 검색하여 즉시 액세스할 수 없도록 모든 변수와 메소드 이름의 이름을 바꾸는 것만 목적인 난독화 장치에 대해 수천 달러를 지불하는 일을 없애고 싶습니다. obfuscator의 비용(대부분) 뿐만 아니라 obfuscator가 추가 문제를 생성한다는 것입니다. 나는 특히 .NET Core 릴리스의 빈도로 자주 이 문제를 겪었습니다. obfuscator가 최신 .NET Core 버전에서 작동하도록 하는 패치를 위해 몇 주만 기다려야 했습니다.

개발자로서 이러한 모든 문제에 직면하는 동안 비즈니스 관리자에게도 설명해야 합니다. 어느 시점에서 그는 다른 프로그래밍 언어를 선택하는 것이 더 좋지 않은지 묻습니다.

C++와 델파이에서는 이 문제가 없습니다. 나는 이것이 모든 사람에게 문제가 되지 않는다는 것을 알고 있습니다. 오픈 소스 개발자는 JIT가 더 흥미롭고 유용하다는 것을 알게 될 것입니다. 열린 책이 더 낫다고 믿을 때 누군가가 자신의 소스 코드를 닫힌 책이 되기를 원하는 이유를 그들에게 설명하는 것은 어렵습니다. 따라서 이상적으로는 완전히 다른 관점을 서로 설명할 필요가 없으며 AOT는 원하는 경우 릴리스 모드에서 켤 수 있는 스위치일 뿐입니다. 원하지 않으면 JIT로 진행하십시오.

AOT❤를 원하는 이유로 "보호"를 선택할 수 있게 해준 .NET 팀에 정말 감사합니다. 그것은 그들이 일부 사람들의 필요를 알고 있음을 보여줍니다. 그리고 여론 조사에서 사람이 그것에 대해 투표하는 것으로 밝혀지면 마침내 AOT 구현이 C++ 컴파일러와 같은 방식으로 이를 처리할 기회를 갖게 될 것입니다. 참고: AOT가 실제로 얼마나 보호하는지에 대한 추가 논의를 피하기 위해 인용문을 넣었습니다.

보안은 전부 또는 전무가 아닙니다. IL을 제거한다고 해서 결정된 공격자가 응용 프로그램을 되돌리는 것을 막을 수는 없습니다. 그러나 그것은 실용적인 의미에서 관련이 있는 장애물을 만듭니다. 심층 방어입니다. 이것이 IL 난독화 제품을 사용하는 것이 합리적일 수 있는 이유입니다.

내 친구가 IL을 C#으로 디컴파일하고 사소한 수정을 통해 .NET 제품을 깨뜨렸습니다. 그는 기본 응용 프로그램을 해독할 수 없습니다. 훨씬 어렵습니다. 그는 또한 디컴파일러 도구가 해당 바이너리에서 충돌했기 때문에 IL 난독화자가 있는 상황에서 포기해야 했습니다. 다시 말하지만, 해당 제품은 실용적인 의미에서 보호되었습니다. 그것은 효과가 있었다.

@심바이

Have you ever seen a tool like dnSpy for C++ code? Delphi code?

Hex-Rays는 C에 대해 좋은 작업을 수행하며 결정 프로세스를 돕는 매크로가 있습니다.

C 소스를 갖는 것은 그것을 C++ 또는 델파이로 변환하는 아이들의 놀이입니다.

또한 이제 우리는 기술이 부족한 사람들을 돕기 위해 AI를 갖게 되었습니다.

제거된 바이너리의 신경 역공학

Hex-Rays는 C에 대해 좋은 작업을 수행하며 결정 프로세스를 돕는 매크로가 있습니다.

Hex-Rays 또는 난독화 소프트웨어를 판매하는 회사에서 일하십니까? 그것은 나타납니다.

어쨌든, 그것을 C로 변환하더라도 코드는 좋은 C# 아키텍처에서 멀리 떨어져 있을 것입니다. 코드 조각을 얻더라도 변경, 개선 등을 위해 많은 노력을 기울여야 합니다....
당신을 위해 네이티브 컴파일이 관련이 없다면, ok. 그러나 많은 사람들에게 그것은 관련이 있습니다.

BTW: 당신은 JIT 컴파일을 유지하는 데 매우 관심이 있어 보이며 소프트웨어 분해에 많은 경험이 있는 것 같습니다. 왜, 어디에 사용해야 했는지 궁금하시죠?!

IL 대 기계어 코드의 디컴파일 용이성에 대해 여러분 중 누구라도 느끼는 것과 상관없이 그것이 실제 비즈니스에서 실제 요구 사항이라는 사실은 변하지 않습니다. (그리고 우리는 소가 집에 돌아올 때까지 그 요구 사항이 얼마나 유효한지 또는 무효한지에 대해 논쟁할 수 있습니다.)

내 이전 고용주는 이러한 이유로 .NET 또는 JVM 도구를 외부적으로 제공하는 것을 명시적으로 금지했습니다. 내가 떠나기 직전에 한 팀은 높은 사람들에게 난독화가 적용된 도구를 제공하도록 설득했지만, 그렇지 않으면 우리는 기업 정책을 충족시키기 위해 C++로 외부 도구를 작성하고 있었습니다.

이 토론은 궤도에서 벗어났습니다. AOT가 IP 보호와 관련이 있는지 여부에 대해 모두 논쟁을 벌이고 싶다면 다른 곳에서 하십시오.

Hex-Rays는 C에 대해 좋은 작업을 수행하며 결정 프로세스를 돕는 매크로가 있습니다.

Hex-Rays 또는 난독화 소프트웨어를 판매하는 회사에서 일하십니까? 그것은 나타납니다.

어쨌든, 그것을 C로 변환하더라도 코드는 좋은 C# 아키텍처에서 멀리 떨어져 있을 것입니다. 코드 조각을 얻더라도 변경, 개선 등을 위해 많은 노력을 기울여야 합니다....
당신을 위해 네이티브 컴파일이 관련이 없다면, ok. 그러나 많은 사람들에게 그것은 관련이 있습니다.

BTW: 당신은 JIT 컴파일을 유지하는 데 매우 관심이 있어 보이며 소프트웨어 분해에 많은 경험이 있는 것 같습니다. 왜, 어디에 사용해야 했는지 궁금하시죠?!

그에 반해 저는 네이티브 코드를 제3자가 더 사용할 수 있는 소스 코드로 리버스 엔지니어링하는 기술을 보유하고 있기 때문에 네이티브 코드로 컴파일하는 것은 스크립트 키디들에게 장애물일 뿐이라는 것을 충분히 알고 있습니다. 여기.

편집: 또한 내 의견을 중지합니다. 인신공격에 답하고 싶었을 뿐입니다.

클라우드 네이티브 및 WPF는 AOT여야 합니다.
Windows 클라이언트 런타임 없음! JIT 없음

설문조사 결과가 게시되었습니다( https://github.com/dotnet/runtime/issues/41522). 현재 연락처 정보를 제공하고 몇 가지 추가 질문이 있는 사람들에게 후속 조치를 취하는 중입니다.

AOT w/ static linking은 jit를 비활성화하는 iOS 및 콘솔 플랫폼의 게임 엔진에 시급합니다.

여기에 전적으로 동의합니다. 이 문제에 대한 솔루션이 필요하기 때문에(비 Unity 프로젝트의 경우 게임 콘솔에서 실행되는 C# 코드) Mono-AOT 기반 도구 체인을 사용하고 있습니다. 그러나 몇 가지 심각한 제한 사항이 있으며 성능이 좋지 않습니다.

따라서 우리는 3개의 포플러 게임 콘솔(XBox One, PlayStation 4 및 Nintendo Switch)에서 CoreRT를 실행하는 방법을 찾고 있습니다. 개념의 초기 교수는 그것이 실제로 작동하지만(여전히 몇 가지 제한 사항이 있음) Mono 기반 솔루션과 비교하여 이미 상당한 런타임 성능 개선이 있음을 보여줍니다.

그러나 게임 콘솔을 둘러싼 NDA 상황에서 이 사용 원인에 대한 공식 지원은 처음부터 공식 네이티브 AOT를 얻는 것보다 훨씬 더 적절합니다.

@RalfKornmannEnvision Xamarin Xbox One/PS4 Mono 포트를 LLVM codegen과 함께 사용하고 있습니까?

@RalfKornmannEnvision Xamarin Xbox One/PS4 Mono 포트를 LLVM codegen과 함께 사용하고 있습니까?

@lateralusX 통합은 다른 사람이 했기 때문에 자세히는 모릅니다. 하지만 내가 아는 한 XBox One/PS4용으로 제공되는 모노 포트를 사용하고 스위치용으로 간단한 포트를 만들었습니다. 자신.

@RalfKornmannEnvision 연락하여 이와 관련된 경험에 대해 논의하는 것이 좋습니다. LLVM codegen은 (프로젝트에 따라) 생성된 코드에 매우 긍정적인 성능 영향을 미치므로 사용하지 않은 경우(활성화해야 함) 일반적으로 활성화하는 것만으로도 많은 것을 얻을 수 있습니다. DotNetEvolution discord 서버에 있습니까? 그렇다면 이와 관련하여 오프라인 토론을 할 수 있습니까?

@lateralusX 이 작업을 수행한 팀원들이 LLVM 코드젠을 활성화하고 다른 작업을 시도했다고 확신합니다. 다른 프로젝트로 넘어가기 전 그들의 마지막 진술은 이것이 그들이 할 수 있는 최선이라는 것이었다.

조사의 일환으로 Xamarin Android를 사용하여 핵심 구성 요소로 벤치마크를 빌드하고 Tegra X1 기반 장치에서 실행하여 Mono의 사용자 지정 스위치 포트 문제로 인해 성능이 손실되었는지 확인합니다. 불행히도 Xamarin 프로젝트의 성능은 스위치에서 본 것과 크게 다르지 않았습니다.

나는 이 불화 서버에 있지 않고 솔직히 말해서 그들이 현재 MONO 통합에 대해 내가 아는 것이 그다지 많지 않다는 점을 유감스럽게 생각합니다. 내 관점에서 이것은 어쨌든 이 프로젝트의 막다른 골목입니다. 현재 CoreRT 프로토타입(공식 지원은 훨씬 적음)은 이미 성능과 유용성 면에서 훨씬 우수합니다.

@RalfKornmannEnvision 좋습니다 . 귀하의 정보와 피드백에 감사드립니다. 모두 매우 소중합니다.