Apple के नाम Anukari डेवलपर की तकनीकी अपील

 (anukari.com)
1 पॉइंट द्वारा GN⁺ 2025-05-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Anukari एक रीयल-टाइम 3D physics synthesizer है, इसलिए बड़े पैमाने के spring-mass model को GPU पर compute करना पड़ता है, लेकिन Apple silicon macOS पर अगर GPU clock पर्याप्त रूप से ऊपर नहीं जाता, तो audio latency की शर्तें पूरी करना मुश्किल हो जाता है
  • DAW हर audio buffer block पर plugin को call करता है, और macOS की power management heuristics के साथ यह संरचना मिलकर ऐसी स्थिति बनाती है जहाँ GPU block के बीच idle दिख सकता है और low performance state में अटका रह सकता है
  • Xcode Instruments के Metal profiler में Performance State को Maximum रखने पर यह सामान्य रूप से काम करता है, जबकि Minimum पर काफी खराब हो जाता है; इससे पुष्टि होती है कि bottleneck का मुख्य कारण GPU clock speed है
  • फिलहाल एक छोटे spin kernel से GPU load को कृत्रिम रूप से बढ़ाने वाला “waste makes haste” workaround इस्तेमाल किया जा रहा है, लेकिन कुछ Pro/Max Apple hardware पर समस्या अब भी बनी हुई है
  • डेवलपर Apple Metal team से Audio Workgroup का GPU तक विस्तार, MTLCommandQueue के लिए real-time sensitivity option, या मौजूदा समाधान के बारे में मार्गदर्शन मांगता है, और मानता है कि Windows पर वही spin loop ज़रूरी नहीं है

macOS GPU performance समस्या जो Anukari झेल रहा है

  • Anukari 3D Physics Synthesizer audio generation के लिए बड़े पैमाने के spring-mass physics model को real-time में simulate करता है
  • पर्याप्त संख्या में physics objects support करने के लिए GPU की ज़रूरत होती है, और physics code memory से ज़्यादा ALU bottleneck के करीब है
  • simulation की mutable state GPU की threadgroup memory में store होती है
    • यह manual allocation वाले L1 cache जैसी संरचना है, इसलिए बहुत तेज़ है
  • सामान्य उपयोग Pro Tools, Ableton जैसे DAW के अंदर AU या VST3 plugin के रूप में चलाने का है
    • DAW हर audio buffer block पर Anukari को call करता है
    • Anukari हर block पर GPU physics simulation kernel चलाता है, result का इंतज़ार करता है और फिर return करता है
  • audio buffer block GPU kernel scheduling delay को कई samples में बाँटकर absorb कर सकता है, लेकिन kernel का अपना execution time अब भी निर्णायक है

macOS power management और real-time audio का टकराव

  • Apple silicon power saving के लिए chip की clock speed घटा सकता है, और macOS अगर processing demand कम मानता है तो low clock बनाए रखता है
  • DAW के भीतर Anukari के execution का तरीका macOS द्वारा GPU demand आँकने के तरीके से ठीक मेल नहीं खाता
  • GPU audio buffer blocks के बीच idle हो जाता है, इसलिए average load, उदाहरण के लिए, सिर्फ़ करीब 60% जैसा दिख सकता है
    • macOS की वास्तविक heuristics पता नहीं हैं, लेकिन अनुमान है कि यह load average जैसी कोई पद्धति हो सकती है
    • यह load GPU clock बढ़ाने की सीमा से नीचे रह सकता है
  • real-time constraints पूरी करने के लिए Anukari को low latency चाहिए, और इसके लिए high GPU clock चाहिए
  • Apple GPU clock कितना नीचे जा सकता है, यह पता नहीं, लेकिन यह इतना कम हो सकता है कि Anukari इस्तेमाल लायक न रहे

Metal profiler से clock issue की पुष्टि

  • Xcode में शामिल Apple Instruments के Metal profiler से पुष्टि हुई कि Anukari ALU-bound है
  • Metal profiler profiling के दौरान Metal “Performance State” चुनने देता है
    • यह setting profiler के बाहर configure नहीं की जा सकती
  • Maximum performance state में Anukari बिल्कुल सही चलता है
  • Minimum performance state में behavior काफी बिगड़ जाता है
  • दोनों states के अंतर से साफ़ हुआ कि GPU clock speed Anukari performance समस्या का मुख्य कारण है

