Von was profitiert der DOC ?

Begonnen von Traxx, Februar 11, 2018, 19:47:22

« vorheriges - nächstes »

Traxx

Langsam möchte ihr mir mal wieder einen neuen PC gönnen. dabei stellt sich die frage was mach das arbeiten mit TSD flotter ?
dabei meine ich nicht das erzeugen des neuen Files, da ist es klar da hilf eine flotte HDD bzw. SSD.
Ich meine zb. wenn man nach dem schneiden im Schnitt Fenster fertig ist, und man 30-40 Schnitt Marken gesetzt hat das "erstellen der Schnitt Marken"
oder das laden und analysieren der Original Files.
was macht das alles Flotter ? mehr Kerne der CPU oder höherer Takt ?
bzw. eventuell für AMD oder Intel was optimiert Programmiert usw. ?
VU+ Solo 4K, Vu+ Duo2, Xtrend ET 10000, Xtrend 7500, TBS-5980 CI

Cypheros

Schnelle Festplatten wie zum Beispiel SSD (M2) sind sehr hilfreich. Damit sind Verarbeitungsgeschwindigkeiten bis zu 100 MBytes/sec möglich.
Einigermaßen aktueller Intel- oder Ryzen- Prozessor mit ausreichend PCI-Kanälen ist dazu auch notwendig.

Traxx

Bringt zb. ein AMD Ryzen Threadripper 1950X mit 16 Kernen etwas im vergleich zu AMD Ryzen 7 1800X mit 8 Kernen, oder Intel Core i7-8700K mit 6 Kernen ?
VU+ Solo 4K, Vu+ Duo2, Xtrend ET 10000, Xtrend 7500, TBS-5980 CI

Cypheros

Viele Kerne bringen nur bei der Videoanalyse einige Vorteile. Ansonsten sind die Datenträger der begrenzende Faktor.

simonsagt

Alt, aber noch relevant.

Ich mache grad ein Upgrade von 2 auf 4 und ausgehend vom Taskmanager und meinem überdimensionierten System, der Doc profitiert erstmal von gar nichts, weil er das System nicht ausreizt. Weder Zahl der Kerne (Rechenleistung ist weniger als 1 Kern), noch Speicher (man sollte meinen wenn die Aufnahme 5-10x komplett in den Ram passen würde, wäre das schneller), noch schnelle Platte (der Taskmanager zeigt, wieviel mb/s Aktiviät auf der Platte ist).

Jedenfalls beim tatsächlichen Abspeichern des geschnittenen ts. Beim Analyse/Schnitt/Vorschau dürfte die CPU schon helfen, ebenso eine schnelle Platte. Allerdings sehe ich auch da kaum 1,5 Kerne in Benutzung bei nicht ausgelasteter Platte. Vielleicht ist der interne CPU Cache oder die Ram-Geschwindigkeit der Flaschenhals.

Ich weiß nicht was es am 4er ist, vielleicht mehr adressierbarer temporärer Speicher durch die 64 bit oder sonst was. Jedenfalls ist der beim Speichern etwa 10x so schnell wie der 2er. Also statt 10mb/s wird mit 100+mb/s geschrieben (und das ist keine ssd).

Selbst wenn ich die Datei von der Ramdisk lade, mehr als 80mb/s und knapp 1 Kern wird da nicht beansprucht.

Wenn man an Hardware-Upgrade denkt, weil der TSDoc zu langsam scheint, am besten einfach mit dem Taskmanager kucken, wo der Flaschenhals zu sein scheint.

Mam

Zitat von: simonsagt am Februar 11, 2023, 14:52:28Selbst wenn ich die Datei von der Ramdisk lade, mehr als 80mb/s und knapp 1 Kern wird da nicht beansprucht.
Ja, so ziemlich alle wissen, dass der Doc nur single threaded ist, geht auch nicht anders.

Wie willst Du denn einen Stream (Byte nach Byte) parallel lesen??? (oder schreiben).

Das geht überhaupt nicht.

Und die "Schreibgeschwindigkeit" ist bedingt durch die Rechenleistung. Der Doc muß halt viel checken, neu berechnen und wieder wegschreiben. Also hilft hier nicht ne "große" CPU (viele Kerne), sondern ne "schnelle" (höchste Taktgeschwindigkeit, die auch gehalten werden kann).

80Mb/s ? Dann hast Du noch viel Luft nach oben, wohl zu lahme Hardware :-)))

So bei 150 bis 200 beginnt der Spaß  ;D


simonsagt

Zitat von: Mam am Februar 11, 2023, 20:18:02Wie willst Du denn einen Stream (Byte nach Byte) parallel lesen?
Ähm. So ganz stimmt das nicht. Streams werden nicht byteweise gelesen, sondern in mehr oder weniger großen Blöcken. Außerdem macht das nicht die CPU. (Oder anders gesagt, von Festplatte wird parallel gelesen und geschrieben, aber sowas von!)

