Anukari 개발자의 Apple에 보내는 기술적 호소문

• Anukari는 실시간 3D 물리 신시사이저라 대규모 spring-mass 모델을 GPU에서 계산해야 하지만, Apple silicon macOS에서 GPU 클록이 충분히 오르지 않으면 오디오 지연 조건을 맞추기 어려움
• DAW가 오디오 버퍼 블록마다 플러그인을 호출하는 구조와 macOS의 전력 관리 휴리스틱이 맞물리며, GPU가 블록 사이에 쉬는 것처럼 보여 낮은 성능 상태에 머물 수 있음
• Xcode Instruments의 Metal profiler에서 Performance State를 Maximum으로 두면 정상 동작하고 Minimum에서는 크게 나빠져, 병목의 핵심이 GPU 클록 속도임을 확인함
• 현재는 작은 spin kernel로 GPU 부하를 인위적으로 높이는 “waste makes haste” 우회책을 쓰지만, 일부 Pro/Max Apple 하드웨어에서는 여전히 문제가 남아 있음
• 개발자는 Apple Metal 팀에 Audio Workgroup의 GPU 확장, MTLCommandQueue의 실시간 민감도 옵션, 또는 기존 해결책 안내를 요청하며 Windows에서는 같은 spin loop가 필요 없다고 봄

---

Anukari가 겪는 macOS GPU 성능 문제

• Anukari 3D Physics Synthesizer는 오디오 생성을 위해 대규모 spring-mass 물리 모델을 실시간으로 시뮬레이션함
• 비중 있는 수의 물리 객체를 지원하려면 GPU가 필요하며, 물리 코드는 메모리보다 ALU 병목에 가까움
• 시뮬레이션의 변경 가능한 상태는 GPU의 threadgroup memory에 저장됨
  • 수동 할당 L1 캐시에 가까운 구조라 매우 빠름
• 일반적인 사용 방식은 Pro Tools, Ableton 같은 DAW 안에서 AU 또는 VST3 플러그인으로 실행되는 형태임
  • DAW는 오디오 버퍼 블록마다 Anukari를 호출함
  • Anukari는 각 블록마다 GPU 물리 시뮬레이션 커널을 실행하고 결과를 기다린 뒤 반환함
• 오디오 버퍼 블록은 GPU 커널 스케줄링 지연을 여러 샘플에 나눠 흡수할 수 있지만, 커널 자체 실행 시간은 여전히 결정적임

macOS 전력 관리와 실시간 오디오의 충돌

• Apple silicon은 전력 절감을 위해 칩의 클록 속도를 낮출 수 있고, macOS는 처리 수요가 낮다고 판단하면 낮은 클록을 유지함
• Anukari의 DAW 내 실행 방식은 macOS가 GPU 수요를 판단하는 방식과 잘 맞지 않음
• GPU는 오디오 버퍼 블록 사이에 유휴 상태가 되므로, 평균 부하가 예컨대 60% 정도로만 보일 수 있음
  • macOS의 실제 휴리스틱은 알 수 없지만 load average 같은 방식일 수 있다고 추정함
  • 이 부하가 GPU 클록 상승 기준을 넘지 못할 수 있음
• Anukari는 실시간 제약을 맞추기 위해 낮은 지연이 필요하고, 이를 위해 높은 GPU 클록이 필요함
• Apple GPU 클록이 얼마나 낮아질 수 있는지는 알 수 없지만, Anukari를 사용할 수 없게 만들 정도로 낮아질 수 있음

Metal profiler로 확인한 클록 문제

• Xcode에 포함된 Apple Instruments의 Metal profiler로 Anukari가 ALU-bound임을 확인함
• Metal profiler는 프로파일링 중 Metal “Performance State”를 선택할 수 있음
  • 이 설정은 profiler 밖에서는 구성할 수 없음
• Maximum performance state에서는 Anukari가 완벽하게 동작함
• Minimum performance state에서는 동작이 크게 나빠짐
• 두 상태의 차이 때문에 GPU 클록 속도가 Anukari 성능 문제의 핵심으로 드러남

“waste makes haste” 우회책과 한계

• macOS가 필요한 시점에 GPU 클록을 올려주지 않기 때문에, Anukari는 별도의 우회책을 사용함
• 오디오 계산 GPU 작업과 병렬로 두 번째 GPU 작업을 실행해 높은 평균 부하를 만들고 macOS가 클록을 올리도록 유도함
  • 이 작업은 가능한 적은 GPU 자원을 쓰면서도 클록 휴리스틱을 자극하도록 조정됨
  • 실질적으로 GPU를 데우는 spin loop임
