Anukari geliştiricisinden Apple’a teknik çağrı

 (anukari.com)
1 puan yazan GN⁺ 2025-05-07 | 1 yorum | WhatsApp'ta paylaş
  • Anukari, gerçek zamanlı bir 3D fizik sentezleyicisi olduğu için büyük ölçekli spring-mass modellerini GPU üzerinde hesaplamak zorunda; ancak Apple silicon macOS’te GPU saati yeterince yükselmezse ses gecikmesi koşullarını karşılamak zorlaşıyor
  • DAW’ın her ses arabelleği bloğunda eklentiyi çağıran yapısı ile macOS’in güç yönetimi sezgiselleri birleşince, GPU bloklar arasında dinleniyormuş gibi görünebiliyor ve düşük performans durumunda kalabiliyor
  • Xcode Instruments içindeki Metal profiler’da Performance State değeri Maximum olduğunda her şey normal çalışırken Minimum’da durum ciddi biçimde kötüleşiyor; bu da darboğazın temelinde GPU saat hızının olduğunu gösteriyor
  • Şu anda küçük bir spin kernel ile GPU yükünü yapay olarak artıran “waste makes haste” geçici çözümü kullanılıyor, ancak bazı Pro/Max Apple donanımlarında sorun hâlâ sürüyor
  • Geliştirici, Apple Metal ekibinden Audio Workgroup’un GPU’ya genişletilmesini, MTLCommandQueue için gerçek zaman duyarlılığı seçeneği eklenmesini ya da mevcut bir çözüm varsa bunun paylaşılmasını istiyor; Windows’ta ise aynı spin loop’a gerek olmadığını düşünüyor

Anukari’nin yaşadığı macOS GPU performans sorunu

  • Anukari 3D Physics Synthesizer, ses üretmek için büyük ölçekli spring-mass fizik modellerini gerçek zamanlı olarak simüle ediyor
  • Kayda değer sayıda fizik nesnesini desteklemek için GPU gerekiyor ve fizik kodu bellekten çok ALU darboğazlı bir yapıya sahip
  • Simülasyonun değişebilir durumu GPU’nun threadgroup memory alanında tutuluyor
    • Elle yönetilen L1 önbelleğe yakın bir yapı olduğu için çok hızlı
  • Tipik kullanım biçimi, Pro Tools veya Ableton gibi bir DAW içinde AU ya da VST3 eklentisi olarak çalışması
    • DAW, Anukari’yi her ses arabelleği bloğunda çağırıyor
    • Anukari, her blokta GPU fizik simülasyonu kernel’ını çalıştırıyor, sonucu bekliyor ve ardından geri dönüyor
  • Ses arabelleği blokları, GPU kernel zamanlama gecikmesini birden fazla örneğe bölerek absorbe edebilir; ancak kernel’ın kendi çalışma süresi yine de belirleyici olmaya devam eder

macOS güç yönetimi ile gerçek zamanlı sesin çatışması

  • Apple silicon, güç tasarrufu için çipin saat hızını düşürebiliyor ve macOS işlem talebinin düşük olduğuna karar verirse düşük saati koruyor
  • Anukari’nin DAW içindeki çalışma biçimi, macOS’in GPU talebini değerlendirme yöntemiyle pek uyumlu değil
  • GPU, ses arabelleği blokları arasında boşta kaldığından ortalama yük örneğin yalnızca %60 civarında görünebiliyor
    • macOS’in gerçek sezgiselleri bilinmiyor, ancak load average benzeri bir yöntem olabileceği tahmin ediliyor
    • Bu yük, GPU saatini yükseltme eşiğini aşamayabilir
  • Anukari, gerçek zaman kısıtlarını karşılamak için düşük gecikmeye ihtiyaç duyuyor ve bunun için yüksek GPU saati gerekiyor
  • Apple GPU saatinin ne kadar düşebildiği bilinmiyor, ancak Anukari’yi kullanılamaz hâle getirecek kadar düşebildiği görülüyor

