다음을 보시지요.

https://news.ycombinator.com/item?id=44061160

Improving performance of rav1d video decoder | Hacker News

Improving performance of rav1d video decoder | Hacker News

news.ycombinator.com

https://news.ycombinator.com/item?id=44084383

Improving performance of original dav1d video decoder | Hacker News

Improving performance of original dav1d video decoder | Hacker News

news.ycombinator.com

각각 사이트 들어가서 Ctrl + a, ctrl + c 를 눌러 전체 복사를 합니다.
구글 제미니에 ctrl + v 로 입력하세요.

URL 주소가 2개니까 두번하세요.

그러면 구글 제미니가 진실을 알려 줍니다.

다음은 구글 제미니 무료 버전이 알려준 진실.

다음은 해커 뉴스 스레드에서 rav1d 비디오 디코더, 특히 Rust 포트의 성능 향상에 대한 논의를 요약한 것입니다.

컴파일러 최적화 및 스토어 포워딩

• u16 비교 문제: 성능 향상의 핵심은 두 개의 16비트 부호 없는 정수(u16) 비교를 최적화하는 데 있습니다. 컴파일러(Rust 및 C, 특히 GCC)는 종종 이를 위해 비효율적인 코드를 생성하며, 이는 단순한 구조체 비교에서도 마찬가지입니다.

• 스토어 포워딩: 논의의 상당 부분은 스토어 포워딩(store forwarding) 실패에 초점을 맞춥니다. 값이 메모리에 저장된 다음 즉시 로드될 때, "스토어 포워딩" 메커니즘을 통해 로드는 주 메모리에 쓰여지고 읽히는 것을 기다리지 않고 스토어 버퍼에서 직접 값을 가져올 수 있습니다. 로드의 크기나 정렬이 스토어와 일치하지 않으면 실패하여 상당한 지연(약 12사이클)이 발생할 수 있습니다.

• 컴파일러 동작:

  • -O3 vs. -O2: -O3 최적화 수준은 공격적이지만 때로는 잘못된 최적화로 인해 "엉망진창"(매우 비효율적인) 코드 생성을 초래할 수 있으며, -O2는 더 합리적인 출력을 생성할 수 있습니다.

  • 인라이닝 및 PGO: 인라이닝 또는 프로파일링 기반 최적화(PGO) 없이는 컴파일러는 로드를 병합(예: 두 개의 u16을 단일 u32로 로드)하는 것이 유익한지 또는 스토어 포워딩 실패를 유발할지 판단하는 데 필요한 컨텍스트가 부족합니다.

  • x86용 LLVM Pass: Rust 및 Clang에서 사용하는 백엔드인 LLVM은 Intel CPU에서 부분 저장-로드 문제를 방지하기 위한 특정 패스를 가지고 있습니다.

• Rust vs. C: 비효율적인 u16 비교 코드 문제는 Rust에만 국한된 것이 아닙니다. C 컴파일러(Clang 및 GCC)도 유사하거나 더 나쁜 동작을 보이며, 이는 Rust 특정 문제가 아닌 일반적인 컴파일러 과제를 나타냅니다.

• 잠재적 수정 사항:

  • Rust의 코드 생성에 freeze 인트린식을 추가하면 LLVM이 결정론적 값을 선택하도록 강제하여 최적화를 해제할 수 있습니다.

  • Rust 구조체의 정렬을 수동으로 정의하면 컴파일러가 더 잘 최적화하는 데 도움이 될 수 있습니다.

FFmpeg 및 Rust 포트

• FFmpeg의 입장: FFmpeg 프로젝트의 트위터 계정은 비디오 디코더의 Rust 포트에 대해 강력한 부정적인 의견을 표명했습니다. 이들은 Rust 포트가 열등하고, 상당한 인적 및 재정적 자원을 소비하며, 기존 유지 관리자에게 자금을 지원하는 것에 비해 노력 낭비라고 주장합니다. 그들은 트윗에서 빈정거리고 비꼬는 듯한 언어를 사용합니다.

• FFmpeg의 어조에 대한 비판: 많은 사용자들은 FFmpeg의 트위터 "성격"이 짜증나고 유해하다고 생각합니다. FFmpeg의 훌륭한 작업을 인정하면서도, 일부는 그들의 태도가 잠재적 자금 지원자들을 단념시킬 수 있다고 제안합니다.

