Jammer-Thread

[Despotist]

Ich nehme an es ist eine späte Rache für Hiroshima und Nagasaki. Es trifft nur die falschen. Oder auch nicht. Wenn Deutschland damals ein paar Monate länger durchgehalten hätte wäre Berlin das Ziel gewesen.

Ich jedenfalls werde die Strahlung nutzen um mir ein drittes Auge wachsen zu lassen. Auch ein zusätzlicher Arm könnte hilfreich sein.

Aber mal im Ernst. Woher stammt diese "Prognose"?

[Krishty]

Aber mal im Ernst. Woher stammt diese "Prognose"?

Selbstgebaut ;)

[eXile]

Sah schon verdächtig nach den anderen Fakes aus, die auf reddit & Co. rumschwirren. Hättest du mal lieber Gray kBq/m² für ein bestimmtes Isotop statt RADS genommen …

Nachtrag: Wegen Verbreitung von Hoaxes gibts für dich erst einmal -5 reputation und -3 wisdom auf deine ability scores.

Nachtrag 2: Grrrr … warum lese ich denn jetzt erst die JPEG-Dateikommentare aus. Ich sage nur: „by Krish“

[Krishty]

Hättest du mal lieber kBq/m² [vorher: Grey] statt RADS genommen …

Nein; Persiflagen sollten sich imo einigermaßen am Original orientieren. Alle anderen Abweichungen sind der Tatsache geschuldet, dass ich einfach Besseres zu tun habe als rauszufinden, wie man im Gimp die Kanten einer Auswahl abdunkelt :)

[eXile]

Der auch ein Fake ist.

[Krishty]

Nein, Hoax! Ich weiß ;)

Btw baue ich nächstes Mal einfach Füll-Posts mit PADPADPA… ein, damit die erste Antwort nicht gleich eine neue Seite eröffnet.

Und gegenseitig toteditieren tun wir uns auch.

Ups, Gray wird mit A geschrieben? Zu viel Grey's Anatomy geguckt :?

[Krishty]

Zombie States sind scheiße. Und trotzdem bin ich immer wieder versucht, welche zu benutzen …

Zuletzt war das in meinem Stream Writer, dem Äquivalent zu ::std::ostream: Der Stream Writer hat intern einen Zeiger, der entweder auf einen Stream zeigte, in welchen geschrieben würde, oder nullptr (um alles, was man dem Stream Writer schickt, ins Nirvana zu verbannen). Ähnlich rdbuf() bei STL-Streams konnte man dann Streams binden oder nullptr übergeben, um den Stream-Writer still zu legen.

Stattdessen habe ich nun den Zombie State entfernt, es ist also immer ein gültiger Stream an jeden Stream Writer gebunden und man hat keine Möglichkeit, nullptr zu binden. Zum Ausgleich habe ich einen Null Stream eingeführt, der alles, was man hineinschreibt, ignoriert. Anstatt also nullptr als Ausgabe zu binden, bindet man eine (am besten die globale Default-)Instanz des Null Streams.

Falls man einen Stream-Writer stilllegt, kostet das nun einen virtuellen Funktionsaufruf mehr, da das Verwerfen der Ausgabe erst im Stream (und nicht schon im Stream Writer) stattfindet. Da die Streams bei mir aber fast ununterbrochen gebunden sind (an den Debugger in Debug-Builds, ans Log in Release-Builds) ist mir das scheißegal.

Und das Ergebnis? 1 % weniger Maschinentext. Das ist an sich nicht viel, bedeutet aber, dass vorher ein ganzes Hundertstel aller Maschinenbefehle darauf verwendet wurde, zu entscheiden, ob Nachrichten in einen Stream geschrieben oder schon vorher verworfen werden sollen. Ein einziges if in einem 4000-Zeilen-Projekt bedeutete 1 %. Und das in einem ziemlich hoch optimierten Programm, das mit einem Hundertstel seiner Komplexität üblicherweise bedeutend Sinnvolleres anfängt.