Metal profiler ile doğrulanan saat sorunu

  • Xcode ile gelen Apple Instruments içindeki Metal profiler kullanılarak Anukari’nin ALU-bound olduğu doğrulandı
  • Metal profiler, profil çıkarma sırasında Metal Performance State seçimine izin veriyor
    • Bu ayar profiler dışında yapılandırılamıyor
  • Maximum performance state altında Anukari kusursuz çalışıyor
  • Minimum performance state altında ise performans ciddi biçimde bozuluyor
  • Bu iki durum arasındaki fark, Anukari’nin performans sorununun merkezinde GPU saat hızının bulunduğunu ortaya koyuyor

“waste makes haste” geçici çözümü ve sınırları

  • macOS, ihtiyaç duyulan anda GPU saatini yükseltmediği için Anukari ayrı bir geçici çözüm kullanıyor
  • Ses hesaplaması yapan GPU işiyle paralel olarak ikinci bir GPU işi çalıştırılarak yüksek ortalama yük oluşturuluyor ve macOS’in saati yükseltmesi teşvik ediliyor
    • Bu iş, mümkün olan en az GPU kaynağını kullanırken saat sezgisellerini tetikleyecek şekilde ayarlanıyor
    • Pratikte GPU’yu ısıtan bir spin loop
  • Bu stratejiye “waste makes haste” adı veriliyor ve ilgili devlog’da ayrıntılı olarak anlatılıyor
  • Geliştiricinin MacBook M1 cihazında bu yöntem sorunu tamamen çözdü ve Anukari kararlı biçimde çalıştı
  • Ancak Anukari Beta yayımlandıktan sonra bazı macOS kullanıcılarında sorunlar görüldü
    • Özellikle Pro veya Max Apple donanımı kullananlarda performans sorunu daha sık görünüyor
    • Yazıda, GPU chiplet başına bağımsız saat olasılığı ve daha güçlü GPU’larda spin iş yükünün fazla tutucu kalması olasılığı öne sürülüyor

Apple’dan istenen çözüm yönleri

  • Apple mühendislerinin konuyu daha iyi bileceği varsayımıyla birkaç olası çözüm öneriliyor
  • Çözüm 1: Audio Workgroup kavramını GPU işlemeye genişletmek
    • macOS’te ses işleme, Audio Workgroup adı verilen bir iş parçacığı veya iş parçacığı grubu içinde yapılıyor
    • OS, bu iş parçacıklarının gerçek zaman kısıtlarına sahip olduğunu biliyor ve onlara öncelik veriyor
    • Audio Workgroup iş parçacıklarının yönettiği MTLCommandQueue, gerçek zamanlı iş olarak değerlendirilip GPU saati buna göre ayarlanabilir
  • Çözüm 2: Metal API’deki MTLCommandQueue için gerçek zaman duyarlılığını belirten bir seçenek sağlamak
    • Böylece ilgili queue’yu işleyen GPU chiplet’ının saati buna göre ayarlanabilir
  • Çözüm 3: İstenen işlevi elde etmenin zaten bir yolu varsa, Apple’ın bunu paylaşması da yeterli olur
  • Yazının başında ayrıca Apple’ın iletişime geçtiği ve ilgili ayrıntıların ayrı bir yazıda yer aldığı belirtiliyor

Game Mode ve Windows karşılaştırması

  • Apple’ın Game Mode özelliği, Anukari’nin ihtiyaç duyduğu şeye benziyor ancak uygulanması zor
    • Game Mode süreç düzeyinde çalışıyor
    • Anukari çoğunlukla başka bir süreç içindeki eklenti olarak kullanılıyor ve ilgili süreç Game Mode’u desteklemiyor
    • Anukari bunu doğrudan kontrol edemiyor
    • Game Mode ayrıca fullscreen gerektiriyor, oysa Anukari genelde fullscreen çalışmıyor
  • Windows’ta bu sorun yaşanmıyor
    • Bunun nedeni Windows’un kullanıcıya performans durumu üzerinde daha fazla kontrol vermesi mi, yoksa NVIDIA sürücülerinin güç tüketimi konusunda daha az temkinli olması mı bilinmiyor
    • Windows’ta spin loop gerekmiyor
  • Daha zayıf GPU’ya sahip Windows PC’ler Anukari’yi sorunsuz çalıştırabilirken, pahalı bir Mac M4 Max’te takılmalar yaşanabildiği karşılaştırması yapılıyor

