Verbesserungsvorschläge für Mathe-Templateklasse

Ich finde diese hundert __forceinline ganz leicht übertrieben. Ein normales inline reicht völlig aus, dass du es in den Header schreiben kannst, es ist schöner lesbar und inlinen ist außerdem Aufgabe des Compilers und nicht deine.

Ich sag ja nicht mal was, wenn du anhand von Messungen begründen kannst, dass diese Funktion nicht geinlined wurde und besser geinlined werden sollte. Aber meistens wird das der Compiler ganz gut machen und dein Source bleibt damit standardkonform.

Im übrigen ist eine fette .exe nicht so ganz ohne Nachteile, wenn der Rechner wegen dir dauernd hin und her cachen muss, hast du nichts gewonnen.

volkard

[quote="Optimizer"]Ich finde diese hundert __forceinline ganz leicht übertrieben. Ein normales inline reicht völlig aus, dass du es in den Header schreiben kannst, es ist schöner lesbar und inlinen ist außerdem Aufgabe des Compilers und nicht deine.[quote]
kann ich bestätigen. mir ist es einfach nicht gelungen, gescheit mit __forceinline__ zu arbeiten. die dicken brummer hat der compiler stets entgegen meinen wünschen doch outline gemacht.

Ich sag ja nicht mal was, wenn du anhand von Messungen begründen kannst, dass diese Funktion nicht geinlined wurde und besser geinlined werden sollte. Aber meistens wird das der Compiler ganz gut machen und dein Source bleibt damit standardkonform.

das mache man mit #define INLINE __forceinline__ und auf ner anderen plattform mit nem anderen define.

Im übrigen ist eine fette .exe nicht so ganz ohne Nachteile, wenn der Rechner wegen dir dauernd hin und her cachen muss, hast du nichts gewonnen.

das allerdings ist eine these, die erst bewiesen werden müßte.
dazu lese man aufmerksam http://www.cs.umass.edu/~emery/pubs/berger-pldi2001.pdf

die haben in der tat mehr performance, weil sie kleine funktionen machen und den compiler entscheiden lassen. im wpc habe ich auch die selbe beobachtung gemacht.
am meisten speed bekommt man im allgemeinen, wenn man dem compiler erlaubt, selber zu entscheiden, und im speziellen hab ich noch keine ausnahme gefunden, ich habe aber auch nicht gesucht.

b7f7

also ich würd viel der operatoren grundsätzlich aus der klasse lassen.
die elemente x,y,z,w würden mich ja dazu hinreissen die Klasse für projektive Koordinaten zu benutzen, aber auch für Quarternions da sind halt die operatoren unterschiedlich definiert.
also erst in mit den abgelittenen klassen solche ops() dazu.
und ein operator*(vector) const ist nicht eindeutig
v*v geht so nicht es geht nur v*vT oder vTv das eine hat als return ne matrix das ander ein skalar.
soll es also elementeweise multiplizieren?
das ist aaber Mv , M <-Matrix.
das ist dan aber kein operator von vector sonder eigentlich von Matrix oder global.

trotzdem
negate() und operator-(...)const machen ja unterschiedliche dinge ob negate nötig ist ist ansichtssache.

volkard

b7f7 schrieb:

v*v geht so nicht es geht nur v*vT oder vT*v das eine hat als return ne matrix das ander ein skalar.

was ist T und was bedeutet der satz?

otze

hier geht es um vectoren, und nicht um matritzen.

b7f7

das vektoren auch nur matrizen sind.

v*v
[x1]   [x2]
[y1] * [y2]  geht so nicht
[z1]   [z2]

aber das geht

v*vT vT<- Transponierter Vektor

[x1]                 [x1*x2] [x1*y2][x1*z2]
[y1] * [x2][y2][z2]= [y1*x2] [y1*y2][y1*z2] eine 3x3 Matrix
[z1]                 [z1*x2] [z1*y2][z1*z2]

vT*v
               [x2]
[x1][y1][z1] * [y2]= Skalarprodukt
               [z2]

volkard

b7f7 schrieb:

das vektoren auch nur matrizen sind.

warum frag ich überhaupt. sowas musst ja kommen.

b7f7

was ist denn dein Problem damit?
es ist nicht intuitiv klar Welche Operation gemeint ist.
es geht halt nur v.transp()*vector oder vector*vector.transp()
es geht def. nicht vector*vector.
die Probleme wird man alle los wenn man das als Matrix operationen betrachtet.

M*v ist definiert für eine Matrx(n,m)und ein Vektor(m,1) oder eine Matrix(m.p)
das ergebnis ist eine Matrix.
Scalierung geht damit

[sx][ 0][ 0]
[ 0][sy][ 0]
[ 0][ 0][sz]

