4. Design für vector-Klasse gesucht

Design für vector-Klasse gesucht


  • hustbaer schrieb:

    @dot
    Geht's dir hier um das sog. "structure packing"? Also dass bei

    struct foo { char c; int i; };

    üblicherweise sizeof(int) - 1 Bytes zwischen c und i freigelassen werden?

    Mir geht es vor allem darum, dass der Standard keine Garanie bietet. Dass es unter allen möglichen Compilern natürlich trotzdem funktionieren wird, ist eine andere Geschichte...

    hustbaer schrieb:

    Vielleicht sollte man dazu einfach das #pragma pack von MSVC standardisieren.

    Zumindest afaik unterstützten die wenigsten Architekturen unaligned Memory Access, x86 is da eher eine Ausnahme als die Regel und selbst unter x86 geht das nur bedingt. Und bereits unter x86/MSVC bedeutet #pragma pack potentiell weniger effizienter Code. Das zu standardisieren, halte ich für sehr problematisch. Selbst wenn man den Compiler Code generieren ließe, der die einzelnen Bytes aus größeren Blöcken abschält, wird man z.B. im Zusammenhang mit Concurrency dann wohl auf Probleme ähnlich zu denen mit Bitfeldern stoßen. Und selbst wenn wir so etwas wie #pragma pack hätten, haben wir unser eigentliches Problem (wir wüden gerne per Name und per Index zugreifen) noch nicht gelöst...

    Wenn du mich fragst, wäre es sinnvoller, einfach im Standard zu garantieren, dass aufeinanderfolgende struct Member von gleichem Typ per union auf ein Array aliasen dürfen und umgekehrt. Es gibt ja bereits in C++11 die Sache mit standard layout unions von standard layout structs mit einer common initial sequence. Die ist nur leider für unseren Fall hier noch nicht ausreichend...

    0
  • ?

    asfdlol schrieb:

    rapso schrieb:

    asfdlol schrieb:

    rapso schrieb:

    asfdlol schrieb:

    rapso schrieb:

    asfdlol schrieb:

    rapso schrieb:

    asfdlol schrieb:

    rapso schrieb:

    otze schrieb:

    @rapso ist unter den Bedingungen überhaupt noch sichergestellt, dass das speicherlayout der vektoren irgendwas ist, womit die Grafikkarte klar kommt? Also dass die elemente kontinuirlich im Sepicher liegen und kein padding etc drin vorkommt?

    solange du da nicht explizit alignment/padding dranbaust, werden die klassen wie erwartet im speicher liegen. auch auf gpus (falls du gerade cuda meinst) wuerde es richtig laufen.

    das dürfte für non-pod-types (wie deiner einer ist) implementation-defined sein.

    ich seh nicht wo etwas nicht POD sein soll.

    ist nicht pod, da:
    1. vererbung
    2. member in private

    fuers layouten der klassen sind es PODs, es gibt keine member oder sonst etwas was ein alignment bzw. padding enforcen wuerde auf nachfolgende elemente.
    solange du nicht per hand eingreifst ist das layout wohl definiert und wird von jedem c++ compiler gleich umgesetzt.

    das stimmt in meinen augen für vererbung nicht:

    N1905 §10.0.4 schrieb:

    The order in which the base class subobjects are allocated in the most derived object (1.8) is unspecified. [Note: a
    derived class and its base class subobjects can be represented by a directed acyclic graph (DAG) where an arrow means
    “directly derived from.” A DAG of subobjects is often referred to as a “subobject lattice.”
    Base
    ↑
    Derived1
    ↑
    Derived2
    5 The arrows need not have a physical representation in memory. — end note ]

    das ist aber ein POD fuers layout.

    A type that is standard-layout means that it orders and packs its members in a way that is compatible with C. A class or struct is standard-layout, by definition, provided:
    It has no virtual functions
    It has no virtual base classes
    All its non-static data members have the same access control (public, private, protected)
    All its non-static data members, including any in its base classes, are in the same one class in the hierarchy
    The above rules also apply to all the base classes and to all non-static data members in the class hierarchy
    It has no base classes of the same type as the first defined non-static data member

    A class/struct/union is considered POD if it is trivial, standard-layout, and all of its non-static data members and base classes are PODs.

    der von mir gequotete paragraph schliesst layout-pods nicht aus und deiner macht keine aussage bezüglich der anordnung - von im beispiel x, y, z und w - in der most-derived-class.

    steht da, es ist C order.

    In c werden alle memeber der deklarationsreihenfolge nach angeordnet.

    Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning.

    da steht dass es mit der art wie es in C gemacht wird kompatibel ist. daraus einen schluss für vererbung zu folgern halte ich für übermütig da es in c natürlich keine vererbung gab.

    Du hast eine interesante Haltung, aber der zu folgen ist noch übermütiger.

    0
  • V

    fail0r schrieb:

    asfdlol schrieb:

    rapso schrieb:

    asfdlol schrieb:

    rapso schrieb:

    asfdlol schrieb:

    rapso schrieb:

    asfdlol schrieb:

    rapso schrieb:

    asfdlol schrieb:

    rapso schrieb:

    otze schrieb:

    @rapso ist unter den Bedingungen überhaupt noch sichergestellt, dass das speicherlayout der vektoren irgendwas ist, womit die Grafikkarte klar kommt? Also dass die elemente kontinuirlich im Sepicher liegen und kein padding etc drin vorkommt?

    solange du da nicht explizit alignment/padding dranbaust, werden die klassen wie erwartet im speicher liegen. auch auf gpus (falls du gerade cuda meinst) wuerde es richtig laufen.

    das dürfte für non-pod-types (wie deiner einer ist) implementation-defined sein.

    ich seh nicht wo etwas nicht POD sein soll.

    ist nicht pod, da:
    1. vererbung
    2. member in private

    fuers layouten der klassen sind es PODs, es gibt keine member oder sonst etwas was ein alignment bzw. padding enforcen wuerde auf nachfolgende elemente.
    solange du nicht per hand eingreifst ist das layout wohl definiert und wird von jedem c++ compiler gleich umgesetzt.

    das stimmt in meinen augen für vererbung nicht:

    N1905 §10.0.4 schrieb:

    The order in which the base class subobjects are allocated in the most derived object (1.8) is unspecified. [Note: a
    derived class and its base class subobjects can be represented by a directed acyclic graph (DAG) where an arrow means
    “directly derived from.” A DAG of subobjects is often referred to as a “subobject lattice.”
    Base
    ↑
    Derived1
    ↑
    Derived2
    5 The arrows need not have a physical representation in memory. — end note ]

    das ist aber ein POD fuers layout.

    A type that is standard-layout means that it orders and packs its members in a way that is compatible with C. A class or struct is standard-layout, by definition, provided:
    It has no virtual functions
    It has no virtual base classes
    All its non-static data members have the same access control (public, private, protected)
    All its non-static data members, including any in its base classes, are in the same one class in the hierarchy
    The above rules also apply to all the base classes and to all non-static data members in the class hierarchy
    It has no base classes of the same type as the first defined non-static data member

    A class/struct/union is considered POD if it is trivial, standard-layout, and all of its non-static data members and base classes are PODs.

    der von mir gequotete paragraph schliesst layout-pods nicht aus und deiner macht keine aussage bezüglich der anordnung - von im beispiel x, y, z und w - in der most-derived-class.

    steht da, es ist C order.

    In c werden alle memeber der deklarationsreihenfolge nach angeordnet.

    Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning.

    da steht dass es mit der art wie es in C gemacht wird kompatibel ist. daraus einen schluss für vererbung zu folgern halte ich für übermütig da es in c natürlich keine vererbung gab.

    Du hast eine interesante Haltung, aber der zu folgen ist noch übermütiger.

    Sehe ich auch so.
    ~Wollte eigentlich mal nur den Fullquote weiterbringen, wie tief schaffen es Forensoftware und Browser wohl?~

    0

  • dot schrieb:

    Wenn du mich fragst, wäre es sinnvoller, einfach im Standard zu garantieren, dass aufeinanderfolgende struct Member von gleichem Typ per union auf ein Array aliasen dürfen und umgekehrt. Es gibt ja bereits in C++11 die Sache mit standard layout unions von standard layout structs mit einer common initial sequence. Die ist nur leider für unseren Fall hier noch nicht ausreichend...

    Ach den Teil meinst du.
    Ja, das wäre vermutlich sinnvoll!

    Das mit non-alinged Zugriffen ist natürlich doof wenn das die meisten CPUs nicht können. Ich hab' mich mit dem Thema ehrlich gesagt nicht wirklich befasst, ich hätte angenommen dass es eher unproblematisch ist.
    In dem Fall macht es wohl weniger Sinn #pragma pack zu standardisieren. Weil ich nur zwei Möglichkeiten sehe, die beide nicht gut sind.

    1. Der Standard schreibt keine Werte vor die unterstützt werden müssen. Ist dann doof, weil nur sehr begrenzt nützlich.

    2. Der Standard schreibt den Wertebereich vor (z.B. alle 2^N von 1 bis 16), und die Compiler müssen dann u.U. langsamen Code generieren. Wenn sich alle Programmierer über den Impact im klaren wären, wäre das OK. Weil immer noch nützlich in vielen Situationen. z.B. wenn man bestimmte Binärformate parsen oder schreiben muss - da wäre dann egal dass der Code nicht superschnell läuft, weil der Code den man sonst schreiben müsste es auch nicht schneller machen wird. Nur dummerweise kann man sich sicher sein, dass viele Programmierer es misbrauchen werden.

    Schade.

    0
  • ?

    hustbaer schrieb:

    Nur dummerweise kann man sich sicher sein, dass viele Programmierer es misbrauchen werden.

    Schade.

    Wenn Missbrauchsgefahr ein Argument wäre, etwas nicht anzubieten, würde C++ nicht existieren und die [quote]-Funktion des Forums auch nicht:

    volkard schrieb:

    fail0r schrieb:

    asfdlol schrieb:

    rapso schrieb:

    asfdlol schrieb:

    rapso schrieb:

    asfdlol schrieb:

    rapso schrieb:

    asfdlol schrieb:

    rapso schrieb:

    asfdlol schrieb:

    rapso schrieb:

    otze schrieb:

    @rapso ist unter den Bedingungen überhaupt noch sichergestellt, dass das speicherlayout der vektoren irgendwas ist, womit die Grafikkarte klar kommt? Also dass die elemente kontinuirlich im Sepicher liegen und kein padding etc drin vorkommt?

    solange du da nicht explizit alignment/padding dranbaust, werden die klassen wie erwartet im speicher liegen. auch auf gpus (falls du gerade cuda meinst) wuerde es richtig laufen.

    das dürfte für non-pod-types (wie deiner einer ist) implementation-defined sein.

    ich seh nicht wo etwas nicht POD sein soll.

    ist nicht pod, da:
    1. vererbung
    2. member in private

    fuers layouten der klassen sind es PODs, es gibt keine member oder sonst etwas was ein alignment bzw. padding enforcen wuerde auf nachfolgende elemente.
    solange du nicht per hand eingreifst ist das layout wohl definiert und wird von jedem c++ compiler gleich umgesetzt.

    das stimmt in meinen augen für vererbung nicht:

    N1905 §10.0.4 schrieb:

    The order in which the base class subobjects are allocated in the most derived object (1.8) is unspecified. [Note: a
    derived class and its base class subobjects can be represented by a directed acyclic graph (DAG) where an arrow means
    “directly derived from.” A DAG of subobjects is often referred to as a “subobject lattice.”
    Base
    ↑
    Derived1
    ↑
    Derived2
    5 The arrows need not have a physical representation in memory. — end note ]

    das ist aber ein POD fuers layout.

    A type that is standard-layout means that it orders and packs its members in a way that is compatible with C. A class or struct is standard-layout, by definition, provided:
    It has no virtual functions
    It has no virtual base classes
    All its non-static data members have the same access control (public, private, protected)
    All its non-static data members, including any in its base classes, are in the same one class in the hierarchy
    The above rules also apply to all the base classes and to all non-static data members in the class hierarchy
    It has no base classes of the same type as the first defined non-static data member

    A class/struct/union is considered POD if it is trivial, standard-layout, and all of its non-static data members and base classes are PODs.

    der von mir gequotete paragraph schliesst layout-pods nicht aus und deiner macht keine aussage bezüglich der anordnung - von im beispiel x, y, z und w - in der most-derived-class.

    steht da, es ist C order.

    In c werden alle memeber der deklarationsreihenfolge nach angeordnet.

    Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning.

    da steht dass es mit der art wie es in C gemacht wird kompatibel ist. daraus einen schluss für vererbung zu folgern halte ich für übermütig da es in c natürlich keine vererbung gab.

    Du hast eine interesante Haltung, aber der zu folgen ist noch übermütiger.

    Sehe ich auch so.
    ~Wollte eigentlich mal nur den Fullquote weiterbringen, wie tief schaffen es Forensoftware und Browser wohl?~

    0
  • V

    hustbaer schrieb:

    Wenn sich alle Programmierer über den Impact im klaren wären, wäre das OK.

    Sind sie sich nicht. Vielleicht baut nächstes Jahr einer einen Supa-Dupa-Prozessor (nennen wir ihn einfach mal Itanium-Pro), der komplett alte Zöpfe abschneidet (und deswegen stromsparender als ARM und schneller als Intel-amd64 wird), der misalignte Zugriffe schlicht nicht unterstützt. Dann fliegt ne Hardware-Exception und das BS *kann* gerne den Code anschauen und per Software solche Zugriffe emulieren, kostet halt 1000 Takte pro misaligned-Zugriff.

    0
  • ?

    Ist das nicht alles eine ein akademische Diskussion? In der Realität benutzt jeder einen simplen struct der Form

    struct vec2{ 
 float x, y; 
 float& operator[](int i){assert(x < 2); assert(x >= 0); return (&x)[i];}
};

    mit ein paar praktischen Konstruktoren und überladenenen Operatoren ohne sinnlosen template unsinn und unions usw. Das einzige wozu das führt ist weniger Übersicht im Debugger, weil man in MSDEV/Xcode mehr aufklappen muss, länge namen hat und der Compiler langsamer wird.

    Und da man Vektoren nur für 2D, 3D, 4D braucht kann man das auch mal eben kopieren. Für Quaternionen und Plückercoordinaten kann man die templates eh kaum nutzen.

    Beispiele von erfolgreicher Software die vektoren ohne komischen c++ voodoo hat:

    Doom4 (idTech4): https://github.com/TTimo/doom3.gpl/blob/master/neo/idlib/math/Vector.h

    C4 Engine: http://www.terathon.com/docs/Math/Vector2D.html

    Torque3D Engine: https://github.com/GarageGames/Torque3D/blob/master/Engine/source/math/mPoint2.h

    ogre: https://github.com/ehsan/ogre/blob/master/OgreMain/include/OgreVector2.h

    ilmmath (Industrial Light & Magic): https://github.com/openexr/openexr/blob/master/IlmBase/Imath/ImathVec.h

    tgt (Benutzt zur medizinischen Visualisierung): https://github.com/lathen/voreen/blob/master/ext/tgt/vector.h

    (+ diverse Lösungen, die nicht ohne lizenzen einsehbar sind)

    0

  • blard schrieb:

    Ist das nicht alles eine ein akademische Diskussion? In der Realität benutzt jeder einen simplen struct der Form [...]

    nope

    blard schrieb:

    ogre: https://github.com/ehsan/ogre/blob/master/OgreMain/include/OgreVector2.h

    Benutzen zumindest einen typedef, um irgendeine Form von Flexibilität zu bekommen. Besser als nichts.

    blard schrieb:

    ilmmath (Industrial Light & Magic): https://github.com/openexr/openexr/blob/master/IlmBase/Imath/ImathVec.h

    Ist ein template.

    blard schrieb:

    tgt (Benutzt zur medizinischen Visualisierung): https://github.com/lathen/voreen/blob/master/ext/tgt/vector.h

    Ist ein template.

    blard schrieb:

    (+ diverse Lösungen, die nicht ohne lizenzen einsehbar sind)

    aha

    0
  • ?

    dot schrieb:

    blard schrieb:

    Ist das nicht alles eine ein akademische Diskussion? In der Realität benutzt jeder einen simplen struct der Form [...]

    nope

    Doch

    blard schrieb:

    ogre: https://github.com/ehsan/ogre/blob/master/OgreMain/include/OgreVector2.h

    Benutzen zumindest einen typedef, um irgendeine Form von Flexibilität zu bekommen. Besser als nichts.

    So? Typedef ist nicht grade hightech...

    blard schrieb:

    ilmmath (Industrial Light & Magic): https://github.com/openexr/openexr/blob/master/IlmBase/Imath/ImathVec.h

    Ist ein template.

    Nicht für Dimension.

    blard schrieb:

    tgt (Benutzt zur medizinischen Visualisierung): https://github.com/lathen/voreen/blob/master/ext/tgt/vector.h

    Ist ein template.

    Nicht für Anzahl der Dimension.

    blard schrieb:

    (+ diverse Lösungen, die nicht ohne lizenzen einsehbar sind)

    aha

    0
  • K

    class Antivector4D ... 🙂

    Ist ein template.

    Ein sehr triviales. Meine einfachen Vektor-/Matrixklassen haben das auch. Funktioniert auch nur fuer double/float.

    0
  • R
    Mod

    volkard schrieb:

    Vielleicht baut nächstes Jahr einer einen Supa-Dupa-Prozessor (nennen wir ihn einfach mal Itanium-Pro)

    heisst eigentlich SPE und ist im CELL processor verbaut.

    .. der komplett alte Zöpfe abschneidet (und deswegen stromsparender als ARM und schneller als Intel-amd64 wird), der misalignte Zugriffe schlicht nicht unterstützt. Dann fliegt ne Hardware-Exception

    kannst du auf der ppu anmachen, die SPE hat hingegen kein wissen ueber die unteren 16byte der addresse, du musst die exception per software emulieren, sonst werden die unteren bytes ignoriert und 16byte aligned gelesen.

    und das BS *kann* gerne den Code anschauen und per Software solche Zugriffe emulieren, kostet halt 1000 Takte pro misaligned-Zugriff.

    software emuliert laufen missaglined zugriffe recht schnell, ist
    -read
    -address masking
    -select von bytes anhand untere 4bits
    read kostet 6cycles latenz, die beiden anderen 4cycles, wenn ich mich recht erinnere.
    normaler c++ code laeuft auf SPEs sehr viel schneller als auf der PPU und kann mit intel cpus mithalten, mit software cache.
    optimierte daten layouts mit hand geschriebenen DMAs und hier und da ein wenig assembler zerlegt jede andere cpu.

    http://www.umiacs.umd.edu/~joseph/Streaming-model-ray-casting.pdf
    http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.125.8622&rep=rep1&type=pdf
    http://graphics.cs.uni-saarland.de/fileadmin/cguds/papers/2006/benthin_06_RTCELL/Benthin_et_al._-_Ray_Tracing_on_the_CELL_processor.pdf

    eine SPU hat 21MTransistors, ein Arm cortex a9 core soll 26MTransistors haben, ich weiss nicht aus dem kopf wieviel watt eine SPU zieht, eine neue ps3 im ganzen zieht <80watt, davon 10watt peripherie, vom rest 50%+ die RSX, sollten also ca 30watt fuer den CELL sein, sollten also etwa 3Watt sein fuer eine SPE.

    0
Anmelden zum Antworten