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.
Předpokládám, že se Intel, v rámci zachování morální integrity, velmi agresivně ohradí oproti výsledkům v Cinebenchi.
To záleží na tom, jaký z toho budeme mít pocit...
(Atom jadra) Chce se mi zvracet...
1) Cinebench je jediný benchmark kde se dařilo Dozeru, takže jeho vypovídací hodnota je takřka nulová :D
2) Atomy už nejsou takový sračky jako bývaly ty první in-order jádra v netbooku. Skylake měl 5x vyšší IPC než ten starý Atom. Cortex A72 v Raspberry Pi4 má 2,5x větší IPC než tyto staré Atomy.
3) Nové "Atom" jádra mají mít IPC na úrovni Skylake, což je mega skok.
4) Spíš jde o to, jak si povedou proti malým jádrům odvozeným od Zen4.
5) Stejně to všechno vydrtí ARM s jeho 2048-bit SVE2 vektory a 64-bit only CPU.
Kdyz tomu nerozumis, neztrapnuj se.
1) Cinebench je benchmark zalozeny na produktu, ktery se realne a casto pouziva, neni nic teoretickeho. Jeho vypovidajici hodnota je pro kazde CPU velka. Bulldozer tam dopadal dobre, protoze to byla dlouhodobejsi uloha, jednotlive casti jsou relativne nezavisle, a je mozne dobre je paralelizovat, takze zadna slabina Bulldozeru (slabejsi frontend, spatna predpoved vetveni, atp.) se neprojevila, naopak to, ze bez prehazovani to dokazalo zamestnat vsechny sub-jadra v modulech znamenala jeste i vyhodu, ze planovac widli do toho nehazel widle.
3) To je porad jeste dost pozadu. Jako majitel Skylaku muzu s prehledem prohlasit, ze dneska bych do toho nesel ani za zlate prase.
4) Ocekavam, ze z pohledu IPC cca na 50%, z pohledu celkoveho vykonu na podobne urovni, protoze "mala" Zen4 jadra by IMHO byt stejna co se tyce IPC jako velka, ale optimalizovana na nizkoenergeticky beh na vyrazne nizsi frekvenci. Napr. 50% f => 30% W oproti "velkemu" Zen4 jadru.
5) ARM s 2048-bit SVE2 vektory a 64-bit only CPU, nikomu nic nenatrhne. Ani jedna z tech ficur neznamena nijak velke zvyseni vykonu skze cele spektrum, jen v okrajovych situacich.
2048bit vektory na ARMu maj výhodu spíš obrácenou: Až vyjde CPU s více fyzickými bity, tak na něm *stávající* software pojede rychleji. Ne jako situace v x86, kdy žádný procesor od AMD a půlka procesorů od Intelu nemá AVX-512, s tím že u Intelu většina má výkon v AVX-512 stejný jako v AVX-2, protože spojí dvě 256bit AVX2 jednotky. Pak pro výrobce softwaru nemá smysl dělat codepath pro AVX-512 a vy jako uživatel jste jen vyhodil peníze (obecně x86 v budoucnu budou jen vyhozené peníze, pokud to nemáte na historický software - např. já mám doma na hraní Pentium 3 s Voodoo 3 na starý hry a Apple iBook G4 s PowerPC).
EDIT: "ARM s 2048-bit SVE2 vektory a 64-bit only CPU" -- Tam je na ARMu výhoda, že ten software pojede. Ne jako na Intelu, kdy odfláknutá malá jádra blokují snížení spotřeby vypnutím *všech* velkých jader.
Jak by rekli anglicane... "Ok, i'll bite. HOW?"
Mezi vyhody SVE2 se zminuje rychlejsi vyvoj a mensi cena vyvoje. A ze neni potreba prekompilovavat kod. Jak to zlepsi naprostou vetsinu aplikaci?
Zaroven SVE2 dovoluje efektivni zpracovavani velkych dat, takze neni potreba na to specialni akcelerator. Znovu, jak TO zlepsi vetsinu uzivatelskych aplikaci?
Jako bude super moznost spustit si nejakou "crunching" serverovou aplikaci na mem desktopu, ale jak to pomuze nejenom BFU, ale i lidem, co pouzivaji pocitace k bezne praci, tzn. virtualizace/kontejnery, kompilace, transcoding (tam asi hadam, ze to bude mit naky vliv), atp.?
Na uživatelský aplikace ti stačí 4 malá letitá in-order 64bit ARM jádra. Všechno tam jede a bude tě brzdit spíš málo RAM a pomalé úložiště. Pokud si chceš připlatit za uživatelský komfort (rychlost UI), tak potřebuješ co největší singlethread výkon (tady vede Apple se svými velkými čipy s velkou cache, velkým re-order bufferem a výhodou ARM, že i dekodér instrukcí může být libovolně rychlý). BFU na desktopu (notebooku) pomůže nízká spotřeba a dlouhá výdrž na baterii. Pro workstation použití ARM samozřejmě umí virtualizaci/kontejnery/kompilaci/transcoding.
Apple vede u uzivatelskeho komfortu nikoli rychlosti, ale implementaci QoS a nastaveni ji tak, ze prave odezva systemu je predrazena vypoctum.
Moje otazky byly k SVE2, nekteri to zde prezentuji jako druhe vanoce (neplest si s druhym prichodem krista), ale ja se ptam, jak to tedy zaclouma s trhem, jak HW podpora SVE2 vykresa nejaky razantni skok ve vykonu?
Apple to tak dělá už od dob "classic" MacOS (<= 9). Co v tom ostatním brání? Jinak čipy Applu jsou větší než konkurence (větší cache, buffery, ...), protože nemusí platit marži middlemenům prodávajícím svoje SoC.
Skok ve výkonu na mainstream mobilech a počítačích nečekej, protože hardwarový počet bitů zůstane, co předtím. Ale odemkne se výkon těm, co ho chtějí/potřebují. Těm, co si připlatí za highend mobil nebo workstation desktop/notebook.
Jako vývojář už nebudeš řešit, jaký instrukce na vektorové operace použiješ - a je jedno, jestli je tvůj kód původně pro hodinky nebo nejvýkonnější počítač na světě. Porovnej s x86: 1) Použiju instrukce pro lowend a na highendu to nepojede o tolik rychleji, o kolik by mohlo. 2) Použiju instrukce pro highend a na lowendu to nepojede. 3) Použiju oba typy instrukcí a musím udržovat více codepath. Navíc potřebuju na vývoj highend hardware, kde jsou oba typy instrukcí. U ARM stačí např mobil s Androidem, připojím monitor, klávesnici a myš, pustím desktopový OS s plným vývojovým prostředím (např Termux app s grafickým Linuxem), napíšu a odladím aplikaci a pošlu *binárku* někomu s 256jádrovou workstation nebo nahraju na výpočetní server v cloudu a jde to plným výkonem všech dostupných bitů.
"odladím aplikaci a pošlu *binárku* někomu s 256jádrovou workstation"
To jako chces rict, ze podpora SVE2 znamena, ze dokaze jeden velky vektor rozpadnout a poslat na treba 256 jader? Zatimco kdyz mas system jen se dvema, tak ho vykonavaji jen 2 jadra?
Až o 8% lepší výkon u pochybného atomového hřebíku z dílny MS :/ Asi mne stále víc zajímá nakolik bude z Windows 11 těžit normalní Ivy Bridge či Haswell než ultramobilní slepenec s atomovými jádry .....
Však to je příprava na Adler lake
Alebo budú konečne optimalizované na Zen. Z pohľadu X-boxu to dáva zmysel
Nebo je to příprava Win scheduleru na vlastní ARM jádra od MS.
Ruku na srdce, x86 je stará sračka co už měla být dávno v křemíkovém pekle.
V momentě kdy MS, Amazon a Google si můžou koupit levnou licenci na 64-bit only CPU jádra s 2048-bit vektory a mnohem vyšším IPC, tak x86 umřelo.
Největší sranda je, že to nové miniaturní Little jádro Cortex A510 má jen 64-bit FPU, ale umí spočítat i vektory pro 2048-bit SVE2 FPU. To je naprosto zabijácká a revoluční kompatibilita, kterou neměla nikdy žádná ISA v historii. Stejné vektory bude umět lednička i super počítač. x86 nemá kromě AMX vektorů nic. A i ty AMX jsou jen další přílepek k AVX512.
Neblábol.
umí ale software je velmi konzervativní, proto se drží kompatibilita a kvůli tomu jsou Win pořád na špici oblíbenosti. Na to žádný unix, linux ani Mac nemají. Na jednu stranu je to přítěž ale na druhou ohromná výhoda.
Tak ta kompatibilita Windows je omezená (stejně jako třeba MS Office). V mým případě např. nefungují staré hry pro starou verzi DirectX. Ne každá má patch pro Win10, takže musím použít wrappery, trippleboot, virtualizaci a emulaci. Emulace API je větší problém než emulace x86 (tam je problém jen výkon, a to jen u některých aplikací a her).
V nejnovějším rozhovoru s Jimem Kellerem na Anandtechu pěkně Keller popisuje, že x86 musí mít prediktory pro délku instrukcí a tedy říká že x86 má obrovský problém s paralelním dekodování instrukcí když se predikce netrefí.
Tady si nikdo neuvědomuje, že x86 z principu nemůže zahodit 16-bit a 32-bit kompatibilitu jako to udělal ARM, protože i v tom 64-bit módu by furt muselo obsahovat ten největší problém - odporné CISC kódování s variabilní délkou instrukce od 1 - 15 bajtů.
Sice by x86 mohlo zavést nějaké nové instrukce s tagy/odkazy na začátek každé 4-té instrukce.... jenže to by zhoršilo hustotu kódu tak moc, že by se ztratila výhoda úspornějšího CISC kodování a zároveň by zůstalo spekulativní žravé dekodování těch 4 instrukcí. To je jako se snažit udělat z rezavé Felicie závodní Formuli 1. To už je lepší se na to vykašlat a přejít rovnou na RISC když už vnitřně to stejně jsou RISC stroje.
1) Intel pracuje na odstranění 16bit podpory v jeho CPU (32bit asi v týhle dekádě nezmízí). PC tak přijde o tu proklamovanou kompatibilitu (už nespustím staré OS). Předpokládám, na výkon dekodéru instrukcí to nebude mít skoro žádný vliv (rozdílná délka je i u 32bit a 64bit instrukcí):
https://arstechnica.com/gadgets/2017/11/intel-to-kill-off-the-last-vesti...
2) "To už je lepší se na to vykašlat a přejít rovnou na RISC" -- Možná bude, aspoň vedle hlavního byznisu okolo x86. Něco jako být připraven, kdyby x86 umřelo:
"Rumor: Intel May Buy RISC-V CPU Designer SiFive to Fend off ARM"
https://www.extremetech.com/computing/323647-rumor-intel-may-buy-risc-v-...
No a otestovali se ty nove widle i na notasu podobneho TDP jako ma Lakefield i s AMD cpu?
Treba je to jen o tom, ze W11 obecne lepe hospodari s energetickym stropem a dovoli tedy lepsi takty.
Bez te informace to muze byt clanek uplne o necem jinem :D
Jak rikaji mechanici motor/objem jednoduse neoklamete, cili muze mit ten pojebanej Alder Lake i 24 jader, i tak si radsi vyberu 16 jaderne AMD kde mam ta jadra plne vybavena cili sobe rovnocenna a nemusi tak jit pod svou uroven jenom proto ze jine jadro je mensi a tudiz osekanejsi, intel namisto toho abu udelal cipletove 8/16 jadro pri rozumnich taktech a TDP jde cestou dalsiho vojebu, co se tyce Windows 11, jenom dalsi update pro Windows 10, pocitam ze cikani z Indie to promakaji a co dalsi rok to nova cislovka Windows, v tomhle urychlenem stylu dnes jede Chrome a Firefox...
No uz i tedka na Ryzenech mas nejaka jadra tzn. "zlata", ktera dokazi drzet boost lepsi a delsi dobu napr.
A podle toho co jsem slysel, tak koncept pro dalsi generace Zenu bude v tom, ze jadra budou mit sice stejne schopnosti (capabilities) co se tyce instrukci atp., ale budou optimalizovana na ruzne frekvence, takze bezne vyrazne pomalejsi. Ja si to predstavuju tak, ze tam bude 8 jader schopnych dobre zvladat frekvence 4.5-5GHz, s tim, ze boost je dostane na 5.x. A pak tam bude 8 jader, ktere optimalizovany a budou bezet pekne na 2-3GHz a zrat o 30% mene, nez kdyby se ty "silnejsi" jadra jen podtaktovaly.
Jinými slovy jde se cestou ARMu. A až bude odladěný scheduler ve Windows, tak switchnem i architekturu CPU.
Přesně. Však MS už připravuje vlastní ARM CPU pro notesy a servery....
Už několik let masivně přijímá nové HW inženýry, takže je jen otázka kdy.
Nový ARM Cortex X2 s IPC cca 20-25% nad Zen3, 2048-bit vektory SVE2, L4 cache sdílená s GPU, navíc letos zahodili 32-bit kompatibilitu .... to je prostě paráda.
Ne, to skutecne neni cesta ARMu.
ARM je uplne jina instrukcni sada ;-) A cestou ARMu jde spise Intel, ktery pouzije jine jadra, ruzne architektury a ruzne ficury.
Instrukční sadu zatím neřešíme. Bottleneck je zatím scheduler Windows, který měl problém si v minulosti poradit i s EPYCy. A to byl x86 a všechna jádra byla stejná. Jinak ARM vždy měl stejné instrukce (architekturu) na malých i velkých jádrech. Aby nebyl žádný problém přehodit úlohy z velkých na malá. Jenže to Intel nedokáže, ten jen lepí, co se dá - proto je potřeba hardwarová asistence scheduleru, aby to vůbec nějak chodilo.
Přesně tak. x86 chce jít cestou ARMu s Big.Little ale tak nějak zapomnělo připravit alternativu k SVE2 vektorům. Sdílená 64-bit FPU pro dvě malá jádra v Cortex A510 bude je SW kompatibilní s nějakým 2048-bit monstr CPU co přijde v budoucnu.
Nadruhou stranu ani SVE2 nemůže mít v big.Little různě dlouhé registry FPU, kvůli context switchingu, tedy jak malá tak i velká jádra musí mít stejnou např. 128-bit HW FPU.
ARM to u malých jader řeší sdílenou 64-bit FPU mezi dvěma jádry, zatímco velká mají 4x128-bit FPU.... tedy rozdíl ve výkonu je 16x. To je víc než dostatečné, zejména když díky SVE umí obě varianty chroustat SW napsané pro 2048-bit vektory. To je geniální....
To si lehce nepochopil, tím že to není monolit, tak si AMD může dovolit každý modul taktovat nezávisle. Takže ano jsou tam zlatá jádra na které by měla být přednostně přehazována jednojádrová zátěž, protože třeba místo 4,6 dokážou běžet na 4,7 GHz, takže žádné ultra pomalejší jádro se nekoná, spíše je to o tom že CPU ví které jednotky dokážou držet vyšší rychlost a sami se přetaktují nad oficiální specifikaci.
AMD si muze dovolit kazdy modul, kazde jadro taktovat nezavisle uz tedka.
Zrovna tedka jsem mrknul do Ryzen Masteru a v mem jednom CCD je stav nasledujici:
C #0 1247MHz
C #1-5 sleep
C #6 450MHz
C #7 sleep
A docela to skace, ale co je dulezite je, ze ty kecas z hladu, nebo nevedomosti ;-)
CPU TDP: 13.47W
Co jim ale chybi je dalsi optimalizace v dosazeni TDP stropu. Kazde architektura dosahuje maximalni efektivity (vykon/watt) v jine frekvencni domene. Nektere vali perfektne na 1.5GHz ale kdyz je pretaktujes, tak zacnou zrat jak cerna dira. Nektere zvladaji idealne frekvence 4GHz. Tim, ze ty jadra budou stejne ISA, ale jina implementace bude moct AMD bez problemu zavest QoS, a neco nechat vykonavat ty pomalejsi jadra a usetrit tak mnohem vice, nez kdyz tedka musi velka jadra presouvat to power stavu, ktere pro to jadro nejsou optimalni.
1.8% multi a 8,2% single stačí keďže vieme, že drvivá väčšina userov si kupuje cpu aby na nom spúšťala Cinebench R23 a aplikačný výkon neriešia.
on je trochu problem inde.
Na W11 sa zlepsil vykon aj inych procesorov.
Vysledok na cpu AMD Athlon64 2x 7750 BlackEdition s 4GB ddr2 800 mhz v aida a cpu-z na win 11 a win 10:
https://postimg.cc/bDRY2dBx
su tam rozdiely od 8% v testoch na OS.
cize na modernom CPU by to cosi spravit malo.
tak v cpu-z a aida64 je rychlejsi win11 (leaknuta verzia) aj na AMD Kuma. Testy pri praci s RAM v priemere 15%
v CPU Queen od 8 do 11% v Zlib o 13-13,5%
a hlavne je zostihlene jadro (kernel32.dll cca o 20%) upravena HAL a nie je tolko spustenych procesov na pozadi.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.