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.
On ten posledni (a nejlepsi) Xeon Phi i kdyz byl na 14nm, tak ma z dnesniho pohledu strasne parametry:
1.5GHz bez AVX
1.1GHz v AVX zatezi
A spotreba 170w bez zateze, 230w se zatezi.
Na druhou stranu, umeli SMT4 :-)
Porad chcete atomy s AVX? A chcete jich rovnou 72? :-)
smt4 v x86 je ti na hov**, ak jadra maju kvalitny prediction.
https://www.zdnet.com/article/linus-torvalds-i-hope-intels-avx-512-dies-...
konecne pochopili ze je to kktina. :D
Chcem sa opýtať a toto všetko vypozoroval vývojár Sisoft pod Windows x64 10.0.21.1 a s detekciou hodnou ... cit. 12. generácia Intel Core i9-12900K 12. generácie Intel (R) Core (TM) i9-12900K (8C + 8c 32T) 4,88 gigahertz (GHz)/5,2 gigahertz (GHz), 3,6 gigahertz (GHz)/4,7 gigahertz (GHz) IMC , 10x 1,25 megabajtov (MB) L2, 30 megabajtov (MB) L3)? :-)
zdroj: https://ranker.sisoftware.co.uk/show_system.php?q=cea598ab92aa9da89fb9de...
P.S. čo sa týka malých atómových E- "Next"mont jadier tak veľmi správne ste sa chytil udičky prečo Gracemont v Alder Lake nepodporuje AVX-512 keď Xeony Phi, deriváty Larrabee postavenými na Atomech s podporou AVX-512 už ich podporovali.
No odpoveď je predsa veľmi prozaická keďže nateraz to bude stačiť na konkurenciu aj s atómami a so SIMD up to AVX2 a extenzemi známými z AVX-512 (VNNI/256, VAES/256, SHA HWA) pričom evolúciam ďalším "Next"mont-om nie je predsa všetkým dňom koniec veď nielen SIMD od Tremontu do Gracemontu pekne poskočilo. Alebo ľudovo povedané: načo sa vystrieľať hneď...
• Alder Lake - 8 velkých jader Golden Cove, 8 Atomů Gracemont; Q4 2021
• Raptor Lake - 8 velkých jader Raptor Cove, 16 Atomů Gracemont; H2 2022
• Meteor Lake - 8× Redwood Cove, ?× Crestmont; čiplety/dlaždice; Q2 2023
• Arrow Lake - 8× Lion Cove, 32× Skymont; Q4 2023
• Lunar Lake - ?× Lion Cove, ?× Skymont; 3nm TSMC; Q4 2024
• Nova Lake - ?× Panther Cove, ?× Darkmont; 2025
"No odpoveď je predsa veľmi prozaická keďže nateraz to bude stačiť na konkurenciu aj s atómami a so SIMD up to AVX2 a extenzemi známými z AVX-512 (VNNI/256, VAES/256, SHA HWA) pričom evolúciam ďalším "Next"mont-om nie je predsa všetkým dňom koniec veď nielen SIMD od Tremontu do Gracemontu pekne poskočilo. Alebo ľudovo povedané: načo sa vystrieľať hneď..."
@Tralalak: ano všichni víme jaký jsi velký fanatik co se týká malých jader, všechny ty Via čipy a Atomy a Jaguary a Bobcaty.... Když to nevyšlo teď tak snad ty příští "next-Mont" čipy už to konkurenci konečně pořádně natřou, což ? Možná ten Darkmont, to zní dost cool :-D
No, poslední dobou není "cool" od Intelu prakticky nic. A mám pocit, že i Tralalákovi se v palici přehřívá nějaký derivát. Nazvěme ho třeba Demont. :-D
hele není potřeba ho nijak urážet. Každý z nás fandí nečemu jinému, on má rád úsporná malá CPU a na tom není nic špatného. Co mě osobně udivuje je že i když mu někdo opakovaně dokazuje, že skutečnost není taková jaká on myslí že je, tak to naprosto odmítá přijmout a pořád se snaží najít něco, co by dokázalo opak. A když ne teď, tak doufá že ten přiští procesor/test to dokáže. Často pak pošle odkaz na nějaký článek, kde je něco vytržené z kontextu nebo je to pravda jen částečně a nechce si nechat nikým vysvětlit, že skutečnost je odlišná od jeho představ. Jako všichni děláme chyby a všichni se můžeme občas mýlit a člověk by si měl umět přiznat, že nemá vždycky pravdu.On si ale pořád tvrdí svoje a naprosto ignoruje co mu kdo říká a to už trochu hraničí se zaslepeností a fanatismem...v podstatě něco jako ten 6ALU RichieRich.
Hele x86 je mrtvý dinosaurus, ARM s SVE-2048 ho vydrtil už v roce 2018, je to jen agónie během úmrtí, budoucnost je v cloudu a mobilních telefonech, ne ve žravých PC a serverech způsobující dieselovou plastovo masovou klimatickou krizi!!!!
Vyborne, branka je de-gol, Tralalak je de-mont :-D
Hodne jsem se nasmal, dobra prace.
A čo ako nevyšlo s atómovými malými E- jadrami Gracemont ?
Že sa v mnohých testoch pod Windows 11 bude aj osem (8C/8T) atómových malých E- jadrier Gracemont samozrejme spolu s ôsmimi (8C/16T) corovými veľkými P- jadrami Golden Cove (Alder Lake 8C + 8c / 24T s 30MB L3 cache) pozerať do výkonnostného spätného zrkadla a uvidí tam 16C/32T veľkých Zen 3 jadier so 64MB L3 cache (2x 32MB). Wao tak tomu sa povie rečou del42sa, že to nevyšlo... :-)
2008: Bonnell
2011: Saltwell
2013: Silvermont
2015: Airmont
2016: Goldmont
2017: Goldmont Plus
2020: Tremont
2021: Gracemont
________________
*2023: Crestmont
*2024: Skymont
*2025: Darkmont
* v pláne preto som v predchádzajúcom príspevku použil výraz "Next"mont.
P.S. Ja som samozrejme zdravo sebavedomo za špecializáciu na malé jadrá, všechny ty VIA / Zhaoxin čipy a Atomy a Jaguary a Bobcaty.... právom hrdý pri čom ja chápem, že so zmenou paradigmi x86 big.LITTLE to mnohých diplomaticky povedané vyrušuje, že musia byť plnokrvníci veľké jadra na pomyselnej jednej lodi s tými malými, ale hold to sa volá okrem iného aj inovácie v danom prípade asymetrického multiprocessingu.
tímhle jen potvrzuješ to co jsem už napsal, že jsi zaslepený fanatik...
PS: "Že sa v mnohých testoch pod Windows 11 bude aj osem (8C/8T) atómových malých E- jadrier Gracemont samozrejme spolu s ôsmimi (8C/16T) corovými veľkými P- jadrami Golden Cove (Alder Lake 8C + 8c / 24T s 30MB L3 cache) pozerať do výkonnostného spätného zrkadla a uvidí tam 16C/32T veľkých Zen 3 jadier so 64MB L3 cache (2x 32MB)"
na tohle se vyloženě těším .-) takže už ne pod windows 10, ale hlavně pod windows 11 ? Tam to bude to pravé ořechové :-D
Pokiaľ je špecializácia na little core procesorových x86/x86-64 microarchitektúr od Centaur (VIA/Zhaoxin), Intel a AMD pre nejakých diskutérov/diskutéra obľubujúcich AMD alebo obľubujúcich len veľké jadrá Intel fanatizmus tak je to potom ich/jeho vnútorný problém.
Kedy už táto spoločnosť dospeje do štádia kedy vzdelanie nebude vnímané ako hendikep a slušnosť nebude apriori chápaná ako slabosť a absolútny nedostatok akýchkoľvek zábran nebude vstupenka so salónu ako je to dnes, ale bude to diskvalifikácia salónu unfair.
ne, specializovat se na malá jádra jistě samo o sobě není fanatismus, fanatismus je to jak naprosto nekriticky a odtržený od reality neustále hypuješ Alder Lake a pořád dokola opakuješ věci které zkrátka nejsou pravda. Nejdřív jsi začal na pctuningu a potom i tu psát silné věty ve stylu "šach-mat" jen na základě prezentací Alder Lake architektury a bez reálného podkladu, potom jsi tvrdil že v testu SiSoft určitě neběžela všechna jádra, a teď tvrdíš že ve windows 11 bude Alder Lake lepší....Všechno jen na základě vlastních doměnek a bez reálného podkladu.
Snaž se pochopit aspoň jednu věc, když to ostatní ti zřejmě činí problémy. Nikdo nemá nic proti big-little koncepci v desktopu, pokud se ukáže že bude fungovat lépe, než dosavadní dizajn CPU. Všichni jsme zatím zdrženliví v jakémkoliv hodnocení a skepse je rozhodně namístě, protože zatím nic nenaznačuje že by tomu tak bylo. Ty ale naprosto nekriticky oslavuješ produkt, který ještě ani není na trhu, šermuješ tady s čísly o velikosti cache a počtem threadů aniž bys tomu rozuměl, taháš do srovnání konzová APU a latence pamětí, mícháš všechno páté přes deváté dohromady a posíláš odkazy na články, které si ani nejsi schopný přečíst, abys všechny okolo sebe včetně sebe samotného přesvědčil, že to je nejlepší řešení.
Ja som stále konzistentný v tom čo píšem.
Vy mi stále podsúvate niečo čo som neuviedol.
Takže ešte raz a pomaly. Ak v mnohých testoch pod Windows 11 (kľudne aj v mnohých testoch pod Win 10 pre mňa za mňa berúc do úvahy, že samotný Intel deklaruje, že efektívne bude ich harwarový Thread director pracovať až s Win 11) bude aj osem (8C/8T) atómových malých E- jadrier Gracemont samozrejme spolu s ôsmimi (8C/16T) corovými veľkými P- jadrami Golden Cove (Alder Lake 8C + 8c / 24T s 30MB L3 cache) pozerať do výkonnostného spätného zrkadla a uvidí tam 16C/32T veľkých Zen 3 jadier so 64MB L3 cache (2x 32MB) tak nebude to ŠACH MAT, že to dosiahol procesor SoC big.LITTLE aj s ATÓMAMI.
Celé to však stále otáčate na výkon pričom v celej diskusii na pct fóre sa snažím argumentovať, že práve tie atómové malé E-jadrá Gracemont majú v celom koncepte SoC big.LITTLE úplne inú úlohu ako performance tj. výkon, ale práve efektivitu atď.
Ale Vy si idete stále svoje...
A tu efektivitu počítáte z Intelem uváděného "TDP" nebo skutečné wattáže?
A výkon berete v úvahu těch prvních 56 sekund Intel (R) Benchmark Cheat Boost (TM) nebo i po něm?
V jednom odstavci zmiňujete "výkonnostné spätné zrkadlo", abyste to hned v dalším najednou popíral a přehazoval na "efektivitu". Zkuste si to v té hlavě trochu srovnat...
Co nechápu je ta myšlenka, že Golden Cove má vůči Zen 3 větší náskok, než Zen 3 vůči Gracemont (ještě navíc v 16 vláknech u Zenu 3 proti osmi vláknům v Gracemontu). Protože jinak by to, co píšete, nebylo možné.
@Tralalak: pochop konečně, já nemám nic proti Alder Lake a klidně bych si ten procesor používající big-little osobně vyzkoušel, je to zajímavý koncept a souhlasím, že v desktopu jde o něco nového.
Co mě ale vadí je to nesmyslné vyhypovaní toho produktu předem, bez reálného podkladu, dávaní prostoru doměnkám a prezentovat je zde jako fakta a také zavírání očí nad nedostatky toho řešení, které prostě jako každý výrobek Alderlake taky má.
Tak se pokus zbavit se toho biasu který tvoje přispěvky obsahují a názoru že malá jádra nutně "spasí svět" a pak snad budeme moct konečně normálně věcně diskutovat.
Nechápem, niekedy som bol rád za tvoje príspevky ale niečo sa stalo.... Intel vydáva nový produkt, nová architektúra, nový koncept, samozrejme že by mal dohnať alebo možno aj predohrať AMD, Zen už je tu nejaký rok.... Veľké jadrá Alder Lake vyzerajú dobre, sigle výkon bude istotne super. Ale veď mali na to more času, Zen ich trápi už dlho.... len ten BigLittle koncept uvidíme, že či zafunguje, jedna vec je teória, druhá vec je reálne fungovanie v dostupnom softvéry...
Vyjadril som sa k tomu už xy-krát žiaľ nemôžem to vypisovať do každej diskusie a zrejme si to len nezachytil.
V AMD po estráde s Bulldozerom (tj. stavebnými strojmi) avšak v tej dekáde aj výbornými malými jadrami Bobcat, Jaguar (tj. mačkovitými šelmami) pochopili to čo Intelu nedochádzalo, že postaviť veľké(malé) jadro sa dá len od začiatku na to treba ísť úplne inak tj. zobrali to najlepšie DNA z oboch microarchitektúr stavebných strojov a mačkovitých šeliem a od "podľahy" namiešali tu správnu alchímiu výbornej microarchitektúry Zen v podobe procesorov Ryzen atď.
Inými slovami AMD po rokoch totálne zamiešalo kartami. Intel mal v tom čase a priestore mali rozpracované svoje architektúry. V Intel si to Zanalyzovali si to podľa simulácii a roadmap Zen (+,2,3,4) zaznela určite v miestnosti hláška typu "Okay, Houston, we've had a problem here".
Bavíme sa niekedy 3-4 roky dozadu. Intelu bolo jasno, že s poukazom na ich výrobné procesy (litografie) v vlastných továrňach sa karta obrátila ne nedarí sa im voči konkurencii TMSC atď. držať krok s čím súvisia limity. K "okrúhlemu" stolu povolali všetky teamy, ktoré mali rozpracované microarchitektúry a samozrejme aj team zodpovedný za litografie (výrobný proces) a vyšlo im v danom čase a priestore jediné: big.LITTLE.
Vymačkáme z P-corov maximum pričom E-cores to budú krotiť avšak len tam kde to reálne dokážu tj. nie do peakov a hlavne big.LITTLE tj. tam kde nie je treba max. výkon tak to preberú E-cores. Tam sa pre zmenu predpokladá "atómové" TDP resp. TDP malých jadier.
Avšak je to setsakramensky náročné namiešať ako sa povie tú alchímiu a súzvuk v danom prípade samostatných veľkých a samostatných malých jadier (microarchitektúr).
A prečo tak dopadli? Lebo oni vždy stavili na jedného koňa na výkon a to bolo len a len veľké jadro a atomy (Celerony N/Pentia N/J) však vieme kam...
Lenže aj tie atomy sa ta revolučne in-order na out of order ako evolučne architektonicky vyvýjali a už Intel Tremont len so SIMD up to SSE4.2 poriadne odskočil výkonovo. Práve tento tremont som otestoval v lete proti malým jadrám Zhaoxinu (Centauru) a výkon je naozaj niekde úplne inde.
https://www.youtube.com/watch?v=SnRe7lcKOV8
A ako vieme Gracemont, o ktorom v tom čase mnohí keď ešte neboli leaky a Intel Architect Day mnohí posmešne prejudikovali aký to bude atómový šunt a pod.
Takže áno nielen že to schytávam od miláčikov AMD, schytávam to aj zboku od miláčikov pravých plnokrvných niekdajších veľkých jadier Intelu.
Oni majú problem so mnou a nie ja s nimi nakoľko im stále opakujem, že vzhľadom na vyššie uvevedené byť chcete alebo nechce teraz sme pri SoC big.LITTLE na jednej lodi a počúvať to ich večné skrípanie so zubami...
Tak áno toto sa stalo.
Veď viem o tvojom vzťahu k malým jadrám a hlavne VIA..... ale tu asi s tebou nesúhlasím
"Vymačkáme z P-corov maximum pričom E-cores to budú krotiť avšak len tam kde to reálne dokážu tj. nie do peakov a hlavne big.LITTLE tj. tam kde nie je treba max. výkon tak to preberú E-cores."
V dektope istotne sigle úloha bude bežať na P-core kôli výkonu a aj ostané úlohy budú bežať na P-core až kým ich všetky neobsadia a a E-cores dostanú úlohy až keď sa niečo zvýši, takže žiadnu veľkú efektivitu tam nevidím, aj P-cores budú mať úsporné funkcie a nevyužité vedia ísť so spotrebou veľmi dole.... ako sa tu spomína, vidím tu iba šetrenie na kremíku a prínos E-cores bude hlavne v benčmarkoch a úlohách, ktoré potrebujú 8+jadier. Tie malé jadrá patria presne tam, kde boli, do Atómových CPU. Toto bude pre desktop mačkopes...
Ale veď jasne, že single pôjde na P-coroch resp. všade tam kde potrebuješ dosiahnuť maximálny výkon 8C/16T (+ 8c/8T) 24T tj. v peakoch avšak v idle, office work, multimediach, internet atď. budú P-cory pekne odpočívať.
Veď priemerný človek sa koľko času zo dňa hrá, encoduje video, prípadne robí vo photoshope, autocade a pod.?
A práve v tých vyššie uvedených dosiahne procesor atómové spotreby.
Áno súhlasím, že v desktope je to omnoho viac viditeľné ako v mobilnom segmente, ale tie scenáre proste existujú.
Napr. ja by som bral najradšej verziu Alderu 1C + 8c / 10T avšak taká nemá byť tak si budem musieť počkať na 2C + 8c / 12T.
V mobilnom segmente mám notebook so 6W atómovým Pentiom N6000 up to 3.3GHz (4C/4T Tremont s 4MB L3 cache na platforme Jasper Lake) so 16GB LDDR4 (dual channel) a 256GB SSD disk M,2.
Prober se. Osm velkých jader Zen žere v notebooku 15W. Malá jádra v desktopu netřeba, je to jen ojeb, případně dočasná softwarová neschopnost naladit i velká jádra, aby se nenechaly zbytečně vybičovat k maximu nějakou debilní webovou stránkou.
> No odpoveď je predsa veľmi prozaická keďže nateraz to bude stačiť na konkurenciu aj s atómami a so SIMD up to AVX2
Odpoved je prozaicka a uplne jina.
Cela pointa big.LITTLE v desktopu, celej duvod proc se s tim Intel sere neni ten, ze je to nejaky uzasny koncept na kterej prisli v Intelu inzenyri po 24 hodinach huleni travy. Pointa jsou penize. Presneji receno, setreni cm2 kremiku na CPU, a vyroba vice CPU ze stejnych waferu. A presne jak se rika v clanku, implementace AVX 512 znamena ZNACNE mnozstvi tranzistoru navic. Bylo by totalne idiotske implementovat AVX512 do CPU kdyz se snazite zmensit jeho plochu.
A nedivil bych se, kdyby i to AVX512 ve velkych jadrech Alder Lake bylo ne vypnuto, ale opravdu odstraneno. Mozna ne z dekoderu, to je nejspis komplikovane, ale AVX512 ma vlastni exekucni jednotky, a tipuji ze zrovna tyhle neni problem vyhodit.
ne ne chápeš to úplně špatně, je to největší inovace za poslední dekádu.Navíc ty další "next-monty" už budou umět AVX512 a ty další i AVX1024 atd. No a nakonec Intel odstraní i ta velká jádra, protože Atomy se natolik výkonově zlepší, že velká jádra nebudou potřeba.Tomu sa hovorí evolúcia a zmeny paradigmy, ak by si nevedel ;-)
Tak táto debata dnes je brutálna, díky, dávno som sa tak nebavil... :-)
Bylo by to vlastně takové ... roztomilé, ze života. Malá jádra budou po boku velkých prosperovat a učit se nové věci ... až taky vyrostou a už to nebudou malá jádra, ale velká jádra. A pak tatíček Intel původní velká jádra odebere a k malým-nyní-velkým jádrům dá zase nějaká malá :-)
tomu PS fakt veris? resp on jeste nekdo furt veri v to, ze Intel si vsechno hlida v suplicku a ceka jen na tu spravnou dobu nekde v budoucnosti? za me to je nesmysl, Intel nebyl schopen dodelat ani PCIE4 ke stary CPU architekture a ty myslis, ze mala jadra neumi AVX512 protoze Intel ceka na Godota? prd leda, proste to nemaji narysovany a nemuzou to tudiz vyrabet, takze az to Intel milostive dopracuje, tak snad nekdy to i bude
Čítal ste vôbec no-x-ov článok ?
cetl, kdyby to slepit slo rychle, tak to mame uz v Alderu, ale protoze tyto veci proste rychle nejdou, takze si pockame, No-X podobne nesmyslne PS v clanku nema
Tak ono reálně stejně žádný desktopový procesor AVX‐512 jednotky neměl, ne? 512bitové operace se rozkládaly do dvou 256bitových jednotek, takže AVX2 s dodatečnýma extenzema asi takový rozdíl zase nebude.
Akorát to teda oproti ARMu s 2048bitovýma vektorama :-D není moc future‐proof.
Při použití AVX512 se musí snižovat takty, protože to úděsně žere a těžko se to chladí.
Dneska jo, ale třeba u takového 5nm Zenu 4 by to už mohlo fungovat líp…
Myslim, ze tu bola vymenena pricina s dosledkom. Skor si myslim, ze sa takty musia znizovat, pretoze je to nejako oprasene, napr. tym pouzitim dvoch jednotiek, alebo je AVX pipelina nejaka moc dlha a pri vyssich taktoch by to ten procak interne nedaval. V pipeline su casti, ktore su synchronizovane hodinami a potom casti, ktore su synchronizovane "nadivoko" prostou propagaciou signalu v kremiku. Ak sa to s hodinami prezenie tak, ze signal sa v ramci jedneho bloku nestihne vypropagovat na vystup skor, nez dojde dalsi takt hodin, procesor zacne pocitat hovadiny. Rychlost propagacie signalu je okrem navrhu a vyrobneho procesu aj funkciou napatia, preto sa procesorom pri vyraznejsom pretaktovavani aj dviha napatie. Zrychli to preklapanie tranzistorov v cisto kombinacnej logike za cenu zvysenia spotreby a mnozstva odpadneho tepla. Je mozne, ze ta AVX jednotka je navrhnuta tak, ze aby to signal stihal, musi sa sahat do napatia a zaroven aj tak zhodit takt procesora. Potom jeden zacne pozorovat zhruba to, co ludia s AVX-512 pozoruju.
> Myslim, ze tu bola vymenena pricina s dosledkom
Nemyslim. Je fakt, ze u CMOS technologie, nejvic energie sezere prave preklapani stavu. Jak rika wikipedie: " Since one transistor of the MOSFET pair is always off, the series combination draws significant power only momentarily during switching between on and off states " AVX512 ma spoustu logiky, ktera (na rozdil od treba SRAM) musi pri vypoctech hodne preklapet. To generuje spoustu tepla, tomu se nijak nevyhnes. Uz AVX2 ma vyrazny vliv na teplo.
> Ak sa to s hodinami prezenie tak, ze signal sa v ramci jedneho bloku nestihne vypropagovat na vystup skor, nez dojde dalsi takt hodin, procesor zacne pocitat hovadiny.
.... sice pravda, ale nevidim jak by tohle mohl byt problem. Kazda instrukce ma urcenou svoji latenci - pocet cyklu, za ktery muzes ocekavat na vystupe vysledek. Treba integer nasobeni na x86 ma kolem 1-4 cykly, deleni bezne 30-90. Kdyz mas instrukci ktera pocita pomalu, je nesmyslne snizovat frekvenci celeho CPU, smysluplne reseni je zvysit latence te instrukce.
> Je mozne, ze ta AVX jednotka je navrhnuta tak, ze aby to signal stihal, musi sa sahat do napatia a zaroven aj tak zhodit takt procesora
Nein, jak sem psal, bylo by nesmyslne zvysovat napeti a snizovat frekvenci celeho CPU kvuli jedne skupine instrukci; staci jim zvysit latence.
Jinak Intel sam o AVX512 "dynamic frequency scaling" mluvi ve svych materialech, a jednoznacne mluvi o "power".
V datasheete dana latencia instrukcie, to je domena synchronizovanych casti pipeline. pre jednoduchost zanedbame mikrokod a budeme sa tvarit, ze instrukcie su uplne v HW. Napr. mam nejaku 5-stage RISC pipeline. instrukcia v prvej stage vstupi do pipeline a viem, ze ak nedojde k blokacii, do piatich taktov hodin mam na konci pipeline vysledok. Potial spravne.
Problem je v tom, ze jednotlive stage pipeline (v terminologii Norberta Adama rezy) maju v sebe nejaku nie prave jednoduchu kombinacnu logiku, ktora hodinami synchronizovana nie je (resp. je hodinami synchronizovany iba zachyt vstupu). Tam je poziadavka, aby sa vystup tejto kombinacnej logiky ustalil na korektnu hodnotu v case kratsom, ako je jeden takt hodin, aby dalsi nabezny signal hodin sposobil zachyt tejto hodnoty a jej presun do dalsej stage pipeliny. Aj preklapanie tranzistorov nejaky cas trva a hodnota vystupu moze v nejakom kratkom case rozne plavat, kym sa ustali na spravnej hodnote.
Toto je dovod, preco ked sa to prezenie s taktovacou frekvenciou procesora, zacne byt nestabilny. Nemusi sa nutne jednat o "nestihanie" signalu v ramci pipeline, ale ide o to, ze asynchronne casti procesora prestanu stihat synchronizacnym hodinam, procesor potom zacne spracovavat bludy (zle medzivysledky spracovania instrukcie, zle precitane data zo zbernice, zle zapisane data, atd.) az sa dopracuje k nejakej forme padu OS.
Zvysenie napatia zrychli preklapanie (alebo ako pise kolega nizsie, zlepsi tvar signalu v prechodoch) a tym defakto zrychli asychronnu kombinacnu logiku idealne natolko, ze bude stihat aj zrychlenym hodinam.
Dlouhé, ale velmi zajímavé čtení a spousta měření:
https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html
Ve stručnosti: při použití AVX-512 instrukcí se jádro procesoru zastaví na cca 11 μs (desítky tisíc taktů) než sníží pracovní frekvenci a zvýší napájecí napětí.
'Občasné' použití několika 512-bitových instrukcí má paradoxně za důsledek zpomalení programu. Pokud tedy nemám výpočetní úlohu, která z velkých vektorů bude mít prospěch (např. zpracování videa, apod.), tak je lepší se 512-bitovým instrukcím v běžném kódu úplně vyhnout. Záměrně nepíšu vyhnout se AVX-512, protože v něm jsou i nově kódované staré 64/128/256-bitové instrukce, které ovšem mohou nově využívat všech 32 vektorových registrů.
"Rychlost propagacie signalu je okrem navrhu a vyrobneho procesu aj funkciou napatia, preto sa procesorom pri vyraznejsom pretaktovavani aj dviha napatie."
Já měl za to, že u CMOS se to napětí při vyšší frekvenci zvedá proto, aby byly lépe definované hrany logických signálů?
A nie je to v konecnom dosledku to iste? Skrati sa cas, po ktorom je garantovana nejaka uroven signalu na vystupe, t.j. sa zvysi sanca, ze pri nejakom case t bude hodnota precitana dalsim clenom spravne a ten sa nedopocita k volovine.
V konecnom dosledku to ale vedie k tomu, ze sa da so spravnou propagaciou signalu pocitat pri vyssich frekvenciach.
Intel uváděl, že výrazné snížení taktů se snažil řešit na serverové verzi Ice Lake.
To se tyka jen FP. Desktopy maji 2x256, Xeony 2x256 + 1x512. V integer operacich krome nasobeni (a obecne vsech, ktere nepotrebuji FMA) je to vzdy 2x256 (porty 0 a 1) + 1x512 (port 5). AVX12 nema nejake sve "jine" jednotky. Jen je rozsiren port 5 na 512bit a v pripade Xeonu je k nemu pridana dodatecna jednotka FMA, ktera tam normalne neni.
Jinak, s ARMem a SVE bych to moc neporovnaval, to je jina filozofie, ktera ma taky sve velke nevyhody a omezeni. Navic tezko lze v dohledne dobe (nebo vubec ?) ocekavat HW implementaci SVE s nativni sirkou vetsi nez 512 bitu.
Přijde mi to jako takový mišmaš. Je fajn, že se Intel snaží dostat opět na špičku, ale trochu mi to přijde, že hází granáty na všechny strany a doufá, že některý nakonec nevybuchne.
Jenže na ARM s SVE-2048 instrukcemi to nemá, éra x86 skončila už před rokem.
Ale zasa navrhu, kde kod je vzdy rovnaky a jeho rychlost sa meni len s ohladom na fyzicku sirku vektora v HW, sa musi nechat, ze je celkom elegantne futureproof.
Inu so SIMD to Intelu viac neslo, ako slo. MMX pajcli tak nesikovne, ze rozbijalo FPU a bolo FP-only (AFAIK), SSE1 a ciastocne aj SSE2 boli dost tazko pouzitelne nekompletne zmatky (im zasa podpora FP chybala), ktore pre plnu podporu SIMD napriec typmi vyzadovali kombinaciu s MMX instrukciami (ktore mali ine registre a kolidovali s FP instrukciami). O tom, ze to bol bordel svedci aj to, ze AMD ich podporu uz pred nejakym casom aspon v niektorych procesoroch zahodila.
Take prve univerzalne pouzitelne SIMD od Intelu bolo SSE3.
(Skoro) vsechno spatne :).
MMX - 64bit, pouze integer, vyuziva x87 (FPU) registry
SSE - 128bit, 16 novych registru, pouze single prec FP
SSE2 - 128bit, single + double prec FP + integer; soucast x64 standardu
SSE3 - nekolik novych FP instrukci
SSSE3 - nekolik novych integer instrukci, jedna a nich (PSHUFB) velmi dobra
SSE4.1 - dalsi nove instrukce (FP i int)
SSE4.2 - par novych integer instrukci + nekolik specialnich (stringy, crc32)
AVX - 256bit FP, 128-bit integer, 3 operandy
AVX2 - plne 256bit (vcetne integer) + FMA + gather
AVX512(F, VL, BW) - 128/256/512bit FP i integer + gather/scatter + masking + broadcast/rounding + dalsich 16 registru + neomezene permutace + lepsi konverze + spoustu novych uzitecnych instrukci (vcetne doplneni par chybejicich v AVX2)
A stejně není AVX-512 v módě. Je to velké zklamání, říkal jsem si, že když už Alder Lake musí kazit malými jádry, tak aspoň ta velká budou nekompromisní.
OK, tak som to mal naopak. Vedel som, ze MMX vie jedno a SSE1 druhe, ale neunuval som sa checknut, ktore ako. SSE2 malo ale nejaky iny problem, kvoli ktoremu nebolo az tak velmi oblubene a odporucalo sa riesit hlavne SSE2.1 (?) a SSE3. Mne osobne to po prechode z Altivecu prislo ako totalny humbuk a curbes.
----------- ----------- ----------- ----------- -----------
kazdopadne: svet x86 a Woken (narozdiel od ARM a Androidu/iOS) NENI pripraveny na mutanty big-MidDlLe-LITTLE procaky ... mozno win11, mozno win 11 s updatami, mozno za rok aj na win10
situcia sa asi uplne idealne nevyriesila ani s ne-monolitickymi procakmi poslednych 4 rokov (8C zeppelin = 2x4C CCX a neskor 8C chiplety) ... vie niekto jaka je situacia? pri presne 8C zatazi sa vyuziju jadra v jedinom 8C chiplete (min. latencie medzi jadrami), alebo pri R9 5900X/5950X bude vsetka zataz behat a bude rozlezena po oboch chipletoch len preto, ze niekde v druhom chiplete su dva-tri ks. o 100 MHz lepsie jadra?
----------- ----------- ----------- ----------- -----------
Jsem si vzpomněl
https://diit.cz/clanek/torvalds-avx-512-zemre-bolestivou-smrti-koduri-al...
To bolo reci, ako to ten "HW scheduler" vsetko poriesi a rozlozi zataz aj podla toho, ci treba AVX-512 alebo nie..
A hen, tu to mame! :D
musíš počkat na windows 11 .-)
Pokud by neco takoveho bylo ve Win 11, tak by na tom jiz davno pracovali v ramci vyvoje Linux kernelu.
to byla ironie .-)
To by teoreticky slo, ale pokud by pro to nebyl specialne napsany SW (treba aby v nekterych threadech pouzival AVX512 a dalsich AVX2), tak by to nemelo smysl. Lepsi je mit 16x AVX2, nez 8x AVX512.
No když se kouknu na výsledky toho benchmarku v Sandře v předchozím článku, tak z hlediska výkonu to vypadá, že to je skoro jedno. Mimo toho jednoho integer SIMD testu, který na Rocket Lake nejspíš využívá tu 512bitovou ALU a na Alder Lake dopadnul tragicky.
Ta malá jádra mají myslím jen dvě 128bitové FMUL/FADD jednotky, takže max. propustnost pro 256bitové FMA instrukce je 1 instrukce za 2 takty = nic moc.
Tak samozrejme vypnuti AVX512 na velkych jadrech je svym zpusobem hw scheduler - scheduled departure... 3.. 2.. 1.. a je to fuc :P
S ohledem na blamáž s AVX-512 v Rocketech je to asi celkem jedno. Prostě pragmatické rozhodnutí, Alder Lake je pro běžné plebs a ti AVX-512 nijak zásadně nepotřebují, lépe využít křemík jinak.
Lenže "ONI" ho potrebujú hneď lebo predchodca ho už mal tak čo že je Alder Lake úplne niekde inde výkonom ako predchodcovia tak treba článok postaviť na skutočnosti, že malé atómové E-jadrá Gracemont ho v prvej generácii AL nepodporujú aj s poukazom, že custom server Xeony Phi, deriváty Larrabee postavenými na Atomech s podporou AVX-512 v rokoch 2013 podporovali tak a článok je na svete. Či pozitívny alebo negatívny to necháme predsa na čitateľoch.
Ale stále je to o galaxiu vyšší level ako dvojpísmenkový svet takže diskusia sa oplatí a má zmyslel.
Má smysl, aby se Intel ještě snažil? x86 je dead, aspoň v jeho podání. AVX-512 se mu možná nikdy nepodaří dostat mezi lidi, takže pro to nikdy nebude rozšířená softwarová podpora. Dopadne to jako třeba Alpha, pro kterou těch pár programů byly optimalizované (např. Lightwave), ale všechny ostatní na nic.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.