Názory k článku Podpora numerických hodnot typu quadruple-precision floating-point v GCC

Pro zajímavost číslo π v quad přesnosti: https://marekknapek.github.io/quad/#?n=0x4000921fb54442d18469898cc51701b8

Díky za doplnění.

Jak moc je to pomalé vůči float nebo double? Odhadem tak minimálně o řád, že?

(jinak toto je na C pěkné, že rozšíření o další typy jsou prakticky "zadarmo". Třeba do Go se to asi nedostane nikdy... :/)

Proč se to do Go nedostane nikdy?

no zatim se brani i pridani float16 a bfloat16 a vlastne co se tyka ciselnych typu, tak je Go takove moc uzavrene do minulosti. IMHO to tam nepridaji.

Nebude pokracovat serial o C3?

Jestli je zájem, já bych osobně rád v psaní pokračoval.

A/nebo TrapC?

zkusit muzu, ale je to uz production ready? Co jsem to kdysi zkousel, tak IIRC mi to ani neslo prelozit ;)

Bejvávalo.

brave://leo-ai/9bafa66d-9ace-4288-b4eb-cb16aeef4c00

Jasne ze je. Ten jazyk vyzera skvelo.

tak jo, doufejme, že už příští týden :-)

Nazdar! Prosim te, pro nas pomalejsi: risc-v ma na praci s temito "rozsirenymi" decimal typy specialni instrukce,a gcc je pouziva?
Ovsem intel ne. a dochazi tam bud k emulaci, nebo se se proste pouzije "obycejny" decimal, nebo "rozsireny" ? S tim ze gcc tam pouze vola tu emulaci a ta si rozhodne co delat pozdeji?

Ptam se, protoze na jedne strane pises ze intel a dalsi to maji podporovane, ale na druhe strane jen u riscu zminujes instrukce. U intelu zminujes "ze se tam cosi vola". Navic internet (pri heldnai vykonu techto vypoctu jak se tu kdosi ptal), tvrdi, ze quadruple-precision floating-point typically ma 4x - 60x pomalejsi vypocty nez double-precision (64-bit) `due to lack of native hardware support on most CPUs` .

A jak je na tom slavny aarch64? Diky!

Pokud není HW podpora v CPU, tak může být podpora v novém mikrokódu CPU nebo překladači zdrojových kódů (jako v dávných dobách byla např. SW emulace FPU). V případě C/C++ může překladač rozhodnout použít horší přesnost, aby to bylo aspoň trochu rychlé, protože specifikace long cokoli akorát říká, že to má být delší (nebo rovno?) než verze bez long.

4. 3. 2026, 15:25 editováno autorem komentáře

Pokud to umi mikro kod, nazval bych to s klidnym svedomim podpora na HW. Protoze to umi "ten cip s tim nahranym microcodem". A tedy a halvne - pro prenositelnou binarku je to pak jedno - ta zavola instrukci, a procesor si s itm rychleji nebo pomlaleji poradi.

Koukam aarch64 to nativne zda se taky nema. Ale pisou "emulovano softwareove", cimz zda se nemysli microcode. Tak uz jsem plne zmatenej a vede vlastne k te me prapuvoidni otazce... @tisnik , nedelej mrtvyho brouka!-)

Zdar, no my taky musíme pracovat, na rozdíl od vás ve Velké modré :-)

Je to takto: ten typ __float128 je podporovaný z pohledu C (!!!) jen na některých platformách, ale patří sem i Intel, ARM i RISC-V (takže většina světa je s tím v pohodě, na druhou stranu to ovšem nepojede řekněme na M68k). Ovšem podpora v tomto kontextu znamená, že to můžeš použít ve zdrojácích. Interně se to bude počítat čistě v SW voláním subrutin (to bylo v tom assemblerovským výpisu). Pokud vím, tak jen na RISC-V je ten typ podporovaný nativně, tj. například __float128+__flo­at128 se přeloží do jediné instrukce.

Ono taky se už pár let neprogramuje v assembleru. Takže proč prodražovat hardware. Mimochodem zrovna ARM už v počátcích řešil to, že kompilace C/C++ prokládala load operace s ostatními, protože trvaly 2 cykly, tak aby byly "za jeden cykl" tím, že je udělá o 1 cykl dopředu. Tedy už v počátcích ARMu by musel assembler programátor řešit věci specifické pro danou platformu (tehdy aby měl výkon). x86 je víc highlevel a nemusel a víc toho řešil sám uvnitř v mikrokódu.

Ta podpora nemá až tak moc s assemblerem moc společného, řekl bych. Spíš se nikdo nenamáhal s přenosem těch subrutin na méně používané platformy.

Mene podporovane platformy? jako intel a aarch64?-)

x264
x265
x266

Big Blues

Je to emulovano softwarove, mikrokod x86-64 toto aktualne neda ze dvou duvodu: za prve na to nejsou k dispozici/v dosahu 128 bit registry (rax atd. nejdou skladat po dvojicich, FPU ma 80 bitu, SSE... nejsou dotazene k FPU) a za druhe FPU aritmetika je 80bitova a jeji rozsireni na 128 by potrebovalo docela dost kremiku navic (predevsim gon. fce apod.) - mikrokodem rozsirena presnost mantisy je vzhledem k moznostem mikrokodu nerealna.
SW emulace napr. v gcc pouziva libquadmath knihovnu, kde funkce sleduji pattern:
1. Natahnuti operandu z pameti do dvojic 64-bit registru (treba rdx:rax)
2. Dekompozice znamenkoveho bitu, exponentu a mantisy v prac. registrech
3. Provedeni operace (treba u scitani komparace exponentu, shift mantisy, soucet, vypocet exponentu, normalizace
4. Repack znamenka, exponentu a mantisy do 128 bitu
5. Ulozeni do pameti
Treba takova sw emulace i jen scitani __addtf3(__flo­at128, __float128) se vsemi pozadovanymi zaokrouhlenimi, NANy, +/- zero atd. spotrebuje nekolik set instrukci, takze muze byt az cca 100x pomalejsi nez double add v FPU.
Jeste horsi je to u goniometrickych funkci, kde je to postaveno na tabulkach a vypoctu Cebysevovych polynomu (a tady to dost brzdi docela dost soucinu 128bit * 128bit).
Ale existuji i ruzne "triky", např. takova odmocnina si prvni odhad vypocita v FPU v double a zbytek se dojede iterativne Newton-Raphsonem.

https://www.righto.com/2026/02/8087-instruction-decoding.html