ZFX + Developia

TDK hat geschrieben:ZLIB vs. Snappy

Ob das gut oder schlecht ist, hängt von zwei Fragen ab:

1. Ist die Anwendung symmetrisch (wird auf dem Zielsystem genau so oft komprimiert wie extrahiert)?
2. Wo bekommt das Zielsystem deine Daten her? (Für das Internet wäre diese Kompressionsrate zu niedrig; für DVD wäre das eine schöne Verbesserung; auf PCs ist die meiste Kompression dieser Größenordnung Verschwendung.)

Trotzdem Glückwunsch.

Ich habe angefangen, das Shadowmapping von meinem Egoshooter-Projekt in "Das Volk und der Turm" zu integrieren. Bis auf ein paar kleine Grafikfehler sieht das auch schon ziemlich hübsch aus :)

Ist die Anwendung symmetrisch (wird auf dem Zielsystem genau so oft komprimiert wie extrahiert)?

Die Daten werden nur ein mal beim Import komprimiert. Da beim Komprimieren allerdings tausende Einzeldateien komprimiert werden, spielt die Zeit schon eine Rolle. Die Content Creator reagieren sonst immer so gereizt, wenn alles so lange dauert...

Ansonsten werden diese auch teilweise während des Simulationslaufes nachgeladen, ab und zu mehrmals. Und da ist eine schnelle Leserate, und vor allem auch weniger Festplattenknistern, von Vorteil. Und die CPU benötige ich nebenbei auch noch.

Ich verwende für alle komprimierten Dateien ein Format, welches zugleich die Versionierung und den Inhaltstyp gegenprüft. Zudem ist das Format so intelligent, dass wenn es eine Änderung der Originalversion festgestellt wird (besonders XML-Konfigurationen), die Datei sofort neu importiert werden kann.

Wo bekommt das Zielsystem deine Daten her? (Für das Internet wäre diese Kompressionsrate zu niedrig; für DVD wäre das eine schöne Verbesserung; auf PCs ist die meiste Kompression dieser Größenordnung Verschwendung.)

3D-Objekte, Konfigurationen (Node-Attribute-Value System), Texturen (teilweise DXT 5) und sonstige binäre Dateien wie World Files und Terrain Files. Jedes MB zählt, da das gesamte Programm mit den verschiedenen Welten viele Gigabyte in Anspruch nehmen wird.

TDK hat geschrieben:Da beim Komprimieren allerdings tausende Einzeldateien komprimiert werden, spielt die Zeit schon eine Rolle. Die Content Creator reagieren sonst immer so gereizt, wenn alles so lange dauert...

Dann komprimier es halt nicht während der Entwicklungsphase, sondern nur vorm Ausliefern; dann schrumpft der Zeitaufwand gegen Null.

TDK hat geschrieben:Ansonsten werden diese auch teilweise während des Simulationslaufes nachgeladen, ab und zu mehrmals. Und da ist eine schnelle Leserate, und vor allem auch weniger Festplattenknistern, von Vorteil. Und die CPU benötige ich nebenbei auch noch.

Dann komprimier am besten garnicht – dann werden ab dem zweiten Lauf weder Festplatte noch CPU überhaupt benötigt.

TDK hat geschrieben:Jedes MB zählt, da das gesamte Programm mit den verschiedenen Welten viele Gigabyte in Anspruch nehmen wird.

Bei Snappy kannst du mir nicht erzählen, dass „jedes Byte zählt“. Wenn die Welten sechs oder sieben GiB in Anspruch nehmen, dann sollen sie das halt. (Ich werte das auch einfach mal als die Daten kommen von der Festplatte eines PCs).

Afaik nutzen selbst RAD Game Tools Kompression nur noch auf Konsolen, weil der Windows Page Cache auf dem PC alles wegrockt. Und mit wegrocken meine ich an eigenen Beobachtungen: 12.000 Dateien in einer Drittelsekunde in den Speicher holen; 4 GiB unkomprimierte Texturen 100× schneller einblenden als die zlib-komprimierten Varianten – mit CPU-Unkosten gegen Null.

