barebone99 hat geschrieben:Asso. Also Virtueller und nicht Physlikalischer Speicher ja? ;-)
Toll! Dann habe ich ja schon doppelt so viel wie sonst wenn ich auf die Zahl schaue ;-)
JEDES 32-bit Programm hat 4GB virtuellen Speicher (minus vielleicht 200-300MB, welchen Mac OS X belegt). Das war schon seit Mac OS X 10.0 so und hat sich nicht geändert.
Der physikalische Speicher kann weniger oder mehr sein. Das ändert aber nichts am Speicherbedarf des Programms, das Programm sieht stets 4GB Speicher, selbst wenn nur 1GB installiert ist. Die "Strafe" mehr Speicher zu nutzen, als installiert ist, ist das sogenannte "Swapping" oder "Paging": das Betriebssystem holt sich den fehlenden physikalischen Speicher von der Festplatte (die hoffentlich noch genug freien Speicher hat, sonst crasht Mac OS X). Das ist natürlich SEHR SEHR lahm und verhindert quasi sofort die Nutzung von Programmen, die Echtzeitanforderungen haben. Der Rechner fühlt sich zäh an, man bekommt ständigt Audio-Engine overloads, u.s.w.
Man sollte stets genug physikalischen Speicher haben, daß der "Activity Monitor" möglichst wenige "Page outs" auflistet. Ein paar MB über die Zeit sind OK und normal, aber wenn man diese Zahl in Bewegung sieht, ist was faul im Staate Dänemark. "Page in" ist stets deutlich größer, denn das Laden von Programmen zählt auch als Page In. Unter normalen Unständen kann man diese Zahl ignorieren.
Vielviel Speicher ein Programm tatsächlich belegt ist sehr schwer zu ermitteln. Das liegt daran, daß Speicher z.B. mit anderen Programmen gemeinsam genutzt werden kann (CoreAudio wird z.B. nur einmal geladen, auch wenn man iTunes und Logic gleichzeitig laufen läßt). Die "Page out" Anzeige zeigt aber, wenn es nicht mehr reicht.
Kommen wir zur "berühmten" 4GB Grenze. Wenn ein 32 Bit Programm (inkl. aller geladenen Plugins) mehr Speicher benötigt, als 4GB (minus der OS Reserve), dann stürzt es ab - früher oder später. Falls das Programm nicht abstützt, kann Mac OS X einen Absturz verursachen, weil z.B. die File-Auswahl für das Speichern nicht mehr geladen werden kann oder weil eine AudioUnit etwas mehr Speicher belegt, oder ... Man muß also vermeiden an diese Grenze zu kommen. In Logic 9 überwacht Logic den Speicher und versucht sicher zu stellen, daß selbst wenn der Speicher knapp wird, nur genug Speicher für eine Warnung übrig ist. Das kostet was 2-3% vom Speicher, aber macht das Programm stabiler. Löst es alle Probleme? Nein, falls eine AudioUnit nicht "akzeptieren" will, daß kein Speicher mehr verfügbar ist, kann die AU Logic immer noch zum Abstürzen bringen. Eine 100%ige Sicherheit gibt es leider nicht. 95%? Ja, die haben wir nun. In Logic 8 gab es 0% Sicherheit.
Diese Sicherheit hat aber natürlich den Effekt, daß Logic 9 etwas mehr Speicher belegt. Das kann dazu führen, daß _DER_ Song gerade nicht mehr paßt, der in Logic 8 gerade noch geladen werden konnte. Gleiches gilt übrigens für _jedes_ Software Update! Eine neue Version von Mac OS X kann gerade genug sein um diese Grenze zu sprengen! Selbst eine neue AudioUnit kann reichen oder die Installation von Live, welches als ReWire Slave in Logic geladen wird. Logic 9 hat mehr Features, die gibt es auch nicht "umsonst" => etwas Speicher.
Deswegen hat Logic 9 zwei Warnungen: eine, die besagt: "Der Speicher wird knapp - du bist gewarnt". Man kann sie wegklicken und ignorieren, aber Logic hat einen gewarnt! Und eine "Der Speicher ist voll - Du kann nur noch speichern". Dies ist die Meldung, welche den Crash verhindert.
Gibt es keine Lösung? Nun, es gibt zwei:
(1) Die allermeisten Songs brauchen nur sehr wenig Speicher. Deutlich weniger als 1GB. Größer wird der Speicherbedarf üblicherweise nur durch Sampler-Instrumente, von denen man evtl. auch noch viele einsetzen will. Seit Logic 8 hat der EXS24 die Möglichkeit Speicher außerhalb dieser 4GB zu nutzen und somit wird sein Speicherbedarf innerhalb der Applikation quasi irrelevant. Kontakt 3.5 hat nun einen ähnlichen Mechanismus. Dies löst das Problem und man kann i.d.R. die "4GB Grenze" vergessen.
(2) Die magischen "64 Bit", ja die Lösen das Problem auch. Endgültig (nunja, die Grenze ist 4 Mrd. mal größer als die bisherige 4GB Grenze - das sehe ich als "endgültig" für uns an). Nur gibt es ein Problem: alle AudioUnits auf dem Markt sind 32 Bit, und wie unter (1) schon beschrieben sie sie die üblichen Verdächtigen beim Sprengen der 4GB Grenze. Aber unter Mac OS X können Programme keine Plugins laden, die nicht zur Architektur passen. So wie PowerPC AudioUnits nicht von einem Intel-Host geladen werden konnten, können 32 Bit Intel-AUs nicht von einem 64 Bit Intel-Host geladen werden. Wer das nicht glaubt, kann die SnowLeopard Developer Tools installieren und AULab in 64 Bit starten: alle AudionUnits sind weg. Man hat als "beliebig" Speicher, aber keine Plugins mehr um den Speicher zu füllen. ReWire ist übrigens auch betroffen, ist schließlich auch nur 32 Bit. 64 Bit sind sicher eine gute Lösung, aber eben keine von heut-auf-morgen.