Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Tak ono nebudú medzi kompilátormi rozdiely ako v minulosti
https://www.phoronix.com/review/amd_6800k_compilers
https://www.phoronix.com/review/apple_llvm_gcc
a už vôbec nie ako s open64 t.j. predchodcu AOCC
https://www.phoronix.com/review/llvm3_gcc_open64
ale aj tak je to málo
Zajímalo by mě i srovnání jak si AMD AOCC 4.0 a Clang 14 vedou na procesorech od Intelu (hlavně moderní Xeony). Dá se předpokládat, že celkově vylepšili optimalizace a generování kódu, tak i tam by mohlo být znatelné zlepšení výkonu.
Ve firemním prostředí je dost často k dispozici jen jedna binárka, která musí běžet na nesourodé směsi mašin různého věku od obou výrobců procesorů (dev, CI, QA a prod prostředí se neupgradují ve stejný čas).
Nakonec by bylo fajn, kdyby AMD zaintegrovala svoje optimalizace zpět do LLVM, pokud si tedy nenapsali kompletně nový back-end kompilátoru.
Otázky:
1) je to opensource?
2) má to nějakou standardní free licenci ala GPL nebo BSD?
vysoko pravdepodobne tipujem, ze ano. ono taketo "debilne" riesenia vznikaju preto, lebo firmy chcu *kvalifikovane* nastroje. kvalifikovane prekladace, kvalifikovane lintery, kvalifikovane staticke analyzatory, kvalifikovane vsetko. tak AMDcko patchlo llvm, urobilo nanho kvalifikacny proces a formalne nieco garantuje (napriklad nejake zrychlenie pri nejakych algoritmoch). no a vyda to. podobne existuje napriklad ARM-GCC pre Cortex M, co je vlastne +- nejaka konkretna verzia GCC zostavena priamo ARM Ltd. Asi to nebude o nic lepsie, nez ked si niekto upecie multi-libove GCCcko doma. Ale je kvalifikovane. A keby nejaky korporat s niekym nieco riesil, jedna z prvych otazok bude: pouzili ste ten nas toolkit s niektorym z kvalifikovanych prekladacov? Nie? No tak to je smola, my vas problem riesit nebudeme.
edit: je dost mozne, ze cely ten kvalifikovany prekladac je v skutocnosti realne pouzitelny len na nejake hodne regulovane procesy. napr. moze byt nevyhnutne ho pouzit pri pisani SW do jadrovej elektrarne, lebo nejaka regulacia bude vyzadovat, aby bol cely SW stack kvalifikovany.
Nebo samoriditelna auta, ci obecne ridici SW pro auta, letadla, ....
To nebude pripad tohto kompilatora. Je dostupny len na Linuxe. Linux nikto sudny (okrem SpaceX, ale oni zrejme neriesia kvalifikaciu) do riadenia nepusti. Tam sa pouziva QNX, alebo VxWorks.
Důvod použití QNX bude asi někde jinde ...
Nebo samoriditelna auta, ci obecne ridici SW pro auta, letadla, ....
Kdyby dali usili do zlepseni GCC/LVMM tak by udelali lepe. Takhle to skoro nikdo nebude pouzivat stejne jako se nepouziva icc Intelu, ktery je "na trhu" uz nejakych 20 let a az na cast baliku v Void Linuxu tim nikdo nic pro bezne lidi nepreklada.
Tohle je vylepšené LLVM.
Není, toto forknuté LLVM a hacknuté tak, aby dávalo na AMD nejlepší výsledky.
To je něco úplně jiného než vylepšit původní projekt (který pochopitelně chce, aby to mělo co nejlepší výsledky na *všech* platformách...).
Stejná zhovadilost, jakou dělají výrobci, že si forknou linuxové jádro pro nějako embedded aplikaci a zbastlí ovladač pro periferie, které ještě v jádře nejsou. Samozřejmě ale pak "nevrátí" kód do jádra, takže se situace vyvíjí tak, že v tom jejich zařízení zůstane jádro, které velmi rychle zastará, nabere bezpečnostní chyby a v normálním jádře chybí ten ovladač. Prostě normální korporátní paskvil...
Tak oni tvurci LLVM asi vedeli, proc to davaji pod BSD a pak Apachem...
Coz je mimo jine celkem rozdil proti tomu Linuxu.
Jinak ja mam samozrejme radeji, kdyz se vraci do upstreamu, ale je potreba si uvedomit, ze za uspechem LLVM m.j. stoji to, ze licencovali dost pratelsky vuci korporatum, aby se mohly rozhodnout, co tam pak poslou a co ne.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.