Hardware: Schnittrechner, Grafikkarten, Schnittkarten, Mischer und mehr Forum



Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard, RAM



Die Hardware ist tot, es lebe die Hardware. Fragen zu Optimierung von Schnittsystemen, den idealen Komponenten sowie Verkabelungen, RAID...
Antworten
Reiner M
Beiträge: 1282

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von Reiner M »

dienstag_01 hat geschrieben: Für MICH ist das geheimnisvoll, da nicht nachvollziehbar.
Ich denke, das verstehst du schon.
Aha. Dann sags doch bitte auch gleich so. (* edit *)

Jetzt liest es sich doch ganz anders. Nicht ICH mache es geheimnisvoll, es liegt an DIR.

Dafür kann ich leider nichts. Ich kann Dir eben nur anbieten: komm vorbei. Dann klärt sich das.

Beste Grüße,
Reiner

Edit: Ich habe Dir mal einen Screenshot beigefügt. Wie geschrieben: AVCHD 1080p50 Take-Folge aus der X909, direkt aus der Card-Copy, eine Spur. Vorschau abgespielt.
Ohne Effekte belegt Premiere Pro irgendwas zwischen 12GB bis 20GB damit, mit Effekte (hier ein Effekt, z.B. Autofarbe) siehe Bild. Die Zahlen bewegen sich real irgendwo zwischen 30GB und 40GB.

Mehr kann ich aus der Ferne nicht tun. ;)
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.



JaKub2011
Beiträge: 2

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von JaKub2011 »

Bin auch gerade am überlegen, meinen PC aufzurüsten. Insbesondere plane ich mit einer neuen Grafikkarte. Bisher war ich der Meinung, sie sollte eine gute CUDA-Unterstützung haben. Ich arbeite mit Pinnacle Studio 16, da wird ja gerade mit der CUDA-Nutzung der Software geworben. Jetzt habe ich aber im Internet ein paar Artikel gefunden, die auf einen schlechtere Bildqualität bei der Encodierung hinweisen. Da diese Artikel aber eher vereinzelt und zum Teil schon älter sind, hätte mich Euere Meinung dazu interessiert. Ist die Nutzung von CUDA überhaupt sinnvoll wenn man Wert auf Qualität legt? Oder sind eventuelle Unterschiede eher gering und zu verschmerzen?



Coco21
Beiträge: 18

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von Coco21 »

danke für Euren Beitrag.
wann kommt denn der Teil 2?



holger_p
Beiträge: 847

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von holger_p »

DV_Chris hat geschrieben:Nur zur Anmerkung:

Edius 6.54 ist eine 32Bit Anwendung, kann also nicht mehr als 2GB adressieren. Und dennoch bescheinigen Tests der Software extrem hohe Performanz bie der Wiedergabe unterschiedlichster Videocodecs. Das ohne Zuhilfename der Gpu. Somit stellt sich die Frage, warum Premiere hier so viel Ram allokiert bzw. allokieren muss?
Das scheint mir ein generelles Problem von Adobe zu sein. Die können (zur Freude der Hardwarehersteller) wohl nur ineffeziente Speicherfresser programmieren. Guck Dir den Acrobat Reader an und die diversen, größtenteils kostenlosen, Alternativen. Die sind sicherer, schneller und brauchen nur einen Bruchteil des Speichers.

32 Bit Software kann übrigens durchaus mehr als 2GB nutzen, da gibt es diverse Mittel und Wege. Ob Edius die nutzt, da bin ich mir nicht ganz sicher. Wenn ich mir Edius im Prozess-Explorer anschaue, dann sollte es möglich sein. Andersrum kann auch 64 Bit Software nicht beliebig viel Speicher belegen, auch da hat Windows (64Bit) erst mal ein 4GB Limit, das mit kleinen Tricks umgangen werden muss. Und unter dem Aspekt erscheint mir die Aussage, dass Premiere selbst (ohne Plugins) 40GB sinnvoll nutzen kann, etwas fragwürdig.


Gruß Holger



Reiner M
Beiträge: 1282

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von Reiner M »

holger_p hat geschrieben: Und unter dem Aspekt erscheint mir die Aussage, dass Premiere selbst (ohne Plugins) 40GB sinnvoll nutzen kann, etwas fragwürdig.
Unglaublich ...
:-)))
holger_p hat geschrieben: Das scheint mir ein generelles Problem von Adobe zu sein. Die können (zur Freude der Hardwarehersteller) wohl nur ineffeziente Speicherfresser programmieren.
Ja, das waren noch Zeiten, als Computer 16KB (Kilo-Bytes) RAM hatten ..., kaum guckt man auf den Kalender, sind sie rum, diese Zeiten. - Unverschämt speicherfressende Anwendungen führten dazu, dass deshalb Hersteller wie Commodore ihr Erfolgsmodell Commodore 64 mit zukunftsweisenden 64KB RAM auslieferte, die kaum ein Programm nutzte (nach Meinung der Commodre 16 Besitzer), oder doch?
PCs mit Intel-CPUs jedenfalls hatten damals maximal 640 KB RAM. Und ja: es lief! - Damals ... ;)

Programme, die mit wenig Speicher auskommen müssen, arbeiten nicht effizient. Sie arbeiten schlimmstenfalls extrem I/O-lastig, was genau das Gegenteil ist. Noch teurer (und somit ineffizienter) gehts in der EDV kaum.

----------

Die schnellwachsenden Datenmengen, die Masse und Komplexität unstrukturierter Daten, die zu verarbeiten sind, die Anforderungen an steigendem Informationsgehalt für Objekte (4K, 8K, Raw, Losless, usw. ...) wird wohl über kurz oder lang breitere Adressen erzwingen. Auch 64bit ist keine Grenze, nur ein Zustand.

Die RAM-Ausbauten werden heute schon größer. Und warum? Die Programme nutzen es!

Schon bald wird sich über 32GB oder 64GB niemand mehr aufregen. Spätestens dann ist Ruhe, wenn die vorkonfektionierten PCs das einfach mitbringen und gar nicht mehr anders zu bekommen sind. Die Diskussion wird aber nicht zur Ruhe kommen. Dann wird man eben fragen: "Machen 256GB RAM, macht 1TB RAM Sinn?" - Es geht doch auch mit 64GB ... ;)

Die Frage, die man sich stellen sollte, wenn man sich für neue Hardware entscheidet (die ja einige Jahre funktionieren soll), lautet;
Orientiere ich mich beim Ausbau an Gestern oder an Morgen?

Das gilt insbesondere für das Herz der Anlage, der CPU. Wer sich heute für eine CPU mit mindestens 8 virtuellen Kernen und sehr hoher Taktrate entscheidet, sollte m. E. mindestens 32GB RAM vorsehen.
Dieser Zusammenhang sollte nicht unterschätzt werden, weil eben RAM sowohl den Arbeitspeicher (Datenberechnung) wie auch den Erinnerungsspeicher (Cache) der CPU und ihrer einzelnen Kerne darstellt, die alle einen Teil abhaben wollen. Wird die CPU durch vermeidbare I/Os ausgebremst, ist das ineffizient. Systemkomponenten (Hard- und Software) müssen aufeinander abgestimmt sein.

Aber jeder, wie er will.

Beste Grüße,
Reiner



tom
Administrator
Administrator
Beiträge: 1485

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von tom »

Coco21 hat geschrieben:danke für Euren Beitrag.
wann kommt denn der Teil 2?
Der Teil über GPUs kommt in den nächsten Tagen (spätestens Montag ;-)

Thomas
slashCAM



DV_Chris
Beiträge: 3213

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1

Beitrag von DV_Chris »

Reiners Beitrag ist putzig, läßt aber dennoch die Frage unbeantwortet, warum Premiere Pro im Vergleich zu anderen Applikationen eine Resourcenschleuder ist...und dennoch schwächer performt.



holger_p
Beiträge: 847

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von holger_p »

Lieber Rainer,


die folgenden AUssagen glaubst Du doch wohl selbst nicht, oder?
Reiner M hat geschrieben: Programme, die mit wenig Speicher auskommen müssen, arbeiten nicht effizient. Sie arbeiten schlimmstenfalls extrem I/O-lastig, was genau das Gegenteil ist. Noch teurer (und somit ineffizienter) gehts in der EDV kaum.
Sorry, das ist für "normale" Windows PCs vollkommener Quatsch! Windows kann Speicher, den die Programme nicht anfordern, als Cache nutzen und das ist fast so effektiv als wenn ein Programm selber die Daten cached. Im Prinzip hat das Caching innerhalb der Software einen Vorteil, in der Praxis kann das aber auch zum Nachteil werden, z.B. bei Schreiboperationen, weil dann Windows keinen Platz mehr zu cachen hat.

Die Foren sind voll von Nutzern, deren Adobe Premiere zu lahm ist, Mag sein, dass die alle zu langsame Rechner mit viel zu wenig RAM haben.

Den Vergleich Edius zu Premiere Pro kann ich nicht ziehen, weil ich kein Premiere Pro habe. Vergleiche ich andere Adobe Software wie den Acrobat Reader mit anderen Readern, dann sehe ich im Prozess Explorer die gewaltigen Unterschiede. Der Acrobat Reader wirkt wie eine schwere S-Klasse, in die man einen Motor vom Käfer eingebaut hat. Beim Acorbat Reader führt der hohe Speicherbedarf keineswegs zu mehr Effizienz beim Arbeiten - der Foxit Reader ist erheblich schneller, schlanker und kann einige Dinge, die Adobe dem kostenlosen Acrobat Reader nicht zubilligt. Und nicht zuletzt war der alternative Reader in der Vergangenheit viel sicherer als das Adobe Produkt.

Reiner M hat geschrieben:
Dieser Zusammenhang sollte nicht unterschätzt werden, weil eben RAM sowohl den Arbeitspeicher (Datenberechnung) wie auch den Erinnerungsspeicher (Cache) der CPU und ihrer einzelnen Kerne darstellt, die alle einen Teil abhaben wollen. Wird die CPU durch vermeidbare I/Os ausgebremst, ist das ineffizient. Systemkomponenten (Hard- und Software) müssen aufeinander abgestimmt sein.
Also die einzelnen physikalischen Kerne eines i7 haben jeweils einen eigenen L1 und L2 Cache, insofern ist die obige Aussage falsch. Die Nutzung des gemeinsamen L3 Cache hat sich im Laufe der Generation etwas geändert. Bei Nehalem und Sandy Bridge ist es ein Inklusive Cache zwischen L2 und dem Speichercontroller, bei Ivy Brdige wurde daraus ein gemeinsamer Exklusive Cache, der wie der Speicher-Controller am Ring-Bus hängt. Beim neuen Haswell hat sich das wohl nicht geändert, obwohl Haswell eine Tock-Cpu ist.