“waste makes haste” workaround और उसकी सीमाएँ

  • क्योंकि macOS ज़रूरत के समय GPU clock नहीं बढ़ाता, Anukari अलग workaround इस्तेमाल करता है
  • audio calculation वाले GPU work के parallel एक दूसरा GPU work चलाकर high average load बनाया जाता है और macOS को clock बढ़ाने के लिए प्रेरित किया जाता है
    • यह work इस तरह tune किया गया है कि जितने कम हो सकें उतने GPU resources इस्तेमाल करे, फिर भी clock heuristics को trigger करे
    • असल में यह GPU को गरम करने वाला spin loop है
  • इस strategy को “waste makes haste” कहा जाता है, और संबंधित devlog में विस्तार से दर्ज है
  • डेवलपर के MacBook M1 पर इस तरीके ने समस्या पूरी तरह हल कर दी और Anukari स्थिर रूप से चलने लगा
  • लेकिन Anukari Beta release के बाद कुछ macOS users को समस्या आई
    • खासकर Pro या Max Apple hardware users में performance समस्याएँ ज़्यादा दिखती हैं
    • लेख में GPU chiplet के स्वतंत्र clocks की संभावना और अधिक शक्तिशाली GPU पर spin workload के बहुत conservative होने की संभावना को hypothesis बताया गया है

Apple से मांगी गई समाधान दिशा

  • यह मानकर कि Apple engineers बेहतर जानते होंगे, कुछ संभावित solutions सुझाए गए हैं
  • Solution 1: Audio Workgroup concept को GPU processing तक expand करना
    • macOS में audio processing Audio Workgroup नाम के thread या thread group में की जाती है
    • OS समझता है कि इन threads पर real-time constraints हैं और उन्हें priority देता है
    • Audio Workgroup thread द्वारा manage किए जाने वाले MTLCommandQueue को real-time processing मानकर GPU clock adjust किया जा सकता है
  • Solution 2: Metal API के MTLCommandQueue में real-time sensitivity दिखाने का option देना
    • उस queue को process करने वाले GPU chiplet का clock उसके अनुसार adjust किया जा सकता है
  • Solution 3: अगर desired functionality पाने का कोई तरीका पहले से मौजूद है, तो Apple का सिर्फ़ उसे बताना भी पर्याप्त होगा
  • लेख के ऊपर यह भी जोड़ा गया है कि Apple ने संपर्क किया है और संबंधित विवरण अलग लेख में है

Game Mode और Windows की तुलना

  • Apple का Game Mode Anukari की ज़रूरत जैसा लगता है, लेकिन apply करना मुश्किल है
    • Game Mode process-level है
    • Anukari अधिकतर किसी दूसरे process के अंदर plugin के रूप में इस्तेमाल होता है, और वह process Game Mode support नहीं करता
    • Anukari इसे सीधे control नहीं कर सकता
    • Game Mode fullscreen भी मांगता है, लेकिन Anukari आमतौर पर fullscreen नहीं होता
  • Windows पर यह समस्या नहीं होती
    • यह इसलिए है कि Windows user को performance state control ज़्यादा देता है, या इसलिए कि NVIDIA driver power consumption को लेकर कम सावधान है, यह पता नहीं
    • Windows पर spin loop की ज़रूरत नहीं होती
  • तुलना की गई है कि weaker GPU वाला Windows PC Anukari अच्छे से चला लेता है, जबकि महंगे Mac M4 Max पर stutter हो सकता है

