Seruan Teknis Pengembang Anukari kepada Apple

• Anukari adalah synthesizer fisika 3D real-time yang harus menghitung model spring-mass berskala besar di GPU, tetapi di Apple silicon macOS, jika clock GPU tidak naik cukup tinggi, sulit memenuhi syarat latensi audio
• Struktur DAW yang memanggil plugin pada setiap blok buffer audio berpadu dengan heuristik manajemen daya macOS, sehingga GPU tampak seperti beristirahat di antara blok dan bisa tetap berada pada status performa rendah
• Di Metal profiler Xcode Instruments, saat Performance State diatur ke Maximum, Anukari berjalan normal, sementara pada Minimum performanya memburuk drastis; ini menegaskan bahwa inti bottleneck adalah kecepatan clock GPU
• Saat ini Anukari memakai workaround “waste makes haste” dengan spin kernel kecil untuk menaikkan beban GPU secara artifisial, tetapi pada sebagian perangkat Apple Pro/Max masalahnya masih tersisa
• Pengembang meminta tim Apple Metal untuk memperluas Audio Workgroup ke GPU, menambahkan opsi sensitivitas real-time pada MTLCommandQueue, atau memberi panduan solusi yang sudah ada; mereka menilai di Windows spin loop yang sama tidak diperlukan

---

Masalah performa GPU macOS yang dialami Anukari

• Anukari 3D Physics Synthesizer mensimulasikan model fisika spring-mass berskala besar secara real-time untuk menghasilkan audio
• Untuk mendukung jumlah objek fisika yang signifikan, GPU diperlukan, dan kode fisikanya lebih dekat ke bottleneck ALU daripada bottleneck memori
• State simulasi yang dapat berubah disimpan di threadgroup memory GPU
  • Strukturnya mirip cache L1 yang dialokasikan manual, sehingga sangat cepat
• Pola penggunaan umumnya adalah berjalan sebagai plugin AU atau VST3 di dalam DAW seperti Pro Tools atau Ableton
  • DAW memanggil Anukari pada setiap blok buffer audio
  • Untuk setiap blok, Anukari menjalankan kernel simulasi fisika GPU, menunggu hasilnya, lalu mengembalikan hasil tersebut
• Blok buffer audio dapat menyerap latensi penjadwalan kernel GPU dengan membaginya ke banyak sampel, tetapi waktu eksekusi kernel itu sendiri tetap krusial

Benturan antara manajemen daya macOS dan audio real-time

• Apple silicon dapat menurunkan kecepatan clock chip untuk menghemat daya, dan macOS mempertahankan clock rendah jika menilai kebutuhan pemrosesan rendah
• Cara Anukari berjalan di dalam DAW tidak cocok dengan cara macOS menilai kebutuhan GPU
• Karena GPU menjadi idle di antara blok buffer audio, beban rata-rata bisa terlihat hanya sekitar, misalnya, 60%
  • Heuristik aktual macOS tidak diketahui, tetapi pengembang menduga bisa saja seperti load average
  • Beban ini mungkin tidak melewati ambang untuk menaikkan clock GPU
• Anukari membutuhkan latensi rendah untuk memenuhi batasan real-time, dan untuk itu diperlukan clock GPU yang tinggi
• Tidak diketahui seberapa rendah clock GPU Apple dapat turun, tetapi bisa turun cukup rendah hingga membuat Anukari tidak dapat digunakan

Masalah clock yang dikonfirmasi dengan Metal profiler

• Dengan Metal profiler di Apple Instruments yang disertakan dalam Xcode, pengembang memastikan Anukari bersifat ALU-bound
• Metal profiler memungkinkan pemilihan “Performance State” Metal selama profiling
  • Pengaturan ini tidak dapat dikonfigurasi di luar profiler