Adobes Acrobat Reader ist im Vergleich zu anderen Readern ein Paradegegenbeispiel für Deine Theorie, dass Software mit hohem Speicherbedarf schnell und effizient ist, wenn genug Ressourcen bereitstehen. Frei nach dem Ikea Motto "Liest Du schon oder lädst Du noch" zeigt fast jeder alternative Reader das PDF schon an, während der Acrobat Reader noch nicht mal geladen wurde. Und das auf einem Rechner mit 16GB RAM und je eine SSD für System/Software UND Daten. Das ist allenfalls für die Hersteller von Pausensnacks und Kaffee effizient, nicht aber zum Arbeiten. Vielleicht blendet der Acrobat Reader ja irgendwann mal Werbung im Sinne von "Have a break, have a kitkat" ein...


Gruß Holger



CamProfi
Beiträge: 3

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von CamProfi »

tom hat geschrieben:Der Artikel ist als Einführung gedacht für Leute, die wissen wollen, aus welchen Komponenten ein System überhaupt besteht
Ok aber ihr erwähnt Adobe und Avid in dem Artikel ..Ooh glaubt ihr wirklich das Einsteiger die nicht mal wissen wie so ein PC aufgebaut ist,Adobe/Avid Programme benutzen ?
Wenn sich also der Artikel an Einsteiger wendet wo bleibt die "kleine Software "für die Masse ?
Profis,die mit den erwähnten Programmen arbeiten lesen euren Test nicht, die haben schon die richtige Hardware.



holger_p
Beiträge: 847

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von holger_p »

CamProfi hat geschrieben: Wenn sich also der Artikel an Einsteiger wendet wo bleibt die "kleine Software "für die Masse ?
Profis,die mit den erwähnten Programmen arbeiten lesen euren Test nicht, die haben schon die richtige Hardware.
Naja, es gibt eine ganze Menge Einsteiger, die mit Premiere arbeiten. Ob das alles legale Versionen sind, sei mal dahin gestellt... Adobe spricht nicht darüber, aber der Online-Zwang und das Abo-Modell soll auch das Nutzen von Raubkopien erschweren.

Ich denke aber auch, dass es sehr sinnvoll ist, eine Systemempfehlung für die gängige Schnittsoftware des Preissegmentes 100 bis 300 Euro zu geben. Selbst da muss schon unterschieden werden, ob die Software CUDA, Quicksync oder OpenCL nutzen kann - davon hängt die Wahl der Grafikkarte und evtl. des Motherboards ab.

Hinweise für die Nutzer der deutliche teureren Systeme sind ja sinnvoll, aber da wird dann im Regelfall nach den Empfehlungen der Softwarehersteller ein System zusammengeschraubt.


Gruß Holger



Reiner M
Beiträge: 1282

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von Reiner M »

holger_p hat geschrieben: Sorry, das ist für "normale" Windows PCs vollkommener Quatsch! Windows kann Speicher, den die Programme nicht anfordern, als Cache nutzen und das ist fast so effektiv als wenn ein Programm selber die Daten cached.
Heißt dass jetzt, viel RAM ist sehr sinnvoll? Wenn nicht von Programmen, dann vom System genutzt? Hmmm ... ;)
holger_p hat geschrieben: Also die einzelnen physikalischen Kerne eines i7 haben jeweils einen eigenen L1 und L2 Cache, insofern ist die obige Aussage falsch.
Heisst das jetzt, dann braucht eine CPU gar kein RAM? Erstaunlich.
Wozu ist das RAM dann gut? Worüber reden wir dann hier? ;)

-----------

Bedeutung, Funktionsweise und Nutzen eines RAMs sind wohl unbestreitbar.

Mal ein simples Beispiel für die I/O-Bremse:
Alle die User, die ihr Systemlaufwerk von HDD auf SSD ausgelegt haben, erklären einhellig einen enormen Geschwindigkeitszuwachs beim Start des Betriebssystems und der Programme.
Woran liegt das?
Weil die SSD so schnell ist?
Nur indirekt.
Es liegt daran, dass die CPU beim Abarbeiten der Programmschritte nicht durch die langsame HDD laufend anhaltend ausgebremst wird und die nötigen Daten im RAM schneller vorfindet, wohin sie ja zunächst transportiert werden müssen. Die SSD liefert schneller, was die CPU braucht.

Mit anderen Worten: eine schnelle CPU nützt gar nichts, wenn ich sie ständig in Waits auf I/Os zwinge. Das ist insbesondere für den non-linearen Videoschnitt ein heikles Thema. Das kann man natürlich ignorieren, ändert aber nichts an den Tatsachen.

Jetzt stell Dir mal vor, System und Programme würden beim Start direkt aus z. B. aus einem ROM geladen werden ... - dann nämlich würde die CPU nicht einmal durch die (im Vergleich zu RAM/ROM-Zugriffen) langsame SSD gebremst werden. Unvorstellbar? - Für mich jedenfalls nicht.

Nun sind wir in der Videobearbeitung leider sehr schnell mit Dateigrößen, Arbeitsplatzbedarf und Abläufen im RAM konfrontiert, die schnell jeden gängigen RAM-Ausbau überfordern. Dennoch gelingt es u. U. durch geeignete Maßnahmen wie Caches, wichtige Teildaten vorzuhalten, wie z. B. Soundabmischungen, Zwischenergebnisse usw., um physische I/Os auf viele Medien- und Hilfsdateien zu reduzieren.

Noch eine Rechnung: Videofile 1080p50. D.h., Eine CPU hat nur maximal 1/50 Sekunde Zeit um einen neuen Frame in der Vorschau vollständig anzuzeigen, inklusive aller Dekodierungen, Effektberechnungen, Re-Kodierung, Demuxen, Remuxen, durch die Grafikkarte bis zum Bildschirm, durch die Soundkarte bis zu den Lautsprechern, usw. 1/50 Sekunde max.
Eine normale HDD hat im Durschnitt 8 bis 10 Millisekunden Latenzzeit. Das ist nur Plattenzeit für die Suche eines angeforderten Datensatzes im Schnitt. Kann effektiv schneller gehen, aber auch deutlich länger dauern. Dazu kommen die Übertragungszeit in den Kanal, die Zeit vom Kanal zum RAM sowie ggf. Warten in der Warteschlange, da die Zugriffe nur seriell, nicht parallel ausgeführt werden (weshalb dringend verteilte Dateisysteme (Programme/Quellen/Temps) nötig sind). Weit mehr als die Hälfte der verfügbaren Zeit für die Anzeige eines Frames in einer 50p-Spur geht also ggf. allein für Warten auf I/O drauf, u. U. sogar alles, dann ruckelts eben.
Mit SSDs gehts schon besser.
Liegen die Daten aber schon im RAM, wenn sie gebraucht werden, gehts quasi latenzfrei. Die CPU kann dann die Zeit für Berechnungen maximal nutzen.

Natürlich: Programme müssen auch so programmiert sein. Adobe Premiere Pro ist es.

Beste Grüße,
Reiner



holger_p
Beiträge: 847

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von holger_p »

Reiner M hat geschrieben:
Heisst das jetzt, dann braucht eine CPU gar kein RAM? Erstaunlich.
Wozu ist das RAM dann gut? Worüber reden wir dann hier? ;)
Nein, es ging um die Aussage
Reiner M hat geschrieben: weil eben RAM sowohl den Arbeitspeicher (Datenberechnung) wie auch den Erinnerungsspeicher (Cache) der CPU und ihrer einzelnen Kerne darstellt, die alle einen Teil abhaben wollen
Das ist eben sachlich falsch - der Cache ist ein separater Speicher und bis Ivy-Bridge sitzt der Cache zwischen den Kernen und dem RAM. Bei Ivy-Bridge wurde das geändert, obwohl Ivy-Bridge ein Tick ist.
Reiner M hat geschrieben: Weil die SSD so schnell ist?
Nur indirekt.
Nein, direkt. Alles andere ist Haarspalterei. Natürlich muss die CPU bei einer HDD länger auf die Daten warten als bei einer SSD, aber der Geschwindigkeitsvorteil beim Booten kommt von der Geschwindigkeit der SSD. Selbst bei einem stinklahmen Atom der ersten Generation ist das so.
Reiner M hat geschrieben: Jetzt stell Dir mal vor, System und Programme würden beim Start direkt aus z. B. aus einem ROM geladen werden ... - dann nämlich würde die CPU nicht einmal durch die (im Vergleich zu RAM/ROM-Zugriffen) langsame SSD gebremst werden. Unvorstellbar? - Für mich jedenfalls nicht.
Sorry für die harten Worte: Das ist ausgemachter Blödsinn!

Booten vom ROM hatten wir mal, gabs bei jedem alten Heimcomputer wie C64 oder ZX81. Damals waren die ROMs sagenhafte 8 oder 16KB groß und das "Booten" war gefühlt ganz schnell. Das Problem ist aber, dass ROMs und EEPROMs sehr langsam sind und es auch nur vergleichsweise kleine Bausteine gibt. Selbst bei einem Mikrocontroller mit 16MHz Taktrate dauert der Zugriff auf das ROM schon 4mal länger wie ein RAM Zugriff. Flash-Speicher, wie man ihn in SSDs einsetzt, ist um ein bis zwei Zehnerpotenzen schneller und sehr viel preiswerter, wenn man mehr als 0,5MB (Megabyte, nicht Gigabyte!!!) braucht. Praktisch alle modernen Geräte haben nur kleine Boot-Roms mit typischen Größen von 16 bis maximal 256 KB. Neben den Bootroutinen sind da nur noch Routinen enthalten, die ein Einspielen von Firmware in den Flash-Speichers ermöglichen. Selbst 19,95 Billigstrouter machen das so und booten von ihrem Flashspeicher. Ist viel schneller und billiger...

