heute habe ich eine etwas allgemeinere Frage. Ich schreibe gerade an einer Regelung und mir ist aufgefallen, dass if-else-Konstruktionen um Größenordnungen langsamer als switch Anweisungen sind.

Warum ist das so und wie stark unterscheidet sich die Geschwindigkeit?

Grüße

DipplInsch

if(ic <= 12)
		{
//Wenige Berechnungen die oft ausgeführt werden
		}
else if(ic >= 13)
		{
//Berechnungen die nur einmal ausgeführt werden
		}
else{
    }

for(ic=0;ic<13;++ic)
  //Wenige Berechnungen die oft ausgeführt werden
ic=13;
//Berechnungen die nur einmal ausgeführt werden

(btw, die zweite if()-Abfrage ist sowieso redundant)

bei switch brauchst du nur eine Adresse aus der Sprungtabelle raussuchen und findest dort den korrekten Anweisungsblock.

Was aber nur geht, wenn die case werte es zulassen, dass mann eine Sprungtabelle aufbauen kann.

Zur Info:

Hier wird über eine SSI-Schnittstelle ein Winkel eingelesen. Der Sensor liefert bei jedem Takt die nächste Stelle der Zahl. Es kommen also 13 mal NULLEN oder EINSEN die abgespeichert werden.

switch (ic/13)
  {
  case 0: break;//<=12
  case 1: break;//>=13
  }

hab noch eine Idee, if-else zu vermeiden, weiß aber nicht, ob das trotz der Division einen Geschwindigkeitsvorteil bringt:

switch (ic/13)
  {
  case 0: break;//<=12
  case 1: break;//>=13
  }

was is bei ic = 30?

CStoll schrieb:

bei switch brauchst du nur eine Adresse aus der Sprungtabelle raussuchen und findest dort den korrekten Anweisungsblock.

Was aber nur geht, wenn die case werte es zulassen, dass mann eine Sprungtabelle aufbauen kann.

Du kannst dem Compiler schon vertrauen, daß er das bei einem standardkonformen switch() auch hinbekommt

@DipplInsch: Du mußt nicht unbedingt jedes if() rausschmeißen wollen - und für so eine Zwei-Wege-Auswahl macht es noch keinen großen Unterschied zwischen if und switch (wie gesagt, das zweite if ist redundant).

Ich schreibe gerade an einer Regelung und mir ist aufgefallen, dass if-else-Konstruktionen um Größenordnungen langsamer als switch Anweisungen sind.

Mit solchen Aussagen sollte man vorsichtig sein, da sie nicht allgemein gültig sind. Was schneller ist, hänt sehr stark von der Anzahl der Zweige ab. Auch Platform, Compiler und Optimierungseinstellungen spielen eine große Rolle.

Bei einer if-else-Kaskade müssen alle Bedingungen ausgewertet werden, bis du bei der richtigen ankommst - bei switch brauchst du nur eine Adresse aus der Sprungtabelle raussuchen und findest dort den korrekten Anweisungsblock.

Das hört sich erstmal nach einem klaren Vorteil für switch an. Dank Branch-Prediction, Speculative Execution usw. kann das Pendel aber auch durchaus mal in Richtung if-else ausschlagen.

Wie immer gilt: im Zweifelsfall messen, nicht raten.

(wie gesagt, das zweite if ist redundant).

Wieso ist das redundant?

Grüße

CStoll schrieb:

(wie gesagt, das zweite if ist redundant).

Wieso ist das redundant?

Wenn der Test auf ic<=12 fehlgeschlagen ist, ist ic>=13 in jedem Fall erfüllt (außer du hantierst mit Gleitkommawerten)

HumeSikkins schrieb:

Wie immer gilt: im Zweifelsfall messen, nicht raten.

Ausserdem war das kein Raten sondern eine Schlussfolgerung aufgrund des Programmverhaltens.

Grüße

103% Leistung schrieb:

CStoll schrieb:

bei switch brauchst du nur eine Adresse aus der Sprungtabelle raussuchen und findest dort den korrekten Anweisungsblock.

Was aber nur geht, wenn die case werte es zulassen, dass mann eine Sprungtabelle aufbauen kann.

Du kannst dem Compiler schon vertrauen, daß er das bei einem standardkonformen switch() auch hinbekommt

switch(a)
    {
    case 1:
        break;
    case 253:
        break;
    case 333:
        break;
    case 1444:
        break;
    case 5555:
        break;
    case 6643:
        break;
    case 11227:
        break;
    case 23458:
        break;
    case 23559:
        break;
    case 25550:
        break;
    }

Wie sieht jetzt die Tabelle aus? Soll die 25550 Einträge haben von denen fast alle leer sind.

Was bei einigen Anwendungen möglich ist: lookup Tables verwenden.
z.B. kann man ein Clamping eines unsigned ints auf 0-255 ohne "if" durchführen, z.B. so:

unsigned int x = ...;
// clamp:
unsigned int const lut[2] = {0, 0xff};
x |= lut[(x & 0x7fffff00) != 0];
x &= 0xff;

Das "(x & 0x7fffff00) != 0" sieht zwar wie ein verstecktes "if" aus, da es aber direkt in einen Index umgewandelt wird können manche Compiler intern ein billiges "conditional set" oder "conditional move" draus machen statt einem teuren "conditional jump".

Genauso könnte man diese Technik u.U. verwenden wenn man je nach Bedingung einen von 2 ganz unterschiedlichen Werten auswählen möchte. Wenn das "if" mehr weh tut als beide Werte zu berechnen (d.h. einen zu berechnen obwohl man ihn garnicht braucht) bringt das auch was.

CStoll schrieb:

103% Leistung schrieb:

CStoll schrieb:

bei switch brauchst du nur eine Adresse aus der Sprungtabelle raussuchen und findest dort den korrekten Anweisungsblock.

Was aber nur geht, wenn die case werte es zulassen, dass mann eine Sprungtabelle aufbauen kann.

Du kannst dem Compiler schon vertrauen, daß er das bei einem standardkonformen switch() auch hinbekommt

switch(a)
    {
    case 1:
        break;
    case 253:
        break;
    case 333:
        break;
    case 1444:
        break;
    case 5555:
        break;
    case 6643:
        break;
    case 11227:
        break;
    case 23458:
        break;
    case 23559:
        break;
    case 25550:
        break;
    }

Wie sieht jetzt die Tabelle aus? Soll die 25550 Einträge haben von denen fast alle leer sind.

Das implementiert der Compiler als binary search tree und blöcke die fortlaufend sind, kann er dann wieder als tabellen implementieren.