• Rust 포트의 동기: Rust 포트, 특히 rav1d의 원동력은 종종 기존 C 구현에 비해 보안 이점(Rust의 메모리 안전 기능)과 관련이 있으며, 초기 성능 절충이 있을 수 있습니다.

• 성능 비교: FFmpeg은 Rust 포트가 열등하다고 주장하지만, 일부 벤치마크(예: rav1d 이슈 트래커의 벤치마크)는 멀티스레드 시나리오에서 플랫폼 전반에 걸쳐 성능 차이가 크지 않음을 보여줍니다.

코덱 및 일반적인 성능

• "버퍼 제로화" 최적화: 이 글은 불필요한 버퍼 제로 초기화를 피하는 것과 관련된 최적화에 대해 논의합니다. 컴파일러는 개별 배열 인덱스를 추적하지 않으면 제로화가 쓸모없다는 것을 증명하기 어렵기 때문에 이는 일반적인 성능 병목 현상입니다.

• AV1의 장점: AV1은 H.265와 유사하거나 더 나은 성능을 가진 훌륭하고 무료 코덱으로 강조됩니다. 특히 고해상도에서 더욱 그렇습니다. 주요 단점은 아직 보편적이지 않은 하드웨어 디코딩 지원입니다.

• 코덱 메모리 관리: 논의는 비디오 코덱이 동적 상태를 관리하는 방식을 심층적으로 다룹니다. 동적 메모리 할당이 사용되지만, 코덱은 하드웨어 디코더를 염두에 두고 설계되었으므로 메모리 요구 사항은 종종 "레벨" 및 프로필 사양에 의해 제한됩니다. 성능을 위해 힙 할당을 최소화하는 것이 목표이지만, 완전히 제거하면 지나치게 복잡한 정적 데이터 구조가 될 수 있습니다.

• "장면" 및 코덱 채택: "장면"(불법 복제 콘텐츠를 릴리스하는 그룹) 내에서 AV1과 같은 새 코덱의 채택은 실제 사용 및 하드웨어 가속의 척도로 논의됩니다. AV1이 릴리스에서 나타나고 있지만, 아직 보편적인 하드웨어 인코딩 및 디코딩 지원 부족으로 인해 지배적이지는 않습니다.

일반적인 관찰

• 상세한 최적화 이야기의 가치: 커뮤니티는 최적화 노력, 단계별 개선 및 프로파일링 결과를 자세히 설명하는 심층적인 기사를 높이 평가합니다.

• 컴파일러 작성의 복잡성: u16 비교 문제는 컴파일러 개발의 내재된 복잡성과 모든 시나리오에 대해 최적의 코드를 생성하는 데 따르는 어려움을 강조합니다.

  
  

  
  

이 Hacker News 스레드는 dav1d 비디오 디코더의 원본 C 구현 성능 향상에 초점을 맞추고 있으며, 특히 Rust 포트인 rav1d와의 비교를 통해 나타나는 논쟁을 보여줍니다. 주요 내용은 다음과 같습니다.

rav1d와 dav1d 간의 논쟁 및 감정

• 비난의 어조: 일부 사용자들은 이 글의 저자(및 VideoLAN 관계자들)가 rav1d/Rust에 대해 "강한 비난"과 "이상하게 공격적인" 어조를 보인다고 지적합니다. 이는 단순히 "어떤 언어가 더 빠른가"에 대한 건전한 경쟁을 넘어선 감정적인 문제로 보입니다.

• 자금 조달 문제: VideoLAN 측에서 rav1d에 대한 비난을 퍼붓는 주요 이유 중 하나는 기존 dav1d 프로젝트에서 Rust 노력으로 자금이 유용되었다는 인식 때문입니다. 이는 오픈 소스 커뮤니티 내의 "게이트키핑"이나 "질투"로 비춰질 수 있습니다.

• 어셈블리 코드 복사: rav1d가 "Rust는 C만큼 빠르다"고 주장하는 반면, 실제 성능 개선 노력의 대부분이 dav1d에서 그대로 복사된 어셈블리 코드 부분에서 나왔다는 주장이 제기됩니다. dav1d 코드의 85% 이상이 수기로 작성된 어셈블리 코드이며, rav1d는 이를 unsafe 블록을 통해 그대로 사용합니다. 이는 "메모리 안전성"이라는 rav1d의 핵심 주장과 모순된다는 비판이 있습니다.