• 이 전략은 “waste makes haste”라고 부르며, 관련 devlog에 상세히 기록되어 있음
• 개발자의 MacBook M1에서는 이 방식이 문제를 완전히 해결했고 Anukari가 안정적으로 실행됨
• 하지만 Anukari Beta 출시 후 일부 macOS 사용자에게 문제가 발생함
  • 특히 Pro 또는 Max Apple 하드웨어 사용자에게 성능 문제가 많아 보임
  • 글에서는 GPU chiplet별 독립 클록 가능성, 더 강력한 GPU에서는 spin workload가 너무 보수적일 가능성을 가설로 듦

Apple에 요청하는 해결 방향

• Apple 엔지니어가 더 잘 알 것이라는 전제에서 몇 가지 가능한 해결책을 제안함
• Solution 1: Audio Workgroup 개념을 GPU 처리까지 확장함
  • macOS의 오디오 처리는 Audio Workgroup이라는 스레드 또는 스레드 그룹에서 수행됨
  • OS는 이 스레드들이 실시간 제약을 가진다는 점을 이해하고 우선순위를 부여함
  • Audio Workgroup 스레드가 관리하는 MTLCommandQueue를 실시간 처리로 간주해 GPU 클록을 조정할 수 있음
• Solution 2: Metal API의 MTLCommandQueue에 실시간 민감도를 표시하는 옵션을 제공함
  • 해당 queue를 처리하는 GPU chiplet의 클록을 그에 맞춰 조정할 수 있음
• Solution 3: 이미 원하는 기능을 얻는 방법이 있다면 Apple이 알려주는 것만으로도 충분함
• 글 상단에는 Apple이 연락해 왔으며 관련 내용은 별도 글에 있다고 덧붙어 있음

Game Mode와 Windows 비교

• Apple의 Game Mode는 Anukari가 필요한 것과 비슷해 보이지만 적용하기 어려움
  • Game Mode는 프로세스 단위임
  • Anukari는 대부분 다른 프로세스 안의 플러그인으로 쓰이며, 해당 프로세스는 Game Mode를 지원하지 않음
  • Anukari가 이를 직접 제어할 수 없음
  • Game Mode는 fullscreen도 요구하지만 Anukari는 보통 fullscreen이 아님
• Windows에서는 이 문제가 발생하지 않음
  • Windows가 사용자에게 성능 상태 제어를 더 많이 주기 때문인지, NVIDIA 드라이버가 전력 소비에 덜 신중한 것인지는 알 수 없음
  • Windows에서는 spin loop가 필요 없음
• 성능이 약한 GPU를 가진 Windows PC는 Anukari를 잘 실행하는 반면, 고가의 Mac M4 Max에서는 stutter가 발생할 수 있다고 비교함

파이프라이닝이 맞지 않는 이유

• GPU 코드를 파이프라인화해 GPU를 포화시키는 방식은 처리량 중심 작업에는 적합하지만, Anukari는 지연 민감 작업임
• 여러 물리 시뮬레이션 커널을 미리 스케줄링하면 GPU가 현재 오디오 블록을 처리하는 동안 CPU가 다음 블록을 준비할 수 있음
• 하지만 파이프라이닝은 처리량을 높이는 대신 지연을 늘림
• Anukari의 각 커널 실행은 마이크 입력 같은 실시간 오디오 입력 데이터에 접근해야 함
• 다음 오디오 블록을 미리 처리하는 speculative execution은 필요한 입력 데이터가 없어서 사용할 수 없음

spin kernel을 같은 MTLCommandQueue에 넣는 방식의 문제

• spin kernel과 physics kernel이 서로 다른 GPU chiplet에서 실행되는 것이 실제 원인이라면, 같은 MTLCommandQueue에 넣는 방법이 해결책처럼 보일 수 있음
• 실제로 이 방법을 시도했지만 동작하지 않았음
• 이유는 Anukari가 지연 민감 작업이기 때문임
  • spin kernel이 가끔 조금 오래 실행됨
  • 그 시간이 physics kernel 실행 시간에 침범함
• 작은 spin kernel과 volatile unified memory를 이용해 CPU가 “exit kernel early” 플래그를 쓰는 방식도 실험함
• 이런 장치에도 spin kernel이 physics kernel 시간을 침범하는 경우가 생김