Was man machen kann und es wird im Server-Bereich auch gemacht: Die SSD nicht via SATA anbinden, sondern über PCI. Damit bekommt man doppelt bis dreimal höhere Transferraten hin. Der Preis steigt aber auch und zwar überproportional zum Geschwindigkeitszuwachs.
Reiner M hat geschrieben: durch die Grafikkarte bis zum Bildschirm, usw. 1/50 Sekunde max.
Grafikkarten können das Bild aus ihrem RAM ohne CPU-Last darstellen. Ausnahmen von dieser Regel waren Heimcomputer von Sinclair oder aktuell der "Maximite 2" (Basic Microcontroller für einfache Steuerungsaufgaben), aber damit wird niemand Videos schneiden wollen.
Selbst beim Kodieren und Dekodieren greifen moderne Grafikkarten der CPU mächtig unter die Arme - warum braucht Premiere Pro wohl CUDA?
Reiner M hat geschrieben: Liegen die Daten aber schon im RAM, wenn sie gebraucht werden, gehts quasi latenzfrei. Die CPU kann dann die Zeit für Berechnungen maximal nutzen.
Du meinst das Richtige, aber auch das ist sachlich erst mal falsch. Auch auf RAM-Zugriffe muss die CPU warten. Warum gibt es wohl die Caches L1, L2 und L3? Natürlich ist der Zugriff aus dem RAM schneller als wenn man erst auf die SSD oder HDD warten muss. Allerdings muss das die Software nicht zwingend selber ins RAM packen - bei geschickter Programmierung kann man Windows dazu animieren, Dateien zu prefetchen und freies RAM als Plattencache zu nutzen. Das hat bei Dateien, die man auch beschreibt, den Riesenvorteil, das ein anschließender Schreibzugriff rasend schnell geht - Windows cached auch den und der Platz für die Datei im RAM ist ja schon da.
Reiner M hat geschrieben: Natürlich: Programme müssen auch so programmiert sein. Adobe Premiere Pro ist es.
Tja, warum schafft es Grass Valley dann mit einem 32 Bit Programm das ach so toll programmierte Premiere Pro in den Disziplinen Geschwindigkeit und Stabilität deutlich zu übertreffen? Sogar mit viel weniger RAM? Edius wird übrigens von sehr vielen TV-Stationen eingesetzt. Vor allen Dingen im Newsbereich. Dort, wo man nicht "creative" ist, sondern hart gegen die Uhr cutten muss. Wo es heißt "Hier, das Material kam gerade rein, mach mal 1:30 raus und wir brauchen es in spätestens einer Stunde".

Versteh es nicht falsch, Premiere ist sicherlich ein tolles Programm, sonst würden es nicht so viele gerne benutzen. Aber es hat ein enormen Ressourcenbedarf und den hat es meines Erachtens nicht, weil es so überlegen und effizient programmiert wurde. Es kann sein, dass diese Ineffizienz der Plugin-Architektur oder anderen Gründen geschuldet ist.

Deine Versuche, diesen Ressourcenhunger zu erklären, erinnern aber mehr an PR Texte einer Marketingabteilung und basieren nicht auf Fakten.


Gruß Holger



Frank Glencairn
Beiträge: 22706

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von Frank Glencairn »

Ich versteh's nicht.

Bei mir läuft Permiere in Echtzeit, was will man denn noch mehr?. Welchen Sinn soll es denn machen, wenn ich mein 10 Minuten Timeline in 5 Minuten abspielen kann?



Reiner M
Beiträge: 1282

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von Reiner M »

holger_p hat geschrieben:
Reiner M hat geschrieben:
Heisst das jetzt, dann braucht eine CPU gar kein RAM? Erstaunlich.
Wozu ist das RAM dann gut? Worüber reden wir dann hier? ;)
Nein, es ging um die Aussage
Reiner M hat geschrieben: weil eben RAM sowohl den Arbeitspeicher (Datenberechnung) wie auch den Erinnerungsspeicher (Cache) der CPU und ihrer einzelnen Kerne darstellt, die alle einen Teil abhaben wollen
Das ist eben sachlich falsch - der Cache ist ein separater Speicher und bis Ivy-Bridge sitzt der Cache zwischen den Kernen und dem RAM. Bei Ivy-Bridge wurde das geändert, obwohl Ivy-Bridge ein Tick ist.
Unsinn, Holger.
Sag mal, kennst Du überhaupt Caches im RAM? Muss man programmieren. Hat mit L1/L2 nichts zu tun. Andere Baustelle.
holger_p hat geschrieben:
Reiner M hat geschrieben: Weil die SSD so schnell ist?
Nur indirekt.
Nein, direkt. Alles andere ist Haarspalterei. Natürlich muss die CPU bei einer HDD länger auf die Daten warten als bei einer SSD, aber der Geschwindigkeitsvorteil beim Booten kommt von der Geschwindigkeit der SSD. Selbst bei einem stinklahmen Atom der ersten Generation ist das so.
Ja, eben!

Das ist nur der triviale Beweis, wie stark eine CPU von I/Os abhängig ist. Das ist bem Booten der Fall, das ist im non-linearen Videoschnitt nicht anders. Blende das bitte nicht aus.

Nimm also zwei unterschiedlich schnelle CPUs und eine lahme Platte.
Die schnellere CPU wird ihre Vorteile kaum nutzen können, wenn der größte Teil der Verarbeitungszeit durch Waits auf die Platte draufgeht.

Wer auf eine schnelle CPU setzt und ihr dann lahme und zu knapp bemessene Ressourcen zuweist, hat sein Geld in diese teure CPU sinnlos angelegt. Ineffizienter gehts kaum. Das sollte man wissen.

Du kannst das auch gern Haarspalterei nennen. Für mich sind das maßgebliche Fakten bei der Zusammenstellung eines Systems. Und genau darum geht es in diesem Artikel.

Nochmal kristallklar: I/Os sind das, was Systeme bremst. Und zwar gewaltig! Sie sind teuer. Sie sind ineffizient.
Videobearbeitung ist nahezu pures Arbeiten mit I/Os. Schon in kleinen Projekten kommen recht schnell viele Dateien zum Einsatz. Der Zugriff erfolgt dabei nicht streng sequentiell, sondern nahezu random: Mitten rein in die Dateien, vor und zurück, je nach Schnitt und Arbeitsweise.

Ich werde alles tun, a) um I/Os zu verhindern (RAM-Ausbau, Caches, Vermeiden von Paging, usw.), wo mich Programme unterstützen und b) wo das nicht möglich ist, sie zu beschleunigen (Datenverteilung über mehrere physische schnelle Platten und getrennte schnelle Kanäle).

Und warum? Weils effizient ist! Im Videoschnitt (und nicht nur dort). ;)
holger_p hat geschrieben: Grafikkarten können das Bild aus ihrem RAM ohne CPU-Last darstellen. ...
Selbst beim Kodieren und Dekodieren greifen moderne Grafikkarten der CPU mächtig unter die Arme - warum braucht Premiere Pro wohl CUDA?
Du kommst nicht umhin, Holger: 1/50 Sekunde für alles. Ich rede nicht vom VRAM und CUDA, sondern von I/O. Also nochmal:
Programm fordert Datensatz an, der im Arbeitsspeicher liegen MUSS - Da spielt die Grafikkarte noch lange keine Rolle. Und ob irgendwelche Berechnungen danach GPU-Unterstützt laufen oder nicht: völlig unwichtig zu diesem Zeitpunkt.
Ist der Datensatz nicht im RAM vorhanden, muss er von Platte gelesen werden. Da hilft auch die beste Grafikkarte nichts.
Ist er im RAM vorhanden, entfällt der I/O. - Das ist der Unterschied.

holger_p hat geschrieben:
Reiner M hat geschrieben: Liegen die Daten aber schon im RAM, wenn sie gebraucht werden, gehts quasi latenzfrei. Die CPU kann dann die Zeit für Berechnungen maximal nutzen.
Du meinst das Richtige, aber auch das ist sachlich erst mal falsch. Auch auf RAM-Zugriffe muss die CPU warten. Warum gibt es wohl die Caches L1, L2 und L3? Natürlich ist der Zugriff aus dem RAM schneller als wenn man erst auf die SSD oder HDD warten muss. Allerdings muss das die Software nicht zwingend selber ins RAM packen - bei geschickter Programmierung kann man Windows dazu animieren, Dateien zu prefetchen und freies RAM als Plattencache zu nutzen. Das hat bei Dateien, die man auch beschreibt, den Riesenvorteil, das ein anschließender Schreibzugriff rasend schnell geht - Windows cached auch den und der Platz für die Datei im RAM ist ja schon da.
Aha. "sachlich erstmal falsch" ... logisch. :-))

Schau mal, was Du da schreibst.
Zitat: "Natürlich ist der Zugriff aus dem RAM schneller als wenn man erst auf die SSD oder HDD warten muss." - Na, also! ;) - Meine Rede! Danke!
(Und was ist jetzt an Deiner Formulierung sachlich richtiger?)

Zitat: "Allerdings muss das die Software nicht zwingend selber ins RAM packen - bei geschickter Programmierung kann man Windows dazu animieren, ..."

a) ???
b) Wie macht Windows das? Programmiert man das etwa? Muss man eine BS-Routine anwerfen? Macht das vielleicht die Software durch geeignete System-Calls? ;)
c) Ach ja: Ist Windows eigentlich Software oder nicht? ;)
d) Wird der Zugriff dadurch schneller, wenn ein physischer I/O ansteht? - ich glaube das nicht ... ;).

Natürlich gibt es Prefetch. Natürlich kann man damit den einen oder anderen I/O sparen. Ganz anderes Thema. Denn auch Prefetch ist I/O und ggf. eine ganze Folge, die ggf. nochmal stärker auf die Bremse tritt. Okay, von mir aus: Prefetchen wir eben mal. Und dann? Wohin soll es eigentlich prefetchen, wenn Du dafür gar kein oder zu wenig RAM hast??? ;)

Ist Dir eigentlich aufgefallen, dass Du laufend davon erzählst: RAM-Zugriffe sind schnell, RAM ist gut, viel RAM ist besser, weil Programme und Betriebssystem es nutzen? ;) Na, also.

holger_p hat geschrieben: Tja, warum schafft es Grass Valley dann...
Edius wird übrigens von sehr vielen TV-Stationen eingesetzt....
Holger,
Es geht nicht um "Mein Auto - Dein Auto" - Brauchst Du das etwa ? ;)
Wenn Du mit Deiner Lösung glücklich bist, ist doch alles gut! Freut mich. Ehrlich. Die Vielfalt der Programme ist aus völlig unterschiedlichen Gründen nötig, sinnvoll und gut.

Edius kenn ich nicht gut genug. Und schon deshalb werde ich dazu nichts sagen. Kennst Du Premiere Pro? ;) - Deine Mutmaßungen, Behauptungen und Versuche, das technisch zu erläutern, sprechen für sich.