• 벤치마크 논쟁:

  • rav1d가 dav1d보다 "겨우 5% 느리다"는 주장에 대해 일부 dav1d 팀원은 단일 코어에서 6% 느리고 멀티 코어에서는 35%까지 느리다는 벤치마크 결과를 공유하며 반박했습니다.

  • rav1d 프로젝트 측은 8코어 벤치마크에서 ARM 플랫폼에서 약 8-10% 느리다고 주장합니다.

  • 최근 벤치마크 결과는 rav1d가 특정 Netflix 테스트 시퀀스를 디코딩하는 데 약 6.2% 느리며, 이는 이전 10.4%에서 개선된 수치임을 보여줍니다.

• dav1d 개선사항의 지속적인 백포팅: dav1d에서 발생하는 개선사항이 rav1d로 지속적으로 백포팅되어야 한다는 점(이미 82개의 PR이 백포팅됨)은 rav1d가 "기생적"이라는 비판으로 이어집니다. 누가 이 유지보수 비용을 계속 지불할 것인가에 대한 의문이 제기됩니다.

기술적 논의 및 최적화

• #[repr(C)] 및 구조체 레이아웃: Rust는 #[repr(C)]를 사용하여 C와 동일한 메모리 레이아웃을 가지도록 구조체를 정의할 수 있으며, rav1d가 이를 활용하여 dav1d의 C 코드에서 파생된 비트 복사 작업을 가능하게 합니다. 이러한 최적화는 rav1d에도 적용되어 두 프로젝트의 성능을 향상시킬 수 있습니다.

• 버퍼 제로화 방지: rav1d의 성능 개선 중 하나는 불필요한 버퍼 제로 초기화를 피하는 것입니다. std::mem::MaybeUninit와 같은 Rust 기능을 사용하여 이 초기화 단계를 제거할 수 있습니다.

• 컴파일러 최적화의 한계:

  • -O3 또는 -Ofast와 같은 컴파일러 플래그가 모든 최적화를 "프로그래머를 위해" 수행하지는 않습니다.

  • dav1d 기여자는 최적화 후 1-3%의 성능 향상을 주장하며, 이는 rav1d가 벤치마크 결과를 따라잡기 어렵게 만듭니다.

• Rust가 C보다 빠를 수 있는가?

  • 이론적으로 Rust가 C보다 빠를 수 있는지에 대한 질문이 제기됩니다.

  • 현재 단계에서는 rav1d가 dav1d보다 느리지만, 많은 사람들은 메모리 안전성과 버그 클래스 제거를 위해 1-3%의 성능 손실을 감수할 가치가 있다고 봅니다.

  • 보안 기술 부채를 해결하기 위해 가장 안전한 코드를 사용하는 것이 현재의 "정치적 환경"에서 중요하다고 언급됩니다.

rav1d의 목적 및 미래

• rav1d가 성능이 뛰어난 인코더를 관용적인 Rust로 작성하는 것이 가능하다는 것을 보여주기 위한 "연구" 또는 "재미있는 사이드 프로젝트"로 간주되어야 하는지에 대한 논의가 있습니다.

• rav1d가 dav1d에 필적하는 성능을 달성하더라도, dav1d의 지속적인 유지보수와 신속한 버그 수정(일반적으로 24시간 이내)을 고려할 때, 누가 dav1d 대신 rav1d를 실제로 채택할 것인지에 대한 의문이 제기됩니다. rav1d 개발자들이 Rust 전문가이지만 코덱 전문가가 아니라는 점도 이러한 의문에 기여합니다.

결론적으로, 이 논의는 dav1d와 rav1d 프로젝트 간의 기술적인 성능 비교뿐만 아니라, 언어 선택, 오픈 소스 프로젝트의 자금 조달, 커뮤니티 간의 경쟁, 그리고 메모리 안전성과 성능 간의 절충에 대한 더 넓은 관점을 포함하고 있습니다.

