Verbesserungsvorschläge für Mathe-Templateklasse

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.

camper

Optimizer schrieb:

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.

entschuldige bitte, dass ich dich falsch vertanden habe. dafür genügt aber ein #undef nachdem alle relevanten deklarationen erfolgt sind - davon hab ich nichts gesagt und du hast auch nicht gefragt, insofern ist akzeptiere ich die kritik. eben weil der unterschied zwischen __forceinline und normalen inline so klein ist, wird sich in aller regel niemand die mühe machen, funktionen selektiv entweder mit dem einen oder dem anderen zu deklarieren. und daher kann es sinn machen, eine ganze gruppe gleichartiger funktionen, von denen man will, dass sie stets geinlined werden (was leider so nicht geht), derartig zu deklarieren. wie du sicher zustimmen wirst, fängt man ja damit an, funktionen mit inline zu deklarieren, und nicht mit __forceinline. wenn das ergebnis nicht befriedigt und man doch forceinline will, ist so ein makro bei weitem die einfachste möglichkeit, das zu tun, ohne unnötig editieren zu müssen, insbesondere wenn man es dann doch nicht will. dass man derartige makros, die schlüsselwörter verstecken, i. allg. nicht global verwenden sollte, betrachte ich als selbstverständlich.