Ich habe bei meinem derzeitigen Projekt auch die Wahl, es mit einem komprimierten Paket aus zu starten oder mit einem unkomprimierten Verzeichnis (erwähnte 12k Dateien) – und ich nehme immer das Verzeichnis, weil mich die Wartezeiten sonst in den Wahnsinn treiben.

Komprimiert werden sollte nur für die Auslieferung via Installer. Davor und danach hat alles unkomprimiert zu sein.

Krishty hat geschrieben:Afaik nutzen selbst RAD Game Tools Kompression nur noch auf Konsolen, weil der Windows Page Cache auf dem PC alles wegrockt. Und mit wegrocken meine ich: 12.000 Dateien in einer Drittelsekunde in den Speicher holen; 4 GiB unkomprimierte Texturen 100× schneller einblenden als die zlib-komprimierten Varianten – mit CPU-Unkosten gegen Null.

Hart sekundiert. Das einzige, was man noch selber machen kann, ist, die Dateien selber zu prefetchen (d.h. ein Memory-Mapping darauf anlegen), wenn man weiß, dass man sie in Zukunft benötigen wird. In diesem Falle hat man einfach mehr Informationen als das Windows-Speichersystem, welches ja schlecht in die Zukunft schauen kann.

eXile hat geschrieben:In diesem Falle hat man einfach mehr Informationen als das Windows-Speichersystem, welches ja schlecht in die Zukunft schauen kann.

Wobei auch das selten zum Problem werden sollte – kommt der Kunde nach dem Kauf am Montag jeden Tag um 17:30 (nach Arbeit und Essen) an den PC, um eine Runde Deathmatch auf seiner Lieblingsspielkarte zu spielen, wird Windows ab MI alle Spieldaten um 17:25 vollständig im Page Cache haben. Falls man dann auf Kompression verzichtet hat, müsste der Kunde innerhalb von zehn Sekunden nach dem Klicken auf die Verknüpfung im Blut baden können. Falls man aber auf Kompression gesetzt hat, lädt es genau so lahm wie immer.

Unrelated: Ich habe shell32.dll aus meinem Programm entfernt gekriegt. Sie hatte von den 40 MiB Images, die mein Prozess benötigt, 13 ausgemacht – und damit etwa gleich viel wie Direct3D und AMD-Treiber zusammen.
Jetzt möchte ich unbedingt die VC-CRT raushaben – die frisst zwar nicht viel Speicher, mappt aber Font-Dateien und Locales aus dem Windows-Verzeichnis. Meine Fresse, was für ein Trauerspiel.

Krishty hat geschrieben:

eXile hat geschrieben:In diesem Falle hat man einfach mehr Informationen als das Windows-Speichersystem, welches ja schlecht in die Zukunft schauen kann.

Wobei auch das selten zum Problem werden sollte – kommt der Kunde nach dem Kauf am Montag jeden Tag um 17:30 (nach Arbeit und Essen) an den PC, um eine Runde Deathmatch auf seiner Lieblingsspielkarte zu spielen, wird Windows ab MI alle Spieldaten um 17:25 vollständig im Page Cache haben.

Trollierst du mich gerade? ;) Ich meinte eher: Es ist ein Cache, kein Precache. Dass gleich in einem Spiel das Level zu Ende ist, und das nächste anfängt, und man somit schon mal leise im Hintergrund anfangen könnte, ein wenig vorzuladen, ist durchaus sinnig.

Wenn man also einen grandiosen Cache wie unter Windows hat, ist nicht mehr die Frage, wie man Cachen soll (nämlich mit Memory-Mappings und dem Windows-Cache), sondern was und wann man etwas cachen sollte.

Vielleicht erinnere ich mich auch nur einfach sentimental an die Zeiten zurück, als ich noch in Spielen in sekundenschnelle Speichern und Laden konnte. :(

(Und was soll Windows MI sein? Der ungeliebte Bruder von Windows ME mit Buckelrücken? Schwätz deutlich Junge! ;))

Upps; da hast du völlig recht. Ich bin ein wenig in meiner Ich lade einfach alles auf einmal direkt am Anfang-Philosophie steckengeblieben ;-)

(Und was soll Windows MI sein? Der ungeliebte Bruder von Windows ME mit Buckelrücken? Schwätz deutlich Junge! ;))

