[C#] Native AOT 컴파일

Java의 카피캣 취급을 받는 C#지만, 자바보다 훨씬 뛰어난 부분들도 여럿 존재한다.
그 중 하나가 바로 Native AOT 컴파일의 지원 수준이다.

Java도 GraalVM을 통해서 Native AOT 컴파일을 지원하긴 하는데, 아직 완성된 느낌도 아니고 내가 볼때 최적화 수준도 저열한 편이다. C#이 훨씬 낫다.

내가 벤치마크를 이래저래 돌려보니까, Java => GraalVM 컴파일은 확실하게 무조건 느려지는데, C# AOT 컴파일은 2-3배 이상 빨라졌고 어지간한 컴파일 언어들보다도 빠른 성능을 보여줬다.
확실히 매력적인 선택지 중 하나인 것 같다.

기존 구조의 장단점: JIT

C#은 컴파일이니 뭐니 하지만 결국 인터프리터 언어다.
닷넷 런타임이라는 인터프리터에 닷넷 전용 어셈블리를 올려서 대신 실행하는 것이기 때문이다.
그리고 이런 방식은 당연히 직접 어셈블리를 실행하는 것에 비해서는 실행성능이 현저하게 느리다.

그래서 닷넷 런타임은 JIT 컴파일 구조를 통해서 성능과 사용성의 균형을 잡으려고 노력한다.
https://blog.naver.com/sssang97/223948313129
이 방식의 장점은, 최초 컴파일이 빠르고, 장기실행으로 갈수록 성능 고점이 높아진다는 것이다.
실행 중에도 프로파일 데이터 기반의 지속적인 최적화가 가능하기 때문에 성능이 컴파일 언어보다 빠르게 나올 때도 있다.

이 방식에는 고질적인 단점도 몇개 있다.

1. 사용 패턴에 따라서 JIT 최적화보다 정적인 최적화가 효율적일 수도 있다.

2. 런타임이 매번 붙어서 돌아다니니 전체 앱의 디스크 크기, 메모리 사용량이 커진다.

3. 처음 시작할때는 느리다가 나중에 빨라지는 문제가 있다. 배포시에 균일한 성능 보장이 필요하다면 데워주는 작업을 해줘야 한다.

4. 실시간 컴파일 결과물을 계속해서 관리하고 메모리에도 올려야 한다.

그래서 뭔가 서버 등을 빠르게 빠르게 올려야 하거나,

이런 단점들이 치명적이라면 AOT 컴파일을 고려해보는 것도 시도해봄직한 방법이다.

AOT (Ahead Of Time)

AOT는 C# 코드를 인터프리터에 올리지 않고, 그냥 진짜 플랫폼 실행파일로 컴파일하는 것을 말한다.
C/C++로 컴파일한 결과물과 동등하게 특정 플랫폼에서만 실행할 수 있는 것이다.

앱 크기가 작아지고, 메모리를 더 적게 먹고, CPU 사용량이 줄어들고, 시작 속도가 매우 빠르다는 장점들이 있다.
이렇게 말면 닷넷 런타임을 배포 파일에 포함할 필요도 없다.

물론 단점들도 있다.
실행시 런타임의 부재로, 누려왔던 이점들을 상당수 잃는다.
JIT 최적화가 더 이상 적용되지 않고, 리플렉션을 비롯한 런타임 의존 기능들을 사용하지 못한다.

그 외에도 호환성이 완전하게 보장되지는 않는다. AOT 컴파일이 가능한 라이브러리가 있고 아닌 것들이 있다.

AOT로 컴파일해보기

컴파일 자체는 간단한 편이다.
graalVM처럼 추가 종속성 같은게 필요하진 않다. 닷넷 툴체인만 있으면 된다.

<PublishAot>true</PublishAot>

프로젝트 파일에서 활성화하거나

dotnet publish -c Release -r linux-x64 /p:PublishAot=true

publish command를 통해서 컴파일을 할 수 있다.

그러면 이런 식으로 실행파일이 떨어질 것이다.
이 자체로 완성된 실행파일이니, 그대로 실행하면 된다.

참조
https://learn.microsoft.com/ko-kr/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet8