Jammer-Thread

[Alexander Kornrumpf]

Naja ich habe Vista benutzt. Fands gar nicht so schlecht. Windows 7 ist gefühlt schneller, aber sonst nicht wesentlich anders. Man kann über diesen Punkt unterschiedlicher Meinung sein, aber Ressourcenhunger ist für mich kein Argument gegen ein Betriebssystem. Oder was genau stört dich an Vista? Habe jetzt mal angenommen, es dreht sich um das Standardargument.

[Schrompf]

Ich habe Vista auf meinem Laptop. Die ganzen Grafik-Spielereien sind echt knuffig. Und die Schnellsuche in der Startleiste ist eine tolle Erfindung. Aber es ist mir zu lahm, in der Standardeinstellung nervt es einen permanent mit Rückfragen und die Netzwerkeinstellungen sind ein Krampf. Ich krieg mit dem Laptop wahlfrei mal das eine, mal das andere System im Netzwerk zu Gesicht, und auf den Laptop zugreifen konnte man auch nur zufällig mal im Public-Verzeichnis. Freigaben habe ich da nie zum Funktionieren bekommen, selbst nach Abschaltung aller Clever-Helfer, Firewalls und LassMichDasFürDichMachen-Deppen aus dem umfangreichen Vista-Fundus. Das Ding NERVT ganz einfach. Es steht mir permanent im Weg.

Und abgesehen davon: ich wechsle Betriebssysteme nicht ohne Not. Die letzten drei Hardware-Generationen meines Heimrechners habe ich jeweils mit dem selben Betriebssystem betrieben. Einfach Platte im neuen System anstecken, ein bisschen Geschimpfe über unpassende Treiber beim Booten ignorieren und das System steht wieder. Erspart mir das tagelange Einrichten, da bin ich nicht böse drüber. Irgendwann demnächst baue ich mir wieder einen neuen Rechner zusammen (NVidia, werd fertig mit dem Fermi-Ding! Ich will nie wieder ATI) und dann kommt da sicher Win7-64 drauf.

[Alexander Kornrumpf]

Dann bleibt ja zu hoffen, dass das Spiel dann auch laeuft.

[Dirk Schulz]

Hi,

@Schrompf: mal die Tipps aus diesem Thread versucht: http://forums.electronicarts.co.uk/batt ... 4-bit.html :?:

Und nicht so auf ATI rumhacken hier! nVidia sind doch die Bösen! :twisted:

Wie lange musste ich NFS:Shift mit 20FPS spielen, weil nVidia und EA meinten gemeinsame Sache machen zu müssen. :(

[Schrompf]

Danke für's Suchen, Dirk. Den Thread kannte ich noch nicht. Aber ich entdecke da auch keine wirklichen Tipps drin, nur ein paar Leute, die so nach und nach den Übeltäter einkreisen. Bislang aber noch keine Handlungsanweisung "Tu das und es geht".

Besonders reg ich mich über die restlichen Deppen in dem Thread auf. "Installiert doch einfach ein neues OS"... Leute, das ist ein Entwickler-PC, da stecken Wochen an Arbeit für Installation, Aktualisierung und Konfiguration drin. Das schmeiß ich nicht weg für ein einzelnes Spiel.

[Alexander Kornrumpf]

Wir kommen zwar vom eigentlichen Zweck des Jammer Threads ab, aber als Depp will ich mich doch nicht beschimpfen lassen.

Entwickler PC hin oder her ein neues OS aufspielen ist etwas was man als Windows Nutzer im Normalfall alle 3-5 Jahre macht. Vista mag ein Sonderfall gewesen sein und Linux Nutzer haben es hier natuerlich einfacher wenn man "neue Kernel Version" mal mit "neuer Windows Version" gleichsetzt.

Es muss doch irgendwie moeglich sein, dass sich die Wochen an Konfigurationsarbeit (wofuer eigentlich genau?) so speichern lassen, dass sie innerhalb eines Tages wieder hergestellt sind.

Ich hab mich auch lange gewehrt von Vista auf Win7 umzusteigen, aber am Ende hat es einen Tag gedauert und gar nicht weh getan. Allerdings steckten in meiner Maschine ohnehin keine Wochen an Konfiguration. Meine Erfahrung generell ist aber das Loesungen die einen hohen Konfigurationsaufwand haben immer auch irgendwie dirty sind.

[Schrompf]

Sorry, Alexander. Ich wollte definitiv nicht *Dich* einen Deppen nennen. Ich bezog mich auf diesen einen Typen in dem vom Dirk verlinkten Thread, der permanent dazwischenfunkte, ohne irgendwas zum Thema beizutragen. Seine einzige Aussage war immer: steigt doch auf Vista/Win7 64 um, weil das ein richtiges Betriebssystem ist und WinXP64 nur ein Zombie.

[edit] Die Einrichtung umfasst hier so Sachen wie Visual Studio + Visual Assist + MSDN + alle möglichen Pfade, Subversion, DirectX, NVidia PhysX ... nur um die zu nennen, die man nicht einfach kopieren kann. Mein sonstiger Arbeitstag ist durch langjährige Erfahrung inzwischen größtenteils auf KopierMichUndFertig-Software umgebaut - Opera, Total Commander, Trillian, Skype, IrfanView, QuintessentialPlayer - und Libs/SDKs - Qt, Boost, FModEx, Intels TBB, TinyXML, AngelScript, zlib, freetype. Und dann kommt noch die Einrichtung hinzu, das Suchen und Installieren aktueller Treiber für alle Hardware-Komponenten, das Putzen von Autostart nachher, das Finden und ZumSchweigenBringen all der ach so gutgemeinten Helfer und Nervlinge von Windows und diversen aufdringlichen Apps... "Wochen" sind da für mich, der ich bestenfalls eins zwei Abende pro Woche überhaupt am Rechner bin, durchaus die passende Zeitspanne.

[Alexander Kornrumpf]

No offense taken.

[Lord Delvin]

Entwickler PC hin oder her ein neues OS aufspielen ist etwas was man als Windows Nutzer im Normalfall alle 3-5 Jahre macht. Vista mag ein Sonderfall gewesen sein und Linux Nutzer haben es hier natuerlich einfacher wenn man "neue Kernel Version" mal mit "neuer Windows Version" gleichsetzt.

Ne der Vergleich ist eigentlich nicht gut. Du musst eigentlich auf ne neue Distributionsversion wechseln, das machst du mit Ubuntu aber auch alle halbe Jahr und ist nicht ganz so schlimm. Zumindest wenn nicht irgendwelche Hu******** irgendwas mit den Paketen falsch gemacht haben und danach für irgendwas wirklich wichtiges kein Paket mehr existiert und dus vielleicht selbst bauen musst. Ist mir aber zum Glück auch nicht so oft passiert. Kann die Aussage mit den Wochen aber durchaus nachvollziehen. In meinem System steckt auch einiges an Individualisierungsaufwand drin.

Kann man bei Windows 7 nicht einfach ein Upgrade von Win xp64 machen und alles funktioniert weiter? Meine das mal gemacht zu haben, würde jetzt aber für nichts garantieren wollen. Und wenn man sich dann doch mal überzeugt hat sein system in home/sys/data/backup partitionen zu unterteilen, dann war das irgendwie auch immer weniger arbeit, egal welches Betriebssystem.

Hab ich aber auch eher schmerzlich lernen müssen:-/

[Alexander Kornrumpf]

Naja vielleicht ist gentoo was das angeht etwas speziell. Ich hatte dort den eindruck dass die "Distributionsversion" nur einmalig beim brennen der Live CD eine Rolle spielt, jedoch nicht im laufenden Betrieb.

[Aramis]

und ist nicht ganz so schlimm.

Dachte ich auch, so sehr sogar dass ich im Vertrauen in Mark Shuttleworth auf die Alpha des neuen Ubuntus aktualisiert hatte. Meine Jammerei wollt ihr gar nicht hören …

[Lord Delvin]

und ist nicht ganz so schlimm.

Dachte ich auch, so sehr sogar dass ich im Vertrauen in Mark Shuttleworth auf die Alpha des neuen Ubuntus aktualisiert hatte. Meine Jammerei wollt ihr gar nicht hören …

Mit Intel graka wars ne gute Entscheidung. Du hast ne ATI? Mir grauts da echt auch noch, ich hoff sie bekommen es nach nem viertel Jahr endlich mal hin, dass ihr behinderter Treiber auch mit nem aktuellen Kernel kompiliert:-/
Sonst hätte ich auch schon die alpha drin gehabt. Find die eigentlich ganz nett.

[Krishty]

Ich habe eine gute Woche investiert, alle überflüssigen Referenzen aus meinem Projekt zu entfernen. Den größten Effekt hatte dabei das Exception-Handling (ersetzen der CRT-Implementierungen (::std::runtime_error, ::std::invalid_argument) durch eine eigene Klasse usw) mit einer .text-Reduktion um fast 20 %.

Ich habe die Sache dann ruhen lassen und mich gerade wegen eines anderen Bugs durch alten Code gewühlt. Dabei stieß ich zufällig auf eine Zeile, die noch eine CRT-Implementierung nutzte. Die Korrektur dieser einzelnen Zeile hat meine Programmgröße auf einen Schlag um verblüffende 25 % reduziert.

Ich sollte mich freuen – aber es kotzt mich momentan viel mehr an zu sehen, wie eine einzelne, eigentlich belanglose Zeile so einen enormen Rattenschwanz an Referenzen und Side-Effects nach sich ziehen kann (– und das, wo ich tagelang an einer Art Schallmauer gekratzt habe, wo einfach nichts mehr optimiert werden zu können schien [ich liebe Grammatik]). Ich würde jetzt am liebsten nochmal jede Zeile gegentesten …

[Schrompf]

Wozu ist das gut, wenn ich fragen darf? Und wie lautete die eine Zeile? :-)

[Krishty]

Wozu ist das gut, wenn ich fragen darf?

Perfektion ist erreicht, wenn man nichts mehr weglassen kann :) … vielleicht schraube ich aber auch nur an der Größe weil ich bei der Performance nicht mehr weiß, was noch optimiert werden könnte.

Ich bin mittlerweile zu dem Schluss gekommen, dass ich nicht mehr als zwei, drei Exception-Typen brauche – und die kommen zudem fast ohne dynamischen Inhalt aus. Gegenüber den fünf bis zehn Typen, mit denen ich vorher um mich geworfen habe, fällt nun eine Menge an virtuellen Funktionen, dynamischer Speicherallokation, Typinformation und weiterem unnötigen Ballast weg. Eine um ein Drittel kleinere Exe lässt das Perfektionistenherz höher schlagen und bringt vielleicht sogar ein, zwei Prozent Performance durch bessere Lokalität, neue Optimierungsmöglichkeiten während der LTGC, weniger Side-Effects, weniger statische Daten zur Initialisierung, weniger Abhängigkeiten beim Laden usw …

Und wie lautete die eine Zeile? :-)

throw ::std::out_of_range("tuple subscript out of range"); statt CExeption::Throw("tuple subscript out of range"); ;)

[Jörg]

Ein Instancing-Shader geht nicht. PIX stuerzt ab beim Debuggen und captured bei Verwendung von UserMarkers das falsche Frame. Und dann kann das REF-Device keine R32G32F offscreen surfaces erzeugen. :x Wird eine lange N8.

[Krishty]

Ich Depp habe die statische Code-Analyse nur im Debug-Build durchführen lassen. Da im Debug-Modus Iterator-Debugging aktiviert ist, ist ein dereferenzierter Nullzeiger in die Release-Version durchgerutscht, in der es dann durch Umstände, die im Debug-Build nicht aufgetreten waren, gekracht hat.

Ich hasse es, wenn sowas Fundamentales wie ::std::auto_ptr nur im Debug-Modus sicher ist. Pure Idiotie.

Und nun ist der RC gerade einen Tag deinstalliert; die ersetzende Professional Edition bietet Code-Analyse nicht an. -.-

[Schrompf]

No cocky attitude out of ulfjorensen please.

Wenn ich den Typen noch lange ertragen muss, passiert ein Unglück.

[kimmi]

Vielleicht würde das UNglück helfen :)...

Gruß Kimmi

[Aramis]

Beeindruckend – bezeichnet auf oeffentlichen MLs erstmal deren Admins als anmaßend, nach dem er gefuehlte 50 Threads im Forum gefuellt hat bis er ueberhaupt den Subscribe–Button fuer besagte ML gefunden hat … :-)

[kimmi]

Wir sollten einen speziellen Link für ihn einfügen: da kann er dann direkt nach /dev/null posten und wir haben Ruhe!

Kimmi

[klickverbot]

Irgendwo habe ich mal einen Text über die drei (?) Typen von Codern gelesen, die Open-Source-Projekten am meisten schaden, und ich bin mir ziemlich sicher, dass eine der Beschreibungen ganz gut auf mick-p zutrifft. Jetzt müsste ich mich bloß an die URL des Artikels erinnern… ;)

Anyway, ich glaube, ich sollte mich auch mal in die Diskussion einmischen – vielleicht flamed er mich ja dann auch bald an. xD

[Krishty]

Manchmal ist mein Hass nicht mehr in Worte zu fassen.

A.png (2.89 KiB) 11557 mal betrachtet

[eXile]

So … irgendwann wurde es auch mal Zeit … und zwar Zeit, dass nun auch ich mal etwas zu jammern habe! Also! Vielleicht kennt ihr die tolle Präprozessordefinition _SECURE_SCL. Oder auch nicht, denn standardmäßig ist diese Definition aktiv, d.h. _SECURE_SCL=1, und das bewirkt, dass die C++-STL-Implementierung von Visual C++ sogenannte „Checked Iterators“ benutzt, also das Programm standardmäßig terminiert wird, wenn ein Iterator komische Sachen macht. Ich selber habe mich darum bisher noch nie gekümmert, denn es ist doch eigentlich super, dass man standardmäßig mehr Sicherheit bekommt.

Allerdings hat mir _SECURE_SCL in der letzten Woche wirklich das Leben schwer gemacht. Hintergrund: Ich benutze manchmal Matlab, und man kann für Matlab auch Funktionen direkt aus C/C++-Code kompilieren lassen. Mein Code benutzte unter anderem die OpenEXR-Library, um OpenEXR-Bilder mit Matlab laden zu können. Natürlich war OpenEXR „standardmäßig“ kompiliert worden. Ich kompiliere also meinen kleinen Code, der zu einer Matlab-Funktion kompiliert werden soll, und rufe die Funktion in Matlab auf. Peng. Matlab abgestürzt.

Also gehe ich der Sache auf den Grund: Ich kompiliere meine Matlab-Funktion mittels des Flags -g, um mir eine PDB generieren zu lassen, und meinen Code zu debuggen. Alles läuft super, bis ein Aufruf an die OpenEXR-Library geht, welche eine std::map zurückgibt (ich kann auch den Code in der OpenEXR-Library sehen, da ich sie auf dem System selber kompiliert hatte). Vor dem return ist alles in Ordnung, die Map hat ungefähr sechs Elemente, und nach dem return meldet der Debugger wahlweise 0 oder 42238212 Elemente in der std::map, je nachdem, ob ich mit der Debug- oder Release-Version der OpenEXR-Library linke.

