Geschwindigkeit von verschachtelten If-Anweisungen

DieDackel schrieb:

diese Verschachtelungen sich als Flaschenhals in meinem Programm herausgestellt haben

Wenn diese Verschachtelungen der Flaschenhals sind, dann bin ich ernsthaft interessiert am Rest des Programms.

allllllterd ein emtuuter hkat eier da würd eid ekuh neidisch werden
qf

Kritiker schrieb:

DieDackel schrieb:

diese Verschachtelungen sich als Flaschenhals in meinem Programm herausgestellt haben

Wenn diese Verschachtelungen der Flaschenhals sind, dann bin ich ernsthaft interessiert am Rest des Programms.

Naja, der Rest des Programmms arbeit fast nur mit Binäroperationen und diese Verschachtelungen machen schon einen größeren Teil des Quelltextes aus. Naja, ich dachte man könnte da in größerem Rahmen etwas machen.

muittterlkrappppppppppper schrieb:

allllllterd ein emtuuter hkat eier da würd eid ekuh neidisch werden
qf

Bitte Was????

volkard schrieb:

DieDackel schrieb:

switch((wert[2]<13)*2+(wert[1]<13)
...

kann noch ein fitztelchen bringen. oder erst nach wert[3] zu prüfen. aber echt nur fitztelchen. wenige prozent wohl.

Danke. Das probiere ich mal aus. Selbst wenn das nur 2 Prozent bringt...

hustbaer

DieDackel schrieb:

volkard schrieb:

DieDackel schrieb:

switch((wert[2]<13)*2+(wert[1]<13)
...

kann noch ein fitztelchen bringen. oder erst nach wert[3] zu prüfen. aber echt nur fitztelchen. wenige prozent wohl.

Danke. Das probiere ich mal aus. Selbst wenn das nur 2 Prozent bringt...

Evtl. auch gleich mit allen drei Bedingungen. Und natürlich ein "case" für alle 4 bzw. 8 Fälle, sonst macht der Compiler am Ende keinen Jump-Table draus, sondern wieder verschachtelte "if"s.
(Kann natürlich auch passieren wenn man alle 4/8 "case" hinschreibt - je nach Compiler)

Natürlich könnte man auch eine Version ganz ohne "if"s machen - ist bloss die Frage ob die dann schneller oder gar langsamer ist.

volkard

und mit
[

default: __assume(false);

](http://msdn.microsoft.com/en-us/library/1b3fsfxw(VS.80).aspx)

So, ich habe das jetzt mal in mein Programm implementiert und das Programm läuft jetzt tatsächlich um ca. 2% (ein bisschen mehr) schneller.

Vielen Dank für eure Idee. Da wäre ich von selbst nicht drauf gekommen...

DieDackel

hustbaer

läuft jetzt tatsächlich um ca. 2% (ein bisschen mehr) schneller.

Lustig. Ich hab mich mal ein wenig damit gespielt. Bei mir ist die Version mit den 3 "if"s immer noch die schnellste.
Die Version mit nur einem "switch" (8 "case"s) ist ca. Faktor 2 langsamer.
Die Version ganz ohne "switch" und "if" ist ca. Faktor 7 langsamer (was ich auch irgendwie erwartet habe, nachdem ich den Code fertig getippt hatte, uns gesehen was für ein Monster es ganz ohne Sprünge wird ).

berniebutt

Um wieviele Millisekunden geht es eigentlich - hast Du sonst noch Probleme?

hustbaer schrieb:

läuft jetzt tatsächlich um ca. 2% (ein bisschen mehr) schneller.

Lustig. Ich hab mich mal ein wenig damit gespielt. Bei mir ist die Version mit den 3 "if"s immer noch die schnellste.
Die Version mit nur einem "switch" (8 "case"s) ist ca. Faktor 2 langsamer.
Die Version ganz ohne "switch" und "if" ist ca. Faktor 7 langsamer (was ich auch irgendwie erwartet habe, nachdem ich den Code fertig getippt hatte, uns gesehen was für ein Monster es ganz ohne Sprünge wird ).

Naja, ich denke mal es kommt darauf an, was der Compiler daraus macht, keine Ahnung warum das bei mir ein bisschen schneller ist. Kann vllt. auch an dem eingesetzten System liegen. Leider hab ich auch nicht viel Ahnung von Assembler, sonst hätte ich mir mal die beiden Versionen verglichen.

hustbaer

Natürlich kommt es auf den Compiler drauf an, und auch auf die Daten und den Rest vom Programm. Und auf die verwendete CPU. Und und und...

Im Release Mode compiliert?

hustbaer

Natürlich. Hab's sogar mit profile guided optimization versucht, aber die if-variante war trotzdem immer deutlich schneller.

Hab ja auch den DieDackel gemeint

unskilled

entscheidende frage schrieb:

Hab ja auch den DieDackel gemeint

Wenn nicht, würde mich noch mehr wundern, warum diese if`s da der Falschenhals sein sollen...
halte ich auch so schon für nen gerücht - denke eher, dass er das nur hingeschrieben hat, damit nicht gleich wieder alle "premature optimation" brüllen, nur weil er eben gern wissen wollte, ob es geht oder nicht...

bb

hustbaer

Dann muss ich ja fast noch meine "branch-freie" Version posten (das erwähnte "Monster")...

void w00t(int* wert, int* moves)
{
	static int const allbits_if[2] = { 0, ~0 };
	static int const allbits_if_not[2] = { ~0, 0 };
	static int const five_if_not[2] = { 5, 0 };
	static int const thirteen_if_not[2] = { 13, 0 };

	int c2 = wert[2] < 13;
	int c1 = c2 & static_cast<int>(wert[1] < 13);
	int c0 = c1 & static_cast<int>(wert[0] < 13);

	moves[3] = (moves[2] & allbits_if[c2]) | five_if_not[c2];
	wert[3] = (wert[2] & allbits_if[c2]) | thirteen_if_not[c2];

	moves[2] ^= (moves[2] ^ ((moves[1] & allbits_if[c1]) | five_if_not[c1])) & allbits_if[c2];
	wert[2] ^= (wert[2] ^ ((wert[1] & allbits_if[c1]) | thirteen_if_not[c1])) & allbits_if[c2];

	moves[1] ^= (moves[1] ^ ((moves[0] & allbits_if[c0]) | five_if_not[c0])) & allbits_if[c1];
	wert[1] ^= (wert[1] ^ ((wert[0] & allbits_if[c0]) | thirteen_if_not[c0])) & allbits_if[c1];

	moves[0] ^= (moves[0] ^ 5) & allbits_if[c0];
	wert[0] ^= (wert[0] ^ 13) & allbits_if[c0];
}

Mag leicht sein dass sich da noch was optimieren lässt, ist bloss schnell zusammengefrickelt.
(Getestet isses aber, also funktionieren tut es. Macht genau dasselbe wie der original gepostete Code)