스티븐 타우브, 'Performance Improvements in .NET 11' 공개... 런타임·라이브러리 수백 개 개선 정리

.NET 팀의 전통적인 브라우저 스트레스 테스트 ㅋㅋ 농담 빼고, 런타임 전체에 걸친 자잘한 개선을 이 정도 디테일로 정리해주는 건 진짜 고맙더라.

요즘 AI 슬롭 아닌 진짜 기술 글 읽는 게 이렇게 반가울 일이냐. 스티븐한테 고맙다.

runtime async는 확실히 흥미로운 방향인데 어떻게 굴러갈지 지켜봐야겠음.

근데 .NET 블로그도 요즘 LLM으로 카피 쓰는 것 같더라. 한 문단에 'real'을 두 번 쓰고 쉼표를 남발하는 건 나한테 확실한 신호임. 'Grab your hot beverage' 같은 문장 보고 바로 느낌 왔음.

LLM 사용 의혹 지적은 좀 지겹다. 스티븐은 6년 넘게 같은 형식으로 이 글을 써왔고 매년 비슷하게 생겼음. 그냥 읽어봐라, 진짜 좋다. 이런 품질의 성능 딥다이브는 드묾.

중간 아닐까. 스티븐이 쓰고 링크나 장식 채우는 건 LLM에 맡긴 다음 다시 다듬는 방식 말이지. 나도 장문 쓸 때 그렇게 함. 슬로피한 방식은 아니라고 봄.

나도 LLM 냄새 맡고 바로 창 닫았다.

근본적인 질문인데, 시스템 언어 안 쓰는 개발자도 어셈블리 읽을 줄 알아야 하나? 코드 diff에 cmp, bhs, brk 같은 게 나오는데 C#/F#만 아는 사람이 교과서 다시 펼 이유가 있나?

아니, 저수준 C 한다면 몰라도 대부분은 필요 없음.

몰라도 되지만 코드가 CPU에서 어떻게 도는지 알면 최적화할 때 확실히 도움됨. B로 시작하면 분기, L/S는 로드/스토어라 니모닉 해독은 생각보다 쉬움. 메모리에서 레지스터로 가져와 계산하고 다시 넣거나 점프하는 게 전부임.

꼭 필요한 건 아닌데 이미지나 비디오 처리하다 느려질 때 이 레벨까지 내려가면 도움이 됨. 첫 번째로 볼 곳은 아니고.

기술적으로 대단한 작업이고 글도 훌륭한데, 이 맥락에서 AoT는 어떻게 된 거냐는 게 좀 걸림.

AoT는 여전히 있고, JIT 개선 상당수는 AoT 컴파일 코드 생성에도 그대로 적용될 것임.

C#/.NET은 LLM 학습 데이터에 기업 백엔드부터 게임까지 잘 들어가 있어서 앞으로도 쓸 만한 언어임.

반대로 LLM한테 '현대적인' .NET/C#으로 짜라고 명시적으로 알려줘야 함. C# 14 extension members 같은 건 자주 틀리고 아직 유효하지 않은 문법이라고 하기도 함. System.Threading.Lock 대신 Object를 쓰는 실수도 흔함.

Unity에서 게임 만드는 건 요즘 프런티어 추론 모델이랑 하면 마법 같음. Roslyn으로 스니펫을 컴파일하는 Unity CLI를 써서 도메인 리로드 없이 돌리는데, 리로드가 1020초씩 걸리는 게 툴 호출 510번만 쌓여도 차이가 큼.

기존 서비스가 공짜로 빨라지는 건 언제나 반가움.

아주 자세한 글인데, 애플리케이션 레벨에서 누적 성능 향상이 어느 정도인지 감을 주는 벤치마크가 있었으면 했음.

이런 글 덕분에 나는 완전 .NET 전도사가 됐다. 프레임워크랑 언어 둘 다 좋음.