Zeitsprung, fünf Stunden später. Ich zweifle so langsam an meinen Fähigkeiten, und zweifle auch irgendwie daran, dass die Grundsätze der Physik für meinen Code doch eigentlich noch gelten sollten. Oder Matlab benutzt einfach einen improbability drive, was ja nie auszuschließen ist. Nunja, ich hätte ja nicht die Einleitung über _SECURE_SCL geschrieben, wenn es damit nichts zu tun hätte ;). Ich entdeckte den -v-Flag als Verbose-Schalter für die Kompilierung unter Matlab, und siehe da: Auf der Kommandozeile wurde mit _SECURE_SCL=0 kompiliert. Das machte mich sofort skeptisch, und ich schmiss Google an:

When changing _SECURE_SCL from its default setting, certain rules need to be followed. These rules are logical consequences of the fact that _SECURE_SCL changes the representations (including the sizes) of STL objects.

The first rule is that _SECURE_SCL must be consistently set throughout each translation unit (a translation unit is a source file and all of its included header files, which is compiled into an object file). That is, _SECURE_SCL can't be changed in the middle of a translation unit. The easiest way to follow this rule is by defining _SECURE_SCL on the command line (or in your project settings) instead of in source files/header files.

The second rule is that _SECURE_SCL must be consistently set in all of the object files that are linked into a single binary (EXE or DLL). Mismatch will be not detected by the VC8/VC9 linker, and will cause incomprehensible crashes. (In technical terms, _SECURE_SCL mismatch is a One Definition Rule violation.) This rule applies to static libraries (which are simply packages of object files).

The third rule is that _SECURE_SCL must be consistently set among binaries (EXEs/DLLs) that pass STL objects to each other. If a DLL has a C or COM interface, nobody can tell what _SECURE_SCL setting it was built with, but if the DLL uses STL objects in its interface, then the mismatch rule applies.

Ihr könnt euch wahrscheinlich meinen damaligen Gemütszustand nun denken … :lol:. Die Bezeichnung „incomprehensible crashes“ trifft es voll. Also kann man eigentlich sagen, wer _SECURE_SCL=0 und _SECURE_SCL=1 mischt, wird sofort gesteinigt und gevierteilt. Auf jeden Fall kompilierte ich nun OpenEXR sofort mit _SECURE_SCL=0 durch, und wunderbarerweise klappte alles wie am Schnürchen. Ich kann nun endlich EXR-Bilder in Matlab laden, ohne sie mühsam konvertieren zu müssen.

Und die Moral von der Geschicht': _SECURE_SCL=0 und _SECURE_SCL=1 mischt man nicht! ;)

[Krishty]

Ja, das Iterator-Debugging ist so eine Sache. Beim Konvertieren meiner Projekte auf VS 2010 (wo _SECURE_SCL afaik ins, zum Glück aussagekräftigere, _ITERATOR_DEBUG_LEVEL geändert wurde) hat das schon richtig gekracht.
Ist bei mir immernoch täglich ein Thema, weil VS beim Batch-Build regelmäßig die Debug- und Release-Versionen durcheinander schmeißt. Echt fantastisch. (Den Fehler gibt es nicht erst in VS 2010. Das ist nur die erste Edition, bei der daraus ordentliche Warnmeldungen statt unerwarteter Crashs resultieren.)

[Krishty]

Boah, D3D9 bringt mich echt um den Verstand.

Mal ganz abgesehen von diesem ganzen Mist, dass nichts standardisiert ist und man eine million Caps prüfen muss um ein Dreieck rendern zu können (was mich jetzt schon Tage gekostet hat) -- was sich ja halbwegs durch die Evolution der Adapter entschuldigen lässt -- ist die Art und Weise, wie man das tun muss, einfach nur katastrophal. Es ist schlicht nicht möglich, Enumerationen und Kompatibilitäts-Checks halbwegs objektorientiert zu kapseln ohne furchtbaren Overhead schlucken zu müssen. (Ob die Grafikkarte ein Format unterstützt sagt einem nicht die Grafikkarte, sondern das D3D-Objekt, dem man Index und Betriebsmodus der Grafikkarte übergeben muss?!? Welcher OOP-Legastheniker denkt sich sowas aus?!?)