Roation

[r00][r01][r02]
[r10][r11][r12]
[r20][r21][r22]

usw.

@Optimizer
er kann doch sowas schreiben:

#if !defined(_MSC_VER)
#define __forceinline inline
#endif

problem gelöst und sogar sehr schön

rüdiger

@Der Guru
nö, nicht sehr schön. Das eine ist nicht das andere und das andere Problem, was Optimizer zu recht angesprochen hat existiert noch.

wieso net schön?

camper

@Da Guru - Ich bin für das hier zu haben:

#ifdef _MSC_VER
#define inline __forceinline
#endif

sieht im code schöner aus, und es fragt dort dann auch keiner, was es bedeuten soll

b7f7 schrieb:

es geht def. nicht vector*vector.

schon mal was vom tensorprodukt gehört?

der * operator ist ohnehin hoffnungslos vieldeutig, definieren darfst du dir das wie du lustig bist. wie ich das sehe, ist dieses template eine art valarray mit erweiterter semantik.

camper schrieb:

@Da Guru - Ich bin für das hier zu haben:
#ifdef _MSC_VER
#define inline __forceinline
#endif
sieht im code schöner aus, und es fragt dort dann auch keiner, was es bedeuten soll

So. Und jetzt erklär mal ganz genau, warum du das inline forcen willst.
Bist du schlauer als die Compilerbauer?
Willst du ne 10MB große .exe?
Ist dir klar, dass vielleicht nicht jeder Compiler __forceinline kennt? Nach dem Präprozessor bekommt der Compiler nur noch __forceinlines zu sehen.
Mir ist die Motivation so unbegreiflich. Du weißt schon, dass inlining nicht ohne Nachteil ist, oder? Funktionsaufrufe hat nicht irgendjemand erfunden, der blöd ist, sondern, weil man damit (Maschinen-)Codeduplizierung vermeidet.

Benutze inline als das, was es heute praktisch ist: Als Erlaubnis dafür, Funktion in Header-Dateien direkt zu definieren. Überlass die Codegenerierung den Compiler. Wenn du Performanceprobleme hast, machst du sie mit sowas nicht weg. Optimiere das, was der Compiler nicht kann, benutze höhere Mathematik und bessere Algorithmen.

b7f7

camper schrieb:

b7f7 schrieb:

es geht def. nicht vector*vector.

schon mal was vom tensorprodukt gehört?

der * operator ist ohnehin hoffnungslos vieldeutig, definieren darfst du dir das wie du lustig bist.

das du dein TensorProdukt so schreiben darfts liegt einfach daran das per Konvention über gleiche Indizes summiert wird.

camper

Optimizer schrieb:

camper schrieb:
@Da Guru - Ich bin für das hier zu haben:
#ifdef _MSC_VER
#define inline __forceinline
#endif
sieht im code schöner aus, und es fragt dort dann auch keiner, was es bedeuten soll
So. Und jetzt erklär mal ganz genau, warum du das inline forcen willst.
Bist du schlauer als die Compilerbauer?
Willst du ne 10MB große .exe?
Ist dir klar, dass vielleicht nicht jeder Compiler __forceinline kennt? Nach dem Präprozessor bekommt der Compiler nur noch __forceinlines zu sehen.
Mir ist die Motivation so unbegreiflich. Du weißt schon, dass inlining nicht ohne Nachteil ist, oder? Funktionsaufrufe hat nicht irgendjemand erfunden, der blöd ist, sondern, weil man damit (Maschinen-)Codeduplizierung vermeidet.

Benutze inline als das, was es heute praktisch ist: Als Erlaubnis dafür, Funktion in Header-Dateien direkt zu definieren. Überlass die Codegenerierung den Compiler. Wenn du Performanceprobleme hast, machst du sie mit sowas nicht weg. Optimiere das, was der Compiler nicht kann, benutze höhere Mathematik und bessere Algorithmen.

selbstverständlich kennt nicht jeder compiler __forceinline, deshalb steht es ja auch in einer ifdef klausel - im übrigen wurde damit nur ausgedrückt, dass ich es eher sinnvoll finde, __forceinline durch inline zu ersetzen als umgekehrt, eben weil __forceinline compilerspezifisch, und inline nun mal leichter zu lesen ist.
im übrigen scheinst du die bedeutung von forceinline nicht zu kennen; so wie das normale inline ist es nur eine vorschlag an den compiler und kein zwang. ich betrachte mich auch keineswegs schlauer als die compilerbauer, schlauer als der compiler dagegen schon - wenn da ein __forceinline steht dann deshalb weil ich es so will, nicht weil es in jedem falle die 'optimale' lösung ist. an geeigneten stellen verwendet, erleichtert es das debuggen, nähmlich dann, wenn die funktion selbst nur aus einem oder zwei maschinenbefehlen besteht, dann ist es leichter diese befehle zu interpretieren, als erst umständlich ein call zurückzuverfolgen. __forceinline führt bei niedriger optimierungsstufe generell eher zu inlining. bei voller optimierung ist es dagegen tatsächlich kaum wirkungsvoller als inline.

