Bedingte Sprünge

Hoi,

gibt es eigentlich eine Möglichkeit, dem Compiler zu sagen, dass ein Sprung wahrscheinlich/unwahrscheinlich ist?
MMIX nennt einen unerwarteten Sprung / unerwarteten nicht-Sprung "bad guess". Ich würde aber ganz gern auf C++ Ebene bleiben, gibt es dafür ein Schlüsselwort oder so?

Wieviel Takte verliert man so (über den Daumen gepeilt) bei einem bad guess? Bei MMIX sind es glaub ich 3, aber das soll ja bei einem "normalem" Prozessor wesentlich mehr sein...

Beispiel:

for( unsigned int i = 0;  i < objects.size();  ++i )
{
        // Sollte meistens zutreffen
	if( objects[i] == NULL )
		continue;

        // mach was mit dem Objekt
}

HumeSikkins

Optimizer schrieb:

gibt es eigentlich eine Möglichkeit, dem Compiler zu sagen, dass ein Sprung wahrscheinlich/unwahrscheinlich ist?

Das ist doch nicht dein ernst oder? In Standard-C++ natürlich nicht.
Schau doch einfach mal in deine Compiler-/Prozessordoku.

Wieviel Takte verliert man so (über den Daumen gepeilt) bei einem bad guess?

Zirka ganz genau 19.
Wie beantwortet man diese Frage ohne den Prozessor, seine Pipelines, die aktuelle Füllung, den Befehl, den Cache-Zustand... zu kennen?

Führ doch einfach ein Null-Object ein und schon kannst du dir die Prüfung sparen. Achso, diese Hinweis ist natürlich ohne Kontext völliger blödsinn.

HumeSikkins schrieb:

Das ist doch nicht dein ernst oder? In Standard-C++ natürlich nicht.

Wieso soll das nicht mein Ernst sein? Wenn es so etwas wie

register

gibt, was IMHO noch mehr low-level ist und bestimmt für den Compiler noch uninterressanter, habe ich mir halt gedacht, dass es so etwas auch geben könnte.

Zirka ganz genau 19.
Wie beantwortet man diese Frage ohne den Prozessor, seine Pipelines, die aktuelle Füllung, den Befehl, den Cache-Zustand... zu kennen?

Der Nachteil kommt doch AFAIK dadurch zustande, dass der Prozessor Befehle im voraus in den Cache lädt und bei einem Sprung diese ungültig sind und er neue laden muss. Natürlich denke ich mal auch, dass sich das von Modell zu Modell unterscheidet, aber eine grobe Richtlinie würde mich mal interressieren. Wenn es zu stark differenziert, so dass es überhaupt nicht mehr sinnvoll ist, eine Angabe zu machen, dann bin ich damit auch zufrieden.
Auf jeden Fall soll es ja so unglaublich teuer sein.

Führ doch einfach ein Null-Object ein und schon kannst du dir die Prüfung sparen. Achso, diese Hinweis ist natürlich ohne Kontext völliger blödsinn.

Ja, jetzt hätte ich mich wirklich fast totgelacht.

Ringding

Als Richtlinie passen die 19 Zyklen wohl eh ganz gut (beim klassischen P4), also so ca. ein Pipeline-Durchlauf.

PGO (Profile Guided Opimization) kann das, wenn es das Instruction Set des Prozessors überhaupt ermöglicht (geht bei x86 z.B. nicht).