Hier geht es u. a. um die Frage, ob und wann Programme viel RAM nutzen. Ich habe aufgezeigt, dass Premiere Pro mit einem einzigen Prozess bei mir Dank Multi- und Hyperthreading 12 CPU-Kerne zu 100% belegen kann (was für den RAM-Bedarf wichtig ist), und dass es locker mehr als 32GB RAM nutzen kann, was bestritten und als unglaubwürdig hingestellt wurde.

Es nützt und ändert ja auch nichts, wenn Du das anzweifelst. Es ist so. ;)

Welche Vor- und Nachteile das im Vergleich zu irgendeinem anderen Programm hat, steht überhaupt nicht zur Debatte. Das wäre eine völlig andere Diskussion, die hier m. E. Fehl am Platz ist.

Beste Grüße,
Reiner



holger_p
Beiträge: 847

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von holger_p »

Reiner M hat geschrieben: Sag mal, kennst Du überhaupt Caches im RAM? Muss man programmieren. Hat mit L1/L2 nichts zu tun. Andere Baustelle.
Es ging Deiner Aussage um "zu programmierenden Cache der CPU" und das ist Unfug. Der ist fest. Natürlich kenne ich die Möglichkeit, sich eigene Caches im RAM zu halten. Wobei ich das für sehr bedenklich halte, denn das kann Windows auch selber machen und Windows macht das im Falle, das man die Dateien auch beschreibt, deutlich effizienter. Wie schon mal erwähnt, kann man Windows mit kleinen Tricks auch dazu ermuntern, Dateien zu prefetchen. Geht aber nur, wenn man Windows dafür noch Speicher läßt.
Reiner M hat geschrieben: Das ist nur der triviale Beweis, wie stark eine CPU von I/Os abhängig ist. Das ist bem Booten der Fall, das ist im non-linearen Videoschnitt nicht anders. Blende das bitte nicht aus.
Jeder Zugriff auf Daten ist ein I/O. Selbst der Zugriff auf den L2 Cache ist ein I/O, der auf RAM sowieso. Also bitte präzise formulieren. Du meinst Plattenzugriffe.
Reiner M hat geschrieben: Programm fordert Datensatz an, der im Arbeitsspeicher liegen MUSS - Da spielt die Grafikkarte noch lange keine Rolle. Und ob irgendwelche Berechnungen danach GPU-Unterstützt laufen oder nicht: völlig unwichtig zu diesem Zeitpunkt.
Ist der Datensatz nicht im RAM vorhanden, muss er von Platte gelesen werden. Da hilft auch die beste Grafikkarte nichts.
Ist er im RAM vorhanden, entfällt der I/O. - Das ist der Unterschied.
Siehe oben: Falscher Begriff. Auch der RAM-Zugriff ist ein I/O. Bitte sauber argumentieren !!!
Übrigens ist es egal, ob die Software selber die Datem im RAM "cached" oder Windows das macht. Wie schon mal erwähnt, kann Windows das in einigen Fällen deutlich effektiver als die Software selber. Weil Windows weiß, wo die Daten auf der Platte physikalisch stehen - das erfährt die Software gar nicht. Wenn die Software selber cached, sind die Daten oft doppelt im RAM und das ineffektiv, weil da mitunter viel Speicher verschwendet wird und weil das doppelte RAM-Caching auch Zeit kosten kann. Wie erwähnt, auch RAM-Zugriffe sind I/O.
Reiner M hat geschrieben: Hier geht es u. a. um die Frage, ob und wann Programme viel RAM nutzen. Ich habe aufgezeigt, dass Premiere Pro mit einem einzigen Prozess bei mir Dank Multi- und Hyperthreading 12 CPU-Kerne zu 100% belegen kann (was für den RAM-Bedarf wichtig ist), und dass es locker mehr als 32GB RAM nutzen kann, was bestritten und als unglaubwürdig hingestellt wurde.
Es geht darum, dass Du ein Programm, das zum gut funktionieren enorme Ressourcen verschlingt, als das Nonplus-Ultra der Softwareprogrammierung anpreist. Und genau das halte ich das für Unfug. Es ist sicherlich ein gutes Programm, aber nicht besonders effizient. Weil andere Programme eben beweisen, dass sie mit deutlich weniger Ressourcen die gleiche oder eine höhere Leistung erbringen.

Natürlich profitiert auch ein Edius von RAM. Ob es den selber alloziert oder Windows darin Dateien cached, ist völlig egal. 8GB ist Minimum, 16GB dürfen es schon sein. Aber es belegt eben nicht 40GB oder mehr. Es braucht zum Rendern kein CUDA-Monster, ein HD3000 oder HD4000 (Intel Quicksync) reicht, um 1080p50 Material in 10Bit Qualität (das wäre notfalls sendefähig) unter Echtzeit zu rendern. Natürlich ist es sinnvoll, die Projekte auf möglichst schnellen Platten vor zu halten. SSD ist ideal, weil schnell und leise, aber halt recht teuer. Wen der Krach nicht stört, ist mit einer Velociraptor auch sehr gut bedient. Es funktioniert aber sogar mit "Green" Platten, was ich nicht empfehlen würde, weil diese Platten leider sehr langsam bei den Zugriffen sind.


Gruß Holger



dienstag_01
Beiträge: 13414

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von dienstag_01 »

Reiner_M hat geschrieben:Hier geht es u. a. um die Frage, ob und wann Programme viel RAM nutzen. Ich habe aufgezeigt, dass Premiere Pro mit einem einzigen Prozess bei mir Dank Multi- und Hyperthreading 12 CPU-Kerne zu 100% belegen kann (was für den RAM-Bedarf wichtig ist), und dass es locker mehr als 32GB RAM nutzen kann, was bestritten und als unglaubwürdig hingestellt wurde.
In dem Thread geht es um Hardwareanforderungen von Schnittsoftware. Und wie meistens erschöpft sich die Aussage in einem Viel-Hilft-Viel. Deshalb hatte ich die Frage gestellt, welche Software in einem realsitischen Workflow überhaupt mehr als 8GB RAM nutzt. Ich kannte ein solches Szenario nicht. Frank Glencairn hat beschrieben, dass es mit mit 4k Red Material (mehrere Spuren) in Premiere funktioniert - ich kanns nicht nachprüfen. Du hast geschrieben, es geht mit einer einzelnen Spur AVCHD plus Effekt. Das kann ich einfach nachbauen. Und siehe, ich komme - nicht ganz - auf eine prozentual ähnlich hohe Speicherauslastung wie du. Bei einem Effekt, den ich noch NIE verwendet hatte. Aber das ist nicht wichtig. Wichtiger ist, dass, wenn man dieselbe Sequenz rendert, auf einmal eine RAM-Auslastung von ca. 25 Prozent gegenüber der Vorschau erreicht wird (ca. 8 GB gegenüber etwas mehr als 2GB beim Rendern, gesamt habe ich 16GB). Das bringt mich natürlich zu der Frage, wieso. Rendert Premiere so ineffizient? Oder liegt es schlicht und ergreifend daran, dass Premiere den RAM für die Vorschau einfach nicht leert, sondern den Speicher erst wieder mit neuen Daten überschreibt, wenn diese Daten auch angefordert werden? Ich tendiere natürlich zu letzterem ;)
Allgemein kann ich aber sagen, einen messbaren Unterschied zwischen einem RAM Ausbau von 16 zu 8GB in meinem Rechner konnte ich nicht feststellen. Adobe schreibt aber *deutlich*. Möglicherweise gibt es Szenarien, die ich nicht nutze. Aber hin und wieder einen etwas distanzierteren Blick auf solche Aussagen zu werfen, kann nicht schaden. Und spart im Zweifel Geld.



Reiner M
Beiträge: 1282

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von Reiner M »

dienstag_01 hat geschrieben:Das bringt mich natürlich zu der Frage, wieso. Rendert Premiere so ineffizient?
Dienstag,
das führt doch nur zu reiner Spekulation. Dir fehlen die konkreten Fakten. Auch ich habe sie nicht. Du kennst die Hintergründe nicht aber bist sehr schnell bei einem Urteil. Wollen wir uns wirklich ins Reich der Sagen, Legenden und waghalsigen Interpretationen begeben?

Wenn es Dich wirklich interessiert. beschäftige Dich damit. Du wirst ganz sicher sehr schnell erkennen, dass es Zusammenhänge gibt, die zzt. außerhalb Deines Radars liegen. Nicht schlimm, nur: geh mal davon aus, dass es so ist.

Fakt ist: es ist, wie es ist. - Da kommt man nicht drum rum. Nur, weil man etwas nicht weiß (wie Du z. B. im Fall, dass Premiere Pro mehr als 32GB RAM adressiert), heißt das weder, dass es das nicht gibt, noch - falls es das dann doch überraschenderweise gibt! - es "ineffizient" sein muss, nur um nicht ganz den Boden zu verlieren ... ;)

Kein User hat etwas davon, wenn man tendenziell versucht zu erklären, "der Hersteller XY könnte MEINER MEINUNG NACH das Programm ABC irgendwie anders programmieren, dann käme man auch noch mit geringeren HW-Anforderungen aus. Also Leute: lieber weniger in die Hardware investieren - ist schließlich Sache des Programms oder des Herstellers, das Problem zu lösen, wenn es denn auftritt ... " - Ich tue es jedenfalls nicht.

Nein, es ist Sache des Nutzers, ein abgestimmtes System zu kaufen oder zu konfigurieren, oder? Denn letztendlich muss er alle Vor- und Nachteile ausbaden. Genau darauf zielt m. E. die Artikel-Reihe von slashCAM.

Und nochmal deutlich: Effizienz ist ein Maß für Wirtschaftlichkeit. Das meint also das Verhältnis Ertrag zu Aufwand, z. B. hier im Videoschnitt. Man investiert z. B. in Systeme oder Komponenten, die schnelleres Rendern erlauben. Aufwand: Mehrkosten. Ertrag: koninuierliche Zeitersparniss über die Lebenszeit des Investionsgutes. Ich kann also sehr leicht einen Return on Investment ermitteln und stelle fest: Produktivität und Profitabilität steigen. Ob das dann durch mehr RAM, eine schnellere Platte, eine stärkere CPU, zusätzliche Software oder sonstwas erreicht wird, ist völlig egal.
Effizienz ist ganz klar nicht das Verhältnis viel RAM zu wenig RAM, auch nicht im Vergleich zwischen verschiedenen Programmen. ;)
Und "mein Programm nutzt aber weniger RAM!" ist sicher kein Trumpf im Spiel. Da zählt was anderes.