pipelining क्यों फिट नहीं बैठती

  • GPU code को pipeline करके GPU को saturate करने का तरीका throughput-focused workloads के लिए उपयुक्त है, लेकिन Anukari latency-sensitive workload है
  • कई physics simulation kernels को पहले से schedule करने पर GPU current audio block process करते समय CPU अगले block की तैयारी कर सकता है
  • लेकिन pipelining throughput बढ़ाने के बदले latency बढ़ाती है
  • Anukari के हर kernel execution को mic input जैसे real-time audio input data तक access चाहिए
  • अगले audio block को पहले से process करने वाली speculative execution के पास ज़रूरी input data नहीं होता, इसलिए उसका उपयोग नहीं किया जा सकता

spin kernel को उसी MTLCommandQueue में डालने की समस्या

  • अगर असली कारण यह हो कि spin kernel और physics kernel अलग-अलग GPU chiplet पर चल रहे हैं, तो उन्हें उसी MTLCommandQueue में डालना solution जैसा लग सकता है
  • वास्तव में यह तरीका आज़माया गया, लेकिन काम नहीं किया
  • कारण यह है कि Anukari latency-sensitive workload है
    • spin kernel कभी-कभी थोड़ा ज़्यादा देर तक चलता है
    • वह समय physics kernel के execution time में घुस जाता है
  • छोटे spin kernel और volatile unified memory का उपयोग करके CPU द्वारा “exit kernel early” flag लिखने का तरीका भी experiment किया गया
  • ऐसी व्यवस्था के बावजूद, spin kernel के physics kernel समय में घुसने के मामले हो जाते हैं

GPU kernel hedging मुश्किल क्यों है

  • distributed systems के request hedging की तरह physics kernel की कई copies चलाकर सबसे पहले खत्म हुए result को इस्तेमाल करने का तरीका भी consider किया गया
  • यह तरीका tail latency और latency variance घटा सकता है, और साथ ही GPU load बनाकर OS को performance state बढ़ाने के लिए प्रेरित कर सकता है
  • लेकिन Anukari में कई समस्याएँ हैं
    • अगर कोई physics kernel एक audio block period से ज़्यादा समय लेता है, तो वह kernel stream पीछे रह जाती है
    • पीछे रह गई kernel stream को future blocks में catch up करना होगा, और इसके लिए दूसरी stream की internal state copy करने वाला fast-forward चाहिए
  • internal state copy करना महंगा है
    • सबसे बड़ी internal state delay line के लिए audio buffer है
    • हर mic के लिए 1 second का past audio store किया जाता है
    • size 48,000 samples * 50 mics * 2 channels * 16 voices * 4 bytes यानी 307MB है
    • higher sample rate पर यह और बड़ा हो जाता है
  • efficient तरीके से handle करने के लिए हर hedged kernel stream की dirty regions को सटीक रूप से track करके सिर्फ़ वही हिस्से copy करने होंगे
    • लेकिन buffer memory layout physics kernel के read workload के हिसाब से optimize किया गया है
    • minimum copy करने पर भी पूरे buffer में बिखरे हुए regions copy करने पड़ेंगे, जिससे यह धीमा हो जाता है
  • user model changes भी सभी hedged kernels में propagate करने होंगे
  • physics kernel का GPU footprint “waste makes haste” spin kernel से कहीं बड़ा है
    • hedging ज़्यादा अनावश्यक GPU load बनाता है, और parallel में चल सकने वाले Anukari instances की संख्या घटा सकता है
    • hedge kernels आपस में compete करके सभी को धीमा भी कर सकते हैं