Okay, nochmal für alle: Windows hat dann ab Mittwoch nachmittag 17:25 alles parat ;)

Nach wochenlangem Hinauszögern habe ich es endlich geschafft, (m)einen Artikel über Functional Purity in D fertig zu schreiben: http://klickverbot.at/blog/2012/05/purity-in-d/. Sorry für die schamlose Eigenwerbung, aber ich dachte, nach Carmack's kürzlich erschienenem AltDevBlogADay-Artikel könnte das für so manchen interessant sein…

Diskussion auf Reddit und Hacker News. Feedback aller Art höchst willkommen!

OMNOMNOM, endlich kann ich wieder vernünftig arbeiten :D (scnr)

Uff. Was hast du dafür ausgegeben wenn man fragen darf? ;)

Da kann man nur gratulieren. 12 Cores? Was ist das für eine Prozessorkonfiguration, die du hast?

Ich finde es auch sehr schön, dass du die Fensterhöhe exakt und pixel-genau zwischen beiden Fenstern angeglichen hast. Nur leider ist der Rahmen oben fünf Pixel zu klein. Ja ich achte auf sowas. ;)

Artificial Mind hat geschrieben:

i7x6.680gtx.png

OMNOMNOM, endlich kann ich wieder vernünftig arbeiten :D (scnr)

Lächerliche 4 GiB RAM

Ich tippe einfach mal auf einen Sandy Bridge E. Und die 32GiB RAM sehen lecker aus, wobei ich mit 16 derzeit noch zufrieden bin.

Ich frage mich aber immer wieder warum Windows so einen zwanghaften Drang zum auslagern hat. Selbst bei dieser Konfig schiebt der bei dir immer noch Speicher auf die Platte. :?

Lynxeye hat geschrieben:Ich frage mich aber immer wieder warum Windows so einen zwanghaften Drang zum auslagern hat. Selbst bei dieser Konfig schiebt der bei dir immer noch Speicher auf die Platte. :?

Das habe ich auch bemerkt, darum habe ich die Auslagerungsdatei komplett deaktiviert.

Linux hat auch den spleen auslagern zu müssen.
Besonders ärgerlich, wenn man keinen Swap-Space eingerichtet hat, weil dann nach einem magischen Schlüssel irgendein Prozess gekillt wird.
Das ist schon seit 2.4.irgendwas im Kernel enthalten und bis jetzt noch nicht gefunden worden.

simbad hat geschrieben:Linux hat auch den spleen auslagern zu müssen.
Besonders ärgerlich, wenn man keinen Swap-Space eingerichtet hat, weil dann nach einem magischen Schlüssel irgendein Prozess gekillt wird.
Das ist schon seit 2.4.irgendwas im Kernel enthalten und bis jetzt noch nicht gefunden worden.

Hast du dazu was genaueres? Ich habe hier aus historischen Gründen immer noch eine 2GB Swap Partition eingerichtet, und auf die ist seit langer Zeit nicht 1MB mehr geschrieben worden. Ich habe allerdings auch nie wirklich mehr als 50% reale Ramauslastung, die 16GB habe ich nur um entsprechend viel Pagecache vorzuhalten.

Ja.
Unter Last kommt das virtual memory management von Linux aus irgendwelchen unerfindlichen Gründen zu dem Schluss, das im Hauptspeicher kein Platz mehr ist und ruft dann den Swapper an, damit der Platz schaft. Und der Swapper hat eine Funktion als Last-Resort, in der ein Prozess gekillt wird, wenn der Swap-Space voll ist.
Gibt es keine Swap-Partition killt er gleich.
Man hat mal im 2.6.8 Kernel einen Versuch gestartet das VMM zu ersetzen. Das hat aber nie fehlerfrei funktioniert. Daraufhin hat man das alte VMM wieder eingebaut und lebt nun mit diesem Verhalten. Denn ich kann auf meinem Rechner, der schlappe 28GB-RAM hat, nach einem Virenscan mit free schauen wie die Speichernutzung ist und voila.
Es gibt keinen vernünftigen Grund auszulagern. 25G Cached. Da wird doch wohl ein bisschen was übrig sein um sich das swappen zu sparen.

