ZFX + Developia

Chromanoid hat geschrieben:Das mag zwar unelegant sein, in vielen Betrieben ist es aber sicher unausweichliche Realität.

fixed that for you ;)

Das Kostenargument ist eine Keule. Unser Betrieb wartet regelmäßig bis die Kundenbasis 40 % schnellere CPUs hat; das ist noch günstiger. Kriegen wir dafür jetzt einen Preis?

Also merke ich einfach an, dass ich Leuten, die

• so verschwurbelte Programme schreiben, dass sogar die CPU nicht mehr weiß, welcher Befehl als nächstes kommt (denn nicht anderes ist ein L1i Cache Miss)
• sich aber wie kleine Kinder darüber freuen dass es schon durch dumpfe Mikrooptimierung 40 % schneller wird

jede Qualifikation abspreche und sofort weghöre wenn die „Performance“ in den Mund nehmen. Darum finde ich das auch nicht wirklich lesenswert.

Verstehe :) ich war noch nicht so mit "PGO" vertraut und fand es deshalb interessant. Hast Du eigentlich mal PGO bei Deinem Code ausprobiert?

Vor dem Hintergrund von VM-Sprachen und JIT-Compiling lässt der Artikel vielleicht auch einen anderen interessanten Trend? erkennen. Schließlich scheint es sich, wie Du schon sagtest, für viele Projekte (ich schließe die Mitarbeiter mit ein) nicht zu lohnen in exzellente Programmierer und manuelle Optimierung zu investieren. Da ist es nicht mehr weit zu VM basierten Sprachen mit GC. Mir kommt es so vor, dass hier vielleicht sogar eine "pathologische" Diskrepanz zwischen Wahl der Zielplattform sowie Programmiersprache und Investitionsbereitschaft in die Fähigkeiten des Projektteams vorliegt. Bei Open Source Projekten kann man entsprechende Schlüsse ziehen.

Chromanoid hat geschrieben:Hast Du eigentlich mal PGO bei Deinem Code ausprobiert?

Zu Hause habe ich leider nicht die passenden Tools (die Visual-Studio-Versionen damit kosten ordentlich).

Auf der Arbeit setzen wir es nicht produktiv ein – wir müssten erst Mausbewegungen und Tastatureingaben skripten um einen Trainingsfall mit den richtigen Anwendungsmustern zu produzieren. (Sonst könnten wir nie genau sagen ob die 10 % Leistungsverlust von unseren neuesten Änderungen kommen oder ob einfach die arme Sau, die PGO trainieren muss, anders geklickt hat als sonst.) Außerdem haben wir keine Echtzeitanwendungen wo wir einfach die Framerate vergleichen können; wir müssten Reaktionszeiten messen, was mir zu happig ist. Ich weiß auch nicht, ob man heutzutage das Problem des niemals optimierten Startvorgangs im Griff hat.

Mein Eindruck aus dem Web ist aber, dass es sich lohnt (10–40 % Gewinn sind garantiert). Microsoft setzt es seit einem halben Jahrzehnt in Office- und Serverprodukten ein (hier ein Beispiel für PHP mit 15 % Gewinn); viele Verbesserungsvorschläge für Visual C++’ Optimizer werden mit „benutz PGO“ quittiert weil das „die Zukunft“ ist und sich nicht-statische Optimierung scheinbar nicht so sehr lohnt.

Von GCC-Seite habe ich auch gehört, dass Firefox enorm davon profitiert haben soll (gefühlt doppelte Reaktionsgeschwindigkeit).

Über den Rest kann ich gerade keine Meinung abgeben, dafür bin ich zu wenig im Bilde.

Code Clinic: How to Write Code the Compiler Can Actually Optimize by Mike Acton (Insomniac Games, Data-oriented Design Evangelist)

Nett. Das mit der Shannon-Entropy hatte ich zwar immer im Hinterkopf, aber ich bin nie so weit gegangen, die Daten tatsächlich auszuspucken und zu komprimieren. (Ich schaue mir höchstens den Speicherinhalt in Hex an und wenn die Muster auf dem Bildschirm zu regelmäßig sind oder zu viele Nullen enthalten muss überarbeitet werden.)

Videos von der Microsoft Build 2014-Konferenz (2.4.2014 bis 4.4.2014 - The Moscone Center, San Francisco, CA):

http://channel9.msdn.com/Events/Build/2 ... heSessions

Hinweis: Die fehlenden Videos bietet Microsoft in den nächsten Stunden bzw. Tagen jeweils als Stream oder Download an.


Gruß,
Daniel

Grassmann Algebra in Game Development
http://www.terathon.com/gdc14_lengyel.pdf

Hat für mich mein Vektorverständnis in Computergrafik revolutioniert.
Klärt unter Anderem mit mathematischer Ästhetik warum beim Kreuzprodukt kein Vektor sondern ein Bivektor herauskommt und man deswegen Normalen nicht mit der Transformationsmatrix selbst sondern mit ihrer Invers-Transponierten transformieren muss.

Emil Persson: Low-Level Shader Optimization for Next-Gen and DX11

