Jammer-Thread

[kaiserludi]

Code: Alles auswählen

if([@"" class] == NSClassFromString(NSStringFromClass([@"" class])))
    printf("foo");
else
    printf("bar");

Output on iOS: foo
Output on OS X: bar

WTF, Apple, WTF?

Ist laut Stackoverflow scheinbar ein Bug in OS X 10.7 und älter. 10.8 verhält sich angeblich wie iOS. Argh

[SunCross]

Hab gedacht, das passt am besten in den Jammer-Thread :)

[Krishty]

Rauchdarstellung gone wrong

smoke_rong.png (32.52 KiB) 3533 mal betrachtet

[Jörg]

Noja, geht noch als Atomkern durch ...

[Krishty]

Ja; es wird auch langsam:

smoke betta.png (43.26 KiB) 3521 mal betrachtet

Dass man für sowas auf Gas- oder Flüssigkeitssimulation setzt liegt wohl daran, dass einen bei herkömmlichen Ansätzen allein das Krickeln der Texturen schon in den Wahnsinn führen kann.

[Krishty]

Was macht es so merkwürdig, alles selber zu implementieren?

Man sieht viel zu viele Dinge, die sonst zu recht versteckt sind. COM mit seinen GUIDs, CLSIDs, und UUIDs treibt mich noch in den Wahnsinn.

[Krishty]

IDirect3D9::GetDeviceCaps method

If the method fails, the return value can be one of the following: D3DERR_INVALIDCALL, D3DERR_INVALIDDEVICE, D3DERR_OUTOFVIDEOMEMORY, and D3DERR_NOTAVAILABLE.

WTF
WTF
WTF

wie kann einem dabei der Video Memory ausgehen

WTFWTFWTF

WTF
WTFWTF
WTFWTFWTF

und nochmal datenorientiert:
WWW
TTT
FFF

[Chromanoid]

Was macht es so merkwürdig, alles selber zu implementieren?
Man sieht viel zu viele Dinge, die sonst zu recht versteckt sind. COM mit seinen GUIDs, CLSIDs, und UUIDs treibt mich noch in den Wahnsinn.

So ist es. Aber als Liebhaber kann man's ja trotzdem nicht lassen. Jedes mal sage ich mir, setz dich doch an den Gameplay-Prototyp... Wenn man sich zum Beispiel das Java Compiler Toolkit von Sun anschaut (der Parser ist im Wesentlichen handgeschrieben), weiß man warum das noch nicht Teil der Public API ist...

[eXile]

Ich habe mir die aktuellen Rants zur NT-Kernel-Entwicklung mal mit dem Mirror der Original-Quelle reingezogen, und dachte mir, hey, da müsste doch auch was zu Visual C++ drin stehen. Und da steht folgende Erkenntnis:

We just can't be fucked to implement C11 support, and variadic templates were just too hard to implement in a year. (But ohmygosh we turned "^" into a reference-counted pointer operator. Oh, and what's a reference cycle?)

Jetzt sind schon Leute bei Microsoft selbst mit dem Compiler unzufrieden.



In der Entschuldigung:

I also want to apologize for what I said about devdiv. Look: I might disagree with the priorities of our compiler team, and I might be mystified by why certain C++ features took longer to implement for us than for the competition, but seriously good people work on the compiler. Of course they know what reference cycles are. We're one of the only organizations on earth that's built an impressive optimizing compiler from scratch, for crap's sake.

Naja, der letzte Satz hat schon im Vergleich zum GCC und Clang, welche darüber hinaus ja kein Geld kosten, ein kleines Geschmäckle (wenn man „one of the only organizations“ betonen würde). Vielleicht gehe ich mit denen einfach auch nur zu hart ins Gericht.

Und zum Schluss noch eine Sache, die ich bedingungslos unterschreiben könnte, und eigentlich in den Anti-Jammer-Thread sollte:

