Kompression: Performance Gewinn!?
 

Hallo zusammen,

Folgende These aus AVSIM Forum: Nach Kompremierung des ganzen FS9 Folders ergab sich auf vielen Systemen ein Performance Gewinn, sowie teilweise auch ein Framerate Gewinn - Nebeneffekt bzw. eigentlich Haupteffekt - HD Speicher!

Hat das schon jemand versucht oder ist das ein alter Hut?

Grüße
Sebastian

Moin Moin !

Wieso sollte eine Software-Komprimierung einen Performance-Gewinn bringen. Da hat das Betriebsystem und im Endeffekt die CPU viel mehr zu arbeiten, da die ganzen Dateien bei Gebrauch erstmal entpackt werden müssen.

Verfolgen werde ich es trotzdem mal oder hat das schon jemand hier ?

CU

Stephan

Grüsse Sebastian,
ich verfolge auch mit Interesse diese Diskussion bei Avsim und glaube die Wahrheit ist "relativ" ??!!!!.
Dieser Trick mit komprimierten Ordnern und Dateien stammt meiner Meinung nach aus der vergangenen FAT16 Zeit, da in einem ZIP file die Datenstruktur anders geordnet ist als auf der Festplatte mit fixen Clustern, was das Fragmentieren und den Zugriff betrifft.
Ich habe damals auch mühevoll meinen FS5 dazu gebracht auf diese Art zu "fliegen".
Eigentlich können alle Postings im Avsim thread stimmen
- der Rechner braucht Zeit zum Dekomprimieren
- durch den nicht an Cluster gebundene anderen Zugriff könnte der Flusi flüssiger erscheinen (mehr fps gibt es sicher nicht, die Graka hat mit komprimierten Ordnern nix am Hut)
- bei Systemen mit NTFS wird man keinen positiven Effekt (ausser Ordnergrösse auf der HD) bemerken

Hallo,
ich denke ein Performance-Vorteil kann sich allein schon dadurch ergeben, dass physikalisch weniger auf die Festplatte zugegriffen werden muss, weil ja die Datenmenge die gelesen wird kleiner ist. Die Frage ist einfach nur, ob die CPU-Zeit, welche zum entpacken der Daten verwendet wird größer ist als die Zeit, die die Festplatte braucht um die Daten unkomprimiert zu lesen.
Dazu ein kleines Rechenbeispiel (korrigiert mich, wenn ich grob daneben liege):
Nehmen wir an, eine 1 Megabyte große Datei wird auf 60% komprimiert also auf 0.6 Megabyte. Nehmen wir weiter an, daß die Festplatte eine Datenmenge von 40 MB/s über den Bus schieben kann (ob moderne Festplatten ein paar MB mehr oder weniger schaffen sei mal dahingestellt, etwa in der Größenordnung sollte es sich abspielen).
Dann braucht der Rechner zum lesen der Datei etwa 0.025 Sekunden (evtl. Zugriffszeiten und Wartezeiten nicht mit eingerechnet). Zum Einlesen der 0.6 MB braucht der Rechner aber nur 0.015 Sekunden. Der Zeitunterschied beträgt also 0.01 Sekunden. Bei einem Rechner mit 1GHz Taktfrequenz vergehen in dieser Zeit 10000000 (=10 Millionen!) Takte. Das ist ne Menge Zeit um die Datei zu dekomprimieren.
Je schneller die CPU und der Arbeitsspeicher des Rechners im Vergleich zum Festplattenzugriff sind, desto größer wird der Performancegewinn.

Nochmal Hallo,

So habs jetzt versucht. Hat ca. 30 min. gedauert, wie bei Avsim beschrieben.

@ Stephan:
So wie Du hab ich und ganz viel im AVSIM Forum auch reagiert. Dort wird ganz viel über die Sache diskutiert. Die meisten hatten Erfolg. Bei keinem hat es sich verschlechtert - nur weniger Speicherbelegung.

@ Schulz:

Es ist wirklich spannend. Die Komprimierung in WIN XP geht nur auf NTFS formatieren HDs. Wie es genau funktioniert ist nicht ganz klar. Man braucht wohl etwas mehr CPU Kapazität, aber bekommt einen schnelleren Datenzugriff, da nicht so viel auf HD gelesen werden muss.

Also bei mir hat es funktioniert. Ca. 3-4 FPS mehr Performance. Für die Darstellung, die sich laut AVSIM Forum auch erheblich besser werden, soll hab ich nicht so das Auge. Es kann sein, muss aber nicht. Der FLUSI läuft wie immer, aber eben etwas flüssiger!

Laut AVSIM geht dies nur bei PC mit 1.6 GHz oder besser. Dann sollte es aber funktionieren!

Erst mal viele Grüße
Seb

@Wean:

So wird auch im AVSIM Forum argumentiert und für mich macht das schon Sinn.

Jetzt frage ich mich, ob es eventuell ausreicht nur den TEXTURE Folder zu komprimieren????

@Seb:
käme wohl auf einen Versuch an. Die Dateien, die sich am besten komprimieren lassen, sollten die größte Performance bringen. Dazu gehören sicher auch die Texturen...
Bei mir läuft der FS9 aber derzeit unter Win98, weil ich festgestellt hab, daß ich mit der speicherhungrigen PMDG 737 dort eine etwas bessere Performance hinbekomme als unter WinXP. Von daher kann ich das mit dem komprimieren grad nicht testen.

@ Andreas:

Geht wohl unter Win 98 nicht. Schade. Bei mir hat es was gebracht. Lass es ert mal so, bis ich irgendwelche Probleme bekomme!

Die beste Performance hab ich mit CS727!!

Viele Grüße
Sebastian

3-4fps mehr ? gleiche Situation ?
Ich muss zugeben die höhere frame rate wundert mich.
Ich starte einen Versuch nur den Texture Ordner zu komprimieren, obwohl ich nicht glaube, dass sich die bmps der Texturen "gross" verkleinern lassen.
Ausserdem hängt ja die overall performance noch von diversen bgl files und wav files in anderen Ordnern ab.
Ausserdem würde mich interessieren ob sich bei längeren Flügen nicht wieder diverse Speicherprobleme auftun.

Ja klar, und Ufos gibt's auch. :D

Bei Spielen geht es gerade darum, daß alle benötigten Dateien auf einmal in den Speicher passen, damit zwischendurch keine Ruckler entstehen, weil auf die - sehr viel langsamere - Festplatte zugegriffen werden müßte.

Das besondere an der Komprimierung des NTFS ist die transparente Komprimierung: Wenn die Daten abgerufen werden, liefert das Betriebssystem sie so, als seien sie nie komprimiert gewesen. Jedes Programm findet seine Daten so vor, wie es sie kennt, das Dekomprimieren geschieht im Hintergrund, unsichtbar für das Programm. Eine ZIP-Datei müßte das zugreifende Programm explizit entschlüsseln.

Damit ist die Frage beantwortet, wie die Daten im Speicher vorliegen: Genau wie sonst auch, ohne esoterische Strukturveränderung.

Auch die nächste ist beantwortet: Solange man (vernünftigerweise) genug RAM hat, daß der Flusi nicht ruckelt (d. h. nicht oder nur selten auf die Festplatte zugreifen muß) hat eine Änderung der Dateien auf der Platte gar keinen Einfluß auf die Framerate.

Das einzige, was sich ändern könnte, ist die Ladezeit der Szenerien.

Grüße,

Betto

Für mich ist das totaler Quatsch. Die Daten liegen zur Verarbeitung ganz normal vor wie auch ohne Komprimierung und müssen ganz normal durch den, bei Problemen, zu schwachen Rechner.
Ich glaub nicht das die Komprimierung dabei schiebt.:D
Vielleicht hatten ja die Jungs die Hand aufliegen...;)