GPU kernel hedging이 어려운 이유

• 분산 시스템의 request hedging처럼 물리 커널을 여러 복사본으로 실행하고 가장 먼저 끝난 결과를 쓰는 방식도 검토함
• 이 방식은 꼬리 지연과 지연 분산을 줄이고, 동시에 GPU 부하를 만들어 OS가 성능 상태를 올리도록 유도할 수 있음
• 하지만 Anukari에는 여러 문제가 있음
  • 한 physics kernel이 오디오 블록 주기 하나보다 오래 걸리면 해당 커널 스트림이 뒤처짐
  • 뒤처진 커널 스트림은 미래 블록에서 따라잡아야 하며, 다른 스트림의 내부 상태를 복사하는 fast-forward가 필요함
• 내부 상태 복사는 비쌈
  • 가장 큰 내부 상태는 delay line용 오디오 버퍼임
  • 마이크마다 1초의 과거 오디오를 저장함
  • 크기는 48,000 samples * 50 mics * 2 channels * 16 voices * 4 bytes로 307MB임
  • 더 높은 sample rate에서는 더 커짐
• 효율적으로 처리하려면 각 hedged kernel stream의 dirty 영역을 정밀하게 추적하고 그 부분만 복사해야 함
  • 하지만 버퍼 메모리 배치는 physics kernel의 읽기 workload에 맞게 최적화되어 있음
  • 최소한만 복사해도 전체 버퍼에 흩어진 영역을 복사하게 되어 느림
• 사용자 모델 변경도 모든 hedged kernel에 전파해야 함
• physics kernel은 “waste makes haste” spin kernel보다 GPU footprint가 훨씬 큼
  • hedging은 더 많은 불필요한 GPU 부하를 만들고, 병렬로 실행 가능한 Anukari 인스턴스 수를 줄일 수 있음
  • hedge kernel끼리 경쟁해 모두 느려질 수도 있음

이미 수행한 최적화와 GPU가 필요한 이유

• Anukari 시뮬레이션은 ALU-bound라서 메모리 접근 패턴 개선 같은 일반적인 최적화 여지가 크지 않음
• 성능을 높이려면 산술 처리량을 최적화해야 함
  • 가능한 곳에서는 FP16 연산을 사용해 Apple ALU를 더 잘 포화시킴
  • micro-benchmark를 사용해 명령어 순서를 조정함
  • 모든 물리 상태를 L1 memory에 둠
  • vectorization을 위해 load 순서를 재배치함
• Apple SIMD-group의 스레드들이 대체로 instruction pointer를 공유한다는 점도 활용함
  • 서로 다른 물리 객체는 branch path가 크게 갈라짐
  • 한 SIMD-group 안에서 두 종류의 객체를 시뮬레이션하면 instruction masking 때문에 느려짐
  • 이를 피하려고 물리 객체의 메모리 배치를 동적으로 최적화해 SIMD-group 안에서 실행되는 객체 타입 수를 줄임
  • 이 최적화는 the new warp alignment optimizer에 자세히 정리되어 있음
• 추가 산술 최적화 여지는 있지만 한 자릿수 퍼센트포인트 수준의 개선에 그칠 것으로 봄
• 강력한 머신에서 Anukari는 768~1024개 물리 객체를 시뮬레이션할 수 있음
  • 각 객체는 다른 객체와 임의로 연결될 수 있음
  • 객체는 보통 초당 48,000 샘플의 오디오 sample rate로 implicit Euler integration을 수행함
  • 각 객체는 3~10개의 동작 파라미터를 가짐
  • 일부 동작에는 vector rotation, exp(), log() 같은 비싼 연산이 포함됨
  • polyphony를 위해 전체 물리 시뮬레이션을 최대 16개 병렬 복사본으로 실행함
• CPU로는 이 방식이 가능하지 않았으며, GPU의 많은 ALU, L1 cache layout 제어, threadgroup_barrier 같은 동시성 구조가 필요함
• Anukari는 GPU 처리 없이는 존재할 수 없음

GPU Audio API가 해결책이 아닌 이유

• GPU Audio의 CEO Alexander Talashov는 Anukari가 GPU Audio API를 쓰면 문제가 해결될 수 있다고 말해 왔음
• 개발자는 GPU Audio를 좋은 제품으로 평가하고, GPU를 DSP에 접근 가능하게 만드는 제품이라고 소개함
• 하지만 Anukari에는 GPU Audio가 유용하지 않다고 판단함
• Anukari는 전통적인 DSP 애플리케이션과 달리 수치 미분방정식 적분기에 가까움
  • DSP 일부가 있긴 하지만 대부분의 계산은 Eulerian integration임
  • 물리 세계의 마이크 압축 같은 DSP는 GPU의 물리 계산 안에서 inline으로 처리됨
