Hacker News 의견

• 2000년대 초반 스택 프레임 포인터 생략이 퍼지기 시작했을 때의 경험
  • 저자는 당시 컴퓨터 과학을 공부하고 있었으며, 사용하는 컴퓨터는 오래되고 성능이 낮았음.
  • 디버깅이 어려워지자 Python을 사용하기 시작함으로써 디버깅 문제를 피함.
• 페도라(Fedora) 배포판에서 스택 프레임 포인터를 유지하기 위한 노력
  • 스택 프레임 포인터가 큰 오버헤드를 가진다는 잘못된 믿음이 있었으나, 실제 오버헤드는 1% 미만임.
• 애플이 ARM 아키텍처에서 스택 트레이스를 항상 의미 있게 유지한 점
  • 특정 함수는 프레임 레코드를 생성하지 않을 수 있지만, 스택 트레이스는 디버그 정보 없이도 유의미함.
• 구글에서의 경험과 커뮤니티와의 20년간의 논쟁
  • libunwind를 gperftools에 적용하기 위한 패치 작업 및 유지보수 경험 공유.
• 과거에 -fomit-frame-pointer 옵션으로 성능 향상을 경험한 사례
  • 32비트 프로세서에서 MySQL과 PHP를 컴파일하여 하드웨어 비용 절감.
• Virgil 프로그래밍 언어의 스택 프레임 관리 방법
  • 동적 스택 할당이 없는 경우, 간단한 테이블 조회로 프레임 크기를 찾을 수 있음.
  • 메타데이터 디코딩을 구현하는 코드에 대한 설명.
• 스택을 '걷는' 대신 RBP와 RSP를 사용하여 두 개의 스택을 관리하는 아이디어
  • 호출 스택이 단순히 반환 주소의 배열이 됨으로써 스택 걷기의 필요성 감소.
• 프레임 포인터에 대한 지지와 관련된 경험 및 생각 공유
  • 프레임 포인터 활성화 여부는 사례별로 결정되어야 하며, 벤치마킹이 중요함.
  • 빌드 시스템이 이를 전체적으로 변경할 수 있는 기능을 제공하는 것의 중요성.
  • SFrame에 대한 기대감과 현재 문제를 해결할 잠재력.
• 프로파일링이 20년 동안 문제가 되었고 이제야 해결되었다는 의견
  • 프레임 포인터의 부재가 많은 사람들에게 고통스러웠으며, 이제 리눅스가 그것을 되돌리는 것을 보며 그들의 노력이 인정받는 것 같음.
• 시스템 프로파일링을 가능하게 하는 메커니즘의 성능에 대한 불만이 역설적임
  • 성능 문제를 식별할 수 있게 해주는 시스템에 대한 성능 불만은 성급한 최적화의 극치임.