Neden pipeline yaklaşımı uygun değil

  • GPU kodunu pipeline hâline getirip GPU’yu doyurma yaklaşımı throughput odaklı işler için uygun, ancak Anukari gecikmeye duyarlı bir iş yükü
  • Birden fazla fizik simülasyonu kernel’ını önceden zamanlamak, GPU mevcut ses bloğunu işlerken CPU’nun bir sonraki bloğu hazırlamasına imkân verebilir
  • Ancak pipeline yaklaşımı throughput’u artırırken gecikmeyi yükseltir
  • Anukari’de her kernel çalıştırması, mikrofon girişi gibi gerçek zamanlı ses giriş verisine erişmek zorunda
  • Bir sonraki ses bloğunu önceden işleyen speculative execution yaklaşımı, gerekli giriş verisi henüz olmadığı için kullanılamıyor

Spin kernel’ı aynı MTLCommandQueue içine koyma yönteminin sorunu

  • Sorunun gerçek nedeni spin kernel ile physics kernel’ın farklı GPU chiplet’larında çalışmasıysa, ikisini aynı MTLCommandQueue içine koymak çözüm gibi görünebilir
  • Bu yöntem gerçekten denendi ancak işe yaramadı
  • Nedeni, Anukari’nin gecikmeye duyarlı bir iş yükü olması
    • spin kernel bazen biraz fazla uzun çalışıyor
    • Bu süre, physics kernel’ın çalışma süresine taşabiliyor
  • CPU’nun “exit kernel early” bayrağını volatile unified memory üzerinden yazdığı, küçük bir spin kernel kullanan denemeler de yapıldı
  • Buna rağmen spin kernel’ın physics kernel süresini ihlal ettiği durumlar yine oluştu

GPU kernel hedging neden zor

  • Dağıtık sistemlerdeki request hedging benzeri şekilde, fizik kernel’ının birden fazla kopyasını çalıştırıp ilk bitenin sonucunu kullanma yaklaşımı da değerlendirildi
  • Bu yaklaşım kuyruk gecikmesini ve gecikme varyansını azaltabilir; aynı zamanda GPU yükü oluşturarak OS’in performans durumunu yükseltmesini de teşvik edebilir
  • Ancak Anukari için çeşitli sorunlar var
    • Bir physics kernel, tek bir ses bloğu döngüsünden uzun sürerse ilgili kernel akışı geride kalıyor
    • Geride kalan akışın sonraki bloklarda yetişmesi gerekiyor ve bunun için diğer akışın iç durumunu kopyalayan bir fast-forward gerekli oluyor
  • İç durum kopyası maliyetli
    • En büyük iç durum, delay line için kullanılan ses arabelleği
    • Her mikrofon için 1 saniyelik geçmiş ses tutuluyor
    • Boyutu 48,000 samples * 50 mics * 2 channels * 16 voices * 4 bytes yani 307MB
    • Daha yüksek sample rate değerlerinde daha da büyüyor
  • Bunu verimli yapmak için her hedged kernel akışının dirty bölgelerini hassas biçimde izlemek ve yalnızca o kısımları kopyalamak gerekiyor
    • Ancak arabellek belleğinin yerleşimi, physics kernel’ın okuma iş yüküne göre optimize edilmiş durumda
    • En az veriyi kopyalasanız bile tüm arabelleğe dağılmış bölgeleri kopyalamak gerektiğinden bu işlem yavaş kalıyor
  • Kullanıcının model değişikliklerinin de tüm hedged kernel’lara yayılması gerekiyor
  • physics kernel’ın GPU ayak izi, “waste makes haste” spin kernel’dan çok daha büyük
    • hedging daha fazla gereksiz GPU yükü üretiyor ve paralel çalışabilecek Anukari örneği sayısını azaltabiliyor
    • hedge kernel’lar birbirleriyle rekabet edip hepsini yavaşlatabiliyor