Du meintest sicherlich, dass die notwendigen Rechenschritte sich nicht parallelisieren lassen. Hmm. Im Prinzip könnte eine Pipeline an Arbeitsschritten ablaufen, wenn die Datenbearbeitung aufeinander aufbaut und sequentiell erfolgen muss. Erster Prozessor macht Schritt 1, Zweiter Prozessor Schritt 2 usw. Aber, das würde ich den Compilerbauern überlassen, was sich da aufteilen läßt und was nicht.

Beim Encodieren geht es jedenfalls offensichtlich parallelisiert, denn da zieht ein Encoder auch deutlich mehr als die Hälfte der Rechenleistung und somit viele Kerne.

Und ähm, beim Schreiben habe ich heute beim Testen bis 150mb/s auf meiner Magnetplatte erreicht. Deswegen ja die Verwunderung, dass beim Einlesen nur 80mb/s auf der Ramdisk erreicht wurden. Das hab ich eben nochmal genauer angeschaut. Von Ram auf Ram kopieren geht bis 1000mb/s. Von Ram auf Ram ein TS mit dem Doc4 schreiben wieder nur 100mb/s. Und ca. 1 Prozessor voll an Rechenleistung (und ja, ich weiß nicht, wieviele Kerne tatsächlich verwendet werden, ich kann nur sicher sagen, wenn es mehr als 1/Kerne ist, dass es mehr als einer sein muss)

Der Doc verbraucht allerdings recht wenig Hauptspeicher. Gerade mal 1% bei mir. Vielleicht ist das der Flaschenhals. Konservative Nutzung der Ressourcen ;-)

Aber wie gesagt, beim Schreiben ist der 4er etwa 10x so schnell wie der 2er. Die Voranalysen gefühlt doppelt so schnell, die Werbungsanalyse zuckelt und ruckelt wie gewohnt vor sich her.

Cypheros

ZitatSo ganz stimmt das nicht. Streams werden nicht byteweise gelesen, sondern in mehr oder weniger großen Blöcken.

Ja, jeder Block ist genau 188 Byte groß und enthält nur einen Schnipsel an Daten. Diese Pakete werden nummeriert (4 bit counter) um festzustellen, ob was fehlt. Wie willst du das machen, wenn du die Pakete nicht seriell abarbeitest?

simonsagt

Das ist natürlich alles theoretische Garnspinnerei, aus User-Seite ist der 4er zumindest beim Schreiben ja 10x schneller als der 2er, was beeindruckend ist. Da würde in der Bedienung tatsächlich ein Soundhinweis nach Öffnen etwas bringen, dass man nun loslegen kann, denn der Teil mit Einlesen und (Werbe-)Analyse dauert beträchtlich länger als der Schreibteil bei dem ein Endsound kommt.

Jedenfalls habe ich mich gewundert, wo der Flaschenhals tatsächlich ist. Gerade wenn ich von der Ramdisk lese, sollte es ja nicht die Festplattengeschwindigkeit sein. Und wenn ich teilweise gerade mal einen halben Prozessor in Verwendung sehe, scheint der Prozessor auch nicht immer ausgelastet zu sein. Von meinem Hauptspeicher zieht der Doc etwas weniger als 300MB, das wird es auch nicht sein. Meine Vermutung wäre, die Befüllung des CPU Caches.

Zählen ob alles da ist, hört sich nicht sehr rechenintensiv an, im Gegensatz zu Recodieren und da sehe ich massive Kernnutzung beim Encoder, obwohl das eigentlich auch eine serielle Aufgabenstellung sein sollte.

Naiv gedachter Parellelbetrieb beim Zählen: mehrere Leute zählen auf Vollständigkeit nach Indexnummern. Jeder bekommt ein 1/x Teilstück und prüft das auf Vollständigkeit und dann werden die Teilstücke aneinander gekettelt bzw. geprüft. Oder man lese einen Block so groß wie der Einzelcache eines Kerns es erlaubt, lasse ihn zählen und starte das selbe mit dem nächsten Kern/Großblock, Ergebnisse kommen in einen Index, der dann danach geprüft wird.

Aber wie gesagt, das ist nur Garnspinnerei, ich bin halt skeptisch, wenn behauptet wird, das geht nicht parallel, nur weil es auf den ersten Blick als serielle Aufgabe erscheint.

In der Praxis scheint mir hier allerdings nicht so sehr der Flaschenhals, das geht schon recht flott. Langsam wird es bei der Werbeanalyse. Und da wird wohl doch auf mehrere Kerne verteilt, denn da sehe ich Leistung von etwa 150% eines Kerns.

--

Um noch was zum Thema zu sagen, meine Einschätzung ist, der TSDoc ist keine Echtzeitanwendung, wie etwa ein Spiel bei dem die Frames pro Sekunde wichtig sind. Die Abläufe sind derart optimiert, dass es auf einem modernen System kaum Unterschiede gibt. Man sitzt sowieso nicht gespannt davor und zählt die Sekunden.