Beste Grüße,
Reiner
Zuletzt geändert von Reiner M am Sa 13 Jul, 2013 10:43, insgesamt 1-mal geändert.



Reiner M
Beiträge: 1282

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von Reiner M »

holger_p hat geschrieben: Es ging Deiner Aussage um "zu programmierenden Cache der CPU" und das ist Unfug. Der ist fest.
Wo habe ich das geschrieben? Hast Du schon mal 40GB L1/L2-CPU-H/W-Cache gesehen?
Bitte nicht rausreden und verdrehen, Holger. ;)
holger_p hat geschrieben: Jeder Zugriff auf Daten ist ein I/O. Selbst der Zugriff auf den L2 Cache ist ein I/O, der auf RAM sowieso. Also bitte präzise formulieren. Du meinst Plattenzugriffe.
Holger, lassen wir es einfach.
Du darfst gerne weiterhin behaupten, dass alles "Unfug", "falsch" und "nicht"präzise" ist. Ändert ja nichts an den Fakten.

Nur zur Abgrenzung:
Ein Zugriff im RAM wird durch eine simple Adressierung erledigt. Die Instruktionen im Befehlssatz der CPU sind genau darauf ausgelegt. Diese Instruktionern können überwiegend nur das: Registerinhalte oder RAM-Speicher lesen/verarbeiten/schreiben.
Die CPU-Instruktionen lesen direkt und unmittelbar Bytes aus dem Speicher von einer bekannten Adresse oder schreiben ebenso direkt Bytes rein. Als wären sie technisch in der CPU vorhanden. Ohne Umwege, ohne einen einzigen I/O.
Das sind KEINE I/Os.

RAM ist Arbeitssplatz und Gedächtnis ("Memory") der CPU. Punkt.
RAM ist CPU-Erweiterung.
Man darf sich beides gedanklich als eine untrennbar verschmolzene Einheit vorstellen. Aus technischen Gründen in der Herstellung macht es Sinn, beides als getrennte Bausteine auszuliefern.
Das allerdings macht es für den Anwender schwer, neben eine einzeln gekaufte CPU das geeignete RAM zu stellen, seine CPU optimal in der nötigen Weise zu erweitern.

RAM muss zur CPU passen, sowohl was Größe angeht (Adressumfang) wie Geschwindidigkeit (Bustakt) als auch Channel-Support (z. B. Dual, Quad).
Die Beschreibungen der CPUs geben dazu hinreichend Erklärungen, welche RAM-Riegel zu wählen sind. Leider orientiert sich offensichtlich wohl kaum jemand daran. ;) Darüber zu philosophieren, was der Nutzen von viel oder wenig, Dual oder Quad, große oder kleine Geschwindigkeiten und Latenzen ist, führt kaum zu Lösungen. Tech-Specs Lesen schon.

----------

Die Adressbreite beschränkt dabei übrigens die Größe des adressierbaren Speichers. 64bit-Programme können also deutlich mehr RAM adressieren, als 32bit-Programme. Sie wären blöd und tatsächlich ineffizient programmiert, wenn sie das nicht nutzen würden. Alles andere ist Unsinn.

Das können sie allerdings auch nur dann, wenn physisch genug RAM vorhanden ist! Die Tatsache, dass solche Programme auch mit wenig RAM funktionieren, heißt nicht, dass sie nicht mehr nutzen würden, wenn sie mehr RAM-Riegel vorfinden würden.

Richtig: 32bit-Programme können längst nicht soviel RAM durchgehend adressieren, wie 64bit-Programme. Das können sie bestenfalls durch "Tricks", wie Du es nennst, z. B. durch Aufgabenauslagerung in andere Tasks. Nur so es ihnen möglich, einen großen RAM-Ausbau zu nutzen.

Diese Tricks haben 64bit-Programme gar nicht nötig. Auch dann nicht, wenn Du persönlich das nicht anders kennst.

Wenn also ein 32bit-Programm mit weniger RAM "auskommt", also nicht über seine Grenze der 32bit-Adressierung hinaus greift, ist das kein Zeichen für effiziente Programmierung, erst recht kein Vorteil (technisch gesehen ganz im Gegenteil!), sondern nur das Faktum, dass dieses Programm gar nicht mehr kann! Ende Gelände. Punkt.

Premiere Pro ist nun mal eine 64bit-Applikation.

---------

Ein I/O hingegen wird in der Programmierung beschrieben, in dem ein I/O-Kanal explizit eröffnet wird. Dafür muss auf Anforderung des Programms ein Handle vom System bereitgestellt werden, das die Kommunikation mit den externen Komponenten (Kanal, Controller, Datei usw.) erlaubt. Danach, wenn der Kanal erfolgreich geöffnet wurde, kann eine geeignete Operation ausgeführt werden wie Lesen, Schreiben, Positionieren des Schreib-/Lesekopfes in der Datei, usw. - je nach Gerät.

Ein I/O hat den Zweck, Daten zwischen RAM und einem externen Gerät - eben gerade nicht RAM! - auszutauschen. Deswegen heißt er so: Input-/Output-Operation, bezogen auf das interne Gerät, das RAM mit angeschlossener CPU.

Tja, so ist das ...

Beste Grüße,
Reiner
Zuletzt geändert von Reiner M am Sa 13 Jul, 2013 11:37, insgesamt 1-mal geändert.



mannamanna
Beiträge: 408

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von mannamanna »

Reiner M hat geschrieben:
holger_p hat geschrieben: Jeder Zugriff auf Daten ist ein I/O. Selbst der Zugriff auf den L2 Cache ist ein I/O, der auf RAM sowieso. Also bitte präzise formulieren. Du meinst Plattenzugriffe.
...
Siehe oben: Falscher Begriff. Auch der RAM-Zugriff ist ein I/O. Bitte sauber argumentieren !!!
Nur zur Abgrenzung:
Ein Zugriff im RAM wird durch eine simple Adressierung erledigt. Die Instruktionen im Befehlssatz der CPU sind genau darauf ausgelegt. Diese Instruktionern können überwiegend nur das: Registerinhalte oder RAM-Speicher lesen/verarbeiten/schreiben.
Die CPU-Instruktionen lesen direkt und unmittelbar Bytes aus dem Speicher von einer bekannten Adresse oder schreiben ebenso direkt Bytes rein. Als wären sie technisch in der CPU vorhanden. Ohne Umwege, ohne einen einzigen I/O.
Das sind KEINE I/Os.
Genau!
Von wegen "falscher Begriff": RAM-Zugriffe sind kein I/O sondern ureigenstes Systemterritorium (nicht die CPU ist das innen und der Rest außen, sondern die Einheit CPU+RAM - darin liegt dass Fehlverständnis), dazu die Wikipedia: "In computer architecture, the combination of the CPU and main memory (i.e. memory that the CPU can read and write to directly, with individual instructions) is considered the brain of a computer, and from that point of view any transfer of information from or to that combination, for example to or from a disk drive, is considered I/O. "
http://en.wikipedia.org/wiki/Input/output

mannamanana



mannamanna
Beiträge: 408

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von mannamanna »

holger_p hat geschrieben: Übrigens ist es egal, ob die Software selber die Datem im RAM "cached" oder Windows das macht. Wie schon mal erwähnt, kann Windows das in einigen Fällen deutlich effektiver als die Software selber. Weil Windows weiß, wo die Daten auf der Platte physikalisch stehen - das erfährt die Software gar nicht. Wenn die Software selber cached, sind die Daten oft doppelt im RAM und das ineffektiv, weil da mitunter viel Speicher verschwendet wird und weil das doppelte RAM-Caching auch Zeit kosten kann. Wie erwähnt, auch RAM-Zugriffe sind I/O.
Nein, das ist falsch (nicht nur wegen der RAM I/O). Das Missverständnis hier liegt glaub ich in Deiner zu engen Definition von Cache. Windows benutzt zB einen File-Cache (den Du meinst) - ein Programm benutzt einen Cache, der Files enthalten kann, aber nicht muss - es ist einfach ein reservierter Speicherbereich, der beliebige Daten fassen kann in einer Form wie ihn das Programm definiert, z.B. die decodierten Bilddaten eines auf der Platte liegenden AVCHD-Files. Es muss also diese Daten nicht nur nicht langsam von der Festplatte lesen, sondern kann auf sie im schnellen RAM zugreifen, sondern auch nicht nocheinmal dekodieren. Wenn der RAM voll ist können diese Daten (nicht so gut weil langsam) auf die Platte geschrieben werden als auf HD ausgelagerter Cache, dann erst kann der Windows File Cache wirksam werden.

Zumal das (Videoschnitt-)Programm wahrscheinlich besser weiss als Windows, was die nächsten wahrscheinlich abgerufenen Daten sein werden und zB diese cachen kann - zB bei einem Preview.

manama



DV_Chris
Beiträge: 3213

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1

Beitrag von DV_Chris »

So viele Beiträge, obwohl es eigentlich genügen würde, dass der Reiner einsieht, dass Premiere im Vergleich zu anderen Applikationen ineffizient programmiert und dadurch eine Resourcenschleuder ist, die selbst noch CUDA braucht, um mit der Echtzeitleistung anderer mithalten zu können.



Reiner M
Beiträge: 1282

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von Reiner M »

Mal Grundsätzlich: Ich verwende meine Programme - alle! - wegen ihres großen Nutzens für mich.
Nicht, um anderen einen Gefallen zu tun. ;)

Ich finde es gut - denn ich habe viel davon! -, dass Premiere Pro und After Effects u. a. seit CS5 64bit-Applikationen sind und die Vorteile, die sich aus diesem technischen Merkmal ergeben, auch nutzen. Ich kenne diese Vorteile aus Erfahrung. Profitiere täglich davon. (Ich weiß allerdings auch, wie sie als 32bit-Applikation laufen. CS4 ist noch installiert).

Jeder, wie er mag.

Beste Grüße,
Reiner



mannamanna
Beiträge: 408

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von mannamanna »

DV_Chris hat geschrieben:So viele Beiträge, obwohl es eigentlich genügen würde, dass der Reiner einsieht, dass Premiere im Vergleich zu anderen Applikationen ineffizient programmiert und dadurch eine Resourcenschleuder ist, die selbst noch CUDA braucht, um mit der Echtzeitleistung anderer mithalten zu können.
Keineswegs ist das das Ergebnis - hier wurde nur festgestellt, das Premiere (wie auch andere Programme) von zusätzlichem RAM in manchen Nutzungen profitiert.

