Technischer Appell eines Anukari-Entwicklers an Apple

• Anukari ist ein 3D-Physiksynthesizer in Echtzeit, daher müssen große Spring-Mass-Modelle auf der GPU berechnet werden. Wenn unter Apple silicon macOS der GPU-Takt nicht ausreichend ansteigt, ist es schwierig, die Bedingungen für Audio-Latenz einzuhalten.
• Die Struktur, in der eine DAW das Plug-in für jeden Audio-Pufferblock aufruft, greift mit den Power-Management-Heuristiken von macOS ineinander, sodass es so aussehen kann, als ruhe die GPU zwischen den Blöcken und deshalb in einem niedrigen Leistungszustand verbleibt.
• Im Metal Profiler von Xcode Instruments funktioniert alles normal, wenn der Performance State auf Maximum steht, und deutlich schlechter bei Minimum. Das bestätigt, dass der Flaschenhals im Kern die GPU-Taktfrequenz ist.
• Derzeit wird als Umgehung die Strategie „waste makes haste“ genutzt, bei der die GPU-Last mit einem kleinen Spin-Kernel künstlich erhöht wird, aber auf mancher Pro-/Max-Apple-Hardware bleibt das Problem weiterhin bestehen.
• Der Entwickler bittet das Apple-Metal-Team um eine GPU-Erweiterung des Audio Workgroup-Konzepts, eine Option für Echtzeit-Sensitivität in MTLCommandQueue oder Hinweise auf eine bereits vorhandene Lösung und weist darauf hin, dass unter Windows dieselbe Spin-Loop nicht nötig ist.

---

Das GPU-Leistungsproblem von Anukari unter macOS

• Anukari 3D Physics Synthesizer simuliert zur Audioerzeugung in Echtzeit große Spring-Mass-Physikmodelle.
• Um eine relevante Anzahl physikalischer Objekte zu unterstützen, ist eine GPU nötig, und der Physikcode ist eher ALU-bound als durch Speicher limitiert.
• Der veränderliche Zustand der Simulation wird im Threadgroup Memory der GPU gespeichert.
  • Das ist eine Struktur ähnlich einem manuell zugewiesenen L1-Cache und daher sehr schnell.
• Typischerweise wird Anukari als AU- oder VST3-Plug-in in einer DAW wie Pro Tools oder Ableton ausgeführt.
  • Die DAW ruft Anukari für jeden Audio-Pufferblock auf.
  • Anukari startet für jeden Block einen GPU-Physiksimulations-Kernel, wartet auf das Ergebnis und gibt dann zurück.
• Audio-Pufferblöcke können die Verzögerung durch GPU-Kernel-Scheduling über mehrere Samples verteilen, aber die eigentliche Laufzeit des Kernels bleibt dennoch entscheidend.

Konflikt zwischen macOS-Energiemanagement und Echtzeit-Audio

• Apple silicon kann zur Energieeinsparung die Taktfrequenz des Chips senken, und macOS hält einen niedrigen Takt aufrecht, wenn es den Verarbeitungsbedarf als gering einschätzt.
• Die Art, wie Anukari in einer DAW läuft, passt nicht gut dazu, wie macOS den GPU-Bedarf einschätzt.
• Die GPU ist zwischen Audio-Pufferblöcken im Leerlauf, sodass die durchschnittliche Last zum Beispiel nur wie etwa 60 % wirken kann.
  • Die tatsächliche Heuristik von macOS ist nicht bekannt, es wird aber vermutet, dass sie so etwas wie einen Load Average verwendet.
  • Diese Last könnte unter dem Schwellenwert bleiben, ab dem der GPU-Takt erhöht wird.
• Anukari braucht für seine Echtzeitvorgaben geringe Latenz und dafür einen hohen GPU-Takt.
• Es ist nicht bekannt, wie weit Apple den GPU-Takt absenken kann, aber offenbar weit genug, um Anukari unbenutzbar zu machen.

Mit dem Metal Profiler bestätigtes Taktproblem

• Mit dem Metal Profiler in Apple Instruments, das mit Xcode geliefert wird, wurde bestätigt, dass Anukari ALU-bound ist.
• Im Metal Profiler kann während des Profilings ein Metal-Performance State ausgewählt werden.
  • Diese Einstellung lässt sich außerhalb des Profilers nicht konfigurieren.
