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.
Neodpustím si ironický úšklebek, že to vypadá na pěkně žravou sr....
Tenhle bazmek chce intel postavit proti Zen 4?
https://cdn.someecards.com/someecards/usercards/1334790525354_6769176.png
vypadá to tak.
To ale taky znamená, že Intel má s výrobou stále problém, protože jinak by tuto delší, zato horší, zkratku určitě nevolil.
Alder Lake ma být Golden Cove na 10nm. Jestli opravdu bude mit 6xALU a Zen3/4 ne, pak bude mit AMD problem.
Ty nove Atom jadra Gracemont maji mit IPC někde kolem Sky Lake, což není vůbec špatné. Nynější Tremont ma IPC kolem SandyBridge.
V kombinaci by to nemuselo mit vůbec špatný výkon Intel by mohl AMD docela zatopit. Ono to totiž je spíš big.MIDDLE, protože ty nové Atomy jsou násobně výkonnější (3xALU OoO) než LITTLE ARM jadra A55 v telefonech (slow in-order).
Ale těžko soudit když víme prd co je Zen3 a GoldenCove.
“[Sunny Cove has an] 800 instruction window, sustains between 3 and 6 x86 instructions per clock,” says Keller, “massive data predictors, massive branch predictors… We’re working on a generation that’s significantly bigger than this and closer to the linear curve on performance. This is a really big mindset change.”
Sunny Cove ma:
* 4x Int ALU
* 3x Vect ALU
* 2x AGU Ld + 2x AGU STA
Takze z tech celkovych 11 jednotek, ktere dokazou naraz paralelne zpracovavat nejake instrukce, vytahne v praxi Intel ze Sunny Cove 3-6.
Nemyslim, ze by Intel volil cestu vice ALU, ktere nema jak zasobovat. Zatim nevytizi ani ty co ma. Keller neni uplne orezavatko a kdyz i on tvrdi, ze je potreba masivnich predpovidaci logika, neco na tom bude :D
> Keller neni uplne orezavatko a kdyz i on tvrdi, ze je potreba masivnich predpovidaci logika
Nejen predpovidaci logika, taky cache a dostatecne siroke cesty vsude. Jinak jsou ti vsechny ALU k h*vnu. Tenhle samy problem melo AMD s Bulldozerem - dekoder byl proste moc slabej na to aby zasoboval dve jadra najednou, takze backend (ALU) 50% casu valel sunky zatimco frontend byl vytizenej jak otrok. Musi se to proste vyvazit. Nicmene tyhle detaily jsou RichieRich ukradene, cim vic ALU tim vic Adidas :)
Presne :)
Bulldozer mel fakticky 2x2 ALU usporadany do dvou "sub-jader" v modulu (coz byl teprve ekvivalent plneho jadra, jak ma treba Intel, nebo tedka AMD u ZENu). A ta logika pred tema "sub-jadrama" byla hodne slaba a navic krom slabeho dekoderu trpel i spatnym predpovidacem vetveni a casto musel splachnout instrukcni frontu na obou jaderkach... celkove to bylo hodne nevydareny pokus o SMT :(
A Richie... to je proste takovej DiiT sasek :) Podle me je klasickej Apple-pozer, ktery se nejak skrze earbuds PR clanky proklikal na test na Anandu a porozumel jen jedne casti... 6x ALU :D Vazby na dalsi casti cipu jsou na nej moc slozite.
Ty poddimenzovane 2xALU se ještě z poloviny flákaly kvůli pretizenemu front endu? Jsi normalni? To by totiž v ST museli dávat dvojnasobne IPC oproti MT, což je samozřejmě pitomost.
Mne furt udivuje kolik lidí nechápe že výpočetní výkon se zvyšuje výpočetními jednotkami v back endu a všechno ostatní se dimenzuje podle nich, aby byly co nejméně brzděné.
Problém je, že Intel ani AMD nemají technologii aby těch 6xALU efektivně nakrmily. Autor toho rozboru na Anandtechu Andrei sam napsal na foru, že Intel a AMD jsou cca 4 roky pozadu ve vyvoji za Applem.
To je jako by si napsal, jaky jsou v apple debilove ze kupujou pro svuj hw x86 procaky. Jenze oni narozdil od tebe debilove nejsou a vedi jak si ten jejich arm opravdu vykonove proti x86 stoji.
Ty ALU nebyly poddimenzovane.
V dobe kdy se Bulldozer planoval uz mel Intel svuj HP. Jeho top model byl 4jadro+Hyperthreading.
AMD na to reagovalo tim, ze udelalo 4 moduly (ktere jsou funkcne na urovni tehdejsiho jadra Intelu). A v ramci tech modulu to zaridilo tak, ze modul je schopen zpracovat 2 separatni vlakna. Pokud tam je jen jedno vlakno na modul (coz pak slo dosahnout nejakym nastavenim scheduleru, affinity, atp.) tak teoreticky ma 4ALU k dispozici jedno vlakno.
Takze na papire by to melo fungovat jako basen. 1modul bude mit na jednom vlakne k dispozici 4ALU+1FPU, coz je ekvivalent toho, co mel Intel. Tady prave padaji ty tvoje teorie. Pocty a rozlozeni exekucnich jednotek v modulu melo znamenat stejne IPC jako mel Intel.
Problem byl ale v tom, ze scheduler a branch predictor nefungovaly dobre. I kdyz BP byl na pomery AMD skvely, porad obcas minul (coz se stava i u Intelu). Ale organizace toho modulu, micro cache, fronty, atp. nebyly pripravene na pripadny omyl v predpovidani vetveni a kdyz k tomu doslo, muselo se toho hodne znovu nacitat + cache meli vetsi latenci, lookaside zasobniky atp. nedokazaly ten problem zamaskovat.a Celkove to zpusobilo hrozny vypadek. Proto to celkove dlouhodobe IPC bylo o dost nizsi nez Intel.
"Takze z tech celkovych 11 jednotek, ktere dokazou naraz paralelne zpracovavat nejake instrukce, vytahne v praxi Intel ze Sunny Cove 3-6."
Takže skvělá příležitost pro deaktivaci HT, jakmile se najdou další chyby... ;)
HT je prave jedna z mala moznosti jak vytizit co nejvice ALU :)
Pri HT se pouziva hromada dalsiho kremiku tak, aby se 'instruction pool' naplnil dostatkem instrukci a potom si ty ALU mohli odebirat instrukce i z druheho vlakna.
No právě proto říkám, skvělá příležitost právě tohle vypnout. ;)
Až by jeden řekl, že úplně bude stačit 2x ALU, 2xAGU a 2x FPU.... jako v Bulldozeru, že? A všichni víme jak to dopadlo.
Když prijde burst deseti ALU instrukci tak jsou ty prumery totiž k ničemu. Netřeba teoretizovat když tu máme v praxi Apple, který ukazuje že z těch jeho 6xALU dokáže dostat o 80% větší IPC než Intel s AMD.
I když budu mít 10 ALU instrukcí za sebou, tak je velmi pravděpodobné, že mezi sebou budou mít datové závislosti, takže se stejně všechny nepodaří vykonat současně. Navíc bych musel mít instrukční dekodér s obrovskou šířkou a složitostí, aby byl schopen tolik instrukcí současně připravit ke zpracování (tady připadá v úvahu jedině využití Trace/Micro-operation cache).
Pokud chci využít 10 ALU naplno, tak musím mít kód, který obsahuje 10 paralelních nezávislých toků výpočtů. Toho se dá někdy dosáhnout rozbalením cyklů (loop unrolling), ale podobný efekt má i vektorizace na SSE/AVX kód. Lze to i kombinovat, ale v praxi to stejně jde použít jen v algoritmech, které zpracovávají velké bloky homogenních dat, např. obraz nebo zvuk. Zároveň se ovšem nesmí stát úzkým hrdlem třeba paměťové rozhraní, kdy moje krásné ALU nebudou mít co počítat nebo se nebudou stíhat zapisovat výsledky.
Jak psali kolegové nade mnou: všechny systémy v procesoru musí být v rovnováze, aby byly efektivně využity (neplýtvalo se křemíkem) a zároveň se maximalizoval výpočetní výkon (neplýtvalo se časem).
To Richie nechape. Tohle je na nej moc slozite. On ma 6xALU babovicky a ty mu po nich slapes realitou :D
On vubec nechape a diky Dunning-Kruger efektu ani neuznava, ze by dekodery, cache, uops cache, predpovidani, scheduler, IO rozhrani, kod, prekladac... meli jakykoli vliv na IPC :)
Ty vůbec nevíš co píšeš.
10 INT instrukcí je úplné nic když Reorder Buffer v Ice Lake má 352 položek a vyhledávání závislostí je v oknu až 800 instrukcí. Takže v praxi když máš kód s bloky nezávislých instrukcí, třeba zpracování videa x264 jak jsi správně napsal, tak ve frontě může být burst klidně i 100 INT instrukcí najednou. Pak je obrovský rozdíl jestli máš 2xALU jako debilní Bulldozer, který na to potřebuje 50 cyklů, nebo máš 4xALU jako v Zenu (25 cyklů) nebo Apple 6xALU (17 cyklů).
A největší sranda je, že ten Apple A13 má jen o 2 ALU víc (a ty jsou ještě simple/jump, neumí dělení, násobení narozdíl od těch komplexních) takže teoreticky +50% nárůst ALU jednotek a reálné IPC má ten Apple vyšší o 80%. Evidentně inženýři Applu dokáží krmit těch 6xALU mnohem efektivněji než Intel s AMD ty pouhé 4xALU. Tedy Apple má lepší i front-end, prediktory a prefetch.
Takže máte pravdu v tom, že nemá smysl stavět 6xALU jádra x86. Jednoduše proto, že ani Intel ani AMD v současné době na to vývojově nemají.
Jenže to je všechno úplně naprd, pokud ty závislosti existují. Jak se poset jednou nedá kvůli uspořádání linearizovat výrazně lépe, tak může být okno dlouhé třeba 800000 instrukcí a nepomůže to.
Takhle bulldozer postaven nebyl. Ukazujes jen svou neznalost, trapnost a celkove jses za saska :)
Buldozer mel 2x2 ALU na modul. Dekoder a dalsi veci byly sdilene pro cely modul. A jeho problem nebyl v nedostatku ALU, ale v tom, ze branch predictor a scheduler byly dost chybove a nemely zadnou zachranou sit.
Sandy Bridge mel podobne latence, mel dokonce o chlup horsi predpovidani vetveni, ale se spatnou predpovedi se dokazal vyporadat mnohem lepe. Neznamenalo to takovy desivy vypadek.
Napr zde:
https://www.anandtech.com/show/5057/the-bulldozer-aftermath-delving-even...
"The problem is that Bulldozer cannot hide its long misprediction penalty, which Intel does manage with Sandy Bridge."
Kdyz prijde burst 10ALU instrukci, tak se nic nestane. Tech instrukci tece pres procesor kvanta a "burst" nikoho zas tak netrapi. Je to "sustained throughput", ktery se snazi inzenyri vyladit. Navic i "burst" musis nejak dekodovat, a jinak osefovat, takze i kdyby na vstupu ten burst byl, uz u dekodovani, predikce, nahravani adres by se to zpomalilo tak, ze ALU opravdu hluche misto nebude :)
Apple mozna dokaze dostat vice IPC, ale celkovy vykon je tak tragicky maly, ze ho Apple nechce dat ani do ultra macbooku, kde na ten vykon zas tak nehledi.
Jo jasně, ten Apple A13 na 2.6 GHz má větší výkon ve SPECint2006 než Zen2 na 4.7 GHz.... ale ty tady budeš lhát že má tragický celkovy výkon. Hochu ty jsi ukazkovej sociopat/psychopat, kterych je ve spolecnosti cca 5%. Ti svým lžím věří tak že projdou i detektorem lži. Řekni mamince ať tě nechá vyšetřit :)
Přeji hodně zábavy při hraní, modelování či výpočtech MKP ve specint2006 ..........
Je už fakt trapné jak se to znažíš všude cpát.
55% zisků herního průmyslu je na ARM platformách Android, iOS a Nintendo. Splněno.
Modelování a výpočty MKP to zvládne taky, to jsou jen výpočty matic které zvládne každá moderní FPU vektorová jednotka. ARM má nové SVE2 vektorové instrukce o šířce až 2048-bit, tak si představ jak to bude frčet oproti Zen2 s jeho trapnými 256-bit AVX2. Ano, nové ARMy budou mít 8x širší vektory než AMD a 4x než Intel s jeho AVX512.
Trapná je zaostalost x86 a nevědomost lidí.
Cece, ty fakt nemas moc rozum. Muzes mit sebelepsi HW, kdyz k nemu nebudes mit SW ekosystem a dostatecnou podporu na strane HW a SW firem, tak si s nim muzes delat akorat tak omalovanky.
SW ekosystem se vyviji dlouhe roky. Myslet si, ze kdyz ma tamhle Apple chip s vyssim IPC, ze to neco znamena v praxi pro ostatni odvetvi, vyjma jeho omezeny appli svet je, je fakt mimo.
Proc se ARM neprosadilo doted nekde vic, nez mobilech a low-power zarizenich. Ja ti odpovim..dokud na to nebude podobna "tuna" SW jako na ten "zastaraly x86-64" a zaroven to nebude mit lepsi pomer cena/vykon, tak si stejne neskrtne a muzes se stavet treba na zadni. To je realita "daily bussinesu" a duvod proc zkrachoval Intel se svym pokusem proti ARM, MS se svym Windows mobile, atd. Historie zna takovych veci mraky.
Bohuzel nevitezi "technictejsi" platforma, ale ta, ktera se dokaze nejlepe na trhu udrzet/prosadit.Vsadim se, ze dneska existuji na papire podstatne lepsi koncepty CPU, ale je to prd platne, kdyz je nebudes na trhu moct udat.
Tak si to dame znova. Proplesknuti pohadkare Richie Riche jeho vlastnima udajema. Apple A13 Multi-Core Score 3583, AMD Ryzen 9 3950X Multi-Core Score 14336. Zdroj https://diit.cz/clanek/ryzen-embedded-r1102g-si-vystaci-s-6-watty/diskus...
Tim ze tu lez budes opakovat porad dokola se z ni pravda nestane.
Irony on. ALE ON MA VYSSIE SINGLE-CORE!!!!! irony off.
Jestli se u Intelu podaří rozběhnout 7nm proces koncem 21, upřednostní mobilní a serverový segment a desktop půjde na řadu jako poslední (MeterLake v Q4 22?), potom má uvedení hybridu AlderLake smysl. Trh se zaplácne 2×:
a) nejprve se na trh uvede s velkou pompou první 16jádro,
b) následně se bude prezentovat, o kolik je 7nm MeteorLake výkonnější než předchozí generace => tím se znovuzíská dobrá pověst CPU Intelu. Už to vidím.
nebo další řešení, "velká" jádra by byla skutečně fyzicky velká na 14nm vzatá z Rocket Lake a menší na onom vylepšeném 10nm+ na nejaktuálnější verzi mobilní architektury, to by se tam pak mohlo nějak seskládat. Takový hybrid by už mohl být aspoň nějak konkurenceschopný vůči aktuální konkurenci.
Pak by šlo o čipletové řešení podobné dnešnímu Zen - 1 čiplet větší s jádry RL, druhý s nástupcem TGL a třetí by byl s grafikou. Taky by se ten 14nm čiplet mohl ořezat o rozhraní a nechat jen základ a zbytek nechat v malém 10nm čipletu.
Koncept je to z jisteho pohledu zajimavy, byt do desktopu nedava moc velky smysl, alespon v ramci konkurence 12-16C CPU AMD.
Pokud by neco takoveho Intel udelal, rad bych vedel, jak se s tim pohosti Win scheduler....
O tom jsem taky přemýšlel, ale pokud to má fungovat, jak si myslím - tedy primárně používat velká jádra a po jejich vyčerpání přidat malá - tak by to nemusel být problém. Už dnes se nějak musí vypořádat s lepšími - horšími jádry, takže velká by prostě byla jako lepší (používala se primárně) a malá jako horší (používala se až když lepší / velká dojdou).
Ciste teoreticky by jeste mohla existovat varianta, ze by "mala jadra" nahrazovala u Intelu trochu problematicke (z hlediska bezpecnosti) HT...
Čekal bych, že tohle vše bude u architektury chystané na rok 2022 dávno opravené.
Pokud je to neco, co prakticky mohou opravit.
Sice si nemyslim, ze je to ten pripad, ALE... pro intel muze byt jednodussi dat tam mensi jadra, nez prekopavat cely koncept jeho HT. Nektere ty "chyby" ktere Spectre atp. vyuzivaji vedou k zakladum te technologie.
"Pokud je to neco, co prakticky mohou opravit."
Pokud je to neco, co prakticky chteji opravit.
Rozumej: ze jim ta technologie prinasi kyzeny vykon a prekopat to by bylo tezsi nez to nejak polepit.
Čekal bych naopak malá jádra pro minimální zátěž a velká jen když jsou vážně třena. Obráceně mi to nedává smysl.
V desktopu nemá smysl používat malá jádra pro minimální zátěž, protože to nic nepřináší. Ušetřené desetiny wattu u 125-150W CPU v desktopu opravdu nikdo neocení. Jediné racionální vysvětlení, které se nabízí, je náhrada velkých jader při vytížení celého CPU. Ušetří se spousta křemíku a negativní dopad na výkon oproti plnému počtu velkých jader nemusí být velký.
Jenze tohle je podle me omezene uvazovani.
Pokud by ty velka jadra zustala uplne netknuta, mas pravdu. Mobilni cipy dokazuji, ze stejne jadro dokaze behat i mnohem mensich frekvenich, gating funguje relativne dobre, povypina se co muze a to jadro tolik nezere.
Jenze takovyhle pristup (8b+8L) by mohl dovolit upravit oboje slozky. Celkove by navrh cipu mohl byt mnohem efektivnejsi, kdyz bys pocital, ze ty velke pojedou opravdu jen na 4+ GHz a nemeli vubec zadnou zbytecnou bagaz, ktera by byla zapojena pri nizsich taktech. PowerManagement by je proste uplne odstrihl.
Ja nevim, kolik obvodu se pouziva na rizeni spotreby, prepinani mezi stavy, kolik tranzistoru padne na vsechny ty ruzne domeny, cache, ktere se snazi zamaskovat ruzne frekvencni domeny a jak je to vse slozite. Ale podle me je tam potencial :)
Treba se timhle konceptem dostaneme k tomu, ze tech 8 "velkych" jader dokaze jet na 6GHz (s minimem treba "jen" 4,5Ghz) a o zatez na kterou staci 3GHz frekvence se postaraji "male" jadra...
Potenciál k čemu? Jestli bude mít v klidu a při minimální zátěži procesor spotřebu nepatrně vyšší nebo nepatrně nižší, bude mít nulový dopad na to, jak dobře se procesor bude prodávat. Už nyní má řada Core nižší spotřebu v idle než Ryzeny - drtivé většině zákazníků je to jedno. Proč by si Intel měl prodražovat výrobu přidáváním malých jader na to, aby ještě v idle watt ušetřil, když to, co zákazníkům na procesorech Intelu vadí, je absence vícejádrového výkonu a příliš vysoká spotřeba v zátěži? V Intelu by se museli definitivně zbláznit, pokud by přidávali malá jádra a zvětšovali si výrobní náklady kvůli tomu, aby u 150W procesoru řešili spotřebu v klidu. Ta je již nyní pro většinu zákazníků natolik nízká, že konkurenční rozdíly ignorují, protože jsou již nepodstatné. Rovněž to neodpovídá na otázku, proč by malá jádra měly jen modely s vyšším počtem jader.
Očekávat od 10nm procesu, u kterého má Intel problém se byť jen přiblížit výsledkům 14nm výroby, takty kolem 6 GHz, je zcela mimo reálné možnosti.
Mno, něco takovýho mělo myslím Ferrari. Místo klasickýho 4x4 to byla zadokolka s připojitelným předkem který měl redukovanou převodovku. a stálo to za prd na silnici i v terénu.
Můžu popsat jak se Windows chovají na 4+4 big.LITTLE ARM laptopu:
Když je systém téměř idle, pak se jádro OS a služby na pozadí schedulují na malá jádra; velká jsou zaparkovaná. Malá jádra se neparkují nikdy.
Když se zátěž systému zvedne, je to jak píšeš, všechno se nasype primárně na velká jádra, malá se využijí až jsou-li živé více než 4 vlákna (což udělá cokoliv co paralelizuje, žádný sw nerozlišuje velká/malá).
A pak jsou ještě vlákna, které programátor explicitně nastavil jako "power throttling", ty zůstávají skoro vždy na malých jádrech.
Intelovská interpretácia konceptu big.LITTLE = big power consumption + little compute performance. Toto určite dokážu reálne vyrobiť!
Na to není třeba Intel, to zvládne každý lepší domácí kutil s pájkou a elektronkami...
Ale ne kazdy domaci kutil dokaze premluvit masy lidi aby takovy sunt kupovali a on u toho mel porad 50% marzi :D
Zoufalé firmy dělají zoufalé činy.
No a uz to bude mit tech 179 ALU? :D
Zajimalo by me, co skutecne dela z tech malych jader ta mala.
Muj osobni typ je tohle...
V tuhle chvili dela Intel jadra, ktera jsou schopna behat na nekolika energetickych urovnich. A v ramci nich jeste tunit za pochodu frekvenci.
A tak kdyby mel 8 jader, ktere maji jen 2 Power State a bezi napr. na 1,5GHz a 2.5GHz a pak "identickych" 8 dalsich jader, ktere ale maji jine PS takove, ze bezi na 3.5 a 4.5GHz, mohl by si dovolit vyrazne zjednodusit jejich navrh a i cele rizeni spotreby.
S dobrym ovladacem pro Scheduler by mohl dosahnout toho, ze treba v bezne zatezi z tech "pomalych" pobezi jen 3 a budou se starat jen o obsluhu eventu na pozadi a na 5 z 8 pobezi na plne koule nake aplikace na popredi (hra) + master vlakno systemu.
A terazky mi povedztě, Kefalín, čo vy si predstavujetě pod takým "dobrym ovladacem pro Scheduler"?
No takovy, ktery dokaze z CPU precist informace o kazdej jadre zvlast a chapat jeho typ.
No a potom vlaknum (z pohledu OS, nikoli vlakna z pohledu CPU), ktera nebezi jako prioritni (napriklad obsluha nejake servisky) nastavi affinitu na ty konkretni jadra, ktera jsou mensi.
Ono to zase neni taaak slozite. Na *nix to relativne dobre funguje. Staci mit rozumnou tabulku, umet cist statistiky (jako napr. vytizeni toho ktereho jadra) a HW Info :)
Nic co by tedka nebylo videt v ProcessExplorer & TaskManager.
To je veľké sústo pre indických "programátorov" čo zostali v MS :) Oni vedia už iba zmeniť ikony v start menu :)
Ale licence za jádra který neumí ani pořídně využít si zaplatit nechají.
Problem tu ani tak nie je o tom, ze by OS nieco nevedel. On to vie, len to nerobi. Klucovy problem tu je v tom, ze Windows (zrejme) nema podporu pre tzv. NUMA stroje. To su stroje, kde nie kazdy procesor ma rovnake podmienky pre pristup ku kazdej oblasti pamate. Totizto v principe dnesne viacjadrove procesory uz (v zavislosti od uhlu pohladu) uz nie su SMP ale NUMA. Pri chipletovom designe AMD to plati 100%, pri Inteli asi hlavne pri pohlade na cache.
A na tuto podstatnu komplikaciu treba mat v OS podporu, pretoze to nie je len o scheduleri, ale o celkovom manazovani resourcov. OS, ktore sa aspon naznakom obtreli o hardware byvaleho SUN a/alebo SGI to podporovat museli, pretoze bez toho neslo ani bootnut. Windows to niekedy podporovat mohol, ale je mozne, ze prepojenie jadrovej funkcionality s platformou chyba.
Windows samozřejmě podporu NUMA má. Ale nijak zvlášť s ní nekouzlí (jako že by se stránky paměti kopírovaly při přeschedulování vlákna na jiný uzel nebo tak). NUMA stroje byly donedávna velké a drahé, a provozoval se na nich zpravidla velký a drahý software, který si to "zmenežoval" sám. Běžný program dostane paměť z toho NUMA uzlu, na kterém zrovna běželo vlákno, které první sáhlo na commitnutou stránku, nic víc. Navíc, rozlišuje se NUMA jen v ohledu na RAM, nikoliv cache.
Nicméně, nedávno jsem v SDK posledních vývojových buildů postřehl novou úroveň rozlišení, "Die" (doposud existovaly Cache, Core, Numa, Package a Group), což by mohlo rozdíl "vzdálenosti" mezi jádry v jednom chipletu a jádry v různých chipletech, přinejmenším vystavit ke zhodnocení aplikaci, přinejlepším pozitivně ovlivnit chování schedulleru. Ale nedělám si naděje, spoustu šlo již dávno odvodit od hierarchie cache.
Jsem zvědav co na tohle WIN scheduler, který má problém s více stejnými jádry, co teprve s rozdílnými, to bude žůžo
chlapi je to ot, ale neviem čo s tým.
pri inštalovaní w10 update sa reštartlo pc. Bliklo svetlo, takže možný pokles napätia.
Po opätovnom naštartovaní pc hlási chybu bootovania. Oprava nepomáha, pokúsil som sa nahodiť nové okná, ale inštalátor nepozná disky. 1x nvme 1 sata ssd.Pri možnosti browsnuť driver pc pozná disky, oddiely a čo je na nich, tedaasi je všetko ok, ale ani z inštalačného cd assu, ani po stiahnutí drajvrov z ich stránok na flešku drajvre aj keď vidí, nenainštaluje....Strávil som s tým niekoľko hodín , bez výsledku...
Nakoniec som ssd vybral z pc, dal do druhého, pomocou partition magic zrušil partície, cez usb nabootoval zálohovací sw a prepísal image disku. Vhodil naspäť do pc a pc nabehlo. Pomocou PM urobil to isté na nvme a bingo, oba os nabiehali bez problému. Teda v sobotu, nedeľu. Dnes som zapol pc a tá istá chyba.....Čo to spôsobuje a čo s tým?
ospravedlňujem sa za off topic, ale je tu pár šikovných ľudí.
Jednou mně výpadek proudu zničil integrovanou síťovou kartu (její firmware) a co jsem hledal, tak je to možné. Tobě se asi něco podobného stalo se základní deskou. Zkusil bych přehrát UEFI-BIOS.
to som skúšal ako prvé, ale mám aktuálny bios a tak mi to nexcelo upgradovať.
Skus chkdsk /f ci ti vypise chyby a opravi, podla mna sformatuj disk a nanovo vsetko, kludne moze byt aj disk v hajzlu.... mne minule po 9 rokoch zdochol PC s SSD, presme rovnaka chyba, nechcel nabootovat, chkdsk /f pomohol, nova bateria na doske a novy bios...
pri kontrole disku neukázalo problém, ovšem po tom čo som dal do pc ten prepísaný disk s image disku to nejaké problémy riešilo. Je zaujímavé, že sa mi po tom nespustil ten nový disk, ale ten nvme s plne funkčným os....
sfc /scannow
Dism /Online /Cleanup-Image /RestoreHealth
admin powershell
Zaujimalo by ma, co su to tie "prvky, které jsou nezbytné pro podporu vysokých frekvencí" ? Schopnost podport vysokych frekvencii je spravidla dana dlzkou pipeline, takze by som cakal, ze procesory pre nizsie frekvencie budu mat kratsiu pipeline a k tomu nalezite zjednodusene obvodove riesenie (mensi pocet ALU, alebo ine zmeny, ktore s kratsou pipeline maju zmysel). A tym sa oblukom dostavame k tretej moznosti, pretoze presne to Atom je.
No jestli to uvedou, tak mně budou zajímat reálné testy, možná by to za určitých scenářů mohlo i reálně fungovat - velká jádra si nerušeně pojedou vlákna náročných úloh, nebudou muset nějak přepínat a vyprazdňovat cache a rušit rozpracované predikce a malá jádra pojedou všechny ty ostatní krátkodobé tasky. V podstatě by to mohl být takový jiný způsob hyperthreadingu (protože něco by bylo sdílené) a zároveň specializace hw na určitý typ výpočtů (hi/low/short), možná i s omezenou instrukční sadou pro low jádra.
Takže bych celkově tuhle myšlenku úplně nezavrhoval i když si myslím, že je to od Intela další zoufalost, jak vytřískat z 14nm ještě trošku výkonu a možná se i popasovat s některými duchy.
No a v čem to má být lepší než když mám 16 "velkých jader" a z nich třeba 14 jede ty "náročné" úlohy a zbývající dvě ty nenáročné? Zas tolik energie tím asi neušetřím ne?
Velikost čipu, výrobní náklady = bude to levnější a menší. Samotná velikost by asi měla praktický význam pro zákazníka, kdyby se s tím změnšil socket a změnilo rozmístění chladiče....
Z tohohle pristupu (velka+mala jadra) me trochu mrazi.
Duvod ?
Protoze jsem vysledoval, ze i pri relativne beznych cinnostech (Browser - prepinani mezi TAB-y, Lightroom - reakce na slidery), STEJNY pocitac 6-gen HEDT, se jevi podstatene sviznejsi, pokud je vypnute snizovani frekvence pri nizkem zatizeni. Proste ten nabeh nejakou dobu trva (pokud to neni nabeh, tak rozpoznani ze je potreba vice "pary"). Poznat to je a to natolik, ze mam vytvoreny specialni power profil ktery nedovoli snizeni frekvenci pri necinnosti a ktery se aktovuje automaticky pomoci Process Lasso pokud bezi Lightroom.
Windows scheduler uz takhle stoji za vyliz p...., jinak to nazvat nejde. Kombinace malych/velkych jader + vyse popsany fenomen => horsi vysledek pro uzivatele.
1. Člověk si koupí procesor Intelu za velice výhodnou cenu, poloviční oproti AMD.
2. V základním plánu bude moci používat jen malá jádra.
3. Pokud bude chtít víc výkonu, Intel mu žádaný počet velkých jáder za poplatek odemkne.
4. Velká jádra si bude moci zapnout i dočasně za měsíční poplatek.
5. Tím se zužitkují bezpečnostní díry a zadní vrátka, protože se procesor prováže s bankovním účtem! ;)
Pozn.) Velká jádra budou stejná jako malá, jenom v substrátu namalovaná tlustší pastelkou ;)
Zdroj: ALUmináti
Jj mohli by ty procesory jen pronajímat, to by byl teprv kauf...
Ještě existuje jedno vysvětlení, že Intel bude konfiguraci 8 + 8 prodávat jako 8 jader 24 vláken (nechal by u velkých jader HT, malá jádra HT nemají), nebo 16 vláken (kvůli dírám by vypnul u velkých HT), nebo 12 vláken (vyplé velké HT, dvě malá jádra tvoří "jedno velké s HT")... no a další podobné divoké konfigurace včetně plných 32 vláken.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.