bei Multicore CPU Auslastung optimieren, TSDoc soll schneller werden!

[peter999]

So, nun muss ich auch meinen Senf dazugeben.

Ich entwickle Software in Win32 und X64 (native). Wenn ich z.B. die Projekte auf einem 64 Bit Windows (7, 8.1, 2008R2, 2012R2) kompiliere, ist die Kompilation der Win32-Version immer so um 30%-40% langsamer, als wenn ich die Version mit dem Nativen 64-Bit Kompiler.

Wenn ich den Doktor (32-Bit) laufen lasse, kann ich den Wert ungefähr auch rechnen, da 32-Software in 64-Bit Betriebssystemen nicht native läuft, sondern über einen "Interpreter", das kostet Zeit. Bei normaler Bürosoftware wie Office merkt man das nicht, 

Wenn ich also 64-Bit Programme auf dem PC laufen lasse, ist die Geschwindigkeit immer größer als wenn ich das gleiche Programm in 32-Bit laufen lasse. Lassen wir nun den Arbeitsspeicher außen vor, erreicht man da schon größere Geschwindigkeiten. Das würde mit der 64-Bit Version vom Doktor auch passieren.

Nebenbei: Ich schneide die Filme direkt von Festplatte der 7080HD auf ein QNAP 469L über das Netzwerk, das geht sehr schnell. In der Regel dauert das Ganze nicht mehr als höchstens 5 Minuten (Schnitt, Namen ändern usw., OK klicken).

Und da gibt es ja auch den Batchlauf.

Man kann ja mal testen, was schneller ist, das schneiden direkt über das Netz, oder das Kopieren des Filmes auf den PC, Schneiden und wieder irgendwo hinkopieren.
Wir haben bei den PCs immer noch Flaschenhälse, wie z.B. die Festplatten, der Speicher usw. UND WINDOWS

[Mam]

Hmm... irgendwie wollen die Leute es nicht verstehen: der Doc hat kaum etwas zu rechnen!

Ob mit 1Ghz, oder mit 4ren, ob mit einem Core oder mit 32, DA PASSIERT NIX!!!

Es werden Daten unverändert von A nach B geschaufelt, das ist I/O, die CPU macht dabei meistens nur eins: WARTEN!

Und selbst wenn es sich mit 64Bit umd 30% schneller warten sollte, das Endergebnis ist weiterhin DASSELBE...

