[Strom]

Alles klar, danke an euch.

Ich schätze mal wir kriegen nicht raus wo der rest vom Arbeitsspeicher verbleibt, aber ich habe meiner meinung nach immer mehr gb ram ausgelastet als die Prozesse zusammen ergeben. liegt es vielleicht echt an 64 bit. vielleicht kann ja ein 32bitler ma zusammenrechnen und schauen ob er auf den angegebenen wert kommt oder kommt das nie hin?

[klawitter]

Zitat (DK2000: 17.04.2009, 14:35)

@klawitter:

Ne, Memory Remapping ist dazu da, um den ansonsten "verlorenen" Speicher unterhalb der 4GB Grenze oberhalb der 4GB Grenze nutzbar zu machen. Er wird halt von unten nach oben "verschoben", neben noch ein paar andere Sachen. Das ganze ist halbwegs verständlich in der Chipsatz Dokumentation von Intel beschrieben (z.b für den P35 im Kapitel 3).

ich hatte es bislang immer so verstanden, dass per memory remapping programme 'unten' adressieren können weil der reservierte speicher 'oben' quasi wieder 'drangeklebt' wird, weil 32bit programme in 64bit-systemen nicht auf die idee kommen, oberhalb 4gb resp 3,x überhaupt nach arbeitsspeicher zu suchen (es nicht können). damit wird der 'verlorene' speicher, der jetzt nach 'oben' geschoben ist, 'unten' nutzbar gemacht und 32bit programme können die 'unteren' 4gb voll nutzen. lieg ich da so falsch?

ok, das mit verlaufen etc. ist eine etwas unscharfe aussage... ich dachte da nur bildlich: wenn die tür 1 meter weiter entfernt ist als gewohnt, rennt ein 32-bit-programm immer wieder gegen die wand an dem ort, wo es die tür gewohnt ist...

ich les mal deinen link... wer weiss, wofürs noch mal gut sein wird...

Dieser Beitrag wurde von klawitter bearbeitet: 17. April 2009 - 14:17

[DK2000]

@Strom:

Das Problem an der Sache ist, so wie ich das sehen, dass er den Festplattencache nicht verwendet bzw. nur stark verzögert schreibt. In den Systeminformationen für Audition steht zwar "Z:\Temp\AudxBUDA.tmp [1] Used 2763200 K of 4000000 K", aber das stimmt nicht. Die Datei ist 0 K groß. Er versucht tatsächlich die komplette Audiodatei erst einmal als wav komplett in den Speicher zu laden, was natürlich Unmengen an RAM verschlingt. Das passt irgendwie nicht. Vermute aber mehr, dass ist eine Inkompatibilität mit Vista x64 und seinem Dateicache ist. Das würde auch erklären, warum der "verbratene" Speicher nicht weiter aufgeführt wird und der Wert "Cached" im Taskmanager im gleichen Maße anschwillt. Unter Windows XP verbraucht Audition wesentlich mehr Platz auf der Festplatte (daher auch das mit dem primären und sekundärem Cache auf zwei Festplatten). Die Systemanforderungen sehen vor: 512MB of RAM (1GB for DV playback; 2GB for HDV and HD playback). 4GB sollten also mehr als genug sein.

@klawitter:

Das ist alles komplizierter. Dadurch dass noch 32bit Kompatibilität auf Hardwareseite benötigt wird, kann der Adressraum von 0 GB - ENDE nicht linear verwendet werden. Die alte 4 GB Grenze muss nach wie vor berücksichtigt werden, weswegen der Adressraum erst einmal in 0 GB - 4 GB und in 4 GB - ENDE eingeteilt wird. Aber das ist nur die Hardwareseite. Was die Speicherverwaltung von Windows macht, ist eine ganz andere Sache. Da Windows den Adressraum so oder so virtualisiert und die Zuordnung der virt. Adresse zu physik. Adresse über eine Tabelle regelt (PTE), kann eine 32bit Anwendung auch schon mal über den gesamten nutzbaren Speicher verteilt werden und so auch oberhalb der 4GB grenze landen. Nur bekommt die Software davon nichts mit, da diese nur die virtuelle Seite sieht.

Alles sehr kompliziert. Das Ganze wäre wesentlich einfacher, wenn sowohl die gesamte Hardware als auch Software vollständig 64bit kompatibel wäre. Dann könnte man das Alles wesentlich vereinfachen.

Dieser Beitrag wurde von DK2000 bearbeitet: 17. April 2009 - 15:23