• Pada maximum performance state, Anukari berjalan sempurna
• Pada minimum performance state, perilakunya memburuk drastis
• Perbedaan antara kedua state ini menunjukkan bahwa kecepatan clock GPU adalah inti masalah performa Anukari

Workaround “waste makes haste” dan batasannya

• Karena macOS tidak menaikkan clock GPU pada saat dibutuhkan, Anukari menggunakan workaround terpisah
• Anukari menjalankan tugas GPU kedua secara paralel dengan pekerjaan GPU untuk komputasi audio guna membuat beban rata-rata tinggi dan mendorong macOS menaikkan clock
  • Tugas ini disetel agar memakai sumber daya GPU sesedikit mungkin sambil tetap memicu heuristik clock
  • Pada dasarnya ini adalah spin loop yang memanaskan GPU
• Strategi ini disebut “waste makes haste” dan didokumentasikan secara rinci di devlog terkait
• Di MacBook M1 milik pengembang, cara ini sepenuhnya menyelesaikan masalah dan Anukari berjalan stabil
• Namun setelah rilis Anukari Beta, sebagian pengguna macOS mengalami masalah
  • Masalah performa tampaknya banyak muncul terutama pada pengguna perangkat Apple Pro atau Max
  • Tulisan tersebut mengajukan hipotesis seperti kemungkinan clock independen per GPU chiplet, atau kemungkinan bahwa pada GPU yang lebih kuat, spin workload terlalu konservatif

Arah solusi yang diminta kepada Apple

• Dengan asumsi bahwa engineer Apple lebih memahami hal ini, pengembang mengusulkan beberapa kemungkinan solusi
• Solution 1: Memperluas konsep Audio Workgroup hingga mencakup pemrosesan GPU
  • Pemrosesan audio macOS dilakukan pada thread atau kelompok thread yang disebut Audio Workgroup
  • OS memahami bahwa thread-thread ini memiliki batasan real-time dan memberi prioritas
  • MTLCommandQueue yang dikelola oleh thread Audio Workgroup dapat dianggap sebagai pemrosesan real-time, lalu clock GPU disesuaikan
• Solution 2: Menyediakan opsi di MTLCommandQueue pada Metal API untuk menandai sensitivitas real-time
  • Clock GPU chiplet yang memproses queue tersebut dapat disesuaikan berdasarkan penanda itu
• Solution 3: Jika sudah ada cara untuk memperoleh fungsi yang diinginkan, cukup bagi Apple untuk memberi tahu caranya
• Di bagian atas tulisan, disebutkan bahwa Apple telah menghubungi mereka dan pembahasan terkait ada di tulisan terpisah

Perbandingan dengan Game Mode dan Windows

• Game Mode Apple tampak mirip dengan yang dibutuhkan Anukari, tetapi sulit diterapkan
  • Game Mode berlaku per proses
  • Anukari sebagian besar dipakai sebagai plugin di dalam proses lain, dan proses tersebut tidak mendukung Game Mode
  • Anukari tidak dapat mengendalikannya secara langsung
  • Game Mode juga mensyaratkan fullscreen, tetapi Anukari biasanya tidak fullscreen
• Di Windows, masalah ini tidak terjadi
  • Tidak diketahui apakah karena Windows memberi pengguna lebih banyak kontrol atas status performa, atau karena driver NVIDIA kurang berhati-hati soal konsumsi daya
  • Di Windows, spin loop tidak diperlukan
• Tulisan tersebut membandingkan bahwa PC Windows dengan GPU lemah dapat menjalankan Anukari dengan baik, sementara Mac M4 Max yang mahal bisa mengalami stutter

Mengapa pipelining tidak cocok