Warum Textur-Sampling seit Direct3D 11 nicht mehr kostenlos ist; wie bereits Eingabeparameter die Shader-Leistung ruinieren können; und wie man solche Probleme umschiffen kann (z.B. für den Himmel einen Atlas von 6 2D-Texturen statt einer Cube Map benutzen).

Krishty hat geschrieben:Emil Persson: Low-Level Shader Optimization for Next-Gen and DX11 [...] wie bereits Eingabeparameter die Shader-Leistung ruinieren können

Wow, d.h. man sollte auf moderner Hardware ohne Weiteres mit den Kosten einer Interpolation die Eingabedaten sämtlicher Vertices erhalten können. Perfekt für Parallax Mapping und andere Ray-Tracing-Hybride, darauf wartet sogar schon die Industrie! Warum das noch nicht in Low-Level-Kooperation mit IHVs eingesetzt wird? Perfekter Kandidat für Mantle und später DX12?

Ja. In der anderen D3D-12-Präsentation wurde schon gezeigt, dass der Treiber immer alle Shader-Stufen in einem Satz konfiguriert; es wird jetzt echt höchste Zeit, dass der Datenaustausch programmierbar gestaltet wird. Blending auch. Aber für D3D 12 haben sie ja leider angekündigt, dass sich an HLSL fast nichts ändern wird …

End-to-end Arguments In System Design, J.H. Saltzer, D.P. Reed and D.D. Clark, M.I.T. Laboratory for Computer Science, 1984
The principle, called the end-to-end argument, suggests that functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level.
[via programmingisterrible.com]
[via highscalability.com]

Hm. Also

• man ist nur an abstraktem Erfolg oder Fehlschlag interessiert.
• Es ist Unsinn zu prüfen, ob ein Netzwerkpaket ankommt, weil die Anwendung sowieso abstrakte Dinge mit den Daten vorhat. Sie führt sowieso eine Konsistenzprüfung mit den Daten durch; falls im Netzwerk was falschlief, wird sie es dann sowieso merken.
• Falls sie so einen Fall bemerkt, kann man die Übertragung neu starten.
• Die Prüfung tiefer zu implementieren ist bloß eine Leistungsoptimierung, damit man nicht immer alles neu übermitteln muss.

Habe ich das so weit richtig verstanden?

Wir würden also Redundanz sparen indem wir alle Prüfoperationen aus Festplatten und Netzwerken entfernten, und sie stattdessen in jedem Programm, das diese Ressourcen nutzt, implementierten?

Ist das Konzept nicht eher nur gültig für Ebenen, die 1:1 aufeinandergeschichtet sind – wie seine verteilte Rechnerarchitektur mit einem CPU-Typ, einem Netzwerkadapter, und einem Protokoll?

Anwendungen, Betriebssysteme, und Protokolle sind aber im heutigen Ökosystem 1.000.000 : 10 : 1 aufeinandergeschichtet: wenn ich die Prüfung aus dem Protokoll entferne, müssen stattdessen 10 Betriebssysteme die Prüfung implementieren (wie im Fall des erwähnten TCP-Protokolls). Wenn ich sie dort entferne, müssen stattdessen eine Million Anwendungen die Prüfung implementieren. Und dabei sparen wir?

————

Das erinnert mich stark an The Rise of „Worse is Better“, das besagt: Die Implementierung einer Schnittstelle soll einfacher sein als sie zu benutzen. Diesem Prinzip folgten Unix und C, und es ist einer der Gründe, warum sie heute so weit verbreitet sind: Sie sind zwar schwer zu benutzen, aber einfach auf neue Architekturen zu portieren. Dafür funktioniert dann zwar viel, aber nichts richtig, und die Leute regen sich seit 30 Jahren über ihre Struktur auf.

Im Kontext, in dem ich das gelesen habe, geht es vor allem um Messaging-Architekturen in verteilten Systemen (das Paper bezieht sich auf "modules of a distributed computer system"). Und genau vor diesem Hintergrund finde ich das Argument auch sehr einleuchtend. Nicht selten wird zugunsten einer Entkopplung eine Zwischenschicht eingebaut, die dann viel kompliziertere Probleme nach sich zieht. Ich sehe in dem Argument eher ein sinnvolles Plädoyer gegen Over-Engineering und Premature Abstraction.

Krishty hat geschrieben:Wir würden also Redundanz sparen indem wir alle Prüfoperationen aus Festplatten und Netzwerken entfernten, und sie stattdessen in jedem Programm, das diese Ressourcen nutzt, implementierten?

Nein, das wird auch nicht behauptet. Eine Implementierung im Programm macht dann Sinn, wenn zur Prüfung sehr viel Domänenwissen nötig ist, das bei den entsprechenden Kommunikations-Zwischenschichten gar nicht zur Verfügung steht. Bei Computerspielen wird hier sogar sehr low-level angesetzt und es wird deshalb wohl häufig UDP statt TCP eingesetzt. In vielen Fällen ist das sicher streitbar, aber es entspringt der gleichen Kosten-Nutzen-Abwägung.