• Anukari는 Metal의 낮은 계층에서 GPU를 직접 프로그래밍하고 있음
• 필요한 것은 Apple이 GPU 클록 속도를 안정적으로 올려주는 것임

[GN⁺]

Hacker News 의견들

• 제 Show HN 글에서 Anukari를 보신 분도 있을 듯함: https://news.ycombinator.com/item?id=43873074

  그 스레드에서 macOS 성능 얘기가 나왔음. Anukari는 기본형 M1을 포함해 Apple silicon 대부분에서 잘 돌아가고, 제 테스트도 전부 기본 M1에서 했는데 훌륭했음. 하드웨어는 정말 대단함

  다만 작동시키려면, 오디오 처리가 충분히 빨라지도록 macOS가 GPU 클럭 속도를 올리게 만드는 괴상한 우회책을 구현해야 했음. macOS가 GPU 성능 상태를 정하는 일반 휴리스틱은 Anukari의 특이한 작업부하를 이해하지 못함

  그래서 결국 전체 상황을 지나치게 자세히 정리했고, Apple에서 적절한 사람, 아마 Metal API 쪽 담당자와 연결될 수 있게 도움을 구하고 싶었음. 도와주세요 :)

  • “아주 길고 매우 기술적인 글”이라고 했지만, 끝까지 읽어보니 너무 길지도 않고 매우 명확하고 잘 쓴 글이었고 유익했음. 글 잘 썼음

    Mac을 가져본 적이 없고 제 PC도 오래되어 제대로 된 GPU가 없어서 Anukari를 당장 써볼 가능성은 낮지만, 정말 멋져 보여서 아쉬움. 빨리 해결되길 바람

  • 이 권한(entitlement)은 시도해봤는지 궁금함: https://developer.apple.com/documentation/bundleresources/en...

    com.apple.developer.sustained-execution이 반대 방향으로도 동작하는지 궁금함

  • 흥미로운 글이고 문제도 흥미로움. 같은 큐에서 작업을 실행하는 아이디어가 실패하는 이유도 결국 원래 문제와 같은 이유 아닐까 싶음. 가변 클럭 속도 때문에 정밀한 스케줄링이 불가능하고, 운영체제가 GPU 클럭을 어떻게 잡았는지에 따라 스핀 정지 시점이 이상적인 시점과 어긋나 aliasing이 생기는 식임

    그렇다면 스핀 작업이 GPU를 최고 클럭으로 올릴 만큼 충분히 복잡하지 않은 것일 수도 있음. 정말 최고 성능으로 돌고 있다면 소프트웨어 PLL을 추가하지 않아도 스핀 종료 시점을 안정적으로 맞출 수 있어야 함. 스핀이 어떻게 구현됐는지 자세한 설명은 못 봤지만, GPU의 더 많은 부분을 꾸준히 몰아붙이는 더 충실한 스핀 루프가 클럭을 최고 성능으로 유지하는 데 더 효과적일 듯함

  • Show HN은 놓쳤지만, 보자마자 창의적인 ASMR 사운드스케이프와 몰입형 다차원 오디오에 잘 어울리겠다는 생각이 들었음. 당신이나 사용자 중 누군가 데모를 만들어주면 좋겠음. 프로젝트 축하하고 Apple 관련 문제도 도움받길 바람

  • 글이 좋았고 설명이 명확해서 이해하기 쉬웠음. 다른 맥락에서도 설명한 것과 같은 문제를 분명히 겪어본 적 있음

• 여러분, 효과가 있었음. Metal 팀의 딱 맞는 사람과 아주 생산적인 대화를 나눴음! Apple의 관심을 끌 수 있게 도와줘서 고마움. 이렇게 많은 지원을 전혀 예상하지 못했음

  https://anukari.com/blog/devlog/productive-conversation-appl...

  • 지금 우회책이 생긴 건 좋지만, 그 우회책이 무엇인지조차 공유할 수 없다는 사실이 아이러니하게도 Apple의 소통 방식에 대한 https://news.ycombinator.com/item?id=43904921 마지막 문장을 그대로 보여줌

    “이 값을 이렇게 설정했다가 저렇게 바꾸면 동작한다. 문서화는 안 됐지만 이제 알았죠” 같은 식임

    우회책을 구현할 때, 비슷하게 지연 시간에 민감한 GPU 제약을 겪는 다른 사람들이 디스어셈블리로라도 마법 주문의 실마리를 찾을 수 있게 노골적인 이름의 함수에 넣어둘 수 있으면 좋겠음

  • HN이 다시 한 번 본래 목적을 달성했음. 대기업 고객지원 앞에 놓인 관료적 장벽을 뚫는 것임

    프로젝트 축하하고 행운을 빔