पहले से किए गए optimizations और GPU की ज़रूरत क्यों है

  • Anukari simulation ALU-bound है, इसलिए memory access pattern सुधारने जैसे सामान्य optimizations की गुंजाइश ज़्यादा नहीं है
  • performance बढ़ाने के लिए arithmetic throughput optimize करना होगा
    • जहाँ संभव है, FP16 operations का उपयोग करके Apple ALU को बेहतर तरीके से saturate किया जाता है
    • micro-benchmark का उपयोग करके instruction order adjust किया जाता है
    • सभी physics state को L1 memory में रखा जाता है
    • vectorization के लिए load order rearrange किया जाता है
  • Apple SIMD-group के threads आमतौर पर instruction pointer share करते हैं, इस बात का भी लाभ लिया गया है
    • अलग-अलग physics objects के branch paths काफी अलग होते हैं
    • एक SIMD-group में दो तरह के objects simulate करने पर instruction masking के कारण slowdown होता है
    • इससे बचने के लिए physics objects का memory layout dynamically optimize किया जाता है, ताकि SIMD-group के भीतर चलने वाले object types की संख्या घटे
    • यह optimization the new warp alignment optimizer में विस्तार से लिखा गया है
  • अतिरिक्त arithmetic optimizations की गुंजाइश है, लेकिन माना गया है कि सुधार single-digit percentage points तक ही रहेंगे
  • शक्तिशाली मशीनों पर Anukari 768~1024 physics objects simulate कर सकता है
    • हर object अन्य objects से arbitrary तरीके से connect हो सकता है
    • objects आमतौर पर 48,000 samples per second के audio sample rate पर implicit Euler integration करते हैं
    • हर object में 3~10 behavior parameters होते हैं
    • कुछ behaviors में vector rotation, exp(), log() जैसे महंगे operations शामिल हैं
    • polyphony के लिए पूरी physics simulation की अधिकतम 16 parallel copies चलाई जाती हैं
  • CPU पर यह तरीका संभव नहीं था; GPU के बहुत सारे ALU, L1 cache layout control और threadgroup_barrier जैसी concurrency structures की ज़रूरत होती है
  • GPU processing के बिना Anukari मौजूद नहीं हो सकता

