Ankündigung: Neuer Decoder

[friendly]

Ich habe jetzt wegen schönen Wetters garnichts durchgelesen.

Sinnvoller dürfte erstmal die Optimierung der Disk-I/O-Vorgänge sein; die restlichen Kerne werden doch eh' dazu gebraucht, gleichzeitig einen Film auf den Monitor auszugeben!

[Mr. S]

Sinnvoller dürfte erstmal die Optimierung der Disk-I/O-Vorgänge sein; die restlichen Kerne werden doch eh' dazu gebraucht, gleichzeitig einen Film auf den Monitor auszugeben!

Das wird zumindestens bei meinem Decoder verbessert. In der Tat ist der IO-Zugriff das Problem. Das wird sich auch nicht ändern, da der verwendete Blowfish für jede verfügbare Festplatte zu schnell ist (außnahme vielleicht wenn man mit 500 MHz decodiert ). Blowfish schafft mehr als 30 MB/s, nur schafft das keine Festplatte diese Menge gleichzeitig zu lesen und zu schreiben. Die schnellen Festplatten schaffen vielleicht 50 MB aber nur lesen und nicht gleichzeitig auch noch schreiben. Ganz zu schweigen davon, das das Verfahren immernoch diese blöde Blockverschiebung hat, womit alle paar Bytes erst mal die Zugiffszeit gewartet werden muss bis der Schreib-Lese-Kopf zu dem nächsten Fragment gesprungen ist. Mit dem neuen Verfahren wird das besser und eine IO-Optimierung wird nochmal zusätzlich Speed bringen. Eine Mehr-Kern-Unterstützung bringt noch nichts. Vielleicht ändert sich das mal wenn es Flash-Speicher mit genügend Geschwindigkeit gibt, aber das dauert noch eine Weile. Das gleiche gilt auch für eine 64-Bit-Optimierung.

[fr3ddy]

Hm komisch, bei meinem Athlon64 3700+ (2,2 GHz) braucht der decoder 100% CPU. Und mit meinem Athlon xp 2600+ geht es auch deutlich langsamer.
Ach ja udma ist auf on...

Ich habe gerade fest gestellt, dass dieses Problem nur unter Linux auftritt, unter XP verhält er sich wie von euch beschrieben.

Damit wird die mehrkern unterstützung natürlich hinfällig :-/

[httpkiller]

ich weiss garnicht, warum so viele über die Dekodier-Geschwindigkeit jammern

XP 2800+ @2413MhZ , 2 GB DDR-4000 und RAID-System, fürn Standart Film (2 Stunden) brauch der nedmal ganz ne Minute.

Multicore-Optimierung ist meiner Meinung nach NOCH nicht sinnvoll, ich denke, die Mehrzahl der PC-Anwender nutzen immernoch Single-Core Prozessoren (Mich inbegriffen )

mfg,

[Taube]

Bedenke, dass nicht jeder Benutzer High-End-PC hat und dafür nutzen möchte! Wir haben einen Linux-Rechner als Router im Keller. Nachttraffic ist bei uns günstiger - was liegt also näher auf der paar hundert Mhz-Mühle als entsprechende otrkeys dann zu laden und bereits dekodiert abzulegen?

[sw2005]

stimmt, mache ich auch oft... nicht dran gedacht. Wenn der RAM nicht ausreicht, ist diese Komfort-Funktion eben deaktiviert (oder gleich vom Benutzer einstellbar)

Andererseits wird auf dem Linux-Router sicher nicht Mr.S's Decoder laufen

[Taube]

Andererseits wird auf dem Linux-Router sicher nicht Mr.S's Decoder laufen

Um ehrlich zu sein blicke ich gerade nicht mehr durch, wessen Decoder auf welchem Betriebssystem in welcher Version für wen was macht.

[Monika]

Der Decoder von Mr. S ist für Windows.

[Mr. S]

Der Mr. S-Dekoder macht das bereits so, dass er größere Blöcke im RAM decodiert und dann zusammen wegschreibt, wenn man den so einstellt (gibt es irgendwo einen Schieber wie viel RAM der dafür verwenden soll). Es macht dabei kaum Sinn, mehr als 20MB oder so zu verwenden, alles da drüber wirkt sich in der Regel kaum noch aus. Der OMR-Multidecoder macht das dagegen aber noch nicht bzw. verlässt sich darauf das Windows das schon irgendwie hincachen wird, was es auch zu tun scheint, sonst wäre der deutlich langsamer. Was den Decoder langsamer macht als den von Mr. S ist die MD5-Prüfung sowohl vor als auch nach dem decodieren und einige sinnlose Warterei nachdem der Key vom Server geholt vor dem decodieren wird bzw. zwischen zwei dekodiervorgängen. In dem Decoder wimmelt es nur so von sinnlosen sleep()s... Was außerdem meiner Meinung nach absolut keinen Sinn macht ist ein MD5-Check der decodierten Datei, der hier aber durchgeführt wird. (Jedoch nur bei neuen OTRKEYs, die ihr noch nicht habt.). Die Verzögerung die ihr bemerkt beruht schlichtweg auf Wartebefehlen in dem Programm.

Ahhh, ich fühle mich geschmeichelt, aber ganz korrekt ist das leider nicht. In der Tat hat mein Decoder diese Speichereinstellung (MsTiFtS hast Recht, ich werde das auf 64 MB beschränken) aber das Ganze ist leider noch ohne Wirkung. Das einlesen von größeren Dateimengen funktioniert erst mit der nächsten Version korrekt. Sleeps sind bei mir auch drin, aber die kann man mit dem Verzögerungsregler ausschalten. Ich bezweifel das Windows da richtig cached, sondern behaupte mal das es eher die Festplatte ist. Bei Windows ist mir eine solche Funktion nicht bekannt.

[JennyMiller]

Der Festplattencache macht zwar sicherlich auch was aus, aber da dieser im Verhältnis zum Windowscache extrem klein ist, wird der Windowscache im Moment sicher den Löwenanteil ausmachen.

Windows ist dafür bekannt, dass es selbst den Cache auslagern kann.

Wenn ich mit 2GB RAM eine 100MB-OTRKEY direkt nach dem Download dekodiere, [...]

Ich denke, der Standard ist bei nicht-Höllenmaschinen eher 512MB bis 1024MB RAM und die OTRkeys bewegen sich auch eher in Richtung 1GB Größe

Wie auch immer, ihr Programmierer werdet das schon richtig machen. Den aktuellen OTR-Dekoder zu verbessern sollte ja nicht schwer sein