P.S. I have no problem with family people, and want to retract the offhand comment I made about them. I work with many awesome colleagues who happen to have children at home. What I really meant to say is that I don't like people who see what we do as more of a job than a passion, and it feels like we have a lot of these people these days. Maybe everyone does, though, or maybe I'm just completely wrong.

[Krishty]

Lustig, dass wir gerade beim Thema sind. Ich habe nämlich eben die implizite #include gefunden, die Visual C++ am Anfang jeder Quelldatei einsetzt (Formatierung von mir):

Code: Alles auswählen

#line 15 "predefined C++ types (compiler internal)"
#ifndef _M_CEE_SAFE
#if defined(Wp64)
	typedef __w64 unsigned int size_t;
#else
	typedef unsigned int size_t;
#endif

extern void * __cdecl operator new(size_t);
extern void __cdecl operator delete(void *) throw();

#ifndef _MSC_EXTENSIONS
	extern void * __cdecl operator new[](size_t);
	extern void __cdecl operator delete[](void *) throw();
	
#ifdef _M_CEE_PURE
	extern "C++" int __clrcall atexit( void (__clrcall *_Function)(void) );
	extern "C" int __cdecl atexit(void (__cdecl *)(void));
		
#ifdef _MANAGED
	extern "C" int __clrcall _atexit_m(void (__clrcall *)(void));
	extern "C" int __clrcall _atexit_m_appdomain(void (__clrcall *)(void));
			
#pragma pack(push, ehdata, 4)
	typedef struct _PMD
	{
		int mdisp;
		int pdisp;
		int vdisp;
	} _PMD;
	typedef void (* _PMFN)(void* );
			
#	pragma warning(disable:4200)
#	pragma pack(push, _TypeDescriptor, 8)
		typedef struct _TypeDescriptor
			const void * pVFTable;
			void * spare;
			char name[];
		} _TypeDescriptor;
#	pragma pack(pop, _TypeDescriptor)
#	pragma warning(default:4200)

	typedef const struct _s__CatchableType {
		unsigned int properties;
		_TypeDescriptor * pType;
		_PMD thisDisplacement;
		int sizeOrOffset;
		_PMFN copyFunction;
	} _CatchableType;

	typedef const struct _s__CatchableTypeArray {
		int nCatchableTypes;
		_CatchableType * arrayOfCatchableTypes[];
	} _CatchableTypeArray;

	typedef const struct _s__ThrowInfo {
		unsigned int attributes;
		_PMFN pmfnUnwind;
		int (__cdecl* pForwardCompat)();
		_CatchableTypeArray * pCatchableTypeArray;
	} _ThrowInfo;

	__declspec (noreturn) extern "C" void __stdcall _CxxThrowException(void* pExceptionObject, _ThrowInfo* pThrowInfo);

	extern "C" int __cdecl __CxxExceptionFilter(void*, void*, int, void *);
	int __clrcall ___CxxExceptionFilter(void*, void*, int, void *);
	extern "C" int __cdecl __CxxRegisterExceptionObject(void *exception, void *storage);

	int __clrcall ___CxxRegisterExceptionObject(void *exception, void *storage);

	extern "C" int __cdecl __CxxDetectRethrow(void *exception);
	int __clrcall ___CxxDetectRethrow(void *exception);
	extern "C" int __cdecl __CxxQueryExceptionSize(void);

	int __clrcall ___CxxQueryExceptionSize(void);

	extern "C" void __cdecl __CxxUnregisterExceptionObject(void *storage, int rethrow);

	void __clrcall ___CxxUnregisterExceptionObject(void *storage, int rethrow);
#pragma pack(pop, ehdata)