• Apple App Store에서 매우 유명한 앱을 가진 두 유명 회사에서 일해봤음

  우리가 얘기했던 Apple 팀은 우리의 문제에는 전혀 관심이 없었고, 대신 WWDC에서 발표할 최신 기능을 논의하자며 자주 사무실로 초대해서 그 기능 지원을 사실상 강요했음. 그게 그들과의 관계의 시작이자 끝이었음. 버그 많은 Apple 소프트웨어가 왜 동작하지 않는지 알아내려면 기술 지원 티켓을 써야만 했음

  Apple의 개발자 관계 담당자들은 진지한 사람들이 아님

  • 위에서 원글이 보여주듯 내 경험이 일반 규칙은 아니라서 다행임. 하지만 약 10년 전 꽤 유명한 앱을 가진 회사에서 일했을 때, 한 업데이트가 앱 성능을 완전히 망가뜨렸음

    정확히 같은 시점에 경쟁사가 성능 문제가 없는 앱을 출시했음. 알고 보니 그 경쟁 앱 개발자가 얼마 전 Apple을 떠난 사람이었고, Apple의 비디오 드라이버에 문서화되지 않은 함정을 남겨서 우리 앱이 깨졌던 것임. 경쟁사 바이너리를 디스어셈블해서야 문서화되지 않은 변경을 찾아 앱을 고칠 수 있었음. 그 개발자는 우리 CEO에게 이메일로 조롱까지 했음. 참 멋진 세상임

• Metal 프로파일러에는 애플리케이션을 프로파일링하는 동안 Metal 성능 상태를 선택할 수 있는 매우 유용한 기능이 있음. 프로파일러 밖에서는 설정할 수 없음

  이걸 보면 비공개 API가 있을 것 같음. 역공학으로 가는 편이 더 쉬울 수도 있지 않을까? 물론 SIP를 끄지 않고는 우회할 수 없는 특수 권한이 필요해지는 경우가 아니라면

  • 이건 반드시 비공개 API가 있어야 함. 글에도 이렇게 나옴

    “Metal 프로파일러에는 애플리케이션을 프로파일링하는 동안 Metal ‘Performance State’를 선택할 수 있는 매우 유용한 기능이 있음. 프로파일러 밖에서는 설정할 수 없음”

    비공개 API가 아니라면 Metal 프로파일러가 어떻게 그걸 할 수 있겠음? 어떤 디버깅 도구로 프로파일러를 관찰해서 내부에서 무슨 일이 일어나는지 알아낼 수 있지 않을까?

• 이 API를 공개할 때의 문제는 너무 많은 개발자가 항상 최고 성능 상태를 강제로 켜둘 거라는 점임. API를 제공하면서 그걸 막을 좋은 방법이 정말 있는지는 모르겠음

  • 배터리 구동 기기에서 앱 하나가 전력을 낭비하는 방법은 이미 끝없이 많음. 결국 이미 개발자들이 의도적으로든 실수로든 에너지 집약적인 작업을 불필요하게 돌리지 않기를 믿는 구조임. 적절히 쓰지 않으면 전력을 낭비할 수 있는 API가 하나 더 생긴다고 해서 크게 달라지지는 않음

  • 글에서는 게임 모드도 다루는데, 최신 Apple 운영체제에서 이런 경우에 맞게 최적화된 기능임. 게임 모드가 켜지면 알림이 뜨고, 대부분의 애플리케이션은 그걸 원치 않을 것임. 지금까지는 이걸 남용하는 사례를 본 적 없음

  • 개발자들이 아직은 모든 스레드 풀에 오디오 워크그룹을 남용해서 P-core 스케줄링과 높은 우선순위를 얻고 있지는 않음. 그렇다면 오디오 워크그룹이 GPU에 명령을 발행할 때, 마지막으로 워크그룹이 데이터를 보낸 시점을 기준으로 GPU 다운클럭에 일종의 타임아웃을 둘 수 있음을 시사함

    GPU 오디오는 요즘 매우 틈새 분야지만, 본문에 언급된 회사가 최근 SDK를 공개했으니 더 대중화될 수도 있음. 그래도 납득은 잘 안 감. GPU에서 처리한다는 건 지연 시간은 신경 쓰지 않겠다는 뜻에 가깝기 때문에, 그냥 입출력 버퍼 크기를 늘리면 된다고 봄

  • API를 남용하더라도, 같은 일을 하려고 가짜 바쁜 작업을 돌리는 것보다는 더 효율적일 것임. 앱들은 이미 API 없이도, 또는 API가 요구할 수 있는 권한 없이도 그렇게 할 수 있음

  • 수동 권한 부여는 어떨까? 어딘가 숨겨두더라도, 아주 틈새 앱에는 필요할 가능성이 큼

    그리고 운영체제 수준에서 Zoom, Teams, 웹 브라우저는 기본 거부로 두면 됨 :)