• Beim maximalen Performance State funktioniert Anukari perfekt.
• Beim minimalen Performance State verschlechtert sich das Verhalten stark.
• Der Unterschied zwischen beiden Zuständen zeigt, dass die GPU-Taktfrequenz der Kern des Leistungsproblems von Anukari ist.

Die Umgehung „waste makes haste“ und ihre Grenzen

• Weil macOS den GPU-Takt nicht zum benötigten Zeitpunkt anhebt, verwendet Anukari eine separate Umgehung.
• Parallel zur GPU-Arbeit für die Audioberechnung wird eine zweite GPU-Aufgabe ausgeführt, um eine hohe Durchschnittslast zu erzeugen und macOS zum Anheben des Takts zu bewegen.
  • Diese Aufgabe ist so abgestimmt, dass sie möglichst wenige GPU-Ressourcen verbraucht und dennoch die Takt-Heuristik triggert.
  • Praktisch ist das eine Spin-Loop, die die GPU warmhält.
• Diese Strategie wird „waste makes haste“ genannt und ist in einem separaten Devlog ausführlich dokumentiert.
• Auf dem MacBook M1 des Entwicklers hat diese Methode das Problem vollständig gelöst, und Anukari läuft stabil.
• Nach dem Beta-Release von Anukari traten jedoch bei einigen macOS-Nutzern Probleme auf.
  • Besonders bei Nutzern von Pro- oder Max-Apple-Hardware scheint es viele Leistungsprobleme zu geben.
  • Im Text wird als Hypothese genannt, dass GPU-Chiplets eventuell unabhängige Takte haben oder dass die Spin-Workload auf stärkeren GPUs zu konservativ sein könnte.

Gewünschte Lösungsrichtungen von Apple

• Unter der Annahme, dass Apple-Ingenieure es besser wissen, werden einige mögliche Lösungen vorgeschlagen.
• Lösung 1: Das Audio-Workgroup-Konzept auf GPU-Verarbeitung ausweiten.
  • Die Audioverarbeitung unter macOS findet in einem Thread oder einer Thread-Gruppe namens Audio Workgroup statt.
  • Das Betriebssystem versteht, dass diese Threads Echtzeitvorgaben haben, und priorisiert sie entsprechend.
  • Eine von Audio-Workgroup-Threads verwaltete MTLCommandQueue könnte als Echtzeitverarbeitung behandelt werden, um den GPU-Takt entsprechend anzupassen.
• Lösung 2: In der Metal-API für MTLCommandQueue eine Option bereitstellen, um Echtzeit-Sensitivität zu markieren.
  • Der Takt des GPU-Chiplets, das diese Queue verarbeitet, könnte dann entsprechend angepasst werden.
• Lösung 3: Falls es bereits einen Weg gibt, das gewünschte Verhalten zu erreichen, wäre es ausreichend, wenn Apple ihn einfach mitteilt.
• Am Anfang des Artikels steht außerdem, dass Apple bereits Kontakt aufgenommen hat; Details dazu stehen in einem separaten Beitrag.

Vergleich mit Game Mode und Windows

• Apples Game Mode scheint dem ähnlich zu sein, was Anukari braucht, ist aber schwer anwendbar.
  • Game Mode ist prozessbasiert.
  • Anukari wird meist als Plug-in in einem anderen Prozess verwendet, und dieser Prozess unterstützt Game Mode nicht.
  • Anukari kann das daher nicht selbst steuern.
  • Game Mode verlangt außerdem Fullscreen, was bei Anukari normalerweise nicht der Fall ist.
• Unter Windows tritt dieses Problem nicht auf.
  • Ob das daran liegt, dass Windows dem Nutzer mehr Kontrolle über Leistungszustände gibt, oder daran, dass NVIDIA-Treiber beim Energieverbrauch weniger vorsichtig sind, ist unklar.
  • Unter Windows ist keine Spin-Loop nötig.
• Als Vergleich wird genannt, dass Windows-PCs mit schwächeren GPUs Anukari gut ausführen können, während es auf einem teuren Mac M4 Max zu Stottern kommen kann.

Warum Pipelining nicht passt