#pragma pack(push, rttidata, 4)
	struct _s__RTTIClassHierarchyDescriptor;

	typedef const struct _s__RTTIClassHierarchyDescriptor __RTTIClassHierarchyDescriptor;

	typedef const struct _s__RTTIBaseClassDescriptor2 {
		_TypeDescriptor *pTypeDescriptor;
		unsigned long numContainedBases;
		_PMD where;
		unsigned long attributes;
		__RTTIClassHierarchyDescriptor *pClassDescriptor;
	} __RTTIBaseClassDescriptor;

	typedef const struct _s__RTTIBaseClassArray {
		__RTTIBaseClassDescriptor *arrayOfBaseClassDescriptors[];
	} __RTTIBaseClassArray;
	
	typedef const struct _s__RTTIClassHierarchyDescriptor {
		unsigned long signature;
		unsigned long numBaseClasses;
		__RTTIBaseClassArray *pBaseClassArray;
	} __RTTIClassHierarchyDescriptor;

	typedef const struct _s__RTTICompleteObjectLocator {
		unsigned long offset;
		unsigned long cdOffset;
	} __RTTICompleteObjectLocator;

	typedef const class type_info &__RTtypeidReturnType;

	extern "C" void*
	__RTDynamicCast (
		void*,
		long,
		int) throw (...);
	__RTtypeid (void*) throw (...);
	__RTCastToVoid (void*) throw (...);
#pragma pack(pop, rttidata)

struct __s_GUID {
	unsigned long Data1;
	unsigned short Data2;
	unsigned short Data3;
	unsigned char Data4[8];
};

typedef const struct _GUID &__rcGUID_t;
#pragma managed(push, off)
	extern "C"
		void __cdecl __debugbreak(void);
	void *__vtguard_imgbase;
	void *__vtguard_imgend;
	__declspec(noreturn) void __cdecl __vtguard(void);

	extern "C" {
		__declspec(noreturn) void __cdecl __report_securityfailure(unsigned long FailureCode);
		__declspec(noreturn) void __cdecl __report_securityfailureEx(unsigned long FailureCode,
		unsigned long NumberParameters,
		void **Parameters);
		__declspec(noreturn) void __cdecl __report_rangecheckfailure(void);
	}
			
#if defined(_NATIVE_WCHAR_T_DEFINED)
	void __cdecl __annotation(const wchar_t *, ...);
	void __cdecl __annotation(const unsigned short *, ...);
				
#	pragma warning( push )
#	pragma warning(disable:4483)
		template<typename _T>
		void __identifier("<auto-helper>")(_T);

		namespace std
#		if defined(_MANAGED) || defined(__cplusplus_winrt)
			typedef decltype(__nullptr) nullptr_t;
			typedef decltype(nullptr) nullptr_t;
		
#	pragma warning( pop )
#pragma managed(pop)


#line 1 "predefined C++ types (compiler internal)"

#ifndef __cplusplus_winrt
	namespace cli


#line 10 "predefined C++ types (compiler internal)"
template <typename Type, unsigned int dimension = 1>
private ref class array : public System::Array
public:
	array(unsigned int size);
	template <typename Type>
	private class pin_ptr{};
	private class interior_ptr{};


namespace default
template <typename ToType, typename FromType>
ToType safe_cast(FromType)

#line 11 "predefined C++ attributes (compiler internal)"
#pragma warning(push)
	namespace __vc_attributes
#pragma warning(pop)



#if defined(_WCHAR_T_DEFINED)
	typedef wchar_t wide_char_type;
#elif defined(_NATIVE_WCHAR_T_DEFINED)
	typedef __wchar_t wide_char_type;
	typedef unsigned short wide_char_type;

namespace helper_attributes
	struct attributeAttribute;

// 1000 weitere Zeilen über C++/CLI, WinRT, usw