Um Aussagen wie die Deine machen zu können, müsste man vergleichende Tests mit einem vergleichbaren Projekt mit den verschiedenen Schnittprogrammen machen - hier beschrieben werden ja nur eigene Erfahrungen mit eigenen Projekten, was nicht ausreicht, um daraus allgemeingültige Aussagen abzuleiten.

manama



holger_p
Beiträge: 847

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von holger_p »

Reiner M hat geschrieben: Wo habe ich das geschrieben?
Am 11. Juli um 8:51 hast Du folgendes geschrieben:
Reiner M hat geschrieben: weil eben RAM sowohl den Arbeitspeicher (Datenberechnung) wie auch den Erinnerungsspeicher (Cache) der CPU und ihrer einzelnen Kerne darstellt
Wer verdreht hier was? Du kannst den internen Cache und das RAM nicht in einen Topf werfen.
Reiner M hat geschrieben: Nur zur Abgrenzung:
Ein Zugriff im RAM wird durch eine simple Adressierung erledigt. Die Instruktionen im Befehlssatz der CPU sind genau darauf ausgelegt. Diese Instruktionern können überwiegend nur das: Registerinhalte oder RAM-Speicher lesen/verarbeiten/schreiben.
Die CPU-Instruktionen lesen direkt und unmittelbar Bytes aus dem Speicher von einer bekannten Adresse oder schreiben ebenso direkt Bytes rein. Als wären sie technisch in der CPU vorhanden. Ohne Umwege, ohne einen einzigen I/O.
Das sind KEINE I/Os.
Sachlich falsch.
RAM Zugriffe sind sehr wohl I/Os. Und so simpel ist der RAM Zugriff nicht. Ich weiß nicht, ob Du mal Maschinencode programmierst hast. Ich habe das anno 83 von der Pike auf gelernt, damals Z80 und dessen Befehlssatz war mit dem des 8080 verwandt, der widerum ein geistiger Vater des 8086 war und der ist der Urvater aller heutigen PC-Prozessoren. Natürlich hat sich seitdem viel geändert und der 64Bit Befehlssatz in vielen Dingen deutlich eleganter als der eines 8086. Dennoch ist die Grundvorgehensweise identisch: Man lädt die Adresse des Bytes/Words/DWords in ein Register und führt dann einen Befehl aus, der ein Register mit dem Inhalt der Speicherzelle lädt, dessen Adresse man zuvor in ein anderes Register geladen hat. Das ist ganz klassischer Input.
Vom Programmieraufwand in Maschinencode ist das Laden von Daten aus einer Datei übrigens kaum Aufwendiger als das Laden des Inhalts einer Speicherzelle - man ruft einfach eine Routine von Windows auf, der man vorher ein paar Angaben zur Datei und dem Bereich, den man haben möchte, übergibt.

I/O heißt simpel INPUT / OUTPUT und da gibt, wie so oft, zwei verschiedene Sichtweisen. Die 1. versteht alles unter I/O, was die Kommunikation des Prozessors angeht und die 2. versteht das unter I/O, was in oder aus dem Computer rauskommt. Dazwischen gibt es natürlich noch die Sichtweise, das alles I/O ist, was nicht auf dem Motherboard sitzt - das wäre dann Deine Ansicht. Wenn es aber um die Betrachtung von Geschwindigkeiten angeht, dann zählt die erste klare Definition. Der Zugriff aus das RAM erfolgt über den FSB (Front Side Bus) und das ganze ist ein IO-Bus.

RAM war noch nie Bestandteil einer CPU. Es gibt ein paar wenige SOCs, die bereits RAM drin haben, aber selbst bei SOCs ist mehrheitlich externes RAM üblich.

Reiner M hat geschrieben: RAM muss zur CPU passen, sowohl was Größe angeht (Adressumfang) wie Geschwindidigkeit (Bustakt) als auch Channel-Support (z. B. Dual, Quad).
Das gilt nur für die CPUs der letzten Jahre, weil es inzwischen üblich ist, die Northbridge in die CPU zu integrieren. Davor saß der Memory Controller jahrzehntelang in der Northbridge und da mußte das RAM nicht zur CPU, sondern zur Northbridge passen. Das ist im Prinzip jetzt immer noch so, nur ist halt inzwischen die Northbridge Bestandteil einer modernen AMD/Intel CPU.
Reiner M hat geschrieben: Diese Tricks haben 64bit-Programme gar nicht nötig. Auch dann nicht, wenn Du persönlich das nicht anders kennst.
Die 64Bit Programme nutzen die gleichen Kniffe. Nicht wegen dem Speicher, sondern um mehr als einen Kern nutzen zu können ohne zu häufige Kernwechsel erleiden zu müssen. Kernwechsel bedeutet Verlust des L1/L2 Caches und das bremst stark aus.

Gruß Holger



mannamanna
Beiträge: 408

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von mannamanna »

holger_p hat geschrieben: RAM Zugriffe sind sehr wohl I/Os. ...
I/O heißt simpel INPUT / OUTPUT und da gibt, wie so oft, zwei verschiedene Sichtweisen. Die 1. versteht alles unter I/O, was die Kommunikation des Prozessors angeht und die 2. versteht das unter I/O, was in oder aus dem Computer rauskommt. Dazwischen gibt es natürlich noch die Sichtweise, das alles I/O ist, was nicht auf dem Motherboard sitzt - das wäre dann Deine Ansicht. Wenn es aber um die Betrachtung von Geschwindigkeiten angeht, dann zählt die erste klare Definition. Der Zugriff aus das RAM erfolgt über den FSB (Front Side Bus) und das ganze ist ein IO-Bus.

NEIN!!

Nochmal:
Wikipedia: "In computer architecture, the combination of the CPU and main memory (i.e. memory that the CPU can read and write to directly, with individual instructions) is considered the brain of a computer, and from that point of view any transfer of information from or to that combination, for example to or from a disk drive, is considered I/O. "
http://en.wikipedia.org/wiki/Input/output

Vielleicht verwechselst Du als Maschinenspracheprogrammierer das hier mit diesen speziellen Memory I/Os: "The CPU and its supporting circuitry provide memory-mapped I/O that is used in low-level computer programming, such as the implementation of device drivers."

Das gilt aber nur für memory-mappging für externe Geräte wie HDs oder den Bildschirmspeicher....

Hier gehts nicht um Meinungen/Rechthaberei, sondern allgemeingültige Definitionen (ja, dem Sinnnach kann man Speicherzugriffe als I/O bezeichnen aus der Sicht der CPU - die allgemeine Verwendung in der Computertechnik ist anders), sonst: wozu über irgenwas reden? Und wenn Du programmierst, schön, dann überleg mal in den Sprachen die Du kennst, was wird da als Input/Output-Operation bezeichnet?


mana



holger_p
Beiträge: 847

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von holger_p »

mannamanna hat geschrieben:
Keineswegs ist das das Ergebnis - hier wurde nur festgestellt, das Premiere (wie auch andere Programme) von zusätzlichem RAM in manchen Nutzungen profitiert.
Naja, es ist wohl eher so, dass Premiere deutlich mehr RAM und Ressourcen benötigt als andere Programme, um auf ähnliche Leistungen zu kommen. Wie auch Rainer schrieb, nutzen viele Premiere mit After Effects, was natürlich den Leistungs- und Ressourcenbedarf enorm steigert.

Vergleichstests gibt es leider eher in den Einsteigerligen (um 100 Euro) und da bescheinigen viele Tests anderen Programm wie z.B Video Deluxe "enorme Geschwindigkeitsvorteile" gegen Premiere Elements. Harte Zahlen dazu findet man bei Magix selber, aber dort hat man das eigene Video Deluxe 2013 mit den Wettbewerbsprodukten aus 2011/12 verglichen - das ist nicht ganz fair. Video Deluxe 2013 wäre demnach beim Import von AVCHD einer GH2 um den Faktor 13 (in Worten Dreizezehn) schneller als Premiere Elements 10. Ob man das übertragen kann, sei dahingestellt, denn dazu müßte man wissen, wieviel Premiere Pro Code im Elements-Produkt steckt und wie der Vergleich mit Elements 11 ausfallen würde

Eins sehe ich aber mal als Tatsache an: Der enorme Ressourcenbedarf ist kein Vorteil des Produktes. Das ist wie der Spritverbrauch beim Auto - weniger ist mehr.


Gruß Holger



Reiner M
Beiträge: 1282

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von Reiner M »

holger_p hat geschrieben:
Reiner M hat geschrieben: Wo habe ich das geschrieben?
Am 11. Juli um 8:51 hast Du folgendes geschrieben:
Reiner M hat geschrieben: weil eben RAM sowohl den Arbeitspeicher (Datenberechnung) wie auch den Erinnerungsspeicher (Cache) der CPU und ihrer einzelnen Kerne darstellt
Wer verdreht hier was? Du kannst den internen Cache und das RAM nicht in einen Topf werfen.
Schau bitte noch mal genau hin: da steht was von Caches im RAM ("Weil eben RAM ... darstellt"). Richtig? Ist das wirklich mißverständlich?
Nirgends beziehe ich mich dabei auf den Mini-Hardware-Cache in der CPU ... anderer Ort, andere Baustelle, der hat nichts mit RAM zu tun.
Den Unterschied kenne ich.

Glaube mir, Holger: Der Begriff "Cache" ist nicht auf L1/L2-HW-Caches in der CPU begrenzt.

Wenn ich Dir jetzt ausführlicher erzählen würde, dass es in der Praxis Caches im RAM gibt, die Tera-Byte-Größe besitzen, und dass es Architekturen gibt, die über zahlreiche Server hinweg Cache-Grids bilden, also virtuell das physische RAM mehrerer Rechner zu einem durchgehenden Adressraum kombinieren, dabei in mehrere Stufen geliedert sind, die man übrigens auch L1 und L2 nennt, (was nichts anders als "Verarbeitungs-Level" meint), wirds wahrscheinlich zu abschweifend, zu kompliziert .... - Erzähle ich lieber nicht näher ... ;) Das macht man übrigens, weil es latenzfreie Echtzeitverarbeitung unstrukturierter Massendaten ermöglicht. Wie sie eben auch beim non-linearen Videoschnitt vorliegen.
holger_p hat geschrieben: Sachlich falsch.
Wieso habe ich nichts nichts anderes erwartet? ;)
holger_p hat geschrieben: RAM Zugriffe sind sehr wohl I/Os. Und so simpel ist der RAM Zugriff nicht.
Doch, ganz simpel. Ganz einfache Instruktionen erledigen das.