(abgesehen davon möchte ich allerdings auch mal bald 'ne native 64 Version sehen, aber mehr aus systemfreundlichen Gründen, nicht wegen Speed oder Ram. (und ja, mir ist klar das Scheffe das solange verhindern wird, wie es geht, weil damit ja all seine braven Emulatoren auf Linux oder Birne sofort ins Essen brechen würden...))
Aber, die Hoffnung stirbt zuletzt, vorher wird garantiert sein DirectX Geraffel den Orkus der vergessenen APIs besteigen, lange kanns nicht mehr dauern, die XBox ist zu mies drauf, da muß Mikrosaft bald dran drehen, damit wieder Alleinstellungsmerkmale herkommen...

[Djfe]

Wird zumindestens interessant, also ob DirectX 12 noch was ändern wird

würde einen einfachen 64bit Test wie Peter aber auch gut heißen

er kann ja parallel für beides entwickeln, wenn er sich gut anstellt, dann hätte er immer noch eine Version für Linux und Mac

oder er empfiehlt die Nutzung einer VM, wenn 64bit tatsächlich unverträglich mit Wine/Crossover ist.

[Cypheros]

OK, werde mal eine 64bit-Version testen.

[Mam]

OK, werde mal eine 64bit-Version testen.

Machma 
Dabei kommen dann meistens Fehler vom Compiler raus, die Du bislang noch nie in Deinen schlimmsten Albträumen erdacht hast 

Und bei vielen stehst Du da mit offenem Mund und stammelst : "was will der Dichter uns damit sagen???"

Ist auf jeden Fall ne gute Idee, sich die Feiertage zu versauen (auf jeden Fall sinnvoller als blöde Aktivitäten wie "Urlaub" oder so)

[Djfe]

ganz ruhig Mam, komische Compilerfehler muss man als Entwickler gewöhnt sein

außerdem reichts ja wenn er einzelne Routinen nach 64bit überträgt und auf Geschwindigkeit testet, wenns mit dem vollen Programm nicht einfach so klappt

und irgendwann muss er es ja mla machen, wie du bereits sagtest

[Mam]

außerdem reichts ja wenn er einzelne Routinen nach 64bit überträgt und auf Geschwindigkeit testet, wenns mit dem vollen Programm nicht einfach so klappt

Sag mal, hast Du in Deinem Leben schon jemals ein (nicht-Java oder sonstiger Interpreterdreck) Programm geschrieben, das nicht trivial war und länger als zwei Zeilen?
Irgendwie habe ich den Eindruck, Du weist nicht so wirklich, was Du da von Dir gibst.
Ansonsten verrate mir doch mal, wie Du gedenkst "einzelne Routinen" umzuheben, ohne das ganze Projekt umzuschalten ? ? ?
Spätestens der Linker spuckt Dir dann aber gehörig in die Suppe (Du weist, was ein Linker ist? Tipp: ist nicht das Gegenteil von Rechter)

[Derrick]

Ich schreibe keine Programme, sondern benutze sie. Wie @Cypheros programmiert, ist mir wurscht. Das Ergebnis zählt. Ihr solltest auch euren lächerlichen *Werhatdenlängstenwettbewerb* beenden oder woanders fortführen 

[testest]

Ich überleg grad ob ich mal nen Schritt nach vorn experimentiere und nen core 4790k probiere der nativ 4.0-4.4 GHz bringt. Obwohl die 4.4-4.6 (übertaktet) bei Spielen und anderem kaum was bringen weil die alle Multicore können (da relativiert sich die max-Speed zugunsten CPU's mit noch mehr Kernen) so müsste beim singlecore-TSDoctor schon ein mittlerer Quantensprung drin sein?

..gesagt getan, sitze gerade vor nem ziemlich atemberaubenden 4K-TV und schau mir über die 4790K Haswell iGPU überwiegend ruckelfreie 3840x2160 Testvideos an. Gute Güte ist das scharf! Da denkt man langsam wirklich man guckt zum Fenster raus.
Und auf den Desktop passt soo viel rauf das man doch öfter überlegen muß, in welcher Ecke war ich jetzt grad? Und dann da hinlaufen... na ja laufen war grad bisschen übertrieben aber kommt einem manchmal so vor..

Um I/O Performance-Mängel zu checken lasse ich TSDoc immer von einer Platte zu einer anderen über verschiedene Controller lesen/schreiben. Dabei stellte sich heraus das zwischen schnellen SATA 6G Platten und SSD's TSDoc bis auf 1-2 sec gleich-schnell/langsam rechnet (knapp 2 min).
Zum Vergleich - 6 GB von SSD zu SSD kopieren braucht 15 sec.
Also kann man die Verlangsamung durch I/O Performance in diesem Testset vernachlässigend ausklammern.

Berechnet wurde immer das gleiche 10,2 GB, 116 min, Arte 720p Test.ts, alle Spuren hatten ein X bis auf das H264 Video und 1 MPEG/Layer2 Audio. Erzeugt wurde daraus ein 6,01 GB, 96 min fixed.ts (Film: Und täglich grüßt das Murmeltier).

Der Befund war recht eindeutig, zur Erinnerung:
Intel Sandy Bridge i7 (max. 3,6 GHz) über P67 Express Chipset - (auch nichts langsames von 2011) - brauchte 2 min 55 sec
und nun
Intel Haswell 4790K i7 (max. 4,4 GHz) über Z97 Express Chipset (ASUS ROG Maximus VII Hero) - brauchte 1min 54sec
OC @ 4,6 GHz - 1min 46 sec
OC @ 4,8 GHz - 1min 41 sec
Overclocken bringt jetzt nicht soo viel weil der Prozessor schon ab Werk ziemlich ausgereizt ist.

Vom Gefühl her - kommt schon ein bisschen an die Dauer eines gleichlangen sd-Schnittes auf meinem Lappi ran, ein bisschen, mir aber immernoch zu langsam wenn man bedenkt welcher Elefant da gerade mit dem TSDoc-Mäuschen rechnet. Der könnte es mit Multithreading wohl so schnell wie eine SSD 6GB schreiben kann - in ein paar sec.
Immerhin das Einladen des ts in den TSDoc macht Spass (ohne Werbungssuche): was orgelt mein Standard-i7-1.6@2.6GHz Lappi da rum - gäähn..was könnt ich derweil noch machen..däumchendreh... Beim gaming Haswell machts ridibe-ridibi-ridiba-ridibum, fertg, 5 sec, yeah so muß es sein!

Soweit erstmal...

[Djfe]

Was ist damit die GUI auf nen anderen thread zu legen?
sollte doch machbar sein oder?

->Beispiele:
Das Klicken von Hilfe während der Analyse pausiert die Analyse

seit einem der letzten Updates der Skinengine sind wenigstens die Animationen während der analyse flüssig, war auch mal anders
ka, ob man mittlerweile die Werbeanalyse unterbrechen kann oder der Doc noch immer zu beschäftigt ist, müsste ich mal testen (ok funktioniert endlich, danke dafür )

Im Schnittfenster könnte man eventuell einzelne Prozesse auch auf Threads verteilen (abgesehen vom Aufbau des Graphen)

ich weiß nicht, obs noch so ist, weil ich keinen zweiten Monitor habe, aber das Hauptfenster des Doc war immer zusehen
normalerweise ist es hinter dem Schnittfenster, wenn man das Schnittfenster aber auf dem zweiten Monitor hat, kann man es auf dem anderen sehen, nur nicht anklicken
kann man eventuell auch ausblenden, wenn es eh nicht anklickbar ist

EDIT:
noch ein Beispiel:
während der Analyse dauert das in den Vordergrund holen des Fensters z.T. länger, weil der TSD mit der Analyse beschäftigt ist
bei einem extra Thread für die GUI wäre das kein Problem mehr

[testest]

...Um I/O Performance-Einflüsse zu minimieren lasse ich TSDoc immer von einer Platte zu einer anderen über verschiedene 6G Controller auf SSD's lesen/schreiben...

Berechnet wurde immer das gleiche 10,2 GB, 116 min, Arte 720p Test.ts, alle Spuren hatten ein X bis auf das H264 Video und 1 MPEG/Layer2 Audio. Erzeugt wurde daraus ein 6,01 GB, 96 min fixed.ts (Film: Und täglich grüßt das Murmeltier).

Der Befund war recht eindeutig, zur Erinnerung:
Intel Sandy Bridge i7 (max. 3,6 GHz) über P67 Express Chipset - (auch nichts langsames von 2011) - brauchte 2 min 55 sec
und nun
Intel Haswell 4790K i7 (max. 4,4 GHz) über Z97 Express Chipset (ASUS ROG Maximus VII Hero) -----> brauchte 1min 54sec

So, TSDoc2 soll nun schneller sein, wollen sehen..

Gleicher Test, gleicher Rechner, gleiches File wie oben (Und täglich grüßt das Murmeltier) jetzt mit TSDoc 2.0.12:

Intel Haswell 4790K i7 (max. 4,4 GHz) über Z97 Express Chipset (ASUS ROG Maximus VII Hero) -----> brauchte 1min 12sec

Also von 114 sec Verbesserung auf 72 sec das ist 37% schneller.
Zwar noch kein Multithreading - ein einziger Thread steigt müde auf ~50% Leistung wärend TSDoc2 mit Priorität "Realtime" rechnet - aber immerhin!
(CPU Last gesamt ~9%).

Da könnten sich die 30€ Aufpreis auf lange Sicht gelohnt haben, die neue GUI ist ja auch hübsch..
Wünsche weiter frohes Gelingen!

[Mam]

Was ist damit die GUI auf nen anderen thread zu legen?
sollte doch machbar sein oder?

Jo, isset, brauchse sogar gar nix für tun 

Hätte er auch echt viel Arbeit, wenn er es verhindern wollte (vielleicht geht das in der Müslisprache auch gar nicht, ist nur was für Hardcore Freaks).

Windows macht das automatisch wenn bestimmte Funktionen (an denen keine GUI vorbeikommt) aufgerufen werden. Wenn die Messagequeue leer ist, wird der Thread gestoppt, der Neustart kann dann durchaus auf einem anderen Prozessor erfolgen.