Eben! Das Nachladen der Szenerien ist es doch, was oft im Landeanflug ein Ruckeln verursacht. Wenn hier die Festplattenzugriffe dadurch veringert werden, daß pro Lesezugriff mehr Daten in den schnellen Arbeitsspeicher geholt werden, kann dies Ruckler verhindern helfen. Das hat nix mit Voodoo oder Handauflegen zu tun, sondern damit das Festplatten sehr langsam sind im Vergleich zum Arbeitsspeicher. Ich glaub zwar auch nicht, dass sich damit mehr Frames gewinnnen lassen. Aber zumindest die Ruckler sollten auf einigen Systemen weniger werden.

Ich glaube auch nicht unbedingt, dass es Wunder wirkt!

Aber, wer es nicht probiert, weiß auch nicht, ob es bei ihm was bringt. Man verliert ja nichts!!

Bisher läuft es bei mir echt besser. Das ist keine Einbildung. Standard Scenery in SEATAC mit Cessna und Fair Weather: ohne Komprimierung ca. 25FPS und mit ca. 30 FPS.

Natürlich hängt das von den Einstellungen und dem System ab. Deshalb einfach probieren und wenn es eben nicht besser wird wieder Rückgängig machen. Ganz einfach!

Ach ja, wer es nicht probieren will, muss ja nicht.

Viele Grüße
Sebastian

Jens, du ungläubiger Thomas ;)

das ganze ist schon etwas komplizierter...

Bei heutigen schnellen CPUs mit schnellem RAM kann die CPU in der Tat schneller komprimierte Daten lesen und dekomprimieren, als die Festplatte die unkomprimierten Daten überhaupt abgeben kann.

Dadurch ergibt sich in der Tat ein Performancegewinn, wenn Daten zwischendurch von der Festplatte gelesen werden müssen. Zusätzlich wird durch die Verlagerung der Dekomprimierung in das OS eine potentielle Parallelisierung der Tasks (Stichwort: HT) ermöglicht. Nebenbei passen durch die kleineren physikalischen Dateigrößen mehr Daten in den Plattencache, was natürlich den physikalischen Zugriff auf die Platte reduziert und damit wieder den Datendurchsatz ganz extrem beschleunigen kann :)

Der Effekt wird mit Sicherheit am deutlichsten sein bei schnellen HT-Rechnern mit langsamen Festplatten - ich kann dazu nur sagen: mit schnellem Rechner (>=2.8GHz) einfach ausprobieren...

das Resultat ist i.d.R. kein fps-Gewinn, sondern ein 'smootheres' Verhalten des FS (bei mir übrigens ist der Sound deutlich besser geworden; kein stuttern mehr)

HansJürgen

Ich denke, bei vielen Systemen heute ist weder die CPU noch die Grafikkarte die Limitierung, sondern der Speicherdurchsatz durch die Northbridge. Speziell System mit i845-Chipsatz, aber andere auch. Sobald das Texturmemory der Grafikkarte nicht mehr alle Texturen halten kann, geht da die Post ab - pro Frame.

Wenn dann die CPU dadurch, das sie ihre Daten komprimiert aus dem Cache holt, den Bus entlastet, kann die Grafikkarte mehr frames machen.

Fazit: Schlechte Systemkonfiguration mit zu schnellem Prozessor und zu schneller Grafikkarte für zu billiges Motherboard - also das, was man heute überall bekommt.

Moin Moin !

So, ich habe das eben mal über einen längeren Zeitraum getestet:
Bei mir bringt es nix ! Wie Alladin schon richtig sagte, es ändert sich ja an der Datenmenge nichts, die CPU und GPU berechnen müssen. Im Gegenteil, die CPU muß jetzt noch mehr berechnen und zwar das Entpacken der Dateien, die vorher komprimiert wurden.

CU

Stephan

@Burkhard:
guter Gedanke - der würde erklären, warum mitunter fps-Gewinne verzeichnet werden. Wieder mal gesehen, dass eigene Gedanken zwar gut, aber nicht immer weit genug sind ;)

@Stefan: es geht um mehr, als um die CPU/GPU... :) Wenn vorher der Flaschenhals die CPU/GPU war, dann ändert sich natürlich durch's (de)komprimieren nix - aber das steht ja auch oben schon.

HansJürgen

Moin Moin !

