Es werden in diesem Versuch zunächst vier mögliche Fetch-Strategien betrachtet. Die einfachste Variante holt Befehle für den Thread, der die wenigsten Bytes in seinem Befehlsfenster hat. Eine Erweiterung bevorzugt bei gleichem Füllstand der Fenster den Thread mit der höheren Priorität. Unabhängig davon, ob die Priorität beachtet wird, kann man Threads, die gerade einen Sprung ausgeführt haben, bevorzugen, da nach einem genommenen Sprung das Fenster vollständig gelöscht werden muß.
Die Fetch-Strategie hat nur einen sehr geringen Einfluß auf die Leistung des Mikrocontrollers, wie in Abbildung 3.4 zu erkennen ist. Ob man die Priorität der Threads mit in Betracht zieht, wirkt sich hier gar nicht aus, da Threads mit niedriger Priorität sowieso nicht häufig gebraucht werden. Die Variante bei der Threads, die gerade einen Sprungbefehl ausgeführt haben, bevorzugt ausgewählt werden, verschlechtert das Ergebnis sogar um maximal ein halbes Prozent. Dies geschieht jedoch nur bei einem ungünstigen Verhältnis zwischen der Größe des Befehlsfensters und der Fetch-Bandbreite. Das liegt daran, daß das Befehlsfenster eines Thread, der einen Sprung ausgeführt hat, leer ist und somit auch mit den geringsten Füllstand hat.
Daraus folgt, daß es sich nicht lohnt, viel Hardware in die Fetch-Strategie zu investieren. Dies gilt umso mehr, da auch ein einfaches Round-Robin-Verfahren die Ergebnisse nicht wesentlich ändert. Lediglich der durchschnittliche Füllstand der Befehlsfenster ist etwas geringer.