• Mem-pipeline kode GPU untuk menjenuhkan GPU cocok untuk pekerjaan yang berorientasi throughput, tetapi Anukari adalah pekerjaan yang sensitif terhadap latensi
• Jika beberapa kernel simulasi fisika dijadwalkan lebih awal, CPU dapat menyiapkan blok berikutnya sementara GPU memproses blok audio saat ini
• Namun pipelining meningkatkan latensi sebagai gantinya meningkatkan throughput
• Setiap eksekusi kernel Anukari harus mengakses data input audio real-time seperti input mikrofon
• Speculative execution untuk memproses blok audio berikutnya lebih awal tidak dapat digunakan karena data input yang diperlukan belum tersedia

Masalah memasukkan spin kernel ke MTLCommandQueue yang sama

• Jika penyebab sebenarnya adalah spin kernel dan physics kernel berjalan di GPU chiplet yang berbeda, memasukkannya ke MTLCommandQueue yang sama bisa tampak seperti solusi
• Cara ini sebenarnya sudah dicoba, tetapi tidak berhasil
• Alasannya adalah Anukari merupakan pekerjaan yang sensitif terhadap latensi
  • Spin kernel kadang berjalan sedikit terlalu lama
  • Waktu itu mengganggu waktu eksekusi physics kernel
• Pengembang juga bereksperimen dengan spin kernel kecil dan volatile unified memory, di mana CPU menulis flag “exit kernel early”
• Meski dengan mekanisme seperti ini, masih ada kasus spin kernel mengganggu waktu physics kernel

Mengapa GPU kernel hedging sulit

• Pengembang juga mempertimbangkan pendekatan seperti request hedging pada sistem terdistribusi: menjalankan beberapa salinan physics kernel dan memakai hasil yang selesai paling dulu
• Cara ini dapat mengurangi tail latency dan variasi latensi, sekaligus menciptakan beban GPU agar OS terdorong menaikkan status performa
• Namun untuk Anukari, ada beberapa masalah
  • Jika satu physics kernel memakan waktu lebih lama daripada satu periode blok audio, stream kernel tersebut akan tertinggal
  • Stream kernel yang tertinggal harus mengejar pada blok berikutnya, dan membutuhkan fast-forward dengan menyalin state internal dari stream lain
• Menyalin state internal itu mahal
  • State internal terbesar adalah buffer audio untuk delay line
  • Setiap mikrofon menyimpan audio masa lalu selama 1 detik
  • Ukurannya adalah 48,000 samples * 50 mics * 2 channels * 16 voices * 4 bytes, yaitu 307MB
  • Pada sample rate yang lebih tinggi, ukurannya makin besar
• Agar efisien, wilayah dirty pada setiap hedged kernel stream harus dilacak secara presisi dan hanya bagian itu yang disalin
  • Namun tata letak memori buffer dioptimalkan untuk workload baca physics kernel
  • Bahkan jika hanya menyalin bagian minimal, wilayah yang tersebar di seluruh buffer tetap harus disalin, sehingga lambat
• Perubahan model oleh pengguna juga harus dipropagasikan ke semua hedged kernel
• Physics kernel memiliki GPU footprint yang jauh lebih besar dibanding spin kernel “waste makes haste”
  • Hedging akan membuat lebih banyak beban GPU yang tidak perlu dan dapat mengurangi jumlah instance Anukari yang bisa berjalan paralel
  • Hedge kernel juga bisa saling berebut sumber daya sehingga semuanya melambat

Optimisasi yang sudah dilakukan dan mengapa GPU diperlukan

• Simulasi Anukari bersifat ALU-bound, sehingga peluang optimisasi umum seperti perbaikan pola akses memori tidak besar
• Untuk meningkatkan performa, throughput aritmetika harus dioptimalkan
  • Menggunakan operasi FP16 saat memungkinkan untuk lebih menjenuhkan ALU Apple
  • Menggunakan micro-benchmark untuk menyesuaikan urutan instruksi
  • Menaruh semua state fisika di L1 memory
  • Menata ulang urutan load untuk vectorization
