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.
> Situace trochu připomínala procesory Skylake, jejichž errata již v době uvedení obsahovala 53
>bodů a jen o půl roku později se rozrostla o dalších 40.
To je nejak málo Errarta obsahujú pri vydávaní okolo 200-300 známych chýb so SW opravou, tých 40 to asi budú neopravené chyby
Ono ten testovací komplex je aj u AMD dosť veľký
https://www.youtube.com/watch?v=7H4eg2jOvVw
Myslim, ze vetsi pecka je ted, ze ORACLE do svych stroju bude ted misto Intelu pouzivat AMD...
https://www.techpowerup.com/310789/oracle-to-spend-billions-on-nvidia-da...
https://www.svethardware.cz/oracle-sazi-na-cpu-od-amd-a-ampere-intel-uz-...
Tohle bude Intel asi hodne bolet..
ORACLE, to jsou ti zoufalci, kteří by bez RHELu nedali ani ránu?
Ja myslim, ze nejaky RHELu je uplne jedno...
POkud Intel ztratil/castecne odesel tak vyznamny obchodni partner, tak je to pro Intel docela rana.
Jen houšť a větší kapky :) Třeba se Intel konečně chytne za nos a něco vymyslí, ne jen samý marketingový pohádky.
To by bolo veľmi zlé keby sa chytil za nos až teraz
11. 4. 2018
Mike T. Clark, šéfarchitekt Zenu, v rozhovoru uvedl, že již pracuje na Zen 5. Jde vůbec o první zmínku o architektuře páté generace, která od AMD přišla…
https://diit.cz/clanek/architekt-zenu-zminil-vyvoj-zen-5
a tento Zen 5 bude na trhu v 1. polovici roku 2024
https://diit.cz/clanek/zen-6-bude-existovat-i-ve-2nm-verzi-kodove-oznace...
teda po 6 rokoch vývoja ladenia výroby
medzi Bulldozer a Zen bolo bez 5 dní 5,5 roka (z toho cca. 4-4,5 vývoj a 1-1,5 rok ladenie výroby
https://www.amd.com/en/press-releases/AMD-Ryzen-7-2017mar02
https://ir.amd.com/news-events/press-releases/detail/32/amd-ships-first-...
Ak by začal Intel robiť niečo teraz, výsledky bude mať na prelome rokov 2028 a 2029
Vzhledem k soucasne situaci u Intelu je to celkem realne datum first launch a availability 2030. ;-)
Predovšetkým je to rana na:
1. povesti Intelu
2. oveľa viac firiem bude rušiť deoptimalizácie pre AMD, čo pridá AMD 20-300% výkonu v aplikáciách ako je Matlab https://www.techpowerup.com/261241/matlab-mkl-codepath-tweak-boosts-amd-...
A tým bodom 2 spôsobia znovu 1, čím spôsobia 2 a viac predaných Epyc-ov
Kdysi jsem slyšel o optimalizacích na software na CPU Intel použitým kompilátorem či podobně jako tady, ale čekal jsem, že je to minulost nebo aspoň hodně vyjímečné.
On ten samotný kompilátor byl laděný na Intel.
Výsledek kompilace pro Intel.
To až poslední dobou (po příchodu Ryzen) alespoň GCC začalo zkoušet nějaké úpravy pro AMD.
Intelí kompilátor na to z vysoka kálí a jinak to dělat nebude.
Jak jsem několikrát psal, nejsem programátor. Ale čekal bych, že když už není kompilátor optimalizovaný AMD, bude aspoň universální, tak aby ani jedna strana moc neztrácela, toto je moc jednostranné.
závisí aký kompilátor
aj aká verzia
https://www.phoronix.com/review/amd-aocc-11
https://www.phoronix.com/review/amd_bulldozer_compilers
detto optimalizácie K8 je optimalizácia na AMD, p7 je optimalizácia na Intel
https://www.pgroup.com/lit/presentations/pgisc06.pdf
a parametre optimalizácie v rámci jedného kompilátora
https://www.phoronix.com/review/gcc12-optimize-threadripper
a ak je kompilátor vyrobený programátormi Intelu ako icc
https://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler
AMD verzia open64
https://en.wikipedia.org/wiki/Open64
čisto AMD-čkový AOCC
https://www.amd.com/en/developer/aocc.html
univerzálne ako GCC
https://sk.wikipedia.org/wiki/GNU_Compiler_Collection
či LLVM
https://en.wikipedia.org/wiki/LLVM
alebo Microsoft-ácke kompilátory
a mnohé iné - V tom. porovnaní je Portland kompilátor PGI
Ak ten program používa nejakú špecialitu jedného kompilátora, ktorá nie je v štandarde jazyka, takže to skompilujte len tým jedným kompilátorom, tak si nepomôžete.
Ak je to ešte knižnica, ktorú využíva viac programov, ako Intel MKL v tom Matlabe vyššie
https://www.intel.com/content/www/us/en/developer/tools/oneapi/onemkl-do...
alebo
AMD CML
https://en.wikipedia.org/wiki/AMD_Core_Math_Library
rep. teraz LibM a AOCL
V knižniciach sú časti kódu/funkcie jazyka predprogramované s nejakou optimalizáciu
Dřív se takové části programovaly nízkoúrovňově. Plácnu, třeba kombinací Pascalu (či jiného vyššího jazyka třeba Cobol, či Fortran) a Assembleru. Jak přibývalo hotových knihoven už nebylo tolik třeba. Ale to je asi hodně dávno.
ale aj v tom ASM musíte vedieť, ktorú podskupinu inštrukcií vie daný procesor a podľa toho spustiť vetvu optimálnu pre daný procesor, alebo univerzálnu verziu, ktorá beží síce na každom CPU ale reltívne pomaly. Univerzálna verzia sa použije vtedy, ak v kóde nie je optimalizovaná verzia pre Váš CPU
Pokud má ale někdo vlastní servery a na nich vlastní aplikaci, tak bych očekával lepší optimalizaci i pro AMD. Neříkám, že je to tento případ (Matlab), ale třeba pro velké instalace cloudu by to mělo být typické, totéž velké superpočítače. Kdekoliv je větší výpočetní výkon. U Komerčního SW záleží asi ne preferencích uvnitř programátorského týmu a nebo toho, kdo o ho řídí nebo platí. Jen na okraj Adobe je na tom s vícejádrovými CPU pořád tak blbě? Moc to nesleduju.
Tak to přesně je. (Velké) custom řešení je ohnuté na míru použité hardwarové architektuře. Komerční software je víc než cokoliv jiného univerzální - má běžet "normálně" na všem.
Samozřejmě existují i komerční aplikace, které umožňují běh optimalizovaný pro nějakou hardwarovou architekturu nastavitelný v konfiguraci (nebo kompilaci). Nicméně, mainstream to není.
Samozrejme,.
Ale tu je chyba práve v optimalizovanom kóde
>Bug, který způsoboval pády systému („přerušil činnost“), se projevil v systému neupřesněného
>zákazníka, jenž používal software na míru (nikoli komerčně dostupné řešení).
Samozrejme,.
Ale tu je chyba práve v optimalizovanom kóde
>Bug, který způsoboval pády systému („přerušil činnost“), se projevil v systému neupřesněného >zákazníka, jenž používal software na míru (nikoli komerčně dostupné řešení).
Abych to upřesnil Intel snad není jediný, kdo ve světě x86 vydává kompilátor. Nebo ne?
ale
1.nie všetko ide kompilovať inými kompilátormi
2. nie všetko chce alebo "chce" autor kompilovať inými kompilátormi
Existovalo to v intel math library. a vzniklo to tak, ze ta kniznica si pri starte podla znamych kombinacii CPUID steppingov zistovala, s cim ma tu cest. A podla toho si vybrala code path - hole bose CPU, MMX, alebo SSE. Samozrejme AMDckovymi steppingami sa nezaoberali, takze ako "nezname" automaticky padali do kategorie FPU.
Sideefekt bol, ze tam padali aj novsie procesory Intelov :>
Slo tomu ale forcnut, ktory code path si to ma vybrat, takze sa detekcia pre AMD dala dopisat.
Prekladac onoho casu obsahoval nejake svinstva, ktore boli known bad na AMD.
Ci dnes este niekto sudny intelacky prekladac pouziva, to neviem.
Chápu. Děkuji za info.
na poli OS nie, ale na poli databáza firemných riešení by sa zaobišli bez Red Hatu, akurát by neboli tak dobrí, ako sú
Co si budeme povídat, bez RH by nebyla půlka dnešních linuxářů ...
Ale ano, vybrali by si jiný GNU Linux projekt, který by díky nim vyrostl. Pokud by to ovšem nebyla forma Free BSD.
Bude to boet nejen Intel, AMD je sice ještě chvíli ve hře kvůli existujícím plánům s x86 platformě, ale: Oracle's database software has been updated to run on Ampere's Arm-based chips, Ellison posits that these grant greater power efficiency when compared to AMD and NVIDIA enterprise processors
Takže primárně je to o přechodu na Arm
A to se jim vyplatí dělat dočasné optimalizace pro AMD? Přece už teď mají mix ARM a x86-64, stačilo by jen měnit ten poměr. Ale pak by další objednávky u AMD nedávaly smysl. Jestli to spíš není tak, že obě architektury budou koexistovat a budou používané k jiným účelům.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.