Názory k článku Režim fast math v překladačích: přednosti, zápory a možné pasti

Tak FP umí přinášet zajímavé pasti. Pořád mi připadá, že se to na univerzitách stále dost ignoruje; potom na projektech vidím, že se FP používá jako reálná čísla. To ale není pravda, vůbec to nesplňuje spoustu vlastností reálných čísel.

Asi nejlepší je volba špatných násobků u jednotek v metrickém systému. To je čistý fail prakticky od začátku.

Jak to řešit při zachování rychlosti? Fixed point je kolikrát pomalejší, protože je děláno nad běžnými registry. A FPU zatím co vím nemá podporu fixed point (nebo aspoň ne na úrovni jazyků)

za mě: zachovat FP a používat ho (klidně i jako fast-math), ale je dobré dopředu vědět, co to může způsobit a kdy můžou být problémy a kdy nikoli. Třeba kladná/záporná nula, to se může hodit, práce s NaN v 90% mých programů stejně nenastane :-)

Připomíná mi to jeden problém, který se řešil před asi 15 lety na Aldebaranu a ukázal se značně netriviální kvůli zmiňovaným problémům - autor se jestli si dobře vzpomínám pokoušel simulovat nějaký složitější systém, ten mu dával zjevné nesmysly, tak postupně dospěl až k úplně primitivní numerické simulaci oběhu jediné planety kolem hvězdy podle Newtonovy mechaniky, a pořád nepříliš snadný problém, jak vůbec dosáhnout toho, aby se po oběhu planeta vracela do stejného místa se stejným vektorem rychlosti.

jakou používal integrační metodu?

(protože to spíš vypadá na nestabilní numerický výpočet)

btw toto je zajímavé video https://www.youtube.com/watch?v=nCg3aXn5F3M

25. 2. 2026, 20:59 editováno autorem komentáře

A nebylo by lepší zapnout alespoň AVX2 aby ten výsledný kód dával smysl pro tuto dekádu? Podle mě dnes nedává smysl kompilovat pro SSE2.

urcite to jde zapnout (klidne i AVX-512, akorat dneska uz je teplo a nemusi se tak topit), ale ty problemy jsou principialni a zustanou tam.

Díky za super článek.

Říkám si, že některé ty optimalizace by mohl překladač udělat, i když o to není žádán. Například nastavování errno - tam je přece většinou vidět, zda hned po té operaci program čte errno. Anebo zda dělá něco jiného, co by to errno mohlo zase změnit. Pokud se errno nekontroluje nikde, lze ho bezpečně nenastavovat, ne?

teoreticky jo. Ale například se může překládat jeden soubor .c do svého objektového souboru (.o) a překladač v tuto chvíli ještě netuší, s čím vším se to bude linkovat. Protože až po slinkování bude jasné, jak se nějaká funkce volá atd.

> zda hned po té operaci program čte errno

On ho nemusí číst hned ale třeba o pár úrovní jinde. Tam už překladač nemusí vidět.
A autoři překladačů musí přemýšlet jinak než normální programátoři. Bezpečná optimalizace nesmí změnit chování ani v extrémně obskurních a nepravděpodobných případech. Pokud to errno někdo někde může číst a je nějaká větev, která ho nezmění, tak tam tu hodnotu zapsat musí.

Druhá věc je samozřejmě to, že errno je historický relikt. Je to špatně z mnoha úhlů pohledu, jen se ho nejde jednoduše zbavit.

Skrytější pasti: pokud se s fast-math zkompiluje jedna .so-knihovna, tak to může částečně ovlivnit i výsledky knihovny jiné, jen proto že jsou v nějakém programu (tranzitivně) použity obě. Výborně se to debuguje.

Praktický příklad: https://github.com/jedisct1/libsodium/commit/ad4584d45590654b9d863ced90d2b2561d5cfbda#commitcomment-129441988
Detailnější vysvětlení: https://trofi.github.io/posts/302-Ofast-and-ffast-math-non-local-effects.html

26. 2. 2026, 06:58 editováno autorem komentáře

Tyjo to je taky pěkná pastička. A s tím -Ofast má reviewer pravdu.