기생 논란, 지적 정직성 논란에 대해 제미니가 아무말 없길래 직접 물어봤습니다.

(구글 제미니가 논란을 의식해서 의도적으로 기생 논란, 지적 정직성 논란을 소개하지 않은 듯해요)

기생 논란, 지적 정직성 논란은?

두 번째 Hacker News 스레드에서 rav1d가 "기생적"이라는 논란과 관련된 "지적 정직성" 논란이 언급됩니다. 해당 내용은 다음과 같습니다.

"기생 논란"

• hulitu 사용자의 주장: hulitu라는 사용자는 rav1d가 dav1d의 개선 사항을 지속적으로 백포팅해야 한다는 점을 지적하며, "기본적으로 작업은 dav1d에서 이루어지지만, rav1d에서 주장된다"고 말합니다. 그리고는 "정말 Rust를 기생충처럼 보이게 한다"고 직접적으로 언급합니다.

• 배경: 이 주장의 근거는 rav1d가 dav1d의 핵심 성능 최적화 부분인 어셈블리 코드를 "그대로" 복사하여 사용한다는 점입니다. 즉, rav1d가 C에서 Rust로 전환되었음에도 불구하고, 가장 성능이 중요한 부분은 dav1d의 원본 어셈블리 코드를 unsafe 블록을 통해 그대로 호출하고 있다는 것입니다. dav1d 개발자들이 해당 어셈블리 코드의 최적화를 지속적으로 수행하고, 이 개선 사항이 rav1d로 "백포팅"될 때마다 rav1d도 성능 향상을 얻게 됩니다. hulitu는 이러한 상황을 "dav1d가 일하고 rav1d가 성과를 가져가는" 기생적인 관계로 묘사하는 것입니다.

"지적 정직성 논란"

"지적 정직성 논란"이라는 표현이 직접적으로 사용되지는 않지만, 이 논란의 본질은 다음과 같은 비판에 기반하고 있습니다.

• hitekker 사용자의 주장: hitekker는 "rav1d가 Rust가 (거의) C만큼 빠르다고 주장하는 반면, 모든 성능 공학적 노력은 dav1d에서 그대로 복사된 ASM 비트에서 나왔다는 점을 언급해야 한다"고 주장합니다. 또한, "rav1d 옹호자들이 벤치마크를 조작하고 실제 코드가 얼마나 안전하지 않은지 모호하게 만들고 있다"며, "memorysafety.org에 이것을 '안전하다'고 제시하는 현상금은 웃기다"고 말합니다.

• 논란의 핵심:

  • 벤치마크 투명성 부족: rav1d 측의 벤치마크 결과가 실제 성능 격차를 충분히 반영하지 않거나, 비교 방식이 불공정하다는 의혹이 있습니다. (예: dav1d 팀원이 단일 코어에서 6%, 멀티 코어에서 35% 느리다고 주장하는 벤치마크 결과와 rav1d 측의 8-10% 느리다는 주장의 차이).

  • "메모리 안전성" 주장의 모호성: Rust의 핵심 장점은 "메모리 안전성"인데, rav1d가 dav1d의 어셈블리 코드를 unsafe 블록을 통해 그대로 사용한다면, 이 부분이 Rust의 안전성 보장 영역 밖에 놓이게 됩니다. 그럼에도 불구하고 rav1d 프로젝트가 마치 전체가 Rust의 메모리 안전성 이점을 누리는 것처럼 홍보된다는 점에서 "지적 정직성" 문제가 제기될 수 있습니다. hitekker의 말처럼 "memorysafety.org에 안전하다고 제시하는 현상금은 웃기다"는 표현은 이러한 비판을 담고 있습니다.

요약하자면, rav1d가 dav1d의 핵심 최적화 코드를 재활용하면서 성능 개선을 주장하고, 동시에 Rust의 메모리 안전성을 강조하는 방식이 일부 dav1d 개발자 및 커뮤니티 구성원들에게 "기생적"이며 "지적으로 정직하지 못하다"는 비판을 받고 있는 상황입니다.

--------------

러스트 커뮤의 나르시시즘적 행태에 관련 개발자들이 분노한거죠.

ㅎㅎ

그거를 숨기는거에요. 러스트 빠돌이들이.

"지적 정직성"

참 중요하게 다가오는군요.