Code: Mal eine Frage: Wieso hast du im aktuellen Codebeispiel "unused" drin und außerdem 3 Byte Verlust durch automatisches Alignment bei "m_MemoryManagment"? Ich dachte du wolltest effizienter mit Cache umgehen und da werden glatt 7 Byte direkt in den Papierkorb verschoben, pro String, 2 mal pro Cacheline und direkt darüber schreit "FixString<16>" nach mehr Platz für SSO. Das kann ich gerade nicht ganz verstehen.
Ich schätze du denkst an folgende Variante, wo ich nicht unused und 1byte enum für den String verwende.
Code: class ALIGN(32) String{ protected: union{ FixString<27> m_Fix; AutoPointerArray<Char> m_Dyn;//RAII Pattern: besteht aus T* m_Data und Size m_Size(16Byte bei 64bit und 8Byte bei 32Bit) } DataManagment::Type m_MemoryManagment; UInt32 Length; //UInt64 unused; };
Das unused sollte zeigen, dass ich noch 8Byte Platz für weitere Dinge in der Klasse hab, sollte ich diesen brauchen und ich auch noch nicht einschätzen kann, wie ich mit den 27byte umgehen würde. Entweder mach ich 2x 16Byte SIMD/1x 32Byte SIMD Operation und kümmer mich dann noch um die 5Bytes von MemoryManagment und Length oder hab halt nur 16Byte länge, mach 1x 16Byte SIMD operation und brauch mich um nix weiter kümmern und verbrenne halt für ein mir unbekannten % an Strings in einem Programm, weil die dann über m_Dyn laufen. Dafür muss ich mich erst mit Beispielcode hin setzen und messen. Optimierung kann man ja leider nur schwer vorraus planen, wenn man auf so niederen Hardware level arbeitet, da ist es besser vorher zu messen. Damit ich sinnvoll messen kann muss ich allerdings sicher sein, dass mein Code auf allen 3 Systemen funktioniert und dafür baue ich ja noch an mein BuildGrid.
Zitat: Ich weiß nicht wie du allokierst oder wie das "ALIGN"-Makro bei dir aussieht. Aber ich vermute es verwendet intern wohl "__declspec(align(...))" und es hat sich bei mir herausgestellt, dass das bei Allokationen auf den Heap scheinbar versagt, das heißt , es bringt dann genau gar nichts. Da verweise ich auf folgendes.
Zitat: Der standard allocator reicht dafür aus, man muss einfach nur Bytegröße+15Byte alloziieren und dann kann man den pointer um bis zu 15 Byte verschieben, um alignment hin zu bekommen. Alternative auch _aligned_malloc oder posix_memalign, damit man nicht jedes mal 15Byte verbrennt. Alignment regelt VC++ im Release bisher ziemlich zuverlässig, in meinen memory funktionen werden die Duff device übersprungen. Im Debug kann es schief gehen, weil dann die speicherfunktionen gehooked werden und dann die Debugger Memory verwaltung zu ignoranten Speicherreservierungen führt. http://blogs.msdn.com/b/reiley/archive/2011/08/28/side-effects-of-debugger.aspx _NO_DEBUG_HEAP=1 könnte das lösen.
Zitat: In VS2013 sind übrigens Profiler und Codeanalyse (zum ersten mal?) auch in der "normalen" Professional-Version integriert. An der UI wüsste ich persönlich ehrlich gesagt keine entscheidenden Änderungen, außer billiger aussehende Symbole im Vergleich zu VS10. VS2010 hatte eine Profile guided optimization aber ein richtigen Profiler und Codeanalyse ist erst mit 2013 rein gekommen. Bisher konnte ich nur auf AMD CPU's mit Code Analyst gescheit profilen, bzw. mit gprof unter linux und OSX auf Intel und AMD. Einzig Intel auf Windows ist pain in the ass, weil Intel einfach mal 900$ für VTune haben will, was AMD OpenSource anbietet. Der VS2013 Profiler ist besser als CodeAnalyst für Intel CPU's von daher sehe ich das als + Punkt für die neue Version. In VS2013 wurden viele neuerungen aus Extensions übernommen. Tab well z.B. ist ziemlich gut implementiert wurden. Syntax formatierung, highlight, jit und intellisense arbeiten nun viel besser und das man nun alle Projekte in der Solution mit einmal neu laden kann ist praktisch(wenn man mit cmake arbeitet). Man kann nun auch Symbole und Datein in der Solution suchen, Funktions Documentation wird korrekter dargestellt, ne menger toller extension von MS zum erweitern, wie z.B. für Profiler und Build Overview. Da fehlt eigentlich nicht mehr viel, bis man kein Visual Assist X mehr bräuchte.
|