Man kann sich allerdings gehörig ausbremsen. Etwa mit einer sehr langsamen Festplatte, oder Arbeiten von USB-Stick. Den Effekt sieht man auch, wenn man von einer Platte liest, wo gerade was anderes gelesen wird (etwa weil man 2 TSDocs lesen läßt)

Traxx

#9
Will dich in deiner Euphorie nicht bremsen, aber ich hab beim Erstellen der neuen Datei keinen bis minimalen Unterschied von 2.x zu 4.x
Keine Ahnung, was bei deinen "alten" 2er DOC verstellt ist, aber der 2er DOC erstellt die neuen Files genauso schnell wie der neue 4.x. Der hat einige Neuerungen, aber was die neue Datei erzeugen betrifft ist er genauso schnell oder langsam wie der alte 2.x bei mir.

Aus den beiden Logs, von einem kurzen Test File für den ich extra den 2.0 nochmal angeschmissen habe.

2.2.24
OS: Windows 10 Build 19045 x64
OS language    : DE
Appl. language : German
TSDoctor.exe V 2.2.24 (Build 049FB2)

PID stream average bitrates
$00A3: 5,1 Mbps
$0062: 203,1 Kbps
$0063: 203,1 Kbps

Speed: 115,5 MBytes/sec
Duration: 00:00:15

4.0.16
OS: Windows 10 Build 19045
OS language    : DE [DE-DE,DE,EN-US,EN]
Appl. language : German
TSDoctor.exe V 4.0.16 (Build 060000)

PID stream average bitrates
$00A3: 5,1 Mbps
$0062: 203,1 Kbps
$0063: 203,1 Kbps

Speed: 143,0 MBytes/sec
Duration: 00:00:12
VU+ Solo 4K, Vu+ Duo2, Xtrend ET 10000, Xtrend 7500, TBS-5980 CI

Mam

Zitat von: Traxx am Februar 12, 2023, 14:06:29Will dich in deiner Euphorie nicht bremsen
Lassen wir ihm seinen Spaß  ;D
Klar, der neue Doc ist "etwas" schneller (so 10-20%), aber Übertreibung macht halt anschaulich, bei ihm sind es dann gleich 10x  8)

Cypheros

Das hängt glaube ich stark von der Hardware ab. Hier mein Test mit einem Ryzen 5900X und einer Samsung NVME 980 Pro:

2.2.24
Speed: 191,9 MBytes/sec
Duration: 00:00:37

3.2.33
Speed: 235,2 MBytes/sec
Duration: 00:00:30

4.0.16
Speed: 251,3 MBytes/sec
Duration: 00:00:28

tsduser

...und dann waere vielleicht noch zu klaeren, wie die "Speeds" aussehen bei umgekehrter Reihenfolge (4->3->2).

@Traxx und sorry, off-topic: Mich persoenlich wuerde viel mehr interessieren, wie Du unter W10 den "[compatibility mode]" losgeworden bist...

Traxx

Zitat von: tsduser am Februar 12, 2023, 15:34:13@Traxx und sorry, off-topic: Mich persoenlich wuerde viel mehr interessieren, wie Du unter W10 den "[compatibility mode]" losgeworden bist...

Was meinst du? Steh gerade aufn Schlauch  :-\
VU+ Solo 4K, Vu+ Duo2, Xtrend ET 10000, Xtrend 7500, TBS-5980 CI

tsduser

Nun, bei mir ist es auf mehreren unterschiedlichen Rechnern so, dass der Doc 2.x unter W10 nur im "Kompatibilitätsmodus" starten mag. Der 3er und 4er haben keine Probleme, ebenso wie der 2er auf W11 (also ist's wohl nicht der Programm-Code vom Doc selber, sondern "nur" irgendeine genutzte DLL). Selbst unter W10 gab's eine Zeit (mit Build 19041), wo der CompatMode (bei mir) nicht erzwungen wurde.
Ich habe definitiv nix unter AppCompat drinstehen, das entsprechende SysInternals-Tool findet auch nix.

Und in Deiner Logausgabe "OS: Windows 10 Build 19045 x64" fehlte halt das bei mir immer dahinter angezeigte "[compatibility mode]".

Die Frage ist hier (und in anderen Foren) auch schon das eine um's andere Mal gestellt worden, aber nie gab's eine sinnvolle Antwort (ausser fuer diejenigen, die halt tatsaechlich was in "AppCompat" stehen hatten...).

OK, es ist nur ein zusaetzlicher Klick auf "so what", aber auf die Dauer bei jedem Start nervt's. Und da noch immer ein laufender Doc 2.x jedesmal beendet werden muss, wenn der Doc 4.x ein Update erhaelt, nervt's nur noch mehr. Mein betagtes i5-2520M-Notebook bekommt halt freiwillig kein W11-Update angeboten, und nach jedem Patch-Day befuerchten zu muessen, dass ich erst einmal das W10 re-installieren muss, ist auch nicht gerade das, was ich mir wuensche.

Es kann selbstverstaendlich auch sein, dass einfach nicht die gesamte Zeile hier in den Thread-Beitrag kopiert wurde...


www.cypheros.de