Odpověď na názor

@FMA4

U FMA4 nešlo o to, že by ta instrukce měla nějaký potenciál zdvihnout výkon v porovnání s FMA3. Aspoň tedy ne v případě, kdy má CPU funkční MOV elimination pro SIMD instrukce (což myslím třeba Sandy Bridge nemělo...). Většinou by FMA3 i FMA4 kód měl mít stejný výkon, ale protože jsou to jiné opcodes, tak aplikace nemusí umět oboje.

Tam IIRC (*prý*) byl problém v tom, že AMD mělo v plánu řešit FMA jako tří operandovou instrukci (výsledek přepíše jeden z registrů na vstupu), ale Intel se tvářil, že to implementuje nedestruktivně jako FMA4 (výsledek se zapisuje do jiného registru, takže všechny vstupy jsou zachované pro další operace). Ale pak když to AMD předělalo na FMA4, tak Intel vyhlásil, že místo toho udělá FMA3. Proto měl Bulldozer jen FMA4 a až Piledriver přidal i FMA3.

Intel měl FMA3 až o rok později v Haswellu. Ale mohl a často asi i byl tam problém v tom, že vývojáři softwaru všechno radši chystali na Intel a binárky používaly instrukce FMA3, takže Bulldozer měl smůlu, i když funkčně to samé uměl udělat. No a AMD kvůli tomu mělo o trošku složitější dekodéry.

Nemusela to být nutně úmyslná buzerace, dá se to vysvětlit i zmatkováním v Intelu, což jak pozdější vývoj ukázal, není něco, co by se tam nedělo...

P.S. matně si vzpomínám na jeden filtr pro avisynth nebo vapoursynth, který měl FMA4 codepath, ale už nevím, jestli to zlepšovalo výkon na AMD, nebo to bylo pro kompatibilitu s FX-81**/61**/41**. A je to pochopitelně SW, který asi relativně málokdo používal. x264 mělo optimalizace v FMA4 i FMA3 (ale je to floating point operace, takže asi jenom pro mbtree rate control, což je spíš malé procento výpočtů). Ale rozdíl ve výkonu by neměl být velký, jak bylo řečeno.