GPU Audio API solution क्यों नहीं है

  • GPU Audio के CEO Alexander Talashov ने कहा है कि अगर Anukari GPU Audio API का उपयोग करे तो समस्या हल हो सकती है
  • डेवलपर GPU Audio को अच्छा product मानता है और इसे GPU को DSP के लिए accessible बनाने वाला product बताता है
  • लेकिन Anukari के लिए GPU Audio उपयोगी नहीं माना गया
  • Anukari पारंपरिक DSP application से अलग numerical differential equation integrator के करीब है
    • DSP के कुछ हिस्से हैं, लेकिन अधिकांश computation Eulerian integration है
    • physical world में mic compression जैसा DSP GPU की physics calculation के अंदर inline process होता है
  • Anukari Metal के low level पर GPU को सीधे program कर रहा है
  • ज़रूरत यह है कि Apple GPU clock speed को reliably ऊपर रखे

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-05-07
Hacker News की राय

  • हो सकता है कुछ लोगों ने मेरी Show HN पोस्ट में Anukari देखा हो: https://news.ycombinator.com/item?id=43873074

    उस थ्रेड में macOS performance की बात उठी थी। Anukari, बेस M1 सहित ज़्यादातर Apple silicon पर अच्छी तरह चलता है, और मेरी सारी testing भी बेस M1 पर हुई, जहाँ यह शानदार था। हार्डवेयर वाकई कमाल का है

    लेकिन इसे चलाने के लिए मुझे एक अजीब workaround लागू करना पड़ा, ताकि audio processing पर्याप्त तेज़ हो सके और macOS GPU clock speed बढ़ा दे। GPU performance state तय करने वाली macOS की सामान्य heuristics Anukari के अनोखे workload को समझ नहीं पातीं

    इसलिए अंत में मैंने पूरी स्थिति को बहुत ज़्यादा विस्तार से लिखा, और उम्मीद की कि Apple में सही व्यक्ति, शायद Metal API से जुड़े किसी व्यक्ति से जुड़ने में मदद मिल सके। कृपया मदद करें :)

    • आपने इसे “बहुत लंबा और बेहद technical लेख” कहा था, लेकिन पूरा पढ़ने पर यह न तो बहुत लंबा लगा और यह बहुत स्पष्ट और अच्छी तरह लिखा हुआ लेख था, साथ ही उपयोगी भी। बढ़िया लिखा है

      मेरे पास कभी Mac नहीं रहा और मेरा PC भी पुराना है, इसलिए उसमें ढंग का GPU नहीं है; इस वजह से Anukari को तुरंत आज़माने की संभावना कम है, लेकिन यह सच में बहुत अच्छा दिखता है, इसलिए अफसोस है। उम्मीद है यह जल्दी सुलझेगा

    • जिज्ञासा है कि क्या आपने यह entitlement आज़माया है: https://developer.apple.com/documentation/bundleresources/en...

      सोच रहा हूँ कि com.apple.developer.sustained-execution उल्टी दिशा में भी काम करता है या नहीं

    • लेख दिलचस्प है और समस्या भी दिलचस्प है। मुझे लगता है उसी queue में work चलाने वाला idea जिस वजह से fail होता है, वह आखिरकार मूल समस्या वाली ही वजह है। Variable clock speed के कारण precise scheduling असंभव हो जाती है, और OS ने GPU clock कैसे सेट किया है, उसके आधार पर spin रोकने का समय ideal time से हट जाता है और aliasing जैसी स्थिति बनती है

      तो हो सकता है spin work इतना complex न हो कि GPU को top clock तक पहुँचा सके। अगर यह सच में maximum performance पर चल रहा हो, तो software PLL जोड़े बिना भी spin खत्म करने का समय स्थिर रूप से मिलना चाहिए। मैंने spin कैसे implement किया गया है, इसकी विस्तृत व्याख्या नहीं देखी, लेकिन GPU के ज्यादा हिस्सों को लगातार push करने वाला एक ज्यादा faithful spin loop clock को maximum performance पर बनाए रखने में अधिक प्रभावी लग सकता है

    • Show HN छूट गया था, लेकिन देखते ही मुझे लगा कि यह creative ASMR soundscapes और immersive multidimensional audio के लिए बहुत अच्छा फिट होगा। अच्छा होगा अगर आप या आपके users में से कोई demo बनाए। project के लिए बधाई और उम्मीद है Apple वाली समस्या में मदद मिलेगी

    • लेख अच्छा था और explanation स्पष्ट थी, इसलिए समझना आसान था। दूसरे contexts में भी मैंने निश्चित रूप से वैसी ही समस्याएँ झेली हैं जैसी आपने समझाईं

  • दोस्तों, असर हुआ। Metal team के बिल्कुल सही व्यक्ति से बहुत productive बातचीत हुई! Apple का ध्यान खींचने में मदद करने के लिए धन्यवाद। इतने समर्थन की मुझे बिल्कुल उम्मीद नहीं थी

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

    • यह अच्छा है कि अब workaround मिल गया है, लेकिन irony यह है कि आप यह भी share नहीं कर सकते कि वह workaround क्या है; यह Apple के communication style के बारे में https://news.ycombinator.com/item?id=43904921 के आखिरी वाक्य को हूबहू दिखाता है

      कुछ ऐसा, “इस value को ऐसे सेट करें और फिर वैसे बदलें तो काम करता है। documented नहीं है, लेकिन अब आपको पता है”

      workaround implement करते समय, अच्छा होगा अगर आप इसे किसी बहुत स्पष्ट नाम वाले function में डाल सकें, ताकि समान रूप से latency-sensitive GPU constraints झेल रहे दूसरे लोग disassembly से ही सही, उस magic spell का कोई clue ढूँढ सकें

    • HN ने एक बार फिर अपना असली उद्देश्य पूरा किया: बड़ी कंपनियों की customer support के सामने खड़ी bureaucratic barriers को पार करना

      project के लिए बधाई और शुभकामनाएँ

  • मैंने दो प्रसिद्ध कंपनियों में काम किया है जिनकी Apple App Store पर बहुत मशहूर apps थीं

    जिन Apple teams से हमारी बात होती थी, उन्हें हमारी समस्याओं में बिल्कुल दिलचस्पी नहीं थी; इसके बजाय वे हमें अक्सर office बुलाते थे कि WWDC में announce होने वाले latest features पर चर्चा करें, और practically हमें उन features का support करने के लिए मजबूर करते थे। उनके साथ relationship की शुरुआत और अंत बस यही था। Buggy Apple software क्यों काम नहीं कर रहा, यह पता लगाने के लिए हमें technical support tickets ही लिखने पड़ते थे

    Apple के developer relations वाले लोग गंभीर लोग नहीं हैं

    • ऊपर original post से जैसा दिखता है, अच्छा है कि मेरा अनुभव कोई general rule नहीं है। लेकिन करीब 10 साल पहले जब मैं एक काफी मशहूर app वाली कंपनी में काम करता था, तब एक update ने app performance पूरी तरह खराब कर दी थी

      ठीक उसी समय एक competitor ने बिना performance problems वाला app launch किया। बाद में पता चला कि उस competing app का developer कुछ समय पहले ही Apple छोड़कर गया था, और उसने Apple के video driver में एक undocumented trap छोड़ दिया था, जिससे हमारा app टूट गया। competitor binary को disassemble करने के बाद ही हम undocumented change ढूँढ पाए और app ठीक कर सके। उस developer ने हमारे CEO को email में ताना भी मारा। क्या शानदार दुनिया है

  • Metal profiler में एक बहुत उपयोगी feature है जिससे application profile करते समय Metal performance state चुना जा सकता है। profiler के बाहर इसे set नहीं किया जा सकता

    इससे लगता है कि कोई private API जरूर होगा। क्या reverse engineering वाला रास्ता ज्यादा आसान नहीं हो सकता? बेशक, अगर ऐसा न हो कि इसके लिए कोई special entitlement चाहिए जिसे SIP बंद किए बिना bypass नहीं किया जा सकता

    • इसके लिए निश्चित रूप से private API होना ही चाहिए। लेख में भी यह लिखा है

      “Metal profiler में एक बहुत उपयोगी feature है जिससे application profile करते समय Metal ‘Performance State’ चुना जा सकता है। profiler के बाहर इसे set नहीं किया जा सकता”

      अगर यह private API नहीं है, तो Metal profiler इसे कैसे कर सकता है? क्या किसी debugging tool से profiler को observe करके यह पता नहीं लगाया जा सकता कि अंदर क्या हो रहा है?

  • इस API को सार्वजनिक करने की समस्या यह है कि बहुत सारे developers हमेशा सबसे high-performance state को जबरन चालू रखेंगे। API देते हुए इसे रोकने का सचमुच कोई अच्छा तरीका है या नहीं, पता नहीं

    • Battery-powered devices पर किसी एक app के power बरबाद करने के तरीके पहले से ही अनगिनत हैं। आखिरकार व्यवस्था पहले से ही इस भरोसे पर टिकी है कि developers जानबूझकर या गलती से energy-intensive tasks को बेवजह नहीं चलाएंगे। ठीक से इस्तेमाल न करने पर power बरबाद कर सकने वाली एक और API आ जाने से बहुत बड़ा फर्क नहीं पड़ेगा

    • लेख में Game Mode की भी बात है, जो नए Apple operating systems में ऐसे मामलों के लिए optimized feature है। Game Mode चालू होने पर notification आता है, और ज्यादातर applications ऐसा नहीं चाहेंगी। अब तक मैंने इसके दुरुपयोग का कोई मामला नहीं देखा है

    • Developers अभी तक सभी thread pools में audio workgroup का दुरुपयोग करके P-core scheduling और high priority हासिल नहीं कर रहे हैं। अगर ऐसा है, तो इससे संकेत मिलता है कि जब audio workgroup GPU को commands जारी करता है, तो पिछली बार workgroup ने data कब भेजा था, उसके आधार पर GPU downclocking पर किसी तरह का timeout लगाया जा सकता है

      GPU audio आजकल बहुत niche field है, लेकिन लेख में बताई गई company ने हाल ही में SDK जारी किया है, इसलिए यह ज्यादा mainstream हो सकता है। फिर भी बात बहुत convincing नहीं लगती। GPU पर process करने का मतलब करीब-करीब यह है कि latency की परवाह नहीं करनी है, इसलिए मुझे लगता है कि बस input/output buffer size बढ़ा देना चाहिए

    • API का दुरुपयोग किया भी जाए, तो वही काम करने के लिए fake busy work चलाने से यह ज्यादा efficient होगा। Apps पहले से ही API के बिना, या API द्वारा मांगी जा सकने वाली permissions के बिना भी ऐसा कर सकती हैं

    • Manual permission grant कैसी रहेगी? कहीं छिपाकर रखी जाए तब भी, बहुत niche apps को इसकी जरूरत पड़ने की काफी संभावना है

      और operating system level पर Zoom, Teams, web browsers को default deny पर रखा जा सकता है :)

  • यह करने का सबसे अच्छा तरीका:

    1. WWDC videos सरसरी तौर पर देखें, और ऐसे engineer को खोजें जिसे आपकी मौजूदा समस्या की सबसे अच्छी समझ लगती हो

    2. अगर Michael Thomson हो तो mthomson@apple.com जैसे format में सीधे email भेजें

    • या उसके भाई Pichael को pthomson पर भेजें

  • वैसे, Anukari को Mick Gordon sound pack निकालना चाहिए और revenue उनके साथ share करना चाहिए। वह सचमुच कमाल की चीजें बना रहे हैं, और demo भी शानदार है। इतना powerful tool आ गया है तो artists के साथ collaborate करना अच्छा business भी है और दुनिया के लिए भी अच्छा है। अगर आपको Mick Gordon पसंद हैं—मुझे तो हैं

  • मुझे इस app की बिल्कुल जरूरत नहीं है, लेकिन यह सचमुच शानदार है। ऐसे apps computing में फिर से मज़ा लाते हैं। इसका मतलब यह नहीं कि अभी मज़ा बिल्कुल नहीं है, बल्कि यह पुराने दिनों की याद दिलाता है जब ज्यादा graphical और experimental programs घूमते रहते थे, यहां तक कि demoscene भी

  • आखिर से दूसरे paragraph में दिए गए https://x.com/Mick_Gordon/status/1918146487948919222 link को miss नहीं करना चाहिए। यह Mick Gordon का बनाया demo है, और @anukarimusic ने ऐसे reply किया:

    “lol release का दूसरा दिन है, और आपने मेरे 2 साल तक रोज इस्तेमाल करके बनाए गए सारे demos को पहले ही पूरी तरह ध्वस्त कर दिया”

  • 1024 objects को 48kHz पर update करना, code कैसे लिखा गया है उस पर निर्भर करते हुए, CPU पर भी संभव लगता है। यह प्रति सेकंड 4.8 करोड़ updates नहीं है क्या? OpenMP से कुछ loops को cores पर parallel चलाने के लिए ठीक लगता है

      1. Anukari polyphony के लिए पूरे physical model की अधिकतम 16 copies चलाता है। यानी 16 * 1024 * 48K। Blog post update करनी होगी

      2. User objects को आपस में मनचाहे तरीके से connect कर सकता है, इसलिए हर object को N दूसरी entities के connections पढ़कर process करने पड़ते हैं

      3. पूरे CPU का इस्तेमाल करने के लिए हर physics step पर cores के बीच synchronization चाहिए, और यह slow है

      4. प्रति object processing काफी ज्यादा है। Transcendental functions बहुत हैं और approximation भी संभव है, लेकिन features भी बहुत हैं। सभी parameters modulate किए जा सकते हैं, NaN-safe भी होना चाहिए, वगैरह कई बातें ध्यान रखनी पड़ती हैं

      5. Users कई tracks और effects आदि के लिए Anukari की कई instances parallel में चलाना चाहते हैं

      दूसरे तरीके से देखें तो 4 GHz / (16 voice * 1024 obj * 4 connections * 48,000 sample) = 1.3 cycles per thing है

      GPU इस workload को पलक झपकते handle कर लेता है। इसकी structure पूरी तरह match करती है। 16 voice * 1024 obj सभी को पूरी तरह parallel process किया जा सकता है, हर step की synchronization भी simple है, और user L1 cache manage कर सकता है

    • अगर calculation सही है, तो एक sample calculate करने में 83 clock cycles निकलते हैं। 16 cores हों तो theory में 1333 cycles हैं, और यह बहुत ज्यादा नहीं है। यह देखते हुए तो और भी कि CPU को हमेशा लगभग 100% पर इस्तेमाल नहीं किया जा सकता