• GPU-Code zu pipelinen, um die GPU zu sättigen, eignet sich für durchsatzorientierte Workloads, aber Anukari ist latenzsensitiv.
• Wenn mehrere Physiksimulations-Kernel im Voraus geplant werden, kann die CPU den nächsten Block vorbereiten, während die GPU den aktuellen Audioblock verarbeitet.
• Pipelining erhöht jedoch den Durchsatz auf Kosten höherer Latenz.
• Jede Kernel-Ausführung von Anukari muss auf Echtzeit-Audioeingabedaten wie Mikrofoneingaben zugreifen.
• Eine speculative execution des nächsten Audioblocks im Voraus ist nicht möglich, weil die nötigen Eingangsdaten noch nicht vorliegen.

Problem beim Einfügen des Spin-Kernels in dieselbe MTLCommandQueue

• Falls die eigentliche Ursache darin liegt, dass Spin-Kernel und Physik-Kernel auf unterschiedlichen GPU-Chiplets laufen, könnte es wie eine Lösung erscheinen, beide in dieselbe MTLCommandQueue zu legen.
• Das wurde tatsächlich ausprobiert, hat aber nicht funktioniert.
• Der Grund ist, dass Anukari latenzsensitiv ist.
  • Der Spin-Kernel läuft gelegentlich etwas zu lange.
  • Diese Zeit überschneidet sich dann mit der Laufzeit des Physik-Kernels.
• Es wurde auch experimentiert mit einem kleinen Spin-Kernel und volatile Unified Memory, in das die CPU ein Flag für „exit kernel early“ schreibt.
• Selbst mit diesen Maßnahmen kommt es vor, dass der Spin-Kernel in die Zeit des Physik-Kernels hineinragt.

Warum GPU-Kernel-Hedging schwierig ist

• Es wurde auch eine Methode nach dem Vorbild von Request Hedging in verteilten Systemen geprüft, bei der mehrere Kopien des Physik-Kernels ausgeführt werden und das zuerst fertig werdende Ergebnis verwendet wird.
• Diese Methode könnte Tail-Latenz und Latenzvarianz reduzieren und gleichzeitig GPU-Last erzeugen, um das Betriebssystem zum Hochsetzen des Leistungszustands zu bewegen.
• Für Anukari ergeben sich jedoch mehrere Probleme.
  • Wenn ein Physik-Kernel länger als ein Audio-Block-Zyklus braucht, gerät dieser Kernel-Stream ins Hintertreffen.
  • Ein zurückgefallener Kernel-Stream muss in späteren Blöcken wieder aufholen und benötigt dazu ein Fast-Forward durch Kopieren des internen Zustands eines anderen Streams.
• Das Kopieren des internen Zustands ist teuer.
  • Der größte interne Zustand ist der Audiopuffer für die Delay Line.
  • Für jedes Mikrofon wird 1 Sekunde vergangenes Audio gespeichert.
  • Die Größe beträgt 48,000 samples * 50 mics * 2 channels * 16 voices * 4 bytes, also 307 MB.
  • Bei höheren Sample Rates wird es noch größer.
• Um das effizient zu verarbeiten, müsste der Dirty-Bereich jedes Hedged-Kernel-Streams präzise verfolgt und nur dieser Teil kopiert werden.
  • Das Speicherlayout des Puffers ist jedoch auf die Lese-Workload des Physik-Kernels optimiert.
  • Selbst bei minimalem Kopierumfang müssten über den gesamten Puffer verteilte Bereiche kopiert werden, was langsam ist.
• Änderungen am Nutzermodell müssten außerdem an alle Hedged-Kernel propagiert werden.
• Der Physik-Kernel hat einen wesentlich größeren GPU-Footprint als der „waste makes haste“-Spin-Kernel.
  • Hedging erzeugt mehr unnötige GPU-Last und könnte die Zahl parallel ausführbarer Anukari-Instanzen verringern.
  • Die Hedge-Kernel könnten zudem miteinander konkurrieren und dadurch alle langsamer werden.

Bereits durchgeführte Optimierungen und warum die GPU nötig ist