• Pengembang juga memanfaatkan fakta bahwa thread dalam Apple SIMD-group pada umumnya berbagi instruction pointer
  • Objek fisika yang berbeda dapat memiliki branch path yang sangat berbeda
  • Jika dua jenis objek disimulasikan dalam satu SIMD-group, instruction masking membuatnya lambat
  • Untuk menghindari ini, tata letak memori objek fisika dioptimalkan secara dinamis agar jumlah tipe objek yang dijalankan dalam satu SIMD-group berkurang
  • Optimisasi ini dijelaskan secara rinci di the new warp alignment optimizer
• Masih ada peluang optimisasi aritmetika tambahan, tetapi diperkirakan hanya akan memberi peningkatan di kisaran beberapa persen satu digit
• Pada mesin yang kuat, Anukari dapat mensimulasikan 768–1024 objek fisika
  • Setiap objek dapat terhubung secara arbitrer dengan objek lain
  • Objek biasanya melakukan implicit Euler integration pada sample rate audio 48.000 sampel per detik
  • Setiap objek memiliki 3–10 parameter perilaku
  • Beberapa perilaku mencakup operasi mahal seperti vector rotation, exp(), dan log()
  • Untuk polyphony, seluruh simulasi fisika dijalankan hingga 16 salinan paralel
• Pendekatan ini tidak mungkin dilakukan dengan CPU, dan membutuhkan banyak ALU di GPU, kontrol atas layout L1 cache, serta struktur konkurensi seperti threadgroup_barrier
• Anukari tidak dapat ada tanpa pemrosesan GPU

Mengapa GPU Audio API bukan solusi

• CEO GPU Audio, Alexander Talashov, pernah mengatakan bahwa masalah Anukari bisa terselesaikan jika memakai GPU Audio API
• Pengembang menilai GPU Audio sebagai produk yang bagus, dan memperkenalkannya sebagai produk yang membuat GPU dapat diakses untuk DSP
• Namun pengembang menilai GPU Audio tidak berguna untuk Anukari
• Berbeda dari aplikasi DSP tradisional, Anukari lebih dekat ke integrator persamaan diferensial numerik
  • Memang ada sebagian DSP, tetapi sebagian besar komputasinya adalah Eulerian integration
  • DSP seperti kompresi mikrofon di dunia fisika diproses secara inline di dalam komputasi fisika GPU
• Anukari memprogram GPU secara langsung pada layer rendah Metal
• Yang dibutuhkan adalah Apple menaikkan kecepatan clock GPU secara stabil

[GN⁺]

Komentar Hacker News

