Vzhledem k tomu, že všechno co leze do procesoru, je strojový kód, tak ano, trpím pocitem, že pro programátora neexistuje více možností, než ty, které má ve strojovém kódu/assembleru.Nikdy jsem nemluvil o tom, že zcela samozřejmě rychlost kódu ovlivňuje i tisíc dalších věcí kolem. Včetně latencí paměťového řadiče, obsahu keší, obsazenosti různých jednotek dalšími jádry a thready, atd. Je to tak samzořejmě, že moc nechápu, proč to zdůrazňujete.Cílem programátora (či jakéhokoli jiného člověka v jakémkoli oboru na světě) je udělat maximální výsledek s tím, co mám k dispozici o mohu ovlivnit. Jediné co jsem psal je, že pořadí strojových instrukcí má obrovský a zásadní vliv (nikdy jsem nepsal jediný, proto nevím, proč furt jako kolovrátek píšete o jiných vlivech) na rychlost výsledného kódu.Zkuste si, pěkně prosím, napsat nějakou jednoduchou rutinu v assembleru, a měřte její rychlost. Třeba zjištění délky řetězce zakončeného nulou (Céčková funkce strlen), nebo zkopírování kusu paměti (memcpy). Před léty jsem na tomto strávil měsíc. Rychle jsem pochopil, jak každá instrukce šíleně ovlivňuje celou rychlost. Za ten měsíc jsem se naučil o rychlosti kódu více, než kdybych si přečetl celou knihovnu.Dnešní Ryzen například, může vykonat za jeden takt řekněme 1/20 instrukce až cca 300 instrukcí. Záleží na vás jako na programátorovi v assembleru, když chcete maximální rychlost. Můžete řídit rychlost programu v měřítku 1:6000 jen jako assemblerista. Když to umíte.Out of order jednotka optimalizuje především věci, které jako programátor ovlivnit nemůžete. Příklad jsem napsal výše, viz ta sekvence push rax, call fce. Proto její výpadek těžko plně nahradíte lepším assemblerem.