Programmiere mal eine IBM 370 oder System z in Assembler, schon 1980, oder wenn schon die 80er, dann vielleicht einen TI-9900-CPU oder eine Motorala, wie sie Atari im Home-Bereich verbaut hatte - alles Zwei-Operanden-Maschinen, - eine ganz simple Assembler-Instruktion, ein Maschinenbefehl genügt, in etwa: "Move a , b", fertig. Und schon ist im RAM der Inhalt eines Wortes von Adresse a an die Speicherstelle Adresse b kopiert ... Simpler gehts wirklich nicht! ;)

Das gilt immer. Wenn Ein-Operanden-CPUs einen Zwischenschritt über Register-Laden gehen müssen, ist das ein technischer Umstand, der den Vorgang für den Programmierer zwar verkompliziert, aber nicht ändert. Adressierung und Zugriff geschieht direkt im RAM. Ohne I/O.

Du kannst es drehen und wenden wie Du willst: RAM-Zugriffe sind keine I/Os.

Der I/O unterscheidet sich dadurch, dass die CPU eben gerade nicht direkt auf die Daten bzw. Speichereinheiten des externen Geräts zugreifen kann. Sie sind nicht im Adressraum der CPU vorhanden.

Sie müssen erst (Input) in das RAM - also in den von der CPU adressierbaren Raum! - gelesen werden mithilfe einer Systemroutine des Betriebssystems. Weil das Programm die physischen Geräte gar nicht kennt, nur logisch auf sie zugreift, kann es das nicht selbst tun. Das Betriebssystem kennt alle Geräte, stellt den Zugriffspfad bereit und erledigt den Transport der Daten. Dann erst können sie von der CPU verarbeitet werden.

Umgekehrt beim Schreiben (Output) müssen sie erst im RAM vollständig erzeugt werden, dann erst können sie mithilfe einer Systemroutine auf das externe Gerät geschrieben werden.

Übrigens ist und war das so seit Anbeginn der Datenverarbeitung. Das war schon so, als man die Programme noch per Lochkartenstapel zum Laufen brachte.
Das hat weder was mit neuen noch mit alten CPUs zu tun.

Fordert ein Programm den Inhalt einer externen Datei an, wartet die CPU mit der weiteren Verarbeitung dieses Programms, bis die gewünschten Daten im RAM vorhanden sind. Das ist der Nachteil der I/Os.

Hat man nun eine lahme Platte, dauerst lang - ggf. zu lange für Video. Die Zugriffszeit zählt. Und die ist bei In-Memory-Operationen in Caches nunmal fast Null.
holger_p hat geschrieben: I/O heißt simpel INPUT / OUTPUT und da gibt, wie so oft, zwei verschiedene Sichtweisen.
Ich habe es erklärt.
holger_p hat geschrieben:
Reiner M hat geschrieben: RAM muss zur CPU passen, sowohl was Größe angeht (Adressumfang) wie Geschwindidigkeit (Bustakt) als auch Channel-Support (z. B. Dual, Quad).
Das gilt nur für die CPUs der letzten Jahre, ...
Das gilt, seitdem es RAM gibt.
holger_p hat geschrieben:
Reiner M hat geschrieben: Diese Tricks haben 64bit-Programme gar nicht nötig. Auch dann nicht, wenn Du persönlich das nicht anders kennst.
Die 64Bit Programme nutzen die gleichen Kniffe. Nicht wegen dem Speicher, sondern um mehr als einen Kern nutzen zu können ohne zu häufige Kernwechsel erleiden zu müssen. Kernwechsel bedeutet Verlust des L1/L2 Caches und das bremst stark aus.
Wieder ein speziells Thema. Ob sie das nutzen oder nicht, spielt auch kaum eine Rolle.
64bit-Programme, die ihren 64bit-Adressraum nicht nutzen oder durch zu knappen RAM-Ausbau daran gehindert werden, sind ineffizient.

Warum arbeiten wir seit längerer Zeit mit 32bit-Systemen? Weil sie gegenüber 8- und 16bit-Adressierung klare Vorteile bieten. Da sind wir uns hoffentlich einig.

Nun, mit 64bit wird der Vorteil noch deutlicher, noch größer. Auch, wenn Du ihn nicht wahrhaben möchtest.
Nur: Ich muss bei der Systemkonfiguration auch die Systemressourcen zur Verfügung stellen (z. B. viel RAM), um überhaupt in den Genuss dieser Vorteile zu kommen.

Aber genug. Soll ja kein Grundlagenkurs EDV werden.

Beste Grüße,
Reiner
Zuletzt geändert von Reiner M am Sa 13 Jul, 2013 16:46, insgesamt 1-mal geändert.



dienstag_01
Beiträge: 13414

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von dienstag_01 »

Reiner_M hat geschrieben:Dir fehlen die konkreten Fakten. Auch ich habe sie nicht.
Reiner, das ist einfach GROSS.

Aber so richtig klar geworden, was du so treibst, ist es mir eigentlich erst mit folgender Aussage:
Reiner_M hat geschrieben:Das macht man übrigens, weil es latenzfreie Echtzeitverarbeitung unstrukturierter Massendaten ermöglicht. Wie sie eben auch beim non-linearen Videoschnitt vorliegen.
Du bezeichnest deine Videos als unstrukturierte Massendaten.
Warum, zum Hergott, sagst du das nicht gleich?!
Das erklärt vieles, wenn nicht alles ;)
Du bist echt ne Granate.



Reiner M
Beiträge: 1282

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von Reiner M »

dienstag_01 hat geschrieben: Du bezeichnest deine Videos als unstrukturierte Massendaten.
Warum, zum Hergott, sagst du das nicht gleich?!
Siehste! ;)

Ja, unstrukturierte Massendaten. So nennt man das. Was sind sie sonst aus der Sicht des PCs? Der kennt keine Videos... er guckt auch keine, hat noch nie eins gesehen. Dem ist es egal, was Du da so produzierst. Der macht in winzig kleinen Schritten das, was Du (stellvertretend durch das Programm) vom ihm möchtest. Massendaten hin- und her schieben, dazwischen ein wenig manipulieren. ;)

Tja, wer hätte das gedacht? Hinter Videobearbeitung gibts eine Schicht, die sich mit Daten und Datenverarbeitung, Speicher, Speicherverfahren, ihren Spiecherorten und -formaten beschäftigt ...
Woran Liegt das? Etwa an CPUs, RAM und Platten, um die es hier geht?

Die Hersteller von NLEs z.B. müssen sich also nicht nur mit "Video" auskennen ... Und sie tun es. Auch wenn manche meinen oder unterstellen, das sei nicht so. ;)

Nicht wirklich wichtig, Dienstag. Nur dann, wenn man z. B. verstehen möchte, - und das war hier die Frage! -, warum RAM sinnvoll ist, ohne in Mutmaßungen und wilde Spekulationen abzugleiten. ;)

Nur dann ein Stück wichtig, wenn man sich fragt: Wie muss ein guter PC für mich und meine Programme konfiguriert sein, und dann noch wissen will: warum genau so und nicht anders?

Manche Dinge haben tatsächlich einen Grund.

Kann man drüber nachdenken. Oder auch nicht. Zwingt einen ja niemand. ;)

Beste Grüße,
Reiner
Zuletzt geändert von Reiner M am Sa 13 Jul, 2013 17:24, insgesamt 1-mal geändert.



holger_p
Beiträge: 847

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von holger_p »