Sorry, vielleicht stehe ich total auf dem Schlauch ;)
Aber welche Komponente außer der Festplatte wird entlastet ? Da es sich bei dem Vorgang um eine Software-Komprimierung handelt, hat die CPU doch mehr zu tun, da es die Daten vor dem Verschicken z.B. der Texturen an die Graphikkarte noch entpacken muss.
Der Datenbestand in der Graphikkarte ist der selbe, weil die Graphikkarte nur mit den entpackten Daten was anfangen kann.

Ich versteh das alles nicht... :heul: ;)

Aber wenn es einigen geholfen hat, dann kann man es ja als möglichen Tip abheften, bei mir hat es nicht geholfen. Bin aber auch mit meinen Frameraten zufrieden.

CU

Stephan

Das stimmt, es geht einzig und allein darum, wie lange die Graphikkarte auf die Daten warten muss. Es müssen weniger Daten von der Platte gelesen werden. Diese müssen dafür entpackt werden was natürlich zusätzliche CPU-Zeit kostet. Da aber die Zeit für den Zugriff auf die Festplatte (da arbeitet Mechanik!) im Vergleich zur zusätzlichen CPU-Zeit, die für das entpacken der Daten benötigt wird wesentlich größer ist, ergibt sich auf vielen Systemen ingesammt ein Gewinn. Siehe auch meine Rechung weiter oben...

ps.: wieder ein neuer Stern :-)

genau das hat Burkhard oben beschrieben... :)

Aber auch Festplattenentlastung kann es bringen - du ahnst gar nicht, wie viel Daten der Flusi konstant immer wieder neu einliest (bzw. den Cache nutzt), ohne dass du was davon merkst. Und wenn dort die Performance besser wird, ist das Gesamtresultat positiv. Wenn komprimiert, dann mehr Daten im Cache. Aber selbst, wenn alle (unkomprimierten) Plattenanfragen aus dem Plattencache zu bedienen wären, dann bringt dir die Kompression immer noch die Reduzierung des Speicherdurchsatzes (siehe Burkhard)

Aber - wie du festgestellt hast - je nach System beim einen mehr, beim anderen weniger...

HansJÜrgen

Ich hab mal etwas Rumgetestet, auf einem Amd 1800+ system mit VIA controller und 512MB Standard SDRAM, dazu GF 2 MX Grafikkarte, .

Bekomme folgendes in zwei verschiedenen Modes, bei Blick über EDDF zum Vogelsberg mit MyTraffic aktiv:

Bildschirmauflösung 800x600 1024x768

Nichts komprimiert 13.6fps 13.6fps
Nur scenery\world\texture komprim. 14.9fps 14.8 fps
Zusätzlich das Aircraft-Verz.kopr. 18.8fps 14.8 fps


Also: Bei der höheren Auflösung begrenzt die Grafikkarte - zu erwarten. Bei der niedrigen bringt das Komprimieren eine Menge - da war wohl die Northbridge von VIA der Flaschenhals. Der Athlon hat offensichtlich überschüssige Energie :)

Also Mädels, ich kapiere es nicht. Erst mal kurz, ich habe es natürlich getestet, Ergebnis NULL.

So und dann erkläre mir mal jemand in Ruhe wieso ich mehr Performance haben soll, wenn der Rechner eigentlich mehr machen muß?
Zwar ist die Datengröße die von der Platte genommen werden muß kleiner, aber dafür muß diese dann wiederum dekomprimiert werden.
Also wenn überhaupt, dann könnte ich mir da ein Gewinn bei der Konstellation sehr schlechte HD/schnelle CPU vorstellen.
Das dabei 5 fps herauskommen glaube ich, ohne jemanden zu nahe treten zu wollen, nicht.
Da kann manchmal auch der Wunsch der Vater des Gedanken sein. ;)
Was ich gerne glauben will, das sich bei betroffenen Systemen Ruckler verringern lassen
Bei mir jedenfalls war es nix. Vielleicht liegt es daran das mein System insgesamt zueinander passt und die HD zu den schnellsten zählt.

Ist ja nur ne Idee und wenn jemand damit glücklicher ist, kann er es ja so machen. Da spricht doch nichts dagegen.