• Die Anukari-Simulation ist ALU-bound, daher gibt es wenig Spielraum für typische Optimierungen wie bessere Speicherzugriffsmuster.
• Um die Leistung zu erhöhen, muss der arithmetische Durchsatz optimiert werden.
  • Wo möglich, werden FP16-Operationen verwendet, um Apples ALUs besser auszulasten.
  • Mit Micro-Benchmarks wird die Instruktionsreihenfolge abgestimmt.
  • Alle physikalischen Zustände liegen im L1 Memory.
  • Für die Vektorisierung wird die Reihenfolge der Loads neu angeordnet.
• Es wird auch genutzt, dass Threads in einer Apple-SIMD-Group meist denselben Instruction Pointer teilen.
  • Unterschiedliche physikalische Objekte verzweigen oft stark in verschiedene Branch Paths.
  • Werden zwei Arten von Objekten innerhalb derselben SIMD-Group simuliert, verlangsamt Instruction Masking die Ausführung.
  • Um das zu vermeiden, wird das Speicherlayout der physikalischen Objekte dynamisch optimiert, damit die Zahl der Objekttypen innerhalb einer SIMD-Group sinkt.
  • Diese Optimierung ist im Beitrag the new warp alignment optimizer ausführlich beschrieben.
• Weitere Optimierung des arithmetischen Teils ist zwar möglich, dürfte aber nur Verbesserungen im einstelligen Prozentbereich bringen.
• Auf leistungsfähigen Maschinen kann Anukari 768 bis 1024 physikalische Objekte simulieren.
  • Jedes Objekt kann beliebig mit anderen Objekten verbunden sein.
  • Die Objekte führen typischerweise bei einer Audio-Sample-Rate von 48.000 Samples pro Sekunde eine implizite Euler-Integration aus.
  • Jedes Objekt hat 3 bis 10 Verhaltensparameter.
  • Manche Verhaltensweisen enthalten teure Operationen wie Vektorrotation, exp() und log().
  • Für Polyphonie wird die gesamte Physiksimulation in bis zu 16 parallelen Kopien ausgeführt.
• Auf einer CPU war dieser Ansatz nicht machbar; erforderlich sind die vielen ALUs der GPU, die Kontrolle über das L1-Cache-Layout und Parallelitätskonstrukte wie threadgroup_barrier.
• Ohne GPU-Verarbeitung könnte Anukari nicht existieren.

Warum die GPU Audio API keine Lösung ist

• Der CEO von GPU Audio, Alexander Talashov, hat wiederholt gesagt, dass sich das Problem lösen ließe, wenn Anukari die GPU Audio API verwenden würde.
• Der Entwickler bewertet GPU Audio als gutes Produkt, das die GPU für DSP zugänglich macht.
• Für Anukari wird GPU Audio jedoch nicht als nützlich angesehen.
• Anders als traditionelle DSP-Anwendungen ist Anukari eher ein Integrator für numerische Differentialgleichungen.
  • Es gibt zwar etwas DSP, aber der Großteil der Berechnung ist Euler-Integration.
  • DSP wie Mikrofonkompression in der physikalischen Welt wird inline innerhalb der GPU-Physikberechnung verarbeitet.
• Anukari programmiert die GPU direkt auf niedriger Ebene über Metal.
• Was benötigt wird, ist, dass Apple die GPU-Taktfrequenz zuverlässig anhebt.

[GN⁺]

Meinungen auf Hacker News