• Sebagian dari kalian mungkin pernah melihat Anukari dari tulisan Show HN saya: https://news.ycombinator.com/item?id=43873074

  Di thread itu muncul pembahasan soal performa macOS. Anukari berjalan dengan baik di sebagian besar Apple silicon, termasuk M1 model dasar, dan semua pengujian saya juga dilakukan di M1 dasar dengan hasil yang luar biasa. Perangkat kerasnya benar-benar hebat.

  Namun agar bisa berjalan, saya harus menerapkan workaround yang aneh untuk membuat macOS menaikkan kecepatan clock GPU supaya pemrosesan audio cukup cepat. Heuristik umum macOS untuk menentukan status performa GPU tidak memahami workload Anukari yang tidak biasa.

  Jadi akhirnya saya merangkum seluruh situasinya dengan sangat detail, dan ingin meminta bantuan agar bisa terhubung dengan orang yang tepat di Apple, mungkin penanggung jawab Metal API. Mohon bantuannya :)

  • Katanya ini “tulisan sangat panjang dan sangat teknis”, tetapi setelah saya baca sampai akhir, ternyata tidak terlalu panjang, sangat jelas dan ditulis dengan baik, serta informatif. Tulisannya bagus.

    Saya belum pernah punya Mac, dan PC saya juga sudah tua sehingga tidak punya GPU yang layak, jadi kecil kemungkinan saya bisa langsung mencoba Anukari, tetapi ini terlihat sangat keren dan itu membuat saya agak kecewa. Semoga cepat terselesaikan.

  • Saya penasaran apakah entitlement ini sudah dicoba: https://developer.apple.com/documentation/bundleresources/en...

    Saya penasaran apakah com.apple.developer.sustained-execution juga bekerja ke arah sebaliknya.

  • Tulisan yang menarik, dan masalahnya juga menarik. Saya merasa alasan ide menjalankan pekerjaan di queue yang sama gagal pada akhirnya sama dengan masalah aslinya. Karena kecepatan clock yang berubah-ubah, penjadwalan presisi menjadi mustahil, dan bergantung pada bagaimana sistem operasi menetapkan clock GPU, waktu berhentinya spin bisa meleset dari waktu ideal sehingga terjadi aliasing.

    Kalau begitu, mungkin pekerjaan spin tersebut tidak cukup kompleks untuk menaikkan GPU ke clock tertinggi. Jika benar-benar berjalan pada performa maksimum, seharusnya waktu berakhirnya spin bisa distabilkan tanpa perlu menambahkan software PLL. Saya tidak melihat penjelasan rinci tentang bagaimana spin diimplementasikan, tetapi spin loop yang lebih “penuh” dan terus-menerus mendorong lebih banyak bagian GPU tampaknya akan lebih efektif untuk menjaga clock tetap pada performa tertinggi.

  • Saya melewatkan Show HN, tetapi begitu melihatnya, saya langsung berpikir ini akan sangat cocok untuk soundscape ASMR yang kreatif dan audio multidimensi yang imersif. Akan menyenangkan jika Anda atau salah satu pengguna membuat demo. Selamat atas proyeknya, dan semoga mendapatkan bantuan untuk masalah terkait Apple.

  • Tulisannya bagus dan penjelasannya jelas sehingga mudah dipahami. Saya jelas pernah mengalami masalah seperti yang dijelaskan, meski dalam konteks lain.

• Teman-teman, ini berhasil. Saya melakukan percakapan yang sangat produktif dengan orang yang benar-benar tepat di tim Metal! Terima kasih sudah membantu menarik perhatian Apple. Saya sama sekali tidak menyangka akan mendapat dukungan sebanyak ini.

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

  • Bagus bahwa sekarang ada workaround, tetapi fakta bahwa bahkan workaround itu sendiri tidak bisa dibagikan secara ironis benar-benar menunjukkan kalimat terakhir tentang cara Apple berkomunikasi di https://news.ycombinator.com/item?id=43904921

    Kurang lebih seperti, “Kalau nilai ini disetel begini lalu diubah begitu, itu akan berfungsi. Memang tidak terdokumentasi, tapi sekarang Anda sudah tahu.”

    Saat mengimplementasikan workaround, semoga Anda bisa menaruhnya di fungsi dengan nama yang sangat gamblang, sehingga orang lain yang mengalami batasan GPU yang sensitif terhadap latensi serupa setidaknya bisa menemukan petunjuk mantra ajaibnya lewat disassembly.

  • HN sekali lagi berhasil memenuhi tujuan aslinya: menembus tembok birokrasi di depan dukungan pelanggan perusahaan besar.

    Selamat atas proyeknya dan semoga sukses.