mannamanna hat geschrieben:
Hier gehts nicht um Meinungen/Rechthaberei, sondern allgemeingültige Definitionen (ja, dem Sinnnach kann man Speicherzugriffe als I/O

mana
Im deutschen Wikipediaartikel zu diesem Thema
http://de.wikipedia.org/wiki/I/O
heißt es
Der Prozessor spricht über I/O-Controller...
Die Northbridge, wo auch der Speichercontroller enthalten ist/war, ist ein ganz klassischer IO-Controller. Man hat seit einigen Jahren in die CPU verlagert. AMD war hier Vorreiter und bei Intel hat man mit Nehalem 2009 nachgezogen, weil die Vorteile überwogen.
Die softwareseitige Ausgabe läuft generell nicht über die Kommandozeile, sondern ausschließlich im Programm als schreibender Zugriff auf Bildschirm, Drucker, Speicher oder einen A/D-Wandler oder Ähnliches
So und nu? Scheint, als würde Wiki was für jede Ansicht zu liefern. Selbst der englische Artikel ist insgesamt nicht so eindeutig wie der zitierte Absatz.

Ich glaube, es ist wirklich eine Frage der Definition. Der Ansatz, "worauf man mit einfachen Befehlen zugreifen kann" zieht nicht wirklich, denn der Zugriff Massenspeicher ist mit den Betriebssystemroutinen kaum komplizierter als der Zugriff auf den Speicher. Und wer noch 16Bit programmiert hat, der kennt auch die Klimmzüge, die man dort machen mußte, um die 64KB Limits zu umgehen. Zwar konnte der Prozessor schon 1MB ansprechen, aber keine Strukturen größer 64KB (16Bit) in einem Block. Egal, ob Assembler oder Hochsprache - das Limit kam vom Prozessorbefehlssatz.

Wie auch immer: Viel RAM im Rechner hilft immer. Aber eine Software, die viel RAM benötigt, um gut zu funktionieren, ist weniger effizient wie eine Software, die mit weniger RAM auskommt und im Falle von viel RAM im Rechner das Betriebssytem cachen läßt. Das verhindert das doppelte Cachen der Daten und wenn auf die Datei auch geschrieben wird, ist die Methode "Windows Cache" klar schneller.

Ich vermute, der enorme Speicherbedarf von Premiere hat eine ganz andere Ursache als das einfache Cachen von Daten, die sich die Software von der Platte gezogen hat und die auch Windows cachen könnte. Soviel Dummheit traue ich den Programmieren von Adobe nicht zu.


Gruß Holger



holger_p
Beiträge: 847

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von holger_p »

Reiner M hat geschrieben:
Ja, unstrukturierte Massendaten. So nennt man das.
Videos sind im Regelfall eher semistrukturierte Daten.
Siehe: http://de.wikipedia.org/wiki/Semistrukturierte_Daten

Der Inhalt (Bildinhalt) ist unstrukturiert, nicht zuletzt auch wegen der variablen Längenkodierung des Inhalts, aber es gibt einen strukturierten Rahmen im Form von Frames, iFrames usw. der in der Datei steckt.

Um mal wieder zum Diskussionsausgang zu kommen: Ich könnte mir vorstellen, dass man ganz viel Speicher braucht, um aus diesen semistrukturierten Daten strukturierte Daten zu machen und diese zu im RAM zu speichern statt die Daten bei jedem Zugriff on the fly neu dekodieren.


Gruß Holger



Reiner M
Beiträge: 1282

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von Reiner M »

holger_p hat geschrieben: So und nu? Scheint, als würde Wiki was für jede Ansicht zu liefern. Selbst der englische Artikel ist insgesamt nicht so eindeutig wie der zitierte Absatz.
So siehts aus: Befindet sich ein Datum im Adressraum der CPU (kann sie es direkt adressieren), tut sie es. Kein I/O.
Dateien auf Platte, Drucker, Bildschirme befinden sich üblicherweise nicht im Adressraum der CPU. Es muss mithilfe des Betrirebsystems ein Kommunikationskanal aufgebaut werden. I/O.

Genau davon spreche ich, wenn ich sage, viel RAM spart ggf. I/Os.
holger_p hat geschrieben: Der Ansatz, "worauf man mit einfachen Befehlen zugreifen kann" zieht nicht wirklich, denn der Zugriff Massenspeicher ist mit den Betriebssystemroutinen kaum komplizierter als der Zugriff auf den Speicher.
Es ist geht nicht um weniger kompliziert oder einfacher zu programmieren. Das ist das Problem der Entwickler, nicht der Anwender. Es geht um Zeitverlust oder Zeitgewinn während der Nutzung, während der Videobearbeitung. Da ist es knallhart das Thema des Anwenders. Und da sind - ich wiederhole es! - physische I/Os das teuerste, was die EDV zu bieten hat.
1080p50 - maximal 1/50 Sekunde Zeit für alles.

Dafür hatte ich das Boot-Beispiel herangezogen, das sehr deutlich jedermann vor Augen führt, wie riesen groß der Zeitgewinn ist bei der Abarbeitung der genau selben Programme, wenn nur einfach statt einer HDD eine SSD eingesetzt wird. Die CPU zeigt, was sie wirklich kann.
Es zeigt, um wie viel I/Os auf HDD teuerer sind (in Zeit) gegenüber I/Os auf SSDs. Ob einem das der Preisunterschied im Laden wert ist, muss jeder selbst wissen. Die CPU jedenfalls "bezahlt" dafür und dümpelt vor sich hin ... trotz hoher Taktrate und vieler Kerne.

Wer nun also glaubt, ein Windows 64bit langt, oder eine SSD reicht, oder ein schnelle CPU genügt, der übersieht die Zusammenhänge.

Das Zusamenspiel aller Komponenten zählt - Es entsteht eine Architektur, die für einen Anwendungsfall optimal ist. Sind mehrere Anwendungsfälle zu berücksichtigen (z. B. Videoschnitt und Compositing mit jeweils spezieller Software, oder auch zusätzlich 3D-Animation) sollte man sich am größten Bedarf ausrichten und zusätzlich eine Reserve einplanen, um diese Programme auch parallel nutzen zu können. Man sollte sich nicht am kleinsten Bedarf orientieren. - Kann man aber machen.

Wie sich das alles also in Aufwände und in Erträge in Form von Zeit oder Geld, in Komfort oder Umsatzbarkeit komplexer Projekte auswirkt, kann und muss sich letztendlich jeder selbst ausrechnen. Seine Anwendungsfälle, seine Programme, Vorgehensweisen und die Nutzungshäufigkeit zählen.

Hier wird der Hobbyanwender vermutlich flexibler reagieren und mal ein bockiges System hinnehmen - kommt ja nicht so oft vor. Wer darauf sein Geschäft gründet, sollte genauer nachrechnen.

Beste Grüße,
Reiner



mannamanna
Beiträge: 408

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von mannamanna »

holger_p hat geschrieben: Das verhindert das doppelte Cachen der Daten und wenn auf die Datei auch geschrieben wird, ist die Methode "Windows Cache" klar schneller.
Warum sollte das Schnittprogramm die Daten so cachen wie sie auf der Disk sind und nicht in dekomprimierter Form oder anderweitig für die optimale Bearbeitung aufbereitet? Es gibt andere Cache-Typen als blosse File-Caches

mamama



holger_p
Beiträge: 847

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von holger_p »

Reiner M hat geschrieben:
Genau davon spreche ich, wenn ich sage, viel RAM spart ggf. I/Os.
Ja, da besteht immer die Chance auf eine Performancesteigerung. Das ist so wie die "garantierte Wertsteigerungschance" bei Gedenkmünzen.

Wir sind aber eigentlich vom Thema ab: Wofür braucht das so überragend programmierte Premiere Pro eigentlich so viel Speicher? Andere Programme sind sogar ohne CUDA schneller und brauchen viel weniger Speicher. Dafür muss es doch einen Grund geben?

Und es wird ja wohl nicht der Marketingvertrag von Adobe mit dem Herstellerverband von DDR-Speicher und mit nVidia sein. Oder doch? Seit PRISM traue ich US-Firmen praktisch alles zu...


Gruß Holger



dienstag_01
Beiträge: 13414

Re: Ratgeber: Der optimale PC für den Videoschnitt- Teil 1: CPU, Mainboard,

Beitrag von dienstag_01 »

holger_p hat geschrieben:Wir sind aber eigentlich vom Thema ab: Wofür braucht das so überragend programmierte Premiere Pro eigentlich so viel Speicher? Andere Programme sind sogar ohne CUDA schneller und brauchen viel weniger Speicher. Dafür muss es doch einen Grund geben?
Welches Programm wäre denn schneller?
Ich denke, die Verwendung von Cuda bringt schon deutliche Vorteile. Zumindest sehe ich es im Vergleich mit Avid. Aber, was interessant ist, bei allen für mich irgendwie denkbaren Szenarien - mit Cuda/ohne Cuda, Ausgangsmaterial AVCHD - rendert keines der beiden Programme mit mehr als 3GB RAM, eher weniger. Deshalb kome ich ja zu dem Schluß. dass die von Reiner_M aufgezeigten 40GB für die Vorschau eigentlich nicht wirklich gebraucht werden. Ist eher so ne Routine von Adobe, lass das Material im RAM liegen, is eh wurscht, is ja da. Oder aber bei Reiner sieht die ungerenderte Vorschau schon aus wie das finale Ergebnis. Dann könnte aber Premiere den roten Balken auch zu einem Gelben oder Grünen machen. Machts aber nicht. Also ist es wohl nicht so doll.



 Aktuelle Beiträge [alle Foren]
 
» Sondergagen - Wer aufmuckt, wird nicht mehr besetzt
von Frank Glencairn - Do 19:31
» Interessante Firmware-Updates für Sony Alpha 1, 7S III und 7 IV
von Abercrombie - Do 19:29
» FCPX/Motion, DaVinci/Fusion... Tipps&Tricks
von Frank Glencairn - Do 19:25
» Nikon stellt NIKKOR Z 28-400mm f/4-8 VR Superzoom-Objektiv vor
von Jan - Do 19:16
» Red Komodo 6K + Gimbal, Advanced Ring Grip und viel Zubehör
von Sevenz - Do 19:01
» >Der LED Licht Thread<
von freezer - Do 18:53
» Was schaust Du gerade?
von Frank Glencairn - Do 18:46
» Mac SSD Speed Messung?
von TomStg - Do 18:40
» Camera Update 8.6: Viele neue Funktionen für Blackmagic Kameras
von slashCAM - Do 17:42
» Neues SIGMA 50mm F1,2 DG DN | Art Objektiv wiegt 745g
von cantsin - Do 17:19
» Tieraufnahmen mit dem MKE600 + H1 Essential rauschen
von Swat - Do 16:06
» 4 Gründe hartes Licht zu nutzen
von ruessel - Do 15:45
» [gelöst] 3.5mm Klinkenstecker Überwurfmutter
von Skeptiker - Do 14:42
» Panasonic S5 - Allgemeine Fragen, Tipps und Tricks, Zeig deine Bilder/Videos usw.
von Darth Schneider - Do 13:49
» -SONY FX- Erfahrungsaustausch
von rush - Do 13:40
» AOC bringt 44.5" OLED-Riesenmonitor mit 98.5% DCI-P3
von MK - Do 12:07
» Adobe führt die neue Funktion "Structure Reference" in Firefly ein
von slashCAM - Do 10:54
» Exhuma - die Südkoreaner können erfolgreiche Filme drehen
von -paleface- - Do 8:46
» Was hörst Du gerade?
von roki100 - Do 0:22
» Sony A9 III im Praxistest - ein echter Überraschungscoup auch für Filmer
von Mantas - Mi 23:27
» Video Pro X stürzt beim Multi Cam Schnitt ab
von MisterX - Mi 21:47
» Uwe Boll: Wie man Filme produziert ohne pleite zu gehen!
von iasi - Mi 19:53
» Nach 7 Jahren mit der OG BMPCC finde ich das Bild noch immer schön.
von Darth Schneider - Mi 18:58
» Verschachtelte Timeline im richtigen Seitenformat
von Clemens Schiesko - Mi 18:43
» Untertitel in FCPX bei vorhandener Textdatei?
von R S K - Mi 18:34
» Deckenlicht mobil abschatten
von Frank Glencairn - Mi 17:31
» LUTs für Canon R6 Mark II
von TomStg - Mi 12:24
» RED versucht User nach Übernahme durch Nikon zu beruhigen
von dienstag_01 - Mi 11:52
» Entfesseltes Storytelling mit der Video-KI Sora?
von Frank Glencairn - Mi 5:54
» Slashcam 2001 - Das Internet vergisst nichts!
von macaw - Di 21:37
» Dehancer Pro - Filmsimulation auf höchstem Niveau
von Frank Glencairn - Di 18:54
» Wie Dune Teil 2 entstand - DoP Greig Fraser und Hans Zimmer im Interview
von iasi - Di 13:32
» 3 Body Problem - so verfilmt man heute Bücher
von stip - Di 8:30
» Neue Sora Version
von Frank Glencairn - Di 7:54
» IDEENFINDUNG: Wie man spannende Filme entwickelt! mit Vi-Dan Tran (Actiondesigner DUNE)
von berlin123 - Di 6:47