• Einige von euch haben Anukari vielleicht in meinem Show-HN-Beitrag gesehen: https://news.ycombinator.com/item?id=43873074

  In diesem Thread kam das Thema macOS-Performance auf. Anukari läuft auf den meisten Apple-Silicon-Geräten gut, einschließlich des Basis-M1, und alle meine Tests habe ich auf einem Basis-M1 gemacht; das war hervorragend. Die Hardware ist wirklich beeindruckend.

  Damit es funktioniert, musste ich allerdings einen seltsamen Workaround implementieren, der macOS dazu bringt, die GPU-Taktrate zu erhöhen, damit die Audioverarbeitung schnell genug wird. Die normalen Heuristiken von macOS zur Bestimmung des GPU-Performance-Zustands verstehen Anukaris ungewöhnliche Workload nicht.

  Deshalb habe ich am Ende die ganze Situation übermäßig detailliert aufgeschrieben und wollte um Hilfe bitten, mit der passenden Person bei Apple in Kontakt zu kommen, vermutlich jemandem aus dem Metal-API-Bereich. Bitte helft mir :)

  • Du hast es als „sehr langen und sehr technischen Beitrag“ bezeichnet, aber nachdem ich ihn bis zum Ende gelesen habe, fand ich ihn gar nicht zu lang, sondern sehr klar und gut geschrieben sowie informativ. Gut geschrieben.

    Ich hatte noch nie einen Mac, und mein PC ist auch alt und hat keine richtige GPU, daher werde ich Anukari wohl nicht so bald ausprobieren können, aber es sieht wirklich großartig aus, was schade ist. Ich hoffe, das wird bald gelöst.

  • Ich frage mich, ob du dieses Entitlement ausprobiert hast: https://developer.apple.com/documentation/bundleresources/en...

    Ich frage mich, ob com.apple.developer.sustained-execution auch in die entgegengesetzte Richtung wirkt.

  • Interessanter Beitrag, und das Problem ist ebenfalls interessant. Ich vermute, dass die Idee, Arbeit in derselben Queue auszuführen, letztlich aus demselben Grund scheitert wie das ursprüngliche Problem. Wegen der variablen Taktrate ist präzises Scheduling unmöglich, und je nachdem, wie das Betriebssystem den GPU-Takt festgelegt hat, weicht der Zeitpunkt, an dem das Spinning endet, vom idealen Zeitpunkt ab, wodurch Aliasing entsteht.

    Dann könnte es sein, dass die Spin-Arbeit nicht komplex genug ist, um die GPU auf den höchsten Takt zu bringen. Wenn sie wirklich mit maximaler Leistung läuft, sollte man den Endzeitpunkt des Spins stabil treffen können, ohne eine Software-PLL hinzuzufügen. Ich habe keine ausführliche Erklärung gesehen, wie der Spin implementiert ist, aber eine substanziellere Spin-Loop, die kontinuierlich mehr Teile der GPU auslastet, dürfte effektiver darin sein, den Takt auf maximaler Performance zu halten.

  • Ich habe Show HN verpasst, aber als ich es sah, dachte ich sofort, dass es gut zu kreativen ASMR-Soundscapes und immersivem multidimensionalem Audio passen würde. Es wäre schön, wenn du oder einer deiner Nutzer eine Demo erstellen könnte. Glückwunsch zum Projekt, und ich hoffe, du bekommst Hilfe bei dem Apple-Problem.

  • Guter Beitrag, und die Erklärung war klar und leicht verständlich. Ich bin ziemlich sicher, dass ich in anderen Kontexten genau solche Probleme erlebt habe.

• Leute, es hat funktioniert. Ich hatte ein sehr produktives Gespräch mit genau der richtigen Person aus dem Metal-Team! Danke, dass ihr geholfen habt, Apples Aufmerksamkeit zu bekommen. Mit so viel Unterstützung hatte ich überhaupt nicht gerechnet.

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

  • Es ist gut, dass es jetzt einen Workaround gibt, aber dass nicht einmal geteilt werden kann, was dieser Workaround ist, zeigt ironischerweise exakt den letzten Satz von https://news.ycombinator.com/item?id=43904921 über Apples Kommunikationsstil.

    So nach dem Motto: „Wenn man diesen Wert so setzt und dann auf jene Weise ändert, funktioniert es. Es ist nicht dokumentiert, aber jetzt wisst ihr es ja.“

    Wenn du den Workaround implementierst, wäre es schön, ihn in eine auffällig benannte Funktion zu packen, damit andere, die ähnliche Einschränkungen bei latenzempfindlicher GPU-Nutzung haben, zumindest per Disassembly einen Hinweis auf die Zauberformel finden können.

  • HN hat wieder einmal seinen eigentlichen Zweck erfüllt: bürokratische Barrieren vor dem Kundensupport großer Unternehmen zu durchbrechen.

    Glückwunsch zum Projekt und viel Erfolg.