Hâlihazırda yapılan optimizasyonlar ve GPU’nun neden gerekli olduğu

  • Anukari simülasyonu ALU-bound olduğu için bellek erişim düzenini iyileştirme gibi genel optimizasyonların getireceği alan sınırlı
  • Performansı artırmak için aritmetik throughput optimize edilmek zorunda
    • Uygun yerlerde FP16 işlemleri kullanılarak Apple ALU’ları daha iyi doyuruluyor
    • Komut sırası micro-benchmark’larla ayarlanıyor
    • Tüm fizik durumu L1 memory içinde tutuluyor
    • vectorization için load sırası yeniden düzenleniyor
  • Apple SIMD-group içindeki iş parçacıklarının çoğunlukla aynı instruction pointer’ı paylaşmasından da yararlanılıyor
    • Farklı fizik nesneleri arasında branch path’ler ciddi biçimde ayrışıyor
    • Aynı SIMD-group içinde iki tür nesneyi simüle etmek, instruction masking nedeniyle yavaşlığa yol açıyor
    • Bunu önlemek için fizik nesnelerinin bellek yerleşimi dinamik olarak optimize edilerek bir SIMD-group içinde çalışan nesne türü sayısı azaltılıyor
    • Bu optimizasyon the new warp alignment optimizer yazısında ayrıntılı biçimde açıklanıyor
  • Ek aritmetik optimizasyon alanı olsa da bunun tek haneli yüzde puanlarla sınırlı kalacağı düşünülüyor
  • Güçlü makinelerde Anukari, 768 ila 1024 fizik nesnesini simüle edebiliyor
    • Her nesne diğer nesnelere keyfî biçimde bağlanabiliyor
    • Nesneler genellikle saniyede 48.000 örneklik ses sample rate değeriyle implicit Euler integration yapıyor
    • Her nesnenin 3 ila 10 çalışma parametresi bulunuyor
    • Bazı işlemler vector rotation, exp(), log() gibi maliyetli hesaplamalar içeriyor
    • Polyphony için tüm fizik simülasyonu en fazla 16 paralel kopya olarak çalıştırılıyor
  • Bu yaklaşım CPU ile mümkün olmadı; GPU’nun çok sayıdaki ALU’suna, L1 cache yerleşimi kontrolüne ve threadgroup_barrier gibi eşzamanlılık yapılarına ihtiyaç duyuluyor
  • Anukari, GPU işleme olmadan var olamaz