Komprimieren bringt schon was.

habe soeben mein Arbeitspensum komprimiert, und schon hatte ich früher Feierabend :D

tja, wer komprimiert, hat mehr vom Leben :lol:

Wer denkt, ein Computer bestände nur aus CPU, Grafikkarte und Festplatte, soll weiter im Kaffeeladen A oder L seine Computer kaufen.

Selbst ein falsch gewähltes IDE-Kabel kann schon massiv Geschwindigkeit kosten - und man findet selbst in neuesten System immer wieder 40-polige statt der 80-poligen.

Es scheint eine erhebliche Anzahl von Systemen zu geben, bei denen es hilft, und auch etliche, bei denen es nicht hilft. Das ist wohl die Tatsache. Argumente, es darf nicht sein was nicht sein kann, helfen da nicht weiter.

Nicht empfehlen würd ich es denjenigen, die wissen, das ihre CPU zu langsam ist, also PIII/Duron unter 1 GHz oder PIV unter 2 GHz.

Mal ne kleine Anmerkung am Rande. MS selbst hat beim FS2000 die BGL Komprimierung speziel eingeführt. Da waren fast alle Dateien komprimiert. Auch die GAP Scenery BGLs sind überwiegend komprimiert. Viele ADDON Teams machen das heute nicht mehr (mir ist das nur bei GAP aufgefallen). Könnte sein das deshalb die GAPS zusätzlich zu dem ohnehin sehr positiv programmierten Scenerien etwas besser als andere ADDONS laufen. Das habe ich neulich beim rumhacken in den BGL gemerkt. Ich bin nur bei den GAPS auf die komprimierten Daten gestossen.

Ich weis das hat jetzt alles nichts mit der Festplattenkomprimierung zu tun. Aber es ist ähnlich und MS hat damals genau damit argumentiert. Sie können so schneller die Daten zur CPU und zur Graka liefern. Da der neue FS2004 die GAP Daten lesen kann, kann er auch mit speziell komprimierten BGLs arbeiten. Ja vermutlich liest er die sogar direkt ohne zu dekompilieren. Das wäre dann sogar ein Vorteil gegenüber der Festplattenkomprimierung. Eine GAP Datei mit einer Größe hatte komprimiert 47KB unkomprimiert 200KB. Bei den neueren Datein weis ich nicht ob das geht da werde ich das mal testen.

Joachim, was Du schreibst scheint schon plausibler, scheint es sich dabei doch um eine spezielle Komprimierung zu handeln, die der FS auch lesen kann. dann wäre ja auch die gesamt Datenmenge die durchläuft kleiner.

Bei der Festplattenkomprimierung bleibt die Datenmenge letztendlich jedoch gleich und somit steht am Ende der Kette die gleiche Arbeit an.

Burkhard, ich weiß ja nicht welchen Rechner Du hast, aber wenn es so gravierend ausfällt, könnte es schon ein Kaffeerechner sein.
Da lobe ich mir den Selbstgeschraubten...;)

Jens,
ich weiss ja nicht, warum du's nicht verstehen willst ;) , aber Effizienz hängt doch nicht nur vom Arbeitsvolumen, sondern auch von einer geeigneten Verteilung der Aufgaben ab...

Bei einem schnellen Rechner mit relativ langsam angeschlossenen Festplatten kann es doch viel sinnvoller sein, den schnellen Rechenknecht mehr zu beschäftigen, damit die langsamen Komponenten nicht das ganze wesentlich schlimmer ausbremsen.

Bei einer Festplatte kann es doch sinnvoller sein, den Plattencache mit vielen (komprimierten) Dateien zu füllen, die die CPU später schnell mal entpacken muss, als den Cache mit wenigen (unkomprimierten) Dateien zu füllen, und die CPU hat weniger zu tun, muss aber später warten, bis die Platte die fehlenden (unkomprimierten) Dateien wieder eingelesen hat

Bei einem Engpass im Speichertransfer (Northbridge, da müssen alle Daten durch) kann es sinnvoll sein, dass weniger (komprimierte) Daten "durchgeschleusst" werden, die später erst ausgepackt werden