Das Render-State-System produziert soviel Scheiße dass man sich beim Debuggen fühlt wie das Klo von Otti Fischer bei Bierschiss. Dazu kommen so grobe Patzer wie, dass VS 2010 mit Debug-Runtime auf D3D9-Hardware nicht nutzbar ist (stürzt ab), was die Benutzung der D3D9-Debug-Runtime (die daran übrigens erhebliche Mitschuld trägt weil sie sich nur global aktivieren oder deaktivieren lässt) nur sporadisch zulässt. Von den Qualen, die einen erwarten, wenn man im Linear Space rendern möchte, mal ganz zu schweigen. Achja PIX ist auch etwa so ein Beispiel an Zuverlässigkeit wie Lindsay Lohan an Enthaltsamkeit.

Ich wünsche dieser missgeborenen Drecks-API einen schmerzhaften, aber zum Wohle der Welt möglichst schnellen Tod und hoffe dass alle, die noch freiwillig damit arbeiten (was bei einer fast-60-%-Verfügbarkeit von D3D10 nicht mehr allzu viele sein dürften) irgendwann zur Besinnung kommen und damit dazu beitragen, die Grafikwelt von dieser Pest zu heilen.

[Jörg]

Schneller Tod? Dann sollte sich MS zu "Schluss damit, kein Unterstuetzung mehr fuer Versionen <Direct3D 10. Fuer alles andere habt ihr ja VM's ...." durchringen und jedem OS ein gratis-XP beilegen. Glaubst Du auch an den Osterhasen oder blau-gruen gestreifte Gespenster? Man könnte ja Wetten abschliessen, wie lange es noch fest im OS bleibt. Laufen eigentlich DirectX-3-Spiele noch? ;)

[Krishty]

Dass MS keine Kompatibilität abknipsen sollte steht hier nicht zur Debatte … ich meine vor allem den Tod auf Seite der Anwendungsentwickler. Schließlich kriegst du heute auch zurecht nirgends mehr ein brauchbares SDK für DirectX 3-7 …

… wer sich heute noch trotz Wahlmöglichkeit für D3D9 entscheidet ist entweder sadomasochistisch, lernfaul oder ewiggestrig. Natürlich braucht man es für die XBox – dann soll MS es eben ausschließlich mit dem XNA-Framework oder in einem XBox-SDK ausliefern. Natürlich gibt es Programme, deren Zielgruppe kein D3D10+ hat – dann sollen die dafür halt bis in alle Ewigkeit das Februar-2010-SDK benutzen (Updates für XNAMath braucht diese Sparte doch eh nicht, oder?). Aber nehmt um Himmelswillen D3D9 aus dem aktuellen SDK, damit die Leute endlich ihren Arsch hochkriegen …

… ich weiß, dass ich hier schon eine ganze Zeit mein D3D10+-Fantum zur Schau trage, aber nach drei Jahren purem D3D10/11 ist D3D9 nicht nur schlimmer, als ich es in Erinnerung hatte, sondern schlimmer, als ich es mir vorstellen konnte. Als hätte ein nuklearer Holocaust unsere ganze Hochtechnologie ausgelöscht und das einzige, was das EMP überlebt hat, war ein Windows-98-Rechner mit GeForce 4 MX. Ich kriege echt die Krise … kann doch nicht sein, dass meine Ansprüche so gestiegen sind.

[Schrompf]

Nanana... ich glaube, Du machst einfach was falsch. Ich bin doch recht zufriedener DX9-Benutzer und kann Deine Hasstiraden so nicht teilen.

[Krishty]

Du hast ja auch nie länger mit D3D10+ gearbeitet, oder? Ich fand XP auch ganz toll. Damals.