Hallo,

Ich multipliziere 40 Mil Vektoren mit einer Matrix. Initialisiere die Matrix, die Vektoren und führe die Multiplikation inklusive Zeit-Messung aus.

const int size = 40000000;


vec4 * vertices;
vertices = new vec4[size];

mat4 transform = mat4(1.0f);


float mod = 0.0f;
for (int i=0; i<size; i++) {
    vertices[i] = vec4(1.0f+mod, 1.0f-mod, 1.0f, 1.0f);
    mod += 0.001f;
}


//transform = mat4(1.0f); //uncomment to increase performance


cout << "Starting GLM multiplication..." << endl;


time_t t = clock();

for (int j=0; j<1; j++) {
     for (int i=0; i<size; i++) {
         vertices[i] = transform * vertices[i];
     }
}

float total = (float)(clock()-t)/CLOCKS_PER_SEC;

cout << "End: " << total << endl;

Jemand eine Idee warum die Performance steigt wenn ich die auskommentierte Zeile einkommentiere? Ich verwende GLM.

Performance mit Zeile: ~170ms
Performance ohne Zeile: ~265ms

vgl in Java:
optimierte Version: ~223ms
mit lwjgl.util: ~330ms

edit: (die optimierte Java Version in 1:1 C++ kommt im Übrigen auf ca 190ms)

Zitat von anwesender

Könnte es theoretisch am caching liegen?
Was passiert wenn du die Zeile in die Zeitmessung inkludierst? (natürlich ohne dem cout)

Welcher Sinn steckt eigentlich hinter nachfolgendem Konstrukt?

Code

for (int j=0; j<1; j++)
{
}

Die vertices werden am Ende schon noch irgendwo freigegeben oder? (delete[] vertices)

Thomas

Hi,

Ja das mit caching war auch eine meiner Vermutungen, also dass z.B. unter Umständen die transform-Matrix nach der langen for-Schleife aus dem cache wandert; jedoch bin ich etwas verwundert, dass der Compiler sowas nicht optimiert und dass nur ein cache miss hier soviel Performance unterschied mache kam mir auch eigenartig vor.

(Auch von stackoverflow: "For comparison, on one particular modern multicore PowerPC CPU, an L1 miss is about 40 cycles", das könnte so in etwa mit 2 misses hin kommen.)

Diese for-Schleife hat nur den Sinn dass ich auch testweise j variiert habe und die Performance verglichen.
Auf delete hatte ich vergessen, aber das macht eigentlich nichts, da es hier nur um einen Performance Vergleich ging. (Der Stack war zu klein, sonst hätte ich die Matrix ja dort gelassen.)

Zitat von emptyvi

Habe vor längerer Zeit Mal aus Langeweile nach Geschwindigkeitsvergleichen von Sprachen gesucht.. Da habe ich mich an diesen Post erinnert.. Könnte es damit was zu tun haben?
http://stackoverflow.com/a/146186

Hm also Fortran kenne ich leider nicht, aber rein theoretisch (nach meinem verständnis) sollte es keinen Memory overlap geben, da die eine variable am heap und die andere am stack liegen sollte.

Trotzdem danke vorerst für die Antworten.

Zitat von anwesender

Naja, was der compiler optimiert und was nicht ist immer so eine sache, hast du -O3 beim g++ probiert?
Ein anderes interessantes Szenario wäre die transfrom Matrix gleich unten zu deklarieren und definieren!
Für die matrix-multiplikation sind die SSE extensions interessant, ich weiss nicht ob die GLM sie (für die multiplikation) benutzt.

Wieviel Zeit ein cache miss kosten kann kann ich dir nicht sagen, ist auch ein typisches problem mit echtzeitgeschichten, in deinem fall sinds wohl 3 cache misses (L1 - L2 - L3).
Was tut das ding wenn du die Zuweisung ins Zeit messen hineinnimmst? (hast du es getestet?)

Thomas

Hallo,

Ja wollte es gerade schreiben, nur das forum will nicht so ganz. Also ox hab ich grad probiert, trotzdem ist die Version langsamer (verwende den visual studio 2010 compiler).

Wenn ich die Zuweisung später mache, selbst wenn ich sie in der j-for-schleife mit mehreren Durchläufen mache, bekomme ich eine bessere Performance.

edit: selbst wenn ich die zuweisung am ende des letzten druchlaufes innerhalb der vertices-zuweisungs-for-schleife mache, bleibt meine performance schlecht. sobald es irgendwo nach dieser schleife passiert ist die verbesserung merkbar.

edit2:
selbst sowas:

for (int i=0; i<size; i++) {            
    transform = mat4(1.0f);
    vertices[i] = transform * vertices[i];
}

ist schneller; möglich wäre es schon auch dass es eine GLM interne optimierung ist (habe mir das aber noch nicht durchgesehen)