Bei einem Hyperthreaded oder Multiprozessor Rechner kann es doch sinnvoll sein, wenn ein 'Prozessor' sich (auf Betriebssystemebene) mit dem dekomprimieren beschäftigt, während der andere Prozessor davon überhaupt nichts mitkriegt, sondern im Gegenteil immer schön schnell mit Daten versorgt wird, weil kein DatenEngpass mehr da ist

Keine Angst, ich bin schon ruhig - ich wollte nur noch einmal den Versuch machen, zu erklären, warum es durchaus von Vorteil sein kann - man kann's sogar erklären.

HansJÜrgen

eins noch: es macht wesentlich weniger Sinn, wenn der Flusi seine Daten selber dekomprimiert - dann fällt nämlich der Nebenläufigkeitsaspekt (HT) raus...

Was Jens meint ist diese Aussage:
Und ich gebe im Recht, das ist Quark.
Dennoch stimmen, rein theoretisch alle anderen Aussagen auch, aber um die geht es nicht. HansJürgen, als Progarmmierer weißt Du, dass zu Zeiten der Speicherknappheit fast jede EXE komprimiert war (und heute auch noch ist). Dass man damit Plattenspeicher spart ist keine Frage, aber wozu?
MS hat nun offenbar bei einigen Dateien dieses Verfahren auch angewendet, wenn auch aus anderen Gründen denke ich. Aber ein gesamtes Verzeichnis zu komprimieren, um eine höhere Framrate zu erreichen ist schon etwas abenteuerlich.

Kompression: Performance Gewinn!?


sicher



aber nur bei verbrennungskraftmaschinen.


eher weniger bei computern :D

mal am Rande: auch die Kompression des Espresso hat entscheidenden EInfluß auf seinen Geschmack. Er sollte nur soweit komprimiert werden, daß Wasser von 95°C mit ca. 9 bar durchgedrückt werden kann. Ansonsten schmeckt er nicht ..... hab´s gelesen :D

...wieder was gelernt :D


http://www.hatzer.at/forum/images/sm...n_question.gif

naj, irgendwie aber bleibt eine Frage offen: wie verhält sich das ganze im Flugzeug bei abnehmender Druckhöhe. Der Siedepunkt des Wassers sinkt, wie weit muß dann die Wassertemperatur für den Espresso gsenkt werden (konstant 5 Grad unter Siedepunkt oder proportional oder ist es eine komplizierte Funktion?) und welcher Druck gehört dann zum wohlfeilen Espresso?

Moin HansJürgen,

ich will es ja gerne verstehen.
Darum hab ich ja meine Gedanken oben geschrieben. In weiten Teilen decken sie sich ja mit dem was Du geschrieben hast.
Nur, bleibt nach den vielen durchaus einleuchtenden Vorteilen, am Ende eine Texture, ein Polygon etc. in der gleichen Form wie vorher und diese müssen durch die gleiche Hardware die durch Kompression nicht an Leistungsfähigkeit gewinnt.

Wie gesagt, das man dadurch Stottern mildern kann leuchtet mir ein, nur Frames eben nicht.

Hyperthreading wäre sicher eine interessante Sache, nur kann der MS das nutzen? Sprich werden die Aufgaben wie gewollt verteil?
Eine CPU dekomprimiert und die andere „fliegt“?

Da haben wir wohl beiden den gleichen Artikel gelesen. Auch wenn ich 3000¤ für eine Maschine etwas viel fand... :D

ja, stimmt, ist teuer, allerdings kostet die Maschine nur 250,-, der Rest ist für die "Wohlschmeckgarantie mit Italianflair-Versicherung".

War der Artikel im Sxxxxxx oder im Fxxxxx?

Ich habe es entgegen meiner persönlichen Safety-Vorschriften ausprobiert und: es funktioniert.

Ich habe jetzt die gleiche Performance mit "Very Dense" Einstellungen wie zuvor mit "Dense" (~20fps, wobei die Density Regler die einzigen sind die nicht auf voll-rechts stehen).

Auf jeden Fall einen Versuch wert.