GPU Audio API neden çözüm değil

  • GPU Audio CEO’su Alexander Talashov, Anukari’nin GPU Audio API kullanması hâlinde sorunun çözülebileceğini söylemiş
  • Geliştirici GPU Audio ürününü olumlu değerlendiriyor ve GPU’yu DSP için erişilebilir kılan bir ürün olarak tanıtıyor
  • Ancak Anukari için GPU Audio’nun faydalı olmayacağı düşünülüyor
  • Anukari, geleneksel DSP uygulamalarından farklı olarak daha çok bir sayısal diferansiyel denklem integratörüne benziyor
    • Bir miktar DSP olsa da hesaplamanın büyük kısmı Euler integration’dan oluşuyor
    • Fizik dünyasındaki mikrofon sıkıştırması gibi DSP işlemleri, GPU üzerindeki fizik hesaplamasının içine inline biçimde gömülü
  • Anukari, Metal’in daha alt seviyelerinde GPU’yu doğrudan programlıyor
  • İhtiyaç duyulan şey, Apple’ın GPU saat hızını güvenilir biçimde yükseltmesi

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-07
Hacker News yorumları

  • Show HN yazımda Anukari’yi görmüş olanlar olabilir: https://news.ycombinator.com/item?id=43873074

    O başlıkta macOS performansı konusu açılmıştı. Anukari, temel model M1 dâhil Apple silicon’ın çoğunda iyi çalışıyor; testlerimin tamamını da temel M1’de yaptım ve harikaydı. Donanım gerçekten inanılmaz

    Ancak çalıştırabilmek için, ses işlemenin yeterince hızlanması amacıyla macOS’in GPU saat hızını artırmasını sağlayan tuhaf bir geçici çözüm uygulamak zorunda kaldım. macOS’in GPU performans durumunu belirleyen genel sezgisel kuralları, Anukari’nin alışılmadık iş yükünü anlamıyor

    Bu yüzden sonunda tüm durumu fazlasıyla ayrıntılı biçimde yazdım ve Apple’da doğru kişiyle, muhtemelen Metal API tarafındaki sorumlulardan biriyle bağlantı kurabilmek için yardım istemek istedim. Yardım edin :)

    • “Çok uzun ve çok teknik bir yazı” denmişti ama sonuna kadar okuyunca ne çok uzun ne de anlaşılmazdı; çok açık ve iyi yazılmıştı, ayrıca bilgilendiriciydi. Güzel yazılmış

      Hiç Mac’im olmadı, PC’im de eski olduğu için düzgün bir GPU’su yok; bu yüzden Anukari’yi hemen denemem pek olası değil ama gerçekten harika göründüğü için üzüldüm. Umarım hızlıca çözülür

    • Şu yetkiyi (entitlement) denediniz mi merak ediyorum: https://developer.apple.com/documentation/bundleresources/en...

      com.apple.developer.sustained-execution ters yönde de çalışıyor mu merak ediyorum

    • İlginç bir yazı ve sorun da ilginç. Aynı kuyrukta iş çalıştırma fikrinin başarısız olmasının nedeni de sonuçta asıl sorunla aynı değil mi diye düşünüyorum. Değişken saat hızı yüzünden hassas zamanlama imkânsızlaşıyor; işletim sisteminin GPU saatini nasıl ayarladığına bağlı olarak spin’in durma anı ideal andan sapıyor ve aliasing oluşuyor

      Öyleyse spin işi, GPU’yu en yüksek saat hızına çıkaracak kadar karmaşık olmayabilir. Gerçekten en yüksek performansta çalışıyorsa, yazılımsal PLL eklemeden de spin’in bitiş anını kararlı biçimde tutturabilmesi gerekir. Spin’in nasıl uygulandığına dair ayrıntılı bir açıklama görmedim ama GPU’nun daha fazla bölümünü sürekli zorlayan, daha kapsamlı bir spin döngüsü saat hızını en yüksek performansta tutmada daha etkili olabilir

    • Show HN’i kaçırmışım ama görür görmez yaratıcı ASMR ses manzaraları ve sürükleyici çok boyutlu ses için çok uygun olacağını düşündüm. Umarım siz ya da kullanıcılardan biri bir demo yapar. Proje için tebrikler; Apple konusundaki sorun için de umarım yardım alırsınız

    • Yazı iyiydi ve açıklama net olduğu için anlaması kolaydı. Başka bağlamlarda da tarif ettiğinizle aynı sorunu kesinlikle yaşadım

  • Arkadaşlar, işe yaradı. Metal ekibindeki tam doğru kişiyle çok verimli bir görüşme yaptım! Apple’ın dikkatini çekmeme yardım ettiğiniz için teşekkürler. Bu kadar çok destek almayı hiç beklemiyordum

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

    • Şimdi bir geçici çözüm bulunmuş olması güzel ama o geçici çözümün ne olduğunu bile paylaşamamanız, ironik biçimde Apple’ın iletişim tarzına dair https://news.ycombinator.com/item?id=43904921 son cümleyi aynen gösteriyor

      “Bu değeri şöyle ayarlayıp sonra böyle değiştirince çalışıyor. Belgelenmiş değil ama artık biliyorsunuz” gibi bir şey

      Geçici çözümü uygularken, benzer şekilde gecikmeye duyarlı GPU kısıtları yaşayan başka kişilerin en azından disassembly ile sihirli sözlerin ipucunu bulabilmesi için bunu adı bariz olan bir fonksiyonun içine koyabilirseniz iyi olur

    • HN bir kez daha asıl amacını yerine getirdi: büyük şirket müşteri desteğinin önündeki bürokratik duvarları aşmak

      Proje için tebrikler, bol şans

  • Apple App Store’da çok ünlü uygulamaları olan iki tanınmış şirkette çalıştım

    Görüştüğümüz Apple ekibinin sorunlarımızla hiç ilgisi yoktu; bunun yerine WWDC’de duyuracakları en yeni özellikleri konuşmak için bizi sık sık ofislerine davet ediyor ve o özellikleri desteklemeye fiilen zorluyorlardı. Onlarla ilişkimizin başlangıcı ve sonu bundan ibaretti. Hatalı Apple yazılımlarının neden çalışmadığını anlamak için teknik destek talebi açmak zorundaydık

    Apple’ın geliştirici ilişkileri sorumluları ciddi insanlar değil

    • Yukarıdaki orijinal yazının gösterdiği gibi, benim deneyimimin genel kural olmamasına sevindim. Ama yaklaşık 10 yıl önce oldukça ünlü bir uygulaması olan bir şirkette çalışırken, bir güncelleme uygulamanın performansını tamamen mahvetti

      Tam aynı dönemde bir rakip, performans sorunu olmayan bir uygulama yayımladı. Sonradan anlaşıldı ki o rakip uygulamanın geliştiricisi kısa süre önce Apple’dan ayrılmış biriydi ve Apple’ın video sürücüsünde belgelenmemiş bir tuzak bırakmıştı; bu da bizim uygulamayı bozuyordu. Rakibin binary’sini disassemble ederek belgelenmemiş değişikliği bulup uygulamayı düzeltebildik. O geliştirici CEO’muza e-postayla alay bile etti. Ne harika dünya

  • Metal profiler’da, uygulamayı profilleme sırasında Metal performans durumunu seçebilmenizi sağlayan çok kullanışlı bir özellik var. Profiler dışında bunu ayarlayamıyorsunuz

    Bu da gizli bir API var gibi gösteriyor. Tersine mühendisliğe gitmek daha kolay olabilir mi? Elbette SIP’yi kapatmadan aşılamayan özel bir yetki gerektiren bir durum değilse

    • Bunun mutlaka gizli API olması gerekir. Yazıda da şöyle geçiyor

      “Metal profiler’da, uygulamayı profilleme sırasında Metal ‘Performance State’i seçebilmenizi sağlayan çok kullanışlı bir özellik var. Profiler dışında bunu ayarlayamıyorsunuz”

      Gizli API değilse Metal profiler bunu nasıl yapabiliyor olabilir? Profiler’ı bir hata ayıklama aracıyla gözlemleyip içeride neler döndüğünü öğrenmek mümkün değil mi?

  • Bu API’yi açmanın sorunu, çok fazla geliştiricinin her zaman en yüksek performans durumunu zorla açık tutacak olması. API sunarken bunu engellemenin gerçekten iyi bir yolu var mı bilmiyorum.

    • Pil ile çalışan cihazlarda tek bir uygulamanın güç harcamasının zaten sonsuz sayıda yolu var. Sonuçta mevcut yapı, geliştiricilerin ister bilerek ister yanlışlıkla enerji yoğun işleri gereksiz yere çalıştırmayacağına güveniyor. Doğru kullanılmazsa güç israfına yol açabilecek bir API’nin daha eklenmesi çok şeyi değiştirmez.

    • Yazı Oyun Modunu da ele alıyor; bu, güncel Apple işletim sistemlerinde bu tür durumlar için optimize edilmiş bir özellik. Oyun Modu açıldığında bir bildirim çıkıyor ve çoğu uygulama bunu istemez. Şimdiye kadar bunun kötüye kullanıldığı bir örnek görmedim.

    • Geliştiriciler henüz tüm thread pool’larda ses çalışma gruplarını kötüye kullanıp P-core zamanlaması ve yüksek öncelik elde etmeye çalışmıyor. Bu da, ses çalışma grupları GPU’ya komut gönderirken, çalışma grubunun en son veri gönderdiği zamanı temel alarak GPU’nun downclock edilmesi için bir tür zaman aşımı konabileceğini düşündürüyor.

      GPU ses bugünlerde çok niş bir alan, ama metinde adı geçen şirket yakın zamanda SDK’sını yayımladığı için daha yaygın hâle gelebilir. Yine de pek ikna edici gelmiyor. Bir şeyi GPU’da işlemek, gecikmeyi önemsemeyeceğiniz anlamına yakın; bu yüzden bence giriş/çıkış buffer boyutunu artırmak yeterli.

    • API kötüye kullanılsa bile, aynı şeyi yapmak için sahte meşgul işler çalıştırmaktan daha verimli olur. Uygulamalar bunu zaten API olmadan da, hatta API’nin isteyebileceği izinler olmadan da yapabiliyor.

    • Manuel izin verme nasıl olur? Bir yerlere gizlense bile, çok niş uygulamalar için gerekli olma ihtimali yüksek.

      Ayrıca işletim sistemi düzeyinde Zoom, Teams ve web tarayıcıları varsayılan olarak reddedilebilir :)

  • Bunu yapmanın en iyi yolu:

    1. WWDC videolarına göz atıp, şu an karşılaştığınız sorunu en iyi biliyor gibi görünen mühendisi bulmak

    2. Michael Thomson ise mthomson@apple.com gibi bir formatla doğrudan e-posta göndermek

    • Ya da kardeşi Pichael’a pthomson olarak göndermek

  • Laf açılmışken, Anukari’nin bir Mick Gordon ses paketi çıkarıp geliri onunla paylaşması iyi olurdu. Adam gerçekten çılgın şeyler yapıyor ve demosu da müthiş. Böyle güçlü bir araç ortaya çıkmışken sanatçılarla işbirliği yapmak hem iyi bir iş modeli hem de dünya için iyi. Mick Gordon’ı seviyorsanız tabii; ben seviyorum.

  • Bu uygulamaya hiç ihtiyacım yok ama gerçekten harika. Böyle uygulamalar bilgisayarlara eğlenceyi geri getiriyor. Şu anda hiç eğlence yok demek istemiyorum; daha grafiksel ve deneysel programların ortalıkta dolaştığı eski günleri, hatta demoscene’i hatırlatıyor.

  • Sondan bir önceki paragraftaki https://x.com/Mick_Gordon/status/1918146487948919222 bağlantısını kaçırmamak gerek. Mick Gordon’ın yaptığı demo bu ve @anukarimusic şöyle yanıt vermiş:

    “Haha, çıkışın ikinci günü ve 2 yıl boyunca her gün kullanarak yaptığım tüm demoları şimdiden tamamen yerle bir ettiniz.”

  • 1024 nesneyi 48 kHz’de güncellemek, kodun nasıl yazıldığına bağlı olarak CPU’da da mümkün görünüyor. Saniyede 48 milyon güncelleme değil mi? OpenMP ile birkaç döngüyü çekirdekler arasında paralel çalıştırmak için uygun görünüyor.

      1. Anukari, polifoni için fizik modelinin tamamını en fazla 16 kopya olarak çalıştırıyor. Yani 16 * 1024 * 48K. Blog yazısını güncellemem gerekecek.

      2. Kullanıcılar nesneleri birbirine keyfî biçimde bağlayabildiğinden, her nesnenin N adet başka varlığa olan bağlantıları okuyup işlemesi gerekiyor.

      3. CPU’nun tamamını kullanmak için her fizik adımında çekirdekler arası senkronizasyon gerekiyor ve bu yavaş.

      4. Nesne başına işlem miktarı epey yüksek. Çok sayıda transandantal fonksiyon var; yaklaşıklama yapılabilir ama özelliklerin kendisi de fazla. Tüm parametreler modüle edilebiliyor, NaN’e karşı da güvenli olmak gerekiyor vb. dikkate alınacak çok şey var.

      5. Kullanıcılar birden fazla kanal ve efektler vb. için Anukari’yi paralel olarak birden fazla kez çalıştırmak istiyor.

      Başka bir açıdan bakarsak: 4 GHz / (16 voice * 1024 obj * 4 connections * 48,000 sample) = 1.3 cycles per thing.

      GPU bu iş yükünü göz açıp kapayıncaya kadar işliyor. Yapıya mükemmel uyuyor. 16 voice * 1024 obj öğesinin tamamını bütünüyle paralel işleyebiliyor; her adımın senkronizasyonu da basit ve kullanıcı L1 cache’i yönetebiliyor.

    • Hesap doğruysa bir sample hesaplamak için 83 clock cycle çıkıyor. 16 çekirdekte teorik olarak 1333 cycle eder; bu da çok fazla değil. CPU’yu her zaman neredeyse %100 kullanamayacağınızı düşününce özellikle öyle.