• Saya pernah bekerja di dua perusahaan terkenal yang memiliki aplikasi sangat populer di Apple App Store.

  Tim Apple yang kami ajak bicara sama sekali tidak peduli dengan masalah kami, dan justru sering mengundang kami ke kantor untuk membahas fitur terbaru yang akan mereka umumkan di WWDC, praktis memaksa kami untuk mendukung fitur itu. Itulah awal sekaligus akhir hubungan kami dengan mereka. Untuk mencari tahu mengapa software Apple yang penuh bug tidak berfungsi, kami tetap harus membuat tiket dukungan teknis.

  Orang-orang developer relations Apple bukan orang yang serius.

  • Untungnya, seperti yang ditunjukkan penulis asli di atas, pengalaman saya bukan aturan umum. Tetapi sekitar 10 tahun lalu, ketika saya bekerja di perusahaan dengan aplikasi yang cukup terkenal, sebuah update benar-benar merusak performa aplikasi.

    Pada waktu yang persis sama, pesaing merilis aplikasi tanpa masalah performa. Ternyata pengembang aplikasi pesaing itu adalah orang yang baru saja keluar dari Apple, dan ia meninggalkan jebakan yang tidak terdokumentasi di driver video Apple sehingga aplikasi kami rusak. Kami baru bisa memperbaiki aplikasi setelah membongkar binary pesaing dengan disassembler dan menemukan perubahan yang tidak terdokumentasi itu. Pengembang itu bahkan mengejek CEO kami lewat email. Dunia yang indah sekali.

• Metal profiler memiliki fitur yang sangat berguna untuk memilih status performa Metal saat memprofilkan aplikasi. Ini tidak bisa disetel di luar profiler.

  Dari sini sepertinya ada API privat. Mungkinkah reverse engineering justru lebih mudah? Tentu saja kecuali jika ternyata membutuhkan privilege khusus yang tidak bisa diakali tanpa mematikan SIP.

  • Ini pasti harus ada API privat. Di tulisannya juga disebutkan begini:

    “Metal profiler memiliki fitur yang sangat berguna untuk memilih ‘Performance State’ Metal saat memprofilkan aplikasi. Ini tidak bisa disetel di luar profiler.”

    Kalau bukan API privat, bagaimana Metal profiler bisa melakukan itu? Mungkin bisa mengamati profiler dengan suatu alat debugging untuk mengetahui apa yang terjadi di dalamnya?

• Masalah saat API ini dibuka adalah terlalu banyak developer kemungkinan akan selalu memaksa status performa tertinggi tetap aktif. Saya tidak tahu apakah benar-benar ada cara yang baik untuk mencegahnya sambil tetap menyediakan API tersebut

  • Pada perangkat bertenaga baterai, sudah ada tak terhingga banyak cara bagi satu aplikasi untuk memboroskan daya. Pada akhirnya, strukturnya memang sudah bergantung pada kepercayaan bahwa developer tidak menjalankan pekerjaan yang boros energi secara tidak perlu, baik sengaja maupun tidak sengaja. Hadirnya satu API tambahan yang bisa memboroskan daya jika tidak digunakan dengan benar tidak akan banyak mengubah keadaan

  • Tulisan itu juga membahas Game Mode, fitur di sistem operasi Apple terbaru yang dioptimalkan untuk kasus seperti ini. Saat Game Mode aktif, akan muncul notifikasi, dan sebagian besar aplikasi tidak akan menginginkannya. Sejauh ini saya belum melihat ada kasus penyalahgunaannya

  • Developer sejauh ini juga belum menyalahgunakan audio workgroup di semua thread pool untuk mendapatkan penjadwalan P-core dan prioritas tinggi. Jika demikian, ini mengisyaratkan bahwa ketika audio workgroup mengeluarkan perintah ke GPU, bisa ada semacam timeout untuk downclock GPU berdasarkan waktu terakhir workgroup mengirim data

    Audio GPU saat ini memang bidang yang sangat niche, tetapi perusahaan yang disebut dalam teks utama baru-baru ini merilis SDK, jadi mungkin saja menjadi lebih populer. Tetap saja, saya sulit menerimanya. Memproses di GPU kurang lebih berarti tidak terlalu peduli pada latensi, jadi menurut saya cukup perbesar ukuran buffer input/output saja

  • Bahkan jika API disalahgunakan, itu kemungkinan akan lebih efisien daripada menjalankan pekerjaan sibuk palsu untuk mencapai hal yang sama. Aplikasi sudah bisa melakukan itu tanpa API, atau tanpa izin yang mungkin diwajibkan API

  • Bagaimana dengan pemberian izin secara manual? Meski disembunyikan di suatu tempat, kemungkinan besar ini diperlukan untuk aplikasi yang sangat niche

    Dan di level sistem operasi, Zoom, Teams, serta browser web bisa ditetapkan default-nya ditolak saja :)