• Ich habe bei zwei bekannten Unternehmen gearbeitet, die sehr bekannte Apps im Apple App Store hatten.

  Die Apple-Teams, mit denen wir gesprochen haben, interessierten sich überhaupt nicht für unsere Probleme. Stattdessen luden sie uns häufig in ihre Büros ein, um über die neuesten Funktionen zu sprechen, die sie auf der WWDC vorstellen wollten, und zwangen uns damit faktisch, diese Funktionen zu unterstützen. Das war Anfang und Ende unserer Beziehung zu ihnen. Wenn wir herausfinden wollten, warum fehlerhafte Apple-Software nicht funktionierte, mussten wir Technical-Support-Tickets schreiben.

  Apples Developer-Relations-Leute sind keine ernst zu nehmenden Ansprechpartner.

  • Wie der ursprüngliche Beitrag oben zeigt, bin ich froh, dass meine Erfahrung keine allgemeine Regel ist. Aber als ich vor etwa zehn Jahren bei einem Unternehmen mit einer ziemlich bekannten App arbeitete, hat ein Update die Performance der App komplett ruiniert.

    Genau zur gleichen Zeit veröffentlichte ein Konkurrent eine App ohne Performance-Probleme. Es stellte sich heraus, dass der Entwickler dieser Konkurrenz-App kurz zuvor Apple verlassen hatte und in Apples Video-Treiber eine undokumentierte Falle hinterlassen hatte, die unsere App kaputtmachte. Erst durch Disassembly des Konkurrenz-Binaries konnten wir die undokumentierte Änderung finden und unsere App reparieren. Dieser Entwickler verspottete unseren CEO sogar per E-Mail. Was für eine großartige Welt.

• Der Metal-Profiler hat eine sehr nützliche Funktion, mit der man während des Profilings einer Anwendung den Metal-Performance-Zustand auswählen kann. Außerhalb des Profilers kann man das nicht einstellen.

  Das deutet darauf hin, dass es eine private API gibt. Wäre Reverse Engineering vielleicht der einfachere Weg? Natürlich nur, sofern es nicht eine spezielle Berechtigung erfordert, die man nicht umgehen kann, ohne SIP zu deaktivieren.

  • Es muss dafür zwingend eine private API geben. Im Beitrag steht ja auch:

    „Der Metal-Profiler hat eine sehr nützliche Funktion, mit der man während des Profilings einer Anwendung den Metal-‚Performance State‘ auswählen kann. Außerhalb des Profilers kann man das nicht einstellen.“

    Wenn es keine private API ist, wie könnte der Metal-Profiler das dann tun? Könnte man den Profiler nicht mit irgendeinem Debugging-Tool beobachten und herausfinden, was intern passiert?

• Das Problem bei der Veröffentlichung dieser API ist, dass zu viele Entwickler den Höchstleistungszustand einfach dauerhaft erzwingen würden. Ich weiß nicht, ob es wirklich eine gute Möglichkeit gibt, das zu verhindern, wenn man die API bereitstellt

  • Auf batteriebetriebenen Geräten gibt es bereits unendlich viele Möglichkeiten, wie eine einzelne App Energie verschwenden kann. Letztlich beruht das System ohnehin darauf, darauf zu vertrauen, dass Entwickler nicht absichtlich oder versehentlich unnötig energieintensive Aufgaben laufen lassen. Eine weitere API, die bei unsachgemäßer Nutzung Energie verschwenden kann, würde daran nicht viel ändern

  • Der Artikel behandelt auch den Game Mode, eine Funktion in aktuellen Apple-Betriebssystemen, die für genau solche Fälle optimiert ist. Wenn der Game Mode aktiviert wird, erscheint eine Benachrichtigung, und die meisten Anwendungen dürften das nicht wollen. Bisher habe ich keine Fälle gesehen, in denen das missbraucht wurde

  • Entwickler missbrauchen bislang auch nicht in allen Thread-Pools Audio Workgroups, um P-Core-Scheduling und hohe Priorität zu bekommen. Das legt nahe, dass man beim Ausgeben von Befehlen an die GPU durch eine Audio Workgroup eine Art Timeout für das Heruntertakten der GPU setzen könnte, basierend darauf, wann die Workgroup zuletzt Daten gesendet hat

    GPU-Audio ist derzeit ein sehr nischiges Gebiet, aber da das im Text erwähnte Unternehmen kürzlich ein SDK veröffentlicht hat, könnte es populärer werden. Trotzdem überzeugt mich das nicht ganz. Verarbeitung auf der GPU bedeutet eher, dass einem Latenz egal ist; meiner Ansicht nach kann man dann einfach die Größe der Ein-/Ausgabepuffer erhöhen

  • Selbst wenn die API missbraucht wird, wäre das effizienter, als Fake-Busy-Work laufen zu lassen, um dasselbe zu erreichen. Apps können das bereits ohne API tun, oder ohne die Berechtigungen, die eine API verlangen könnte

  • Wie wäre es mit manueller Berechtigungsvergabe? Selbst wenn man sie irgendwo versteckt, dürfte sie für sehr nischige Apps nötig sein

    Und auf Betriebssystemebene kann man Zoom, Teams und Webbrowser standardmäßig ablehnen :)

