store forwarding이 논의에서 언급되지 않은 점이 의외라는 놀람 표현, -O3에서의 코드 생성 결과는 지나치지만 -O2에서는 합리적 판단, 구조체 중 하나가 연산 직후라면 32비트 로드 시도 시 store forwarding 실패로 성능 향상이 무의미해질 수 있다는 구체적 설명, 비인라인/비-PGO 상황에서는 컴파일러가 최적화 적합성 판단에 필요한 정보 부족함 지적
이슈 토론이 단순한 “나도 겪었다” “언제 고쳐지나” 류의 댓글로 채워지지 않아 좋다는 감상, 웹 개발자로서 GitHub 이슈는 불만족이라는 솔직한 의견 공유
이 사례가 컴파일러 개발이 얼마나 복잡한 일인지 보여주는 예시라는 의견, C 계열 컴파일러들도 이런 이슈를 더 잘 다루지 못할 것이라는 확신 표현
블로그 포스트에 프로파일러 결과를 어떻게 삽입했는지 궁금증 표출, HTML 노드를 그대로 복사한 것인지 질문
본문 제목이 실제 성과에 비해 너무 소극적이라는 지적, 실제로는 두 가지 좋은 최적화 덕분에 2.3% 속도 향상이 있음 강조
1.5% 개선은 aarch64에만 해당되므로 전체 수치로 언급하는 것은 다소 공정하지 않다는 의견, arm/x86 비중을 고려하면 절반 정도로 보는 게 맞다는 주장
게시글이 유익했고 16비트 정수 쌍 비교의 비효율적 코드 발견이 인상적이었다는 평가
Rust/LLVM 개발자들이 이 최적화를 가능한 경우 자동으로 적용할 수 있을지 궁금함, Rust에서는 메모리 초기화 관련 정보가 훨씬 정확하다는 점 언급
모든 조건이 같다면 이런 코덱은 Rust보다는 WUFFS 같은 언어나 그에 준하는 특수 목적 언어에서 다뤄야 한다고 생각, dav1d처럼 복잡한 코드를 WUFFS로 변환하는 것은 기존 C 코드 번역(clean up)보다 훨씬 더 큰 난이도라는 체감 공유, 그럼에도 이런 시도를 가치 있다고 여기며 문명적 차원에서 투자할 만하다는 주장
WUFFS는 Matroska, webm, mp4와 같은 컨테이너 파싱에는 적합하지만 비디오 디코더에는 전혀 적합하지 않다는 점 설명, 다이나믹 메모리 할당이 없어 동적 데이터 처리에 도전적임, 비디오 코덱은 단순히 파일을 파싱하는 것이 아니라 매우 다양한 동적 상태 관리 필요성 강조
rav1d 현상금 진행 상황이 궁금해서 혼잣말 삼아 묻고 있었는데, 비슷한 고민을 가진 사람이 있다는 공감 표현
이 사례는 명확한 ‘Nominative determinism(이름짓기 효과)’ 케이스라는 위트 섞인 의견
솔직히 첫 번째 최적화는 perf만 잘 써도 쉽게 찾을 수 있는 흔한 유형이므로 다소 의외였음, 제로잉 이슈는 이미 첫 포스트에서 논의된 줄 알았음, 두 번째 최적화는 더 복잡하고 흥미로웠지만 역시 perf가 이끈 방향이었다는 점 강조, perf 툴의 효용성 과소평가 말라는 조언
perf만 사용한 것이 아니라 C 버전과 Rust 버전 간의 차등 프로파일링 및 수동 매칭 과정을 통해 파악한 점 정확히 설명, perf diff 기능이 있지만 심볼명이 달라서 자동 매칭이 어렵다는 한계점 지적
aarch64 기반 Apple 기기 관점에서 접근했다는 점 언급, 서로 다른 배경을 가진 사람이면 뒷날 되돌아보면 "당연했던" 부분도 빠르게 포착할 수 있음을 경험에서 강조
ffmpeg 트위터 계정을 읽고 ffmpeg 사용에 회의감이 들었다는 솔직한 심경, 대안이 없어서 아쉽다는 아쉬움, 개발자 커뮤니티가 매우 독소적이라는 지적, 최대 성능이 중요할 수 있지만 외부와 데이터를 주고받는 환경에선 ffmpeg에서 매년 수차례 원격 취약점(CVE) 발생 가능성 언급, 보안 측면에서 타이트한 샌드박스 필요성 강조, 빠르고 안전한 솔루션을 함께 만들어가는 중간 지점이 필요하다는 의견, 관련 링크 공유 https://ffmpeg.org/security.html
더 나은 반응은 dav1d 성능 개선으로 대응하는 방법이라는 제안, 스포츠 기록과 비교해 지나치게 기록만 개선해봐야 실제 신기록 달성에 비하면 감흥이 떨어진다는 비유, 진짜 해결책은 실질적으로 빠르고 혁신적인 결과라는 유쾌한 설명
Hacker News 의견