So, ich habe nun meine weiteren Tests auch gemacht, diesmal mit installierten Quicktime, ich vergaß zuvor wahrscheinlich zu sagen, dass das .mov footage nen Platzhalterbild hatte, weil ich QT noch nicht hatte, jetzt ist es installiert.
Aber Bilder sagen erstmal mehr als Worte, im ersten Blog war es mit Fragmentierung des DLL Adressraums (erklär ich unten), die anderen Beiden ohne (also Hacken rein in den Voreinstellungen, so wie bei freezer).
Der erste Test hat mich nicht gewundert, dass mit 2 Core nen Tick schneller ist, kann auch gleich sein und im Hintergrund bremste was.
Im zweiten Durchgang bin ich einfach mal zum Anfang der Datei und da war es Überraschend, das mit 4 Core schneller ist als mit 3, aber noch immer langsamer als mit 1 oder 2, verblüffend.
Nun dachte ich mir, ich benutze nur eine Instanz der Libraries (Hacken rein bei DLL, wie bei freezer), könnte was bewirken, wenn die Effekte (sind DLL´s) nicht mehrfach vorhanden sind.
Bringt was, aber der gleiche Effekt, 4 C schneller als 3 C, dennoch langsamer als mit 1 oder 2 C.
Das gleiche habe ich dann noch mal im Framebereich von 1500-1550 getestet und da ist es anders, am schnellsten wieder mit 1 Core und mit 4 am Langsamsten.
Auffällig war immer, um so mehr Cores, um so länger war die Vorberechnung der Instanzen, weil er vermutlich mehr Schienen vorbereiten muss, daher würde ich sagen, das unser Testausschnitt da auch eine Rolle spielt.
Aber, weiter erwies Thom, das ohne Multiframerender, es schneller geht, wie meine Tests auch zeigen, genutzt wird immer alles und ich denke bei Einzelbildausgabe oder Überhaupt, wenn das speichern und Komprimieren länger dauert als das berechnen der Komposition, das ohne Multiframe besser und schneller ist.
Disk Operationen können nun mal ausbremsen.
Ich habe auch irgendwie das Gefühl, das QuickTime eine Rolle spielt, wer nett freezer wenn Du dein Test am Mac wiederholen könntest, ohne die Mov Datei im Projekt, vielleicht auch zum PC, ich werde das auch bei mir mal machen, also weitere Tests, nur vermutlich erst nach Weihnachten, je nach dem.
Es können sich auch andere mal an Tests beteiligen, welche CS3 oder CS4 besitzen und mind. Dualcore!
Hier nun wie gesagt mal die Erklärung, ganz mager damit es jeder wo versteht, mit dem DLL-Adressraum, wird dieser Fragmentiert (ohne Hacken drin) werden alle nötigen DLL´s (auch Plugins) als eigene Instanzen geladen, für jeden Core und Ablauf, wird dieser nicht fragmentiert, bleibt davon eine Instanz die jeder Vorgang dann aufruft. Der Vorteil ist, wenn Hacken drin ist, das Speicher gespart wird .
Ich erhielt eben, als ich hier schreibe, eine Info, die Multicore Unterstützung ist nur auf 32Bit Systemen optimiert, auf 64 Bit Systemen können erstaunliche Effekte in der Geschwindigkeit auftreten und nur Turbo der i7 Reihe ist Effektvoll, SMT sollte da auch nicht aktiv sein, da es die Speicherverwaltung mehr bremst, als es Sinnvoll im Speed genutzt wird.
Weiter managed AE 3,25 GB pro Core maximal, bei 32 Bit voll und bei 64Bit sind es nur 1,625 Effektiv, bei 64 Bit Systemen geriet die Speicherverwaltung außer Kontrolle mit mehreren Cores. Hierzu soll man auf eine 64Bit Version von AE warten, wie Photoshop, oder eben die Speichernutzung herab senken, was nur effektiv ist, wenn mind. 16GB installiert sind.
Hintergrund, AE allocate nur den tatsächlichen Speicher für 32Bit, und rechnet diesen nicht für 64 Bit hoch, AE merkt sich daher den Verbrauch, der aber tatsächlich bereits doppelt so hoch ist, Rest ist Auslagerung.
Mit meinen Worten, wenn AE sagt, ey Alta geb man en Gig mir, dann kriegt er 2 und er meint er hat nur 1. Jetzt verstehe ich auch, das bei den Tests immer mit ein Core die Line des Speichers nahezu Konstant war und sonst wie die Alpen.
Fazit: wir müssen auf CS5 warten
Ich habe es selbst auch getestet, also Speicher reservieren (allocmem) und Windows denkt sich fröhlich, bekommst, aber die andere Hälfte nehmen wir von der Pladde.
Was ein Scheiß. Ich habe XP64, freezer du hast Vista, kannst Du testen ob er da besser mit umgeht, wenn du mal eben die Codezeilen nicht selbst schreiben willst, gebe ich Dir mein Programm, oder Source wenn du lieber selbst Compilern willst.
Demnach muss ein PC mit 8GB und 64Bit BS, etwas langsamer sein, als mit 4GB und 32Bit BS, das werde ich testen!!!!
Dafür aber ein PC mit 16GB und 64Bit BS wiederum schneller, das wird auch getestet, jetzt will ich es wissen. Speicher ist bestellt und geht am 04. Januar raus.
Die 64Bit Falle, ja warum ist man nicht eher darauf gekommen, hmpf.