Musik, Audio, Medien und Gesellschaft

64 BIT – Windows-Systeme (in der Audioproduktion) – Teil 2

Letzte Woche hatten wir den ersten Teil, heute geht es mit Teil 2 weiter! Bitte lest zunächst den den Workshop von letzter Woche 😉 Wie die breite des Adressbusses mit der Menge des adressierbaren Arbeitsspeichers zusammenhängt, haben wir ja bereits geklärt. Was bedeutet das praktisch?

[amazon_carousel widget_type="ASINList" width="580" height="200" title="64Bit DAW" market_place="DE" shuffle_products="False" show_border="False" asin="B004K3206K, B002JEAJWO, 3827329140, B001GIHLMU, B003JG3W5C, 1458402266, 3941531093, 393784144X" /]

Mit jedem Bit mehr auf dem Adressbus, verdoppelt sich der verfügbare Adressraum. Das ist so, weil jedes Bit ja nur „1″ oder „0″ als Wert annehmen kann, und somit zwei „Schaltzustände“ hinzukommen. Zur visuellen Verdeutlichung:

Vier BIT breiter Datenbus

Vier BIT breiter Datenbus

…und mit verdoppelter BIT-Zahl…

Ein ACHT Bit breiter Datenbus

Ein ACHT Bit breiter Datenbus

…und so weiter.

64BIT-Systeme sind aber nicht per se schneller, besser und performanter als 32BIT-Systeme, zumindest wird man praktisch niemals eine Leistungsverdopplung feststellen. Vergleichen wir den Datenbus nochmal mit der Autobahn: Auf einer Autobahn geht es nicht automatisch schneller voran, weil eine neue Spur hinzu kommt, zumindest dann nicht,wenn von den vier ursprünglichen nur zwei genutzt werden. Wenn die Autobahn hingegen voll ist, und „aus dem letzten Loch“ pfeift, dann wird jede Spur eine merkliche Entlastung und auch einen Geschwindigkeitshub bedeuten. Nur die einzelnen Autos fahren deshalb nicht schneller –> analog dazu reisen die Datenpakete auf dem Datenbus auch nicht schneller, es können nur mehr Daten gleichzeitig abgewickelt werden.

Lohnen sich 64BIT für die Audioproduktion nun? Ein klares JA und ein klares NEIN:

Nun könnte man sich ja auf das Argument versteigen, dass samplebasierte VSTis die Daten mittels Diskstreaming von der Festplatte ziehen und somit der Arbeitsspeicher relativ unwichtig ist und allenfalls Komfort bringt. Dazu muss man wissen, dass in einem Windows 32-Bit-System die maximale RAM-Zuteilung pro Prozess (auch Thread genannt) 2GiB sind. Mehr RAM wird den einzelnen Anwendungen nicht zugeteilt. In der Praxis hat sich gezeigt, dass es (je nach System) eine „magische Grenze“ gibt (die Größe der Pagefile ist ein guter Indikator), ab der das System keine Session-Files mehr speichert, funktionieren tut alles noch eine ganze Weile, bis der Arbeitsspeicher noch ein wenig voller gepackt wird. Jetzt wird der aufmerksame Leser sagen: „Jaaaaa das liegt an Werbung:Cubase!“ – Leider falsch! Es ist bei allen von mir dahingehend getesteten (VSTi-)Hosts der Fall. „Jaaa das liegt an Werbung:Kontakt…“ – Leider auch falsch! Ich habe das Problem mit der Halion-Engine zum ersten Mal gehabt, und konnte es auch unter der Werbung:Spectrasonics-Engine, der Werbung:PLAY-Engine von EastWest und anderen Produkten erleben :-(.

Deutlich entschärft wird das Problem, wenn man die VSTis auf mehrere Hosts (Prozesse/Threads) aufteilt, wie das zum Beispiel mit dem Linux-Sampler der Fall ist, dazu folgt noch mehr im nächsten Teil. Ein Supportmitarbeiter eines großen Softwarehauses für Musiksoftware erklärte mir, dass das Systemverhalten im „Grenzbereich“ ist „nicht ausreichend erforscht“. Kein Scherz, dass war die Aussage eines Herstellers :-).

Dabei bleibt die Frage, wo die Grenze des 32-BIT-Systems ist völlig auf der Strecke; denn es kann so pauschal einfach nicht gesagt werden. Als ich angefangen habe mich intensiver mit großen Libraries zu befassen, habe ich versucht die Grenze des Machbaren auszuloten – nicht mal Hersteller und Supporter scheinen genaueres zu wissen. Natürlich habe ich auch versucht die Grenze des Machbaren weiter heraus zu schieben, davon berichte ich das nächste Mal mehr.

Das könnte Dich interessieren...

Schreibe mir

@

XHTML: Erlaubte Tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

OHRpost läuft stressfrei mit WordPress | WPD und Kommentare (RSS)
OHRpost ist ein Projekt von Florian Scholz - Design: 2014-2018 FCScholz.de     Impressum   |   Datenschutzerklärung