User Testing with Limited Resources, Isla Schanuel, Gamasutra, 21.04.2014
Ein sehr feiner komprimierter Artikel über User Testing mit begrenzten Ressourcen bzw. für Indie-Spieleentwickler.

Moment Shadow Mapping - hochgradig systematische Verbesserung der Ideen von VSM / ESM. Gleicher Speicherbedarf wie VSM, laut Paper aber bessere Resultate (weniger Light Leaks). Kommt mit Shader Code im Supplementary Material, sieht nach perfekter drop-in Solution für robustes Shadow Mapping aus.

Nachtrag: Man findet in der Demo leider auch mit MSM recht schnell störende Light Leaks, erwartungsgemäß an Stellen wo schon VSM und ESM Probleme hatten. Zumindest in manchen Situationen scheint ESM weiterhin robuster. Genaueres wird man erst sagen können, wenn das mal jemand in einem bedienbaren Programm implementiert hat, in der beiliegenden Demo ist leider schon die Kameranavigation eine kognitive Überforderung.

Nice. Ignoriert zwar leider das Penumbra-Problem, aber das kriegt man da sicher noch irgendwie reingepatcht.

Hach, ich wollte es auch schon hier posten. Entwickelt hats nämlich der Typ der links neben mir sitzt :D

Stups ihn mal an und frag, ob er ne Idee hat, wie man das Auffächern der Penumbra Region mit zunehmendem Abstand vom Occluder einbaut. Je nach Antwort darfst Du ihm dann die Hand schütteln oder Dich kopfschüttelnd schweigend wegdrehen.

Ist nur ne Neugierfrage. Ich bin mathematisch bei weitem nicht so sattelfest und stümper deswegen nur mit optischen Tricks rum.

Er betreut gerade ne Masterarbeit genau zu dem Thema (Contact Hardening Moment Shadow Mapping).

Er hat es wohl selbst noch nicht implementiert, meint aber es sollte nicht so schwer sein und erwartet dass es der Masterstudent dann auch hinbekommt. Aber ich kann ja nochmal fragen, wie man das in der Theorie machen würde.

CodingCat hat geschrieben:Moment Shadow Mapping - hochgradig systematische Verbesserung der Ideen von VSM / ESM. Gleicher Speicherbedarf wie VSM, laut Paper aber bessere Resultate (weniger Light Leaks). Kommt mit Shader Code im Supplementary Material, sieht nach perfekter drop-in Solution für robustes Shadow Mapping aus.

https://mynameismjp.wordpress.com/2015/ ... le-update/

Er meinte das hier ist die Grundidee:

http://http.developer.nvidia.com/GPUGem ... _ch08.html

Und es gibt halt noch ein paar Kleinigkeiten, was man noch anders machen könnte, aber so sollte es gehen. Und eigentlich ist es auch eine Bachelorarbeit. (+ der Speicherverbrauch ist eigentlich doppelt so hoch wie bei VSM, wenn man VSM und MSM jeweils so verwendet, wie man es normalerweise verwenden würde).

Gerade über GitHubs Lizenzberater (http://choosealicense.com/) gestolpert und für niedlich befunden.

How to Pixelart: http://opengameart.org/content/les-forg ... art-course

Awesome!

Ein weiteres schönes Tutorial für's pixeln lernen: http://makegames.tumblr.com/post/426486 ... t-tutorial
Ich bin mir nicht sicher ob solche Tutorials hier gut aufgehoben sind. Falls noch mehr kommen würde ich die vielleicht in ein eigenes Thema verschieben... oder?

Artikelserie zu Multiplayer-Spieleentwicklung von IT Hare:
Part I: Client Side of 64 Network DO’s and DON’Ts for Game Engine Developers
Part IIa: Protocols and APIs of 64 Network DO’s and DON’Ts for Game Engine Developers
Part IIb: Protocols and APIs (continued) of 64 Network DO’s and DON’Ts for Game Engine Developers
Part IIIa: Server-Side (Store-Process-and-Forward Architecture) of 64 Network DO’s and DON’Ts for Game Engines
Part IIIb: Server-Side (deployment, optimizations, and testing) of 64 Network DO’s and DONT’s for Game Engines
Part IV: Great TCP-vs-UDP Debate of 64 Network DO’s and DONT’s for Game Engines
Part V: UDP of 64 Network DO’s and DON’Ts for Game Engines
Part VI: TCP of 64 Network DO’s and DON’Ts for Multi-Player Game Developers
Part VIIa: Security (TLS/SSL) of 64 Network DO’s and DON’Ts for Multi-Player Game Developers
Part VIIb: Security (concluded) of 64 Network DO’s and DONT’s for Multi-Player Game Developers

Sehr geil, bin grade mal kurz drüber geflogen, sieht richtig gut aus

What Makes an Indie Hit?: How to Choose the Right Design, Ryan Clark, Gamasutra, 17.09.2015
Interessanter Artikel, der versucht zu erklären, wie man seine Spiele möglichst erfolgsversprechend entwirft.

Chat Service Architecture: Protocol, Michal Ptaszek, Riot Games, 09.2015
Chat Service Architecture: Servers, Michal Ptaszek, Riot Games, 08.2015