• Cara terbaik untuk melakukan ini:

  1. Telusuri video WWDC, lalu cari engineer yang tampaknya paling memahami masalah yang sedang dihadapi

  2. Jika namanya Michael Thomson, kirim email langsung dengan format seperti [e-mail]

  • Atau kirim ke saudaranya, Pichael, di pthomson

• Omong-omong, akan bagus kalau Anukari merilis sound pack Mick Gordon dan berbagi pendapatan dengannya. Orang itu benar-benar membuat sesuatu yang gila, dan demonya juga luar biasa. Jika sudah ada alat sekuat ini, berkolaborasi dengan artis adalah bisnis yang bagus dan juga baik bagi dunia. Kalau Anda menyukai Mick Gordon—saya menyukainya

• Saya sama sekali tidak membutuhkan aplikasi ini, tetapi ini benar-benar keren. Aplikasi seperti ini membawa kembali kesenangan ke komputasi. Bukan berarti sekarang sama sekali tidak menyenangkan, tetapi ini mengingatkan saya pada masa lalu ketika program yang lebih grafis dan eksperimental banyak beredar, bahkan sampai demoscene

• Jangan sampai melewatkan tautan https://x.com/Mick_Gordon/status/1918146487948919222 yang ada di paragraf kedua dari akhir. Itu demo yang dibuat Mick Gordon, dan @anukarimusic membalas seperti ini

  “Haha, ini baru hari kedua sejak rilis, dan Anda sudah benar-benar menghancurkan semua demo yang saya buat selama 2 tahun pemakaian setiap hari”

• Memperbarui 1024 objek pada 48kHz tampaknya mungkin dilakukan di CPU, tergantung cara kodenya ditulis. Bukankah itu 48 juta pembaruan per detik? Kelihatannya cocok untuk menjalankan beberapa loop secara paralel di sejumlah core dengan OpenMP

  • 1. Anukari menjalankan seluruh model fisika hingga 16 salinan untuk polyphony. Jadi 16 * 1024 * 48K. Sepertinya posting blognya perlu diperbarui

    2. Karena pengguna bisa menghubungkan objek-objek satu sama lain secara arbitrer, setiap objek harus membaca dan memproses koneksi ke N entitas lain

    3. Untuk memakai seluruh CPU, diperlukan sinkronisasi antar-core pada setiap langkah fisika, dan ini lambat

    4. Jumlah pemrosesan per objek cukup besar. Ada banyak fungsi transendental, dan meski bisa diaproksimasi, fiturnya sendiri juga banyak. Semua parameter bisa dimodulasi, harus aman terhadap NaN, dan masih banyak hal lain yang perlu dipertimbangkan

    5. Pengguna ingin menjalankan beberapa instans Anukari secara paralel untuk berbagai track, efek, dan sebagainya

    Dilihat dengan cara lain, hitungannya adalah 4 GHz / (16 voice * 1024 obj * 4 connections * 48,000 sample) = 1.3 cycles per thing

    GPU menangani workload ini dalam sekejap. Arsitekturnya benar-benar cocok. 16 voice * 1024 obj semuanya bisa diproses sepenuhnya secara paralel, sinkronisasi tiap tahap juga sederhana, dan pengguna bisa mengelola cache L1

  • Jika perhitungannya benar, hasilnya 83 siklus clock untuk menghitung satu sampel. Dengan 16 core, secara teoretis menjadi 1333 siklus, dan itu tidak terlalu banyak. Apalagi mengingat CPU tidak selalu bisa dipakai mendekati 100%