• 이걸 하는 가장 좋은 방법:

  1. WWDC 영상을 훑어보고, 지금 맞닥뜨린 문제를 가장 잘 아는 것처럼 보이는 엔지니어를 찾기

  2. Michael Thomson이면 [e-mail] 같은 형식으로 직접 이메일 보내기

  • 아니면 그의 형제 Pichael에게 pthomson으로 보내기

• 여담이지만 Anukari는 Mick Gordon 사운드 팩을 내고 수익을 그와 나누면 좋겠음. 그 사람은 정말 미친 듯한 걸 만들고 있고, 데모도 굉장함. 이렇게 강력한 도구가 생겼다면 아티스트와 협업하는 건 좋은 비즈니스이고 세상에도 좋음. Mick Gordon을 좋아한다면 말인데, 나는 좋아함

• 이 앱이 전혀 필요하진 않지만 정말 멋짐. 이런 앱들이 컴퓨팅에 재미를 다시 가져옴. 지금 재미가 전혀 없다는 뜻은 아니고, 더 그래픽적이고 실험적인 프로그램들이 떠돌던 옛날, 심지어 데모신까지 떠올리게 함

• 끝에서 두 번째 문단에 들어간 https://x.com/Mick_Gordon/status/1918146487948919222 링크를 놓치지 말아야 함. Mick Gordon이 만든 데모이고, @anukarimusic는 이렇게 답했음

  “ㅋㅋ 출시 둘째 날인데, 제가 2년 동안 매일 쓰며 만든 모든 데모를 이미 완전히 박살냈네요”

• 1024개 객체를 48kHz로 갱신하는 건 코드 작성 방식에 따라 CPU에서도 가능해 보임. 초당 4,800만 번 갱신 아닌가? OpenMP로 몇 개 루프를 코어들에 병렬로 돌리기에 적당해 보임

  • 1. Anukari는 다성(polyphony)을 위해 물리 모델 전체를 최대 16개 복사본으로 돌림. 즉 16 * 1024 * 48K임. 블로그 글을 업데이트해야겠음

    2. 사용자가 객체들을 서로 임의로 연결할 수 있어서, 각 객체는 N개의 다른 엔터티에 대한 연결을 읽고 처리해야 함

    3. CPU 전체를 쓰려면 매 물리 단계마다 코어 간 동기화가 필요하고, 이게 느림

    4. 객체당 처리량이 꽤 큼. 초월함수가 많고 근사도 가능하지만, 기능 자체도 많음. 모든 매개변수를 변조할 수 있고, NaN에도 안전해야 하는 등 고려할 게 많음

    5. 사용자는 여러 트랙과 효과 등을 위해 Anukari를 여러 개 병렬로 실행하고 싶어 함

    다른 방식으로 보면 4 GHz / (16 voice * 1024 obj * 4 connections * 48,000 sample) = 1.3 cycles per thing임

    GPU는 이 작업부하를 순식간에 처리함. 완벽하게 맞는 구조임. 16 voice * 1024 obj를 모두 완전히 병렬로 처리할 수 있고, 각 단계의 동기화도 단순하며 사용자가 L1 캐시를 관리할 수 있음

  • 계산이 맞다면 샘플 하나를 계산하는 데 83 클럭 사이클이 나옴. 16코어라면 이론상 1333사이클이고, 그리 많지 않음. CPU를 항상 거의 100%로 쓸 수는 없다는 점을 생각하면 더 그렇다