dWing — die Welt ist nicht gerecht

sign in

Tagesrückblick 2010-03-29

Habe mein vServer Paket hochgestuft, nun steht mir vier mal so viel Hauptspeicher zur Verfügung. Habe ein dist-upgrade auf die Lucid Beta versucht, ohne Erfolg. vServer neu installiert mit Hardy. Backups über rsync einspielen, Software auf Server installieren.

dWing wollte anfangs nicht. Update auf die aktuelle Entwicklungsversion. Bug behoben, dass bei fehlgeschlagener SQL Verbindung das Passwort im Stack Trace angezeigt wurde.

Die OpenID Bibliothek hat viel Stress verursacht. Im Endeffekt hat das php5-gmp Paket gefehlt. Die Bibliothek sagt allerdings nichts und produziert einfach falsche Ergebnisse. Viel Zeit mit der Lösungssuche verloren, geht nun.

Die Bibliothek selbst hat dringend eine Neuprogrammierung von null auf nötig.

Server bietet nun 160 Zugriffe/Sekunde, 530 für einfache Seiten.

Tagesrückblick 2010-02-25

Ich habe meinen Server weiter optimiert, nun schafft die komplexe Startseite von dWing 150 Zugriffe pro Sekunde, einfachere Seiten schaffen bis zu 400.

Es pisst mich total an, dass Michael Larabel immer noch keine Bootcharts lesen kann.

Habe selbst auch mit Lucid experimentiert… Leider funktioniert Nouveau KMS nicht auf meinem Laptop. Das Bild wird schwarz und nichts geht mehr. Vielleicht sollte ich einfach probieren mein Passwort einzugeben, vielleicht wird dies akzeptiert obwohl der Bildschirm Schwarz bleibt.

Ohne Worte

public class ContentItemServiceImpl implements ContentItemServiceLocal, ContentItemServiceRemote {
	// …
	public void updateTextContentWithoutStoringPipeline(ContentItemI item, String content) 
		throws TextContentNotChangedException {
		
		ContentItem _item = item.getDelegate();
		
		if(renderingPipeline.renderEditor(_item.getTextContent()).equals(content)) {
			throw new TextContentNotChangedException("Could not create TextContentUpdate for an unchanged text content");
		}
		// …
	}
	// …
}

Effiziente Resource-Dateien

In einem meiner letzten Beiträge hatte ich das Laden von Spielinhalten in aktuellen Spielen kritisiert und davon geträumt, dass Spielinhalte mit mmap() in den Prozessspeicher abgebildet werden aber tatsächlich im pagecache des Betriebssystems liegen. Nun habe ich einen sehr interessante Blog Eintrag über effiziente Ressourcenverwaltung in einer Engine gelesen. Dabei werden die Inhalte direkt als C-Strukturen in Dateien geschrieben und von denen direkt gelesen.

Irgendwie finde ich es toll, dass jemand anders die selben Ideen wie ich hat und diese auch umsetzt, ich werde mich auf die Engines freuen die so etwas umgesetzt haben.

Tagesrückblick 2010-01-26

Ich habe mir vorgenommen etwas öfter zu bloggen. Möglicherweise im Stil kleiner Tagesrückblicke.

Ich habe den ersten Schritt gemacht und habe gelernt wie in Mozilla ein neues CSS Property definiert wird. Es war komplizierter als ich dachte. Die Teile für den Parser und die DOM Unterstützung sind getrennt aber auch darüber hinaus gibt es sehr viele Dateien in denen man etwas rumwerkeln muss. Leider fehlt mir jetzt die Motivation die nächsten Schritte auch zu tun.

Ich bin auf das LuxRender Wiki gestoßen. Dort werden Erfahrungen mit OpenCL im Bezug zu Path Tracing gesammelt. Intel arbeitet ja seit langer Zeit an spielefähigem Ray Tracing. Dafür OpenCL und somit die Grafikkarte zu nutzen liegt sehr nahe. Scheinbar kann man damit auch sehr gute Ergebnisse erzielen.

Über Umwege bin ich dann zu einem kleinen Tutorial gelangt, wie man Schrittweise die Größe von Linux Executables verkleinert. Ein simples C Programm wird von ~4K auf 45B geschrupft. Es ist zwar keine valide ELF Datei mehr, aber wird trotzdem von Linux ausgeführt. Sehr interessant zu lesen, auch wenn es keine praktische Bedeutung hat.

In letzter Zeit spiele ich immer mehr Team Fortress 2. Um mich zu entspannen und vom Leben abzulenken. Aber es lädt extrem lange und hängt dabei auch noch das gesamte Betriebssystem auf. Experimente im Fenstermodus und mit dem Windows Resource Monitor haben gezeigt, dass die Festplatte für einige Zeit zwar voll ausgelastet ist, aber keine Daten liefert. Für den Steam Prozess werden über 10 Sekunden bei der Reaktionszeit einiger Lesezugriffe angezeigt. Ist auch logisch, dass während dieser Zeit keine anderen Daten gelesen werden können und somit keine neuen Prozesse wie beispielsweise der STRG+ALT+ENTF Prozess gestartet werden können. Der Verdacht liegt nahe, dass etwas mit der Laptop Festplatte nicht stimmt. Unter Linux zeigt es mir bereits seit längerer Zeit einen Fehlerhaften Sektor an. Da heißt es demnächst nochmal Backup machen.

Die Kombination aus Steam und TF2 ist außerdem absolut ineffizient. Steam selbst braucht 80M und TF2 in Fenstermodus mit niedrigsten Grafikeinstellungen 600M. Auf hohen Einstellungen frisst es 1G. Die Grafik läuft flüssig aber da das OS viel swapt hat man merkbare Hänger drin. Sowieso ist es komisch, dass die TF2 Content Dateien von Steam gelesen werden und danach einige vom TF2 Prozess wieder auf die Festplatte geschrieben werden. Das Digitale Rechte Management von Steam schlägt da enorm auf die Ladezeit und Effizienz. Ich wünschte mir, dass 64bit bei Spielen endlich Einzug hält und die Spielinhalte mit mmap() in den Adressraum abgebildet werden. Somit würde das Spiel weniger RAM verbrauchen und das Betriebssystem könnte den Page-Cache effizienter verwalten.


newer posts
older posts