Dennoch stört mich, dass ich dem Compiler per assert() bzw. __assume() (in Debug- bzw. Release-Builds; lässt sich ja per #define perfekt umschalten), also „trust me on this one“ mitteilen muss, dass dieser Zeiger in Stream Writers immer auf was Gültiges zeigt. Ich wünsche mir für solche Fälle wirklich, C++ würde nicht-transparente Referenzen anbieten, die zwar im Gegensatz zu Zeigern immer auf ein gültiges Objekt zeigen, im Gegensatz zu Referenzen (die ja eigentlich eher Aliase sind) aber geändert werden können. Naja; man kann halt nicht alles haben.

[Krishty]

Irgendwas hat sich im VC-Linker in SP1 gegenüber der Beta geändert … meine ganze CRT ist schrott … augenscheinlich verarbeitet der Linker nun auch Objekte, die nicht referenziert werden – anders kann ich mir jedenfalls nicht erklären, dass meine CRT-main() in DLLs unaufgelöste Symbole speit obwohl sie dort garnicht eingesetzt wird.

Offenbar darf ich nun meine ganze CRT (okay – ca. 200 Zeilen, aber immerhin!) zu einer Header-only-Bibliothek machen (die Alternative wäre eine eigene statische Bibliothek, die ist mir aber zu viel Wartungsaufwand), juchhuuu. Und es fiel mir erst jetzt auf, weil ich die letzte Woche garnicht mit den dynamisch gebundenen Bibliotheken gearbeitet habe.

Und gerade habe ich 200 inlines entfernt, ohne, dass sich was geändert hat. Dann habe ich die 20 letzten auch noch rausgenommen, VC neu gestartet (weil beim Ersetzen vieler Wörter alles so furchtbar langsam wird) und ZACK sind irgendwo 200 B Maschinentext geleckt … und ich weiß nicht mehr, wo und kann’s nicht mehr rückgängig machen -.- Noch sonderbarer: Mein Analysewerkzeug zeigt mir an, dass die einzelnen Datenobjekte überhaupt nicht größer geworden seien obwohl die read-only-Daten der Exe definitiv 200 B schwerer sind … wt…

[Krishty]

Okay … der Gleitkomma-Rant, der hier vorher stand, war zu mindestens 60 % unbegründet weil mein schlafentzogener Kopp durch den Debug-Build gesteppt ist -.- SSE ist toll, doch …

… aber dass man jeder nicht-Register-double-Operation einen Speicherzeiger mitgeben muss, der nochmal so groß ist wie die double, die man ins Register kriegen will, es selber ist, suckt.

Und Visual C++s SSE-Register-Allokation bleibt furchtbar; man findet an allen Ecken und Enden movapss weil Zwischenergebnisse im erstbesten verfügbaren Register berechnet wurden anstatt so, dass das Ergebnis automatisch dort landet, wo man es später braucht.
(Kann natürlich sein, dass da ganz kluge Latenzberechnungen reinspielen, die ich einfach nicht erkenne – aber wenn angesichts von 16 freien SSE-Registern nur drei benutzt werden und das Ergebnis am Ende immernoch von xmm2 nach xmm0 geschoben werden muss sieht das für mich nicht danach aus.)

Ja, das ist den Destruktoraufruf und die Allokation in der atexit()-Liste wirklich wert:
Cric::`dynamic atexit destructor for 'nullStream'':
000000013F2433F0 ret 0
Super optimiert, VC!

[Jonathan]

Juhu...
Ich brauch für meinen neuen PC Win7 64, was ich auch problemlos über die Uni kriegen kann. Bloß muss ich mich dafür einmal in die Liste eintragen und kann es dann erst nächsten Dienstag abholen. D.h. 2mal für fast nix zur Uni fahren und ne Woche warten :(

[Chromanoid]

Falls du es noch nicht kennst: Bei https://www.dreamspark.com/ solltest du für andere Software auch mal vorbeischauen. Bei den Sachen klappt Freischaltung schon mit einer universitären Mail-Adresse. Visual Studio 2010 Prof. und Expression Studio Ultimate sind so für Studenten verfügbar.

[CodingCat]

Kann mir jemand erklären, warum alles immer hässlicher werden muss? Schon die neuen Icons, erst bei Thunderbird, dann bei Visual Studio, jetzt beim Internet Explorer. Und was ist denn das bitte für eine ekelhafte Platzaufteilung da oben, wo ich eh immer zu viele Tabs offen habe, die Favoriten dagegen kann ich jetzt nicht mehr platzsparend unterbringen. Und wer zur Hölle hat diese hässliche Oberfläche mit den klobigen Tabs und Buttons und den ekelhaften Rändern designt! :evil:

IE9 (Nachher)

IE8 (Vorher)

Alles was hier grau ist kommt vom Internet-Explorer:

Rand

[Krishty]

Ha

Kann mir jemand erklären, warum alles immer hässlicher werden muss?

Der Kunde setzt Veränderung der Benutzeroberfläche mit Verbesserung des Programms gleich; das sollte nach Windows 7 jawohl jeder wissen. Aber in der neunten Revision einer UI was zu ändern macht sie nicht unbedingt hübscher (siehe neues ZFX-Thema).

(Wtf hast du eigentlich für eine sonderbare Auflösung)

<3 mah StaSi browsah

Nur dumm, dass sie letztens (vor ca. achtzig Major Releases) die Alle Tabs neu laden-Funktion entfernt haben :/

[Chromanoid]

Naja wenn das jetzt so aus sieht, dann würde ich endgültig auf Chrome umsteigen. Ich kann da krishty nur beipflichten. Addon-Entwicklung mit javascript oder GWT :) geht auch easy. Gut ist auch, dass man in so von anderen entwickelten Addons auch reinschauen und ggf. was verändern kann (z.B. lästige werbung entfernen etc. :)).
Da ich die Favoritensidebar bei Chrome vermisst habe, habe ich angefangen mir eine eigene "sidebar" zu bauen. Das ganze ging leicht und schnell, allerdings bin ich noch nicht fertig... -.- falls wer helfen will :) code stelle ich gerne bereit, ist allerdings gwt (da ich neulich meinen pc formatiert habe und nicht mehr genau weiß wie ich in chrome für addons den gwt debugging mode eingestellt habe, erfordert das leider alles ein bisschen einarbeitungszeit... dank gwt und guten komponenten kommt mir mein addon wenigstens wesentlich schneller vor als die, die man sonst so findet)
Irgendwie finde ich mittlerweile die Lesezeichenleiste schon fast ausreichend :D woran man sich alles gewöhnen kann ^^

[CodingCat]

So denn, nach über 10 Jahren, mehreren Generationen von Browser-Missionaren trotzend, lasse auch ich den Internet Explorer hinter mir. Mal sehen ob Chrome die nächsten 10 Jahre durchhält. Machs gut alter Begleiter!

[Jonathan]

Falls du es noch nicht kennst: Bei https://www.dreamspark.com/ solltest du für andere Software auch mal vorbeischauen. Bei den Sachen klappt Freischaltung schon mit einer universitären Mail-Adresse. Visual Studio 2010 Prof. und Expression Studio Ultimate sind so für Studenten verfügbar.

Jo, da hab ich schon geguckt, aber die haben kein Win7. VC10 Prof hab ich hier schon. Bei MSDNAA hab ich auch geguckt, aber ich soll mich an den zuständigen in meiner Uni melden.

[eXile]

Da wacht man eines Morgens auf, und dachte, man sei bisher immer verrückt. Weil man häufig den IE verwendet. Oder weil einem die Sidebar in Chrome fehlt. Und nun innerhalb weniger Stunden ist alles normal! :)

Vielleicht werde ich auch irgendwann Erweiterungen für Chrome basteln. Erst einmal wurde mir wieder ein Riesenbrocken Arbeit in den Weg gelegt. Ich selber würde dann vielleicht sogar eine RSS-Sidebar wie im IE basteln wollen, aber ich glaube, dazu werde ich erst wieder im Rentenalter Zeit haben ...

[Krishty]

Ich hasse

1. C++
2. wie C++ mit der Standardbibliothek verwoben ist
3. die Implementierung der Standardbibliothek
4. Die Windows-Header
5. wie die Windows-Header mit der Standardbibliothek verwoben sind

Ich kriege die verdammte CRT nicht aus meinem Programm, weil in ihr ::std::exception definiert ist, und davon erbt ::std::bad_alloc, und das ist die einzige Exception, die operator new werfen darf, und in derselben Datei ist auch Placement operator new definiert

Ich würde jetzt gern die ganze CRT und STL rausschmeißen, weil ich sie für nichts anderes als bad_alloc brauche, das ich selber besser implementiert kriege, aber dann kann ich keine Windows-/Direct3D-/sonstwas-Header mehr benutzen weil die alle aus mir unbekannten Gründen die STL #includen, und dann ist bad_alloc doppelt implementiert

Und wusstet ihr, dass man Placement operator new laut Sprachdefinition nicht überschreiben darf, sondern die Definiton der STL benutzen muss? Das ist mal saubere Trennung

Und was soll überhaupt diese what()-Methode in ::std::exception
Wer die in den Standard gequetscht hat kann doch nur völlig ahnungslos gewesen sein

Und das traurigste ist, dass C++ trotz diesem ganzen Kompatibilitäts- und Miskonzeptscheiß noch um Äonen schneller ist als die „modern“eren Sprachen

Ist doch alles so ein Schwachsinn

Nachtrag: Mal testweise Microsofts Header verstümmelt; mit eigener Exception-Hierarchie habe ich 1,5 KiB == 1,5 % weniger Programmdaten, 0,5 davon werden direkt wieder wettgemacht wenn ich __assume(nullptr != _Where); in Placement operator new einsetze weil dann pro Placement drei Befehle und ein bedingter Sprung entfallen und meine ganzen Container aggressiver geinlinet werden können. Hass

[Top-OR]

Ich hasse

1. C++

Er hat Jehova gesagt!

[j.klugmann]

FULL ACK

[rüp]

Bin gerade passenderweise über das hier gestolpert und hängengeblieben: http://gigamonkeys.wordpress.com/2009/1 ... plus-plus/# (via c0de5157e).

[Helmut]

Ich würde jetzt gern die ganze CRT und STL rausschmeißen, weil ich sie für nichts anderes als bad_alloc brauche, das ich selber besser implementiert kriege, aber dann kann ich keine Windows-/Direct3D-/sonstwas-Header mehr benutzen weil die alle aus mir unbekannten Gründen die STL #includen, und dann ist bad_alloc doppelt implementiert

Du kannst ja die Includeguards von den STL Headern selber vorher definieren. So musst du die offiziellen Header nicht anfassen.

Ciao
Helmut

[Krishty]

Welche wären das denn? Die Header benutzen keine herkömmlichen Include-Guards sondern #pragma once. Es gibt jede Menge STL-spezifischer #defines, die aber nie konsistent gesetzt werden (entweder setzt sie Windows.h zu oft oder ich zu wenig) oder nur für verschiedene Klassen und Sub-Header gelten. Ich habe auch schon die CRT-#defines ausprobiert und nach entsprechender Dokumentation gesucht, aber für die STL scheint kein #define vorgesehen zu sein (weil man annimmt, dass sie sowieso immer eingebunden ist).

[CodingCat]

Kannst du dir nicht einfach deine eigene Mini-STL zusammenbasteln (-klauen) und den Include-Pfad entsprechend dorthin setzen? Dann kannst du modifizieren / implementieren was du brauchst (scheint ja nur ein winziges Subset des Standards zu sein), den Rest lässt du mit Attrappen ins Leere laufen, sofern die anderen Bibliotheken wirklich bis auf die Includes nicht weiter davon abhängen.

[Krishty]

Kannst du dir nicht einfach deine eigene Mini-STL zusammenbasteln (-klauen) und den Include-Pfad entsprechend dorthin setzen? Dann kannst du modifizieren / implementieren was du brauchst (scheint ja nur ein winziges Subset des Standards zu sein), den Rest lässt du mit Attrappen ins Leere laufen, sofern die anderen Bibliotheken wirklich bis auf die Includes nicht weiter davon abhängen.

Ja, darauf wird es wohl hinauslaufen. Die winzige Untermenge der CRT, die ich brauche, habe ich auch schon zu einem Großteil selber implementiert; warum also nicht das Cric Framework um STL-Basiskram erweitern … werde direkt anfangen, die Windows-Header auf Abhängigkeiten zu analysieren.

… ich muss allerdings zu meiner Schande eingestehen, dass ich noch Projekte habe, die mit der originalen STL laufen und die ich erst portieren müssen werde. Das wird u.U. ein ziemliches Massaker.

[Matthias Gubisch]

Versteh einer die Microcontroller...

Warum interessiert bei einem Atmega162 bei der einen Uart die Reiehenfolge der Initialisierung nicht und bei der anderen schon??????
Und an so nen Mist such ich nun schon seit Ewigkeiten hin...

[Krishty]

C++: eh vector constructor iterator called unnecessarily – Status geändert von „Aktiv“ zu „Geschlossen (als nicht lösbar)“
Jaa, ist schon schwer, so eine for-Schleife. Meine Vermutung: Visual C++’ RAII-Konzept stammt noch aus 6.0-Zeiten und sie haben schlicht und einfach nicht die Möglichkeit, festzustellen, ob K’toren oder D’toren Exceptions schmeißen können (oder ob sie überhaupt etwas tun). Ich freue mich diesbezüglich schon auf ihre Implementierung von default- und delete-Funktionen in C++0x – das Schlimme ist ja, dass die selber nicht darunter leiden werden, sondern nur wieder irgendeinen Dreck hinhacken, unter dem wir dann leiden.

[Krishty]

Wieder was gespart … manchmal komme ich mir verrückt vor

Code: Alles auswählen

// Bytecode of "sampleFromInterpolatedVertex" in the sprite shader's source code, compiled for "ps_5_0" with June
//	2010 SDK compiler on highest optimization level; all unneeded data stripped.
static builtIn::CUnsignedInteger1Byte const spritePixelShaderBytecode[] = {
	0x44, 0x58, 0x42, 0x43, 0x67, 0x43, 0xA6, 0xCD, 0x62, 0xDB, 0x62, 0xDD, 0xD0, 0xB6, 0xC3, 0xE1,
	0xB1, 0xB5, 0xC7, 0xF4, 0x01, 0x00, 0x00, 0x00, 0x40, 0x01, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00,
	0x2C, 0x00, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0xB8, 0x00, 0x00, 0x00, 0x49, 0x53, 0x47, 0x4E,
	0x50, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00, 0x38, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x0F, 0x00, 0x00, 0x00, 0x44, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x03, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x03, 0x03, 0x00, 0x00, 0x53, 0x56, 0x5F, 0x50,
	0x6F, 0x73, 0x69, 0x74, 0x69, 0x6F, 0x6E, 0x00, 0x54, 0x65, 0x78, 0x63, 0x6F, 0x6F, 0x72, 0x64,
	0x00, 0xAB, 0xAB, 0xAB, 0x4F, 0x53, 0x47, 0x4E, 0x2C, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00,
	0x08, 0x00, 0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0F, 0x00, 0x00, 0x00, 0x53, 0x56, 0x5F, 0x54,
	0x61, 0x72, 0x67, 0x65, 0x74, 0x00, 0xAB, 0xAB, 0x53, 0x48, 0x45, 0x58, 0x80, 0x00, 0x00, 0x00,
	0x50, 0x00, 0x00, 0x00, 0x20, 0x00, 0x00, 0x00, 0x6A, 0x08, 0x00, 0x01, 0x59, 0x00, 0x00, 0x04,
	0x46, 0x8E, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x5A, 0x00, 0x00, 0x03,
	0x00, 0x60, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x58, 0x18, 0x00, 0x04, 0x00, 0x70, 0x10, 0x00,
	0x01, 0x00, 0x00, 0x00, 0x55, 0x55, 0x00, 0x00, 0x62, 0x10, 0x00, 0x03, 0x32, 0x10, 0x10, 0x00,
	0x01, 0x00, 0x00, 0x00, 0x65, 0x00, 0x00, 0x03, 0xF2, 0x20, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x45, 0x00, 0x00, 0x8B, 0xC2, 0x00, 0x00, 0x80, 0x43, 0x55, 0x15, 0x00, 0xF2, 0x20, 0x10, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x46, 0x10, 0x10, 0x00, 0x01, 0x00, 0x00, 0x00, 0x46, 0x7E, 0x10, 0x00,
	0x01, 0x00, 0x00, 0x00, 0x00, 0x60, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3E, 0x00, 0x00, 0x01
};
static_assert(320 == sizeof(spritePixelShaderBytecode), "sprite pixel shader bytecode incomplete");

(Verrückt nicht, weil ich die Shader vorkompiliere und ihren Bytecode statisch im Programm speichere; das mache ich schon seit Monaten – verrückt, weil ich diese Shader gerade eben tatsächlich noch optimiert habe damit der Bytecode 100 B kleiner wird.)

[Krishty]

Mein Kram lässt sich 15 % besser packen, wenn ich von meinen Texturen die Dateierweiterung .ctx weglasse (und dann nur noch die vier Buchstaben, die ich zum Identifizieren des Inhalts nutze, als Dateierweiterung habe). Der Grund ist, dass Ultra7z die Kompressionsmethode nach Dateierweiterung aussucht – vorher wurden R8G8B8A8_UNORM_SRGB- und R8G8B8A8_SNORM-Texturen mit der gleichen Methode gepackt, aber ihr Kompressionscharakter ist so unterschiedlich, dass sie sich getrennt deutlich besser quetschen lassen. 15 % für vier Buchstaben – es sind immer die Details.

[Chromanoid]

Ich würde gerne mal die Vision hinter deiner Engine und deinen Optimierungen kennen :) du hast doch bestimmt ein Spiel im Kopf oder?