(Man bemerke, dass #endifs und Klammern fehlen – offenbar interpretiert der Compiler intern Null-Bytes als geschlossene Klammern, oder die Standard-Syntax gilt schlicht nicht für diese Datei.)

Die Definition einiger Typen, die da benutzt werden, musste ich mir über Monate aus verschiedenen Quellen akribisch selber zusammensuchen. Vielen Dank auch.

[eXile]

Und wo findet man das? Das ist doch wohl nicht in die cl.exe hart reinkompiliert? Wenn ich hier mit /P kompiliere, kommen die nicht in die verarbeitete Datei.

[Krishty]

Doch. cl.exe ist nur der Command Line Parser des Compilers; dort findest du nichts. Das Kompilieren zu Intermediate Language findet in c1xx.dll statt (für C statt C++ in c1.dll); die Erzeugung des Maschinentextes in c2.dll. In c1xx.dll findest du im Maschinentextabschnitt die Daten, wenn du nach size_t suchst. Mehr, aber leider veraltete Informationen, bei Geoff Chappell. Via /P könntest du sie sowieso nicht sehen weil die Datei scheinbar fertig tokenisiert vorliegt (Nachtrag: und wir hier das Resultat von String Pooling sehen) und damit erst nach dem Präprozessor (also wenn /P die Kompilierung bereits abgebrochen hat) eingefügt wird.

Ich könnte mich aber auch irren; bin gerade heftig betrunken.

Dir würde alles aus dem Gesicht fallen wenn du sähest, was da hard-codet ist:

    static LPOLESTR names[] = { [NUL][NUL][NUL][NUL]L"%s"[NUL][NUL][NUL], L"%s"[NUL] };

Wobei ich persönlich das nicht so schlimm finde, so lange es in Quelltextform vorliegt und die Typen nicht direkt im AST-Quelltext stehen …

oh look
__is_constructible()
__underlying_type() (das ist für enum)

[Krishty]

Winzige Aktualisierung:

Die #include sieht in der 64-Bit-Version anders aus, aber ich kann sie in der Exe nicht finden. (Man sieht das daran, dass size_t logischerweise nicht unsigned int ist und in der 64-Bit-Version keine Zeilennummer angezeigt wird, wenn man die Definition davon ausgeben will.) Möglicherweise ist sie tatsächlich in den AST hard-codet.

Weiterhin sind die Datenstrukturen für die Ausnahmebehandlung, wie sie dort definiert sind, symbolisch. Der 64-Bit-Linker wandelt sie in die tatsächlichen Datenstrukturen um. Für 32-Bit-Programme sind sie zufälligerweise gleich.

[Krishty]

Wenn man die Wahl hat zwischen

    condition ? foo() : bar()

und

    (condition ? foo : bar)()

dann immer die erste Variante nehmen. Die zweite nimmt Funktionsreferenzen, und dann optimiert Visual C++ nicht mehr.

[Krishty]

Wow. Ich habe ja schon länger experimentiert um herauszufinden, warum Visual C++’ SSE-Datentypen mit dem mysteriösen __declspec(intrin_type) deklariert sind. Umgeht es die RVO-Probleme des Optimizers? Bewirkt es spezielle Dekorationen? Fügt es besondere Typeigenschaften hinzu?

Nichts. Die einzige Wirkung, die ich bis jetzt bemerkt habe: entfernt man es von der Deklaration der SSE-Datentypen, tritt ein interner Compiler-Fehler in irgendwelchen Quelltexten für Register Coloring auf. Wie sieht das bloß aus in deren Quelltext …

[kaiserludi]

    (condition ? foo : bar)()

Geil. Wusste nicht mal, dass das so überhaupt erlaubt ist. Im Fall von identischen aber relativ langen Parameterlisten und nicht performancekritischem Code ist es schon ganz nett, die Parameterliste nicht redundant im Code haben zu müssen (OK, ich gebs zu, ist jetzt kein Anwendungsfall, den man alle 5 Zeilen hat).

[kaiserludi]

Visual Studio 2010:

Nach einem

Code: Alles auswählen

FILE* pFile = freopen("stderr.log", "a", stderr);

funzt

Code: Alles auswählen

fflush(stderr);

wie gedacht, bloß dass VS mir ein nerviges deprecated Warning um die Nase schmeißt, aber nach

Code: Alles auswählen

FILE* pFile;
freopen_s(&pFile, "stderr.log", "a", stderr);

zur Vermeidung des Warnings zeigt das flushen keinerlei Wirkung mehr. :(

Was ist da denn kaputt?

[kaiserludi]

Argh, laut MS API Reference für _kbhit() soll die Funktion angeblich die Konsole auf Input überprüfen, nicht etwa stdout(), aber sobald ich stdout umleite, reagiert _kbhit() nicht mehr auf Konsoleninput, während ihm ein Umleiten von stdin und/oder stderr nichts ausmacht. Das selbe gilt für kbhit() ohne Unterstrich.

EDIT:
Hmm, ich muss stderr UND stdout umleiten, damit _kbhit() nicht mehr funzt. Leite ich nur eins von beiden um, dann funzt es immernoch, egal welches der beiden ich umleite.

EDIT2:
Mit

Code: Alles auswählen

FILE* pFile0 = freopen("log.txt", "a", stderr);
std::cout.rdbuf(std::cerr.rdbuf());
std::wcout.rdbuf(std::wcerr.rdbuf());

funzt _kbhit() dann wieder in der Konsole, obwohl nun stderr, cout und wcout alle in der Datei landen.
Zum Glück schreibt die App nur über cout und wcout in stdout und nicht über printf, dessen Output hier nämlich nicht umgeleitet wird (fprintf(stderr) hingegen wird verwendet, wesewegen ich tatsächlich stderr umleiten muss und einfach nur cerr und wcerr umleiten nicht ausreicht).

[Krishty]

Die Konsole und die Standarddatenströme sind so eine Pest (auch, wenn ich da nur für Windows sprechen kann). Ich wollte letztens eine "Press any key to continue" ohne CRT realisieren und bin fast verrückt geworden.

Eben war mein Tastaturtreiber zerschossen. Ich dachte erst, es sei die Tastatur selber; aber der Fehler ist von jetzt auf gleich aufgetreten und eine Neuinstallation via Gerätemanager hat es behoben. WTF. Wie kann sowas passieren? Keylogger?!

Jedenfalls war eine der Wirkungen, dass der PC kaum noch reagiert hat. Offenbar wurde ein CPU-Kern dermaßen mit Interrupts bombardiert, dass ich kaum noch die Maus bewegen konnte. Nach einem Neustart kamen beim Tippen nur Steuerzeichen an. USB-Steckplatz wechseln hat nichts gebracht. Wirklich sonderbar.

[Krishty]

    warning: trigraph converted to ']' character [-Wtrigraphs]
    ASCIICharacter usageAsString[] = "axis ???? (????)";
                                                  ^

Boah wie ich Trigraphs hasse

[Jonathan]

Ich wollte ein Qt-Projekt kompilieren, dass glew benutzt. Allerdings wird irgendwo intern qglfunctions includiert, was wohl etwas ähnliches wie glew macht, aber nur für OpenGL 2 und damit lange nicht die Funktionen bietet, die ich brauche. Und egal, wieherum man sie inkludiert, man kann nicht beides gleichzeitig benutzen.
Ich hatte jetzt also meine cpp-Datei bei deren Kompilierung der Fehler auftrat und die Zeilennummer in der qglfunctions.h, wo die Ursache des Fehlers ist. Nur wusste ich beim besten Willen nicht, wie ich jetzt herausfinde, über welche Umwege diese Dateien inkludiert wird.
Nach ein wenig Recherche gabe ich einen Compilerschalter gefunden, um die Includehierarchie im BuildLog anzuzeigen. Und jetzt sieht man wieder, warum dass C++ Buildsystem so mies ist, mein Buildlog war statt ~20 Zeilen auf einmal ~27.000 Zeilen lang (beim kompilieren einer einzigen cpp-Datei). Die Includehierarchie war ungefähr so formatiert, wie man es erwarten konnte, für jede Ebene stand zu beginn der Zeile ein Leerzeichen mehr. Ganz unten dann meine gqlfunctions.h, mit der Fehlermeldung.
Aber wie soll ich bei derartig vielen Verzweigungen an den Pfad kommen? Die Liste durchscrollen viel bei derartig vielen Verzweigungen von Anfang an aus. Könnte ich jetzt besser Python oder RegEx oder sonst etwas, hätte ich den Build-Log vermutlich mit einem kurzen Skript parsen konnten - aber derartiges zu Schreiben würde mich wohl Stunden kosten. Zum Glück kam mir die rettende Idee: Python benutzt ja Whitespaces statt Klammern um den Code zu strukturieren. Ich musste also nur den "Including File:" Hinweis zu Beginn jeder Zeile los werden, die Codesprache in Notepad++ auf Python stellen und schon habe ich mein Folding für die Includes. Hätte ich den Trick mit "Rechteck ziehen, während man Alt gedrückt hält" nicht gekannt, hätte ich die Nachrichten am Beginn jeder Zeile wohl nie entfernt bekommen, aber so ging es.
Mit einem Unfold-All und selektiven Auffalten hatte ich dann schließlich den Include-Pfad den ich gesucht habe. Letztendlich war es eine nette Kombination verschiedener Tools, die mich zu meinem Ziel geführt haben, und die Komplexität der Lösung erschien es mir wert, um sie hier zu schildern, aber andererseits nervt es mich auch echt, dass man ständig auf derartige Fummeleien angewiesen ist, um einen Compilerfehler zu finden. Hach...

[Krishty]

Genau deshalb dürfen bei mir Header keine anderen Header einbinden.

[kaiserludi]

Kannst dir zu solchen Zwecken auch einfach die Includehierarchy mit Doxygen als Baumdiagramm grafisch darstellen lassen.

[Thoran]

Qt hat mich die letzten Tage auch fast um den Verstand gebracht.Ich wollte in meinen Editor-Plugins einbauen, das sie beim Laden eine Instanz von QToolbar zurückliefern, die dann im Editor als Toolbar eingeblendet wird. Das Dumme daran ist, dass in meiner Plugin-DLL QToolbar als "Unknown identifier" angezeigt wird. Egal was ich getan habe, mein Compiler lies sich nicht davon überzeugen, dass das QToolbar bekannt ist durch den oben angegebenen Inlcude

Im Code sah das dan so aus:

Code: Alles auswählen

#include <QtGui/QToolbar>

class CCamEdToolbar: public IPluginToolbar
{
public:
  CCamEdToolbar();
  virtual ~CCamEdToolbar();
  QToolbar* getToolbar();
  
private:
 QToolbar m_toolbar;
};

Bereits bei der Funktionsdeklaration hat der Compiler gemeckert, dass er den Typ der Funktionsrückgabe nicht kennt. Dito natürlich bei der Deklaration der Membervariablen.

Ich hab mir die Include-Hierarchie angeschaut, die Qt-Header manipuliert um 100% sicher zugehen, dass in jeder Situation die Klasse QToolbar includiert wird. Ohne Erfolg. Das Spassige daran ist, dass ich in meinem eigentlichen Editorprojekt QToolbar ohne Probleme verwenden kann, wie z.B.

Code: Alles auswählen

#include <QtGui/QToolbar>

Controller::Controller(CEngine& engine)
:m_engine(engine)
{
  m_pluginDirs.clear();
  m_regWritePlugins.clear();
  m_regLoadPlugins.clear();
  QToolbar toolbar;
}

Dann hab ich die Projekteigenschaften abgegrasst, besonders die Qt-Defines aber keine Unterschiede gefunden. Zwischenzeitlich hab ich aufgegeben aus meinem Plugin eine QToolbar-Instanz zurückzugeben und stattdessen eine Liste von QActions erzeugt, die dann im Editor in eine QToolbar eingehängt werden. Ich weiß nicht ob ich jetzt zufrieden oder unzufrieden sein soll. :|

[kaiserludi]

Das kann passieren, wenn man zirkuläre Includes hat:

Code: Alles auswählen

// A.h
#include "C.h"

Code: Alles auswählen

// B.h
#include "A.h"

Code: Alles auswählen

// C.h
#include "B.h"

Ich gehe aber eher davon aus, das das Problem wo anders liegen muss, denn ansonsten müsste ein Header aus QT einen deiner eigenen Header einbinden

[Thoran]

Ich glaube zwar nicht, dass das Problem ist, aber es liese sich mit einer Forwarddeklaration zumindest prüfen, ob dass das Problem behebt. Eine Lösung ist das dann nicht wirklich.

[Krishty]

Visual C++ rafft nicht, wenn Destruktoren keine Ausnahmen werfen können. Gewöhnliche Methoden und Funktionen scheinen zuverlässig erkannt zu werden, aber bei Destruktoren merke ich hier ein halbes KiB Ersparnis pro throw()-Dekoration. Beängstigend.

[Krishty]

Schleichender Fehler:

    auto const palette = *reinterpret_cast<Palette const *>(paletteFile.toBeginning);
              ^ '&' vergessen

hätte ich meine Palette nicht als struct definiert sondern als typedef RGB Palette[256];, wäre das nicht passiert, weil Arrays sich nicht kopieren lassen, structs aber schon. Grmpf.

Der Mist ist jedenfalls, dass ich den Fehler erst gesehen habe, als ich das Disassembly durchgegangen bin. Das ist beunruhigend, weil ich noch Wochen brauchen werde, um auch alle anderen Funktionen des Programms im Disassembly zu untersuchen.

Lobenswert ist übrigens das Store Sinking von Visual Studio 2012. Ich hatte ja auf Schrompfs Anfrage schonmal gezeigt, dass vier Byte-Werte in einem struct wie ein 4-B-Wert rumgeschoben werden. Ebenso bewirkt das oben beschriebene Umstellen von struct auf typedef identischen Maschinentext. Was Kopien angeht, ist VC11 egal, in welcher Datenstruktur die Dinge vorliegen; nur die Größe zählt. Bei vorherigen Versionen war das ja leider afaik unberechenbar.

    palette[0] = BGRCFrom(0, 0, 0, 0);
        mov dword ptr [palette], 0

[kaiserludi]

Mal rein interessehalber: Welche Art von Software entwickelst du eigentlich, dass du dich dermaßen viel mit Assembler und Low-Level Optimierungen auseinandersetzen musst, wie man hier den Eindruck bekommt? Klingt ja fast nach Software für embedded devices, aber ich hätte jetzt nicht gedacht, dass in dem Bereich VS eine große Rolle spielt.

[Krishty]

Die meisten Jammereien hier stammen von einem Computerspiel, bei dem ich seit geraumer Zeit für den Programmtext verantwortlich bin. Ich muss mich nicht mit solchen Sachen auseinandersetzen, sondern ich will weil ich gern weiß, was meine Software macht.

Da ich ab und zu gezwungen bin, auf meinem Intel Atom zu arbeiten, ist das mit Embedded Devices aber nicht so weit hergeholt ;) Die meisten dortigen Optimierungen (wie Cache-Effizienz) schlagen auch auf Desktop-CPUs fast 1:1 durch. Am meisten überrascht hat mich das als ich Zeigerarithmetik auf char * umgestellt habe (um die Adressberechnungen bei Arrays zu vereinfachen) und die eigentlich schon hoch optimierte innere Schleife plötzlich auch auf dem Core i7 6 % schneller lief, obwohl dort zero-clock-LEA, Out-of-Order Excecution, Address Prediction und Prefetching ein paar zusätzliche Multiplikationen locker verstecken können sollten.

Ich sitze jetzt gerade an einem 6 Jahre alten Core 2 Quad und habe exakt die selbe Aktualisierungsrate wie auf dem Core i7 meines Hauptsystems. Entweder habe ich was grundsätzlich falsch gemacht oder das (CPU-limitierte) Programm ist mittlerweile so hoch optimiert, dass die zeitkritischen Operationen auf beiden System komplett im L1-Cache ablaufen. (Der Leistungsvorsprung des i7 rührt ja hauptsächlich daher, Latenzen besser verstecken zu können; der Durchsatz hat sich nicht signifikant verbessert. Mit Sandy Bridge müsste man aber wieder einen Unterschied sehen können.)