Fakt ist, das ich schon diverse Linux-Systeme gesehen habe die keinen Swap-Space hatten und über die man mir berichtete, das da manchmal Prozesse verschwinden würden. Nach einrichten des Swap-Space, und sei er noch so klein, war das Phänomen erledigt.

simbad hat geschrieben:Fakt ist, das ich schon diverse Linux-Systeme gesehen habe die keinen Swap-Space hatten und über die man mir berichtete, das da manchmal Prozesse verschwinden würden. Nach einrichten des Swap-Space, und sei er noch so klein, war das Phänomen erledigt.

Jawoll, wir beschreiten das Zeitalter der fehlertoleranten Software!

Andre hat geschrieben:Uff. Was hast du dafür ausgegeben wenn man fragen darf? ;)

Also der six-core i7 war so ca. 500€, die 680 gtx ca. 550€, beim RAM musste ich teureren 240€ für 32GB nehmen, da mir der 180€ 32GB von Mushkin mit Fehlern zugesandt wurde. Mainboard auch nochmal 240€. Dazu kommt 2 mal 120 GB SSD im RAID 0 mit je 80k IOPs für je 85€.

eXile hat geschrieben:Da kann man nur gratulieren. 12 Cores? Was ist das für eine Prozessorkonfiguration, die du hast?

Das ist der neue i7 3930K, 6 Kerne @ 3.5 GHz mit HT.

eXile hat geschrieben:Ich finde es auch sehr schön, dass du die Fensterhöhe exakt und pixel-genau zwischen beiden Fenstern angeglichen hast. Nur leider ist der Rahmen oben fünf Pixel zu klein. Ja ich achte auf sowas. ;)

Arrrgh, ja ich hatte nur auf Fensterhöhe geachtet. Da das aber nach Weiß ausfadet, war mir der Rahmenabstand egal ;)

antisteo hat geschrieben:Lächerliche 4 GiB RAM

Auf der Grafikkarte.

Na wenigstens weiß ich jetzt, an wen ich Implementierungen zum Ultra High End Benchmark schicken kann. ;)

Tu dir keinen Zwang an, meine Nummer hast du ja ;)

Ist Standard-Ausnahmebehandlung eingeschaltet (/EHsc), nimmt Visual C++ an, dass extern "C"-deklarierte Funktionen keine Ausnahmen werfen. Das ist tatsächlich mal was Sinnvolles und spart mir jede Menge throw()-Dekorationen.

http://herbsutter.com/2012/05/04/lookin ... engineers/
http://herbsutter.com/2012/06/01/were-h ... gain-more/

Wer hätte das gedacht...

Kann es tatsächlich wahr sein, dass Microsoft es mit der "C++ Renaissance" doch ernst meint? :D

lol – AMP, PPL, Windows Phone und GPU. KA, was Casablanca ist; aber es hat sicher mit Wolkendiagrammen zu tun.

Krishty hat geschrieben:KA, was Casablanca ist; aber es hat sicher mit Wolkendiagrammen zu tun.

http://msdn.microsoft.com/en-us/devlabs/casablanca.aspx hat geschrieben:Casablanca is a Microsoft incubation effort to support cloud-based client-server communication in native code using a modern asynchronous C++ API design.

Warum nur

SyncToy (meine einzige Form der Quelltextarchivierung) verschiebt zum Glück jede überschriebene Datei in den Papierkorb. Das hat mir meinen süßen Popo gerettet, nachdem ich schlafentzogen die Sicherheitskopie aufs Entwicklungsverzeichnis gespiegelt habe statt umgekehrt.

Nvidia buddelt dann mal wieder ihre Waldfee aus; wobei ich im Video klar die Nachteile von FXAA sehen konnte. Für die gigantischen Screenshots haben die (vermute ich mal) einfach die Szene mehrfach mit (auf der Bildebene) verschobenen Projektionsmatrizen gerendert.

Fantastisch, wie sie es mit 4 Millionen Dreiecken und 40.000 Haaren immer noch schaffen, dass alles nach billigstem CG aussieht.

Man sieht vorallem nichts neues wenn man mal in deren SDKs geschaut hat. Also so vom Hocker hauen tut mich diese next-next-gen noch nicht. Und das obwohl doch immer alle gesagt haben sie würde alle vom Stuhl/Sofa fegen.