• Der beste Weg, das zu machen:

  1. WWDC-Videos durchgehen und den Engineer finden, der am ehesten so wirkt, als kenne er das aktuelle Problem am besten

  2. Wenn es Michael Thomson ist, direkt eine E-Mail im Format [e-mail] schicken

  • Oder seinem Bruder Pichael unter pthomson schreiben

• Nebenbei: Anukari sollte ein Mick-Gordon-Soundpack veröffentlichen und die Einnahmen mit ihm teilen. Der Mann macht wirklich verrücktes Zeug, und die Demo ist großartig. Wenn man ein so mächtiges Tool hat, ist die Zusammenarbeit mit Künstlern gutes Business und gut für die Welt. Wenn man Mick Gordon mag — ich tue das

• Ich brauche diese App überhaupt nicht, aber sie ist wirklich cool. Solche Apps bringen wieder Spaß ins Computing. Nicht, dass es aktuell gar keinen Spaß gäbe, aber sie erinnert an frühere Zeiten, als grafischere und experimentellere Programme unterwegs waren, sogar an die Demoszene

• Den Link https://x.com/Mick_Gordon/status/1918146487948919222 im vorletzten Absatz sollte man nicht übersehen. Es ist eine Demo von Mick Gordon, und @anukarimusic antwortete darauf:

  „lol, es ist Tag zwei nach dem Launch, und du hast schon alle Demos, die ich in zwei Jahren täglicher Nutzung gebaut habe, komplett zerlegt“

• 1024 Objekte mit 48 kHz zu aktualisieren scheint je nach Code auch auf der CPU machbar. Das sind doch 48 Millionen Aktualisierungen pro Sekunde, oder? Sieht nach etwas aus, bei dem man mit OpenMP ein paar Schleifen gut parallel über die Kerne laufen lassen kann

  • 1. Anukari führt für Polyphonie bis zu 16 Kopien des gesamten physikalischen Modells aus. Also 16 * 1024 * 48K. Ich sollte den Blogpost aktualisieren

    2. Da Nutzer Objekte beliebig miteinander verbinden können, muss jedes Objekt Verbindungen zu N anderen Entitäten lesen und verarbeiten

    3. Um die gesamte CPU zu nutzen, ist bei jedem Physikschritt Synchronisation zwischen den Kernen nötig, und das ist langsam

    4. Der Rechenaufwand pro Objekt ist ziemlich hoch. Es gibt viele transzendente Funktionen, auch wenn Approximationen möglich sind, und die Funktionalität selbst ist umfangreich. Alle Parameter können moduliert werden, sie muss NaN-sicher sein und so weiter

    5. Nutzer möchten mehrere Instanzen von Anukari parallel ausführen, etwa für mehrere Tracks, Effekte usw.

    Anders betrachtet ergibt das 4 GHz / (16 voice * 1024 obj * 4 connections * 48,000 sample) = 1.3 cycles per thing

    Die GPU verarbeitet diese Workload im Handumdrehen. Die Architektur passt perfekt. 16 voice * 1024 obj können vollständig parallel verarbeitet werden, die Synchronisation bei jedem Schritt ist einfach, und der Nutzer kann den L1-Cache verwalten

  • Wenn die Rechnung stimmt, kommt man auf 83 Taktzyklen für die Berechnung eines Samples. Bei 16 Kernen wären das theoretisch 1333 Zyklen, und das ist nicht besonders viel. Umso mehr, wenn man bedenkt, dass man die CPU nicht dauerhaft nahezu zu 100 % auslasten kann