Hacker News 의견

• Matt의 컴파일러 최적화를 살펴본 후, 내가 그와 진행한 인터뷰도 확인해보면 좋겠음
  내가 믿게 된 건 이거임: 자신이 편한 추상화 레벨에서 일하되, 그 아래 계층도 이해해야 함
  예를 들어 C 프로그래머라면 C 런타임이 운영체제와 어떻게 상호작용하는지 알아야 함. 모든 세부사항은 몰라도 되지만, 문제가 생겼을 때 어디서부터 봐야 할지 감을 잡을 정도는 필요함
  Matt가 쓴 ACM Queue 기사도 오래된 글이지만 이런 최적화 개념을 이해하기에 아주 좋은 입문서임

  • “자신이 일하는 계층 바로 아래를 이해하라”는 말을 대학 시절 교수님께 들었음. 그게 내 커리어에 큰 도움이 되었음
    예를 들어 Java를 다룰 때 JVM을 이해하니 의료 소프트웨어의 성능을 훨씬 잘 최적화할 수 있었음. 그리고 단순히 그 아래 계층을 이해하는 게 재미있기도 함
  • 고마워 Adam 😊

• 그는 명백한 도메인 전문가임에도 불구하고, 처음부터 복잡한 x86 명령어 세트로 뛰어들지 않고 기본적인 부분부터 차근차근 설명하는 점이 인상적임

• Matt Godbolt은 C와 C++ 커뮤니티의 진정한 보석 같은 존재임
  Compiler Explorer와 그의 기여 덕분에 많은 개발자들의 세상이 더 나아졌다고 생각함

  • 뭐라고?! Godbolt이 실제 사람이라고!?

• Advent of Computer Science Advent Calendars, Day 2를 보고 있음

  • 이제 그 시점에 도달한 것 같음

• 나는 SQLite가 사용하는 코드 통합(amalgamation) 기법에 관심이 많음
  SQLite 팀에 따르면 이 방식만으로도 5~10%의 성능 향상이 있다고 함. Matt가 세션 중에 이 주제를 다뤄줬으면 좋겠음

  • 이건 꽤 일반적인 주제이고, 사실상 컴파일러 최적화라기보다는 “** unity build**”라고 부르는 빌드 방식임
    참고: Unity build 위키
  • 요즘은 unity build보다 LTO(Link Time Optimization) 가 더 많이 쓰임
    그래도 LTO가 비증분 빌드에서는 느릴 수 있어서, 일회성 빌드에서는 여전히 unity build가 유용함

• 25년 동안 소프트웨어 개발을 해왔지만, 여전히 내가 최적의 컴파일러 플래그를 쓰고 있는지 궁금함

  • 내 경험상, 플래그는 적을수록 좋음
    대부분의 경우 -O2면 충분함. 컴파일러가 업데이트될 때마다 내부 최적화가 개선되므로, 개발자가 직접 세세히 조정할 필요는 거의 없음
    또, 잘못된 벤치마크에 기반해 플래그를 추가하는 건 위험함. 시스템 상태에 따라 1~2% 성능 차이는 흔한 일임
    코드 구조가 바뀌면 캐시 친화성이 달라져서 성능이 변할 수도 있음. 즉, 플래그 때문이 아니라 코드 배치 덕분일 수도 있음

• 남은 포스트들이 기대됨. 오늘 아침엔 SBCL에 (+ base (* index scale))과 (+ base (ash index n)) 패턴을 단일 LEA 명령어로 최적화하도록 가르쳐봤음. Day 2에서 배운 내용을 바로 적용해본 셈임

• Godbolt 콘텐츠는 아무리 많아도 부족하지 않음

• 정수 상수로 나누는 연산을 다뤄줬으면 좋겠음. Hacker’s Delight의 해당 챕터가 정말 훌륭하지만, 일반 독자에게는 조금 어렵게 느껴짐

• 컴파일러 덕후들을 위한 Advent of Code 같음
  매일 한 입 크기의 최적화 레슨을 통해 직관을 쌓는 포맷이 너무 좋음
  컴파일러가 무엇을, 왜 하는지를 이해하면 어떤 언어를 쓰든 더 나은 프로그래머가 될 수 있음