[klawitter]

@ DK2000

This is usually the point in the discussion where the majority of folks start getting confused and their eyes start to glaze over.

durch die brust ins auge... aber einen klaren cut dieser 32/64-suppe wird es in absehbarer zeit wohl nicht geben. danke für die klärungsansätze (und den lesestoff... )

[Strom]

danke an euch,
also wenn audition unter xp 32 bit mehr speicher verbraucht (angezeigt), dann liegts wohl an 64bit. Ich finde es ja total hirnrissig, das Windows 7 nochmal in 32bit rauskommt. Weil der umstieg auf ein neues betribssystem sowieso neue Treiber uns software erfordert. und grade bei windows 7 was ja ein so gutes image hat, da bieten die hersteller doch tatsächlich jetzt schon die passenden treiber für windows 7 an, obwohl es noch es noch in der betaphase ist. ich glaube da würden sich die hersteller auch ins zeug legen damit alles auf 64bit läuft, wenn windows 7 nur in 64bit kommen würde. eindeutig eine verpasste chance!

[berndpfe]

Mich wunderts eigentlich nicht daß so ein Programm zur AV-Direktbearbeitung so viel Speicher wie gerade im System vorhanden ist, verwendet.
Um effizient bearbeiten zu können wird möglichst viel (!) von dem was in der zu bearbeitenden
Datei ist, voraus in den Speicher geladen.
Das Programm selber benötigt für den eigenen Betrieb eher "normale" Bereichsgrössen.
Was aber dazu zählt, ist wohl oder übel der Cache für die Arbeitsdaten des Programms,
und der steigt gewaltig je länger so ein Clip ist und je besser die Qualität ist die man
eingestellt hat resp. in der man das was man daraus macht, zu reproduzieren.
(z.B. zum Umcodieren in ein anderes Format).

Jedenfalls ist "enormer" wenn nicht "astronomischer" Speicherverbrauch gerade im
Multimediabereich und bei langen Clips die man bearbeitet, an der Tagesordnung.
Prefetching ist da ein Muss, um effizient und schnell von Szene zu Szene zu kommen,
Szenen zu verschieben, typische "Cutting"-Aufgaben, Zusammenstellungen zu verändern
usw. usw.

[DK2000]

Nein, das Programm verhält sich normaler Weise anders. Das ist ein Problem mit dem Dateicache von Vista x64. Ich hatte das Programm schon damals, als es sich noch Cool Edit Pro hieß und es kam mit 1 GB Arbeitsspeicher locker aus, weil es eigentlich nur sehr wenig in den Speicher läd, dafür aber sehr sehr viel in seinen Cache auf der Festplatte schreibt. Anders wäre es bei dem Program auch gar nicht machbar, da man damals schon mit Cool Edit Pro bis zu 64 Tracks gleichzeitig aufnehmen bzw. laden und bearbeiten konnte. Adobe hat das ganze dann auf 80 simultane Aufnahmen und 5.1 Support erweitert. Cool Edit Pro/Audition ist eigentlich mehr ein Festplattenrecorder/-editor und profitiert ungemein von einer großen und schnellen Festplatte (o. RAID 0 Array). Arbeitsspeicher hat es noch nie viel benötigt. Daher hatte mich das auch gewundert, warum es bei Strom die 4 GB bis zur Erschöpfung zumüllt.

Das Problem ist jetzt unter Vista x64 halt, dass der Vista Dateicache die Daten nur sehr verzögert auf die Festplatte schreibt und anschließend den Cache nicht sofort wieder frei gibt. Die einzelnen Daten, welche eigentlich auf nur auf der Festplatte sein sollten, bleiben im Speicher und belegen den. Erst wenn man das Programm beendet, gibt Vista den seinen Cache mit etwas Verzögerung wieder frei. Das passt so nicht.

Hier ist mal eine Kurve für den Vista Dateicache und dem freien Speicher:



Das Einzige, was ich da gemacht habe, ist Audition starten und die Audiodatei laden. Die Lücken waren die Punkte, wo der Rechner nicht mehr reagiert hat. Und der Verlauf bleibt auch so. Erst als ich Audition über dem Kill Switch im Process Explorer beendet habe, hat Vista nach einer Verzögerung den Dateicache wieder geleert. Das sollte so eigentlich nicht sein.

Dieser Beitrag wurde von DK2000 bearbeitet: 18. April 2009 - 08:57