__forceinline führt bei niedriger optimierungsstufe generell eher zu inlining.

Das ist Einstellungssache.

Du willst mich nicht verstehen, oder? Es geht überhaupt gar nicht darum, wie sehr inline oder __forceinline bewirkt, dass etwas geinlined wird. Es geht darum, dass der Compiler schon gute Gründe haben wird, wenn er etwas trotz normalen inline nicht inlined und das man inline in erster Linie nur verwenden sollte, um etwas in den Header zu definieren und nicht, um was zu "optimieren".
Es spricht vielleicht nichts dagegen, nach genauen Messungen vielleicht doch etwas zu forcen. Aber der Compiler wird das in den meisten Fällen schon machen und ich finde es dämlich, in einem Debug-Build überhaupt was zu inlinen, weil das nur dem Debugger die Arbeit erschwert.
Ich wiederhole mich... weil ich immer wieder gegen den selben Stumpfsinn anreden muss. Du kannst einfach keine wirklich guten Gründe für dein komisches #define vorweisen.

bei voller optimierung ist es dagegen tatsächlich kaum wirkungsvoller als inline.

Und warum machst du dann dieses behinderte typedef überhaupt? Ach egal, interessiert mich nicht mehr.

Leg dich doch nicht mit camper an, sondern mit ***. Der hats verdient.

camper

Optimizer schrieb:

Ich wiederhole mich... weil ich immer wieder gegen den selben Stumpfsinn anreden muss.

Und warum machst du dann dieses behinderte typedef überhaupt? Ach egal, interessiert mich nicht mehr.

wenn es dich nicht interessiert, solltest du vielleicht nicht überhaupt erst mit 'anreden' anfangen. es genügt völlig, wenn du deinen standpunkt klar machst. ich habe weder zeit noch geduld noch motivation für einen flame war. wenn du selbst keinen sinn in solchen formulierungen findest, ist das deine sache. daraus aber zu schliessen, es könnte keinen sinnvollen einsatz dafür geben, ist mindestens arrogant.

nebenbei:

Optimizer schrieb:

Aber der Compiler wird das in den meisten Fällen schon machen und ich finde es dämlich, in einem Debug-Build überhaupt was zu inlinen, weil das nur dem Debugger die Arbeit erschwert.

leider sind wir noch nicht soweit, dass der debugger MIR das debuggen abnimmt, und genau darum geht es. was weist du denn überhaupt über die art von programmierproblemen, mit denen ich mich beschäftige? solche mantras im stile von inline ist böse, pointer sind böse, operatoren sind böse, etc... hebst du dir besser für jemand anderes auf. im übrigen bin ich überhaupt nicht auf die frage eingegangen, ob der einsatz von inline in diesem konkreten fall (das heisst obigem klassen template) überhaupt sinnvoll ist. DARAUF angewandt macht deine argumentation sinn und ich stimme ihr auch zu. in einem anderen zusammenhang ist sie dagegen völlig unsinnig. solange compiler so dumm sind, wie sie eben sind; also zwar richtigen code erzeugen aber nicht begreifen, was ich damit bezwecke (bzw. überhaupt erst sourcen brauchen, um ein programm zu erzeugen), muss es legitim sein, den compiler anzuweisen, einen ausdruck in einer bestimmten weise zu interpretieren, soweit die syntax das zulässt.

otze

inline ist böse, pointer sind böse, operatoren sind böse

nene, das muss heissen: makros sind böse, goto ist böse

solche mantras im stile von inline ist böse, pointer sind böse, operatoren sind böse, etc... hebst du dir besser für jemand anderes auf. im übrigen bin ich überhaupt nicht auf die frage eingegangen, ob der einsatz von inline in diesem konkreten fall (das heisst obigem klassen template) überhaupt sinnvoll ist. DARAUF angewandt macht deine argumentation sinn und ich stimme ihr auch zu.

Leg mir doch nicht einfach irgendwas in den Mund. Ich habe niemals gesagt, dass inline böse ist. Ich habe gesagt, dass es Unfug ist, statt inline grundsätzlich __forceinline zu schreiben.
Nichts anderes machst du nämlich mit deinem Makro. Bei dir gibt's gar kein normales inline. Aber das siehst du ja auch nicht ein.