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.
"taktech detekovaných jako 1,38 GHz pro základní takt a 17,6 GHz pro boost." ...tak těch skoro 20GHz by bylo úžasných ;-)
Hlavne pre Slovenské elektráne, ČEZ a im podobné organizácie by to bolo dobré-
Ale výrobcovia kotlov by skrachovali..
Ten čip by mal spotrebu
okolo 16 320 W
Bez chlazení... Vlastně je ta spotřeba celkem v pohodě, nabIntel ;)
Celá ta spekulace je NP neboli naprostá pitomost.
Posun v desetinné čárce je při detekci naprostý nesmysl. Tam evidentně díky nesourodých vlakem špatně detekují frekvence spíš změřili jednou spodní frekvenci velkých a jednou malých jader.
17,6 GHz je frekvence velkých jader nebo malých jader?
Hádal bych spíš těch velkých.
Při frekvenci 17,6 GHz tato velká jádra dávají výkon 996 bodů v GeekBench 5, tedy na úrovni Skylaku na 3,9 GHz?
https://browser.geekbench.com/processors/intel-core-i5-4690k
Ale prd. Říkám, že to jsou podle mě spodní provozní frekvence a v tom případě 1,76 GHz je spodek toho velkého jádra.
Cituji první příspěvek: „Posun v desetinné čárce je při detekci naprostý nesmysl.“ Jak tedy z hodnoty 17,6 GHz vytvoříme hodnotu 1,76 GHz bez posunu v desetinné čárce?
Nemůžu zároveň vyvracet teorii o posunu v desetinné čárce a zároveň jí dál rozvádět.
po aplikacii occamovej britvy je riesenie jasne: je to totalne zakamuflovane, aby nebolo mozne vyvodit ziadne rozumne zavery o vykone a sucasne aby sa ziskala pozornost
tak to do**bali, ze ani diva srnka v case ruje (říje) netusi wo co go, nesedi ani jedno ani druhe ani tretie vysvetlenie, proste ziadne vysvetlenie nesedi, narast IPC o 56% oproti desktopovej rakete je blbost, 17,6 ghz je blbost na druhu ...
"Posun v desetinné čárce je při detekci naprostý nesmysl."
Proč? Co my víme, třeba v výpočtům používají desítkový ENIAC. ;)
redakce by mohla zablokovat ty dva nesouvisející profily: Alinalia a appu
První profil byl zablokovaný, ale obsah zůstal, takže jsem ho komplet smazal. Druhý profil nenacházím.
https://diit.cz/clanek/ryzen-9-5900hx-je-mobilni-delo-ryzen-5-5600h-nejv...
Aha, to nebyl nový profil, proto. Díky, smazáno.
16C/24T....nakonec ten ARMovský big-little není tak strašný, Intel ho překonal:).
eeh? dyt kofigurace 8+8 bylo prvni info co se o alderlake objevilo, ne? proc to jako puvodne melo bejt blby a ted je to dobry??
Nevěřil jsem, že v tom Intel udělá bordel i na úrovni vláken. Člověk instinktivně nevěří katastrofickým scénářům, i když jsou reálné. Pořád jsem to vytěsňoval, myslel jsem na něco jiného, četl raději o jiných CPU, učil se vařit a nakonec to stejně přišlo...
Procesory Alder Lake (Core 12000) tedy budou o 4 architektonické generace dál než současný Comet Lake (Core 10000) a o 2 architektonické generace dál než (na březen chystaný Rocket Lake (Core 11000).
tak tomu sa vazeni hovori mega-mrdnikovy super-bordel; a to este nerozoberam mobilne CPU kde kde ma clovek 10-th gen. ani dive svina nevie co to je:
Intel Core i5 10310U = Comet Lake, 14 nm
a sucasne
Intel Core i5 1035G1 = Ice Lake, 10 nm
(proste 10 na zaciatku znaci velke ho*no a nie novy vyrobny proces a/alebo novu mikroarchitekturu)
Doufejme, že se intel pochlapí, ale já zatím jsem spíše naladěn pesimisticky. Nevěřím na přínos Big.little a nevěřím, že by Intel byl schopen za 2 roky vytáhnout z rukávu takové eso.
Nicméně konkurence pro AMD by byla z pohledu zákazníků nanejvýše vhodná, byť z pohledu finančního "ztloustnutí" AMD a zrovnoprávnění OEM trhu by ještě rok či dva mohl Intel paběrkovat. :-)
Já se spíš obávám o AMD. Big-little může vzít AMD prvenství ve veškerém max. 16 vláknovém SW (98,5% veškerého SW v roce 2021?) a ta prohra v tom zbývajícím extrémním multithreadu bude nepodstatná, protože to většinu moc zajímat nebude a pro dobrý poměr cena/výkon bude mít Intel prostor.
Nechce sa mi veriť, že Alder lake tu bude do roka. Keď má Intel problém s Rocket lake-om, AL príde do pol roka od RL? Som zvedavý. A AMD snáď v marci 2022 príde so Zenom 4, ktorý v SC Alder lake snáď dobehne a v MC predbehne. A aj keď nebude každý chcieť 32vlákno, ale je rozumnejšie ísť do AMD so 16vláknom a časom vymeniť CPU za 32vláknový, ako kúpiť Intel s 8+8+8 a nemať možnosť dať viac jadier do danej dosky. BTW, koľko jadier bude mať Meteor lake?
„A AMD snáď v marci 2022 príde so Zenom 4, ktorý v SC Alder lake snáď dobehne…“
Abychom mohli mluvit o dobíhání, museli bychom alespoň tušit, jaké IPC bude mít Alder Lake a jaké Zen 4.
Buďto vycházíme z toho, že IPC Alder Lake oproti Rocket Lake stouplo o 56 %, a pak je nereálné očekávat, že Zen 4 oproti Zen 3 zvedne IPC o 45-50 %, aby ho mohla dorovnat nebo překonat.
Nebo vycházíme z toho, že IPC Alder Lake neznáme a tudíž ani nevíme, jaký nárůst IPC by Zen 4 musel mít, aby Alder Lake předehnal.
Snáď = verím. Nepíšem, že to tak bude, ale že by som chcel aby bolo. A 1 vec je IPC, druhá takty. Aj keby IPC bolo o 50% vyššie, musia byť aj takty vysoké, inak SC výkon o 50% nebude (toto aj očakávam). Som veľmi zvedavý aj na spotrebu 1. desktopového 10nm CPU.
No ako inžinierska vzorka na nízkych taktoch, ktorá v tom nepodarenom benchmarku (Geekbench 5) maskuje frekvenciou malých jadier, frekvenciu veľkých jadier, ale výsledok je výkon veľkých jadier...z toho nevyvodíš nič, iba to, že budú radi ak to bude + 20% IPC oproti "Rakete" a kľudne nech to beží aj na tom super 10nm++++ procese
Tak podľa všetkého je ešte v pláne aj ZEN3+, ktorý posunie IPC o cca 20-25%. A zen4 bude nová architektúra s infinity cache 2.0., podporou ddr5 a AMD pravdepodobne posunie každú prod.líniu o 2 jadrá dopredu. Ja sa moc o AMD nebojím.
Až také navýšenie u „refresh“ architektúry sa IMHO očakávať nedá. Ale keby, bolo by to super.
Ono je to síce len refresh, ale ddr5 a nové features am5 platformy určite pomôžu zvýšiť výkon. V podstate zen3+ je pre amd test nového 5nm procesu. A zen4 je úplne nová architektúra prispôsobená novej platforme takže tam si také zvýšenie viem aj predstaviť. Uvidíme či tam neintegruje aj nejaké fpga.
U Zen 4 nárast IPC môže byť zaujímavý, ale u Zen 3+ to nečakám. A Zen 3+ má byť na 5nm? Nezdá sa mi. Podľa videokarty.com má byť stále na 7nm procese.
Podľa wafer agreements má AMD vybavené prvé kusy 5nm waferov pre RDNA3 ku koncu roku a údajne pre prvú várku ZEN4. Nemyslím si, že sa jedná o zen4, ale o Zen3+, ktorý už má byť na novej platforme. Ale je pravda, že zen3+ má mať stále 7nm I/O. Preto je to niečo ako príprava na zen4 keď AMD musí mať už vyšperkovaný proces.
No, nevím, ale řekl bych, že masivně paralelizovatelné úlohy budou z 80% taky výkonově náročné. Je samozřejmě otázka, zda a nakolik se v takovém prostředí bude prosazovat sofistikovaná predikce větvení nebo velká cache. Jak jsem už psal, na koncept big.little v x86 prostředí nevěřím - ten se prosadil jen u ARMu, a to jen proto, že ARM neuměl udělat zároveň výkonné a úsporné jádro (tj. věc, která je bytostně vlastní oběma x86 vendorům a na níž pracovali od hlubokých dob Pentií).
Nedokážu si moc představit situaci/scénář, ve které by 1,5násobek malých jader podával výkon vyšší, než jádra plnotučná.
edit: a paradoxně na běžnou kancelář bude stačit i těch "málo" (4) plnotučných jader.
> Nedokážu si moc představit situaci/scénář, ve které by 1,5násobek malých jader podával výkon vyšší, než jádra plnotučná.
Ja jo - treba situace kdy je jadro 100% omezene pameti. Trebars, program vykonava nahodny pristup do pameti, takovym stylem ze L1/L2/L3 cache jsou neefektivni. Tohle se muze stat trebars pri specifickem druhu pristupu do obrovske databaze, nebo nektere druhy vedeckeho softwaru tohle delaji. Je docela snadne dokazat ze v tomhle pripade maji mala jadra temer stejny vykon (myslim ze nemusim rikat proc).
Kazdopadne mate pravdu v tom, ze tohle neni ani zdaleka obvyklej "scenar", a v desktopu temer irelevantni. A taky v tom ze ty mala jadra nebude podavat vykon plnotucnych jader. Duvod je jednoduchej: pokud mate "levnej kremik" tj vic tranzistoru (AMD ma), tak muzete proste a jednoduse podtaktovat plnotucne jadro. 10% podtaktovani vam da 90% vykonu se spotrebou mozna 50-60% (viz AMD 3900X vs 3950X).
Myslíš IO waity ? Tedy blbě napsanou aplikaci nebo navrženou architekturu ?
Ja by som bol radšej, keby sa Intel ešte nepochlapil. Nech AMD doženie straty, aby následník Radeonov 6000 už nVidiu výkonostne predbehol (t.j. aby AMD mal dosť USD na vývoj) a aby Zen 4, alebo 5 bol za slušnú cenu a nad Intelom ako kedysi bol Intel nad Visherou. Osobne neverím v úspech hybridu 8+8+8. Ako OS rozdelí zátaž medzi veľké jadrá, virtuálne jadrá a medzi malé? Presne tak, nech Intel ešte paberkuje ako kedysi AMD. Aj tak AMD ešte veľa % na trhu nemá.
ten vysoký posun IPC by pak dával smysl při použití menších jader - i tak by to stačilo na konkurenci a výrazně srazilo spotřebu. Vědce v Intelu určitě nenachali pobírat plat jen za docházku takže spousta věcí končila v "šuplíku" a čeká se jen na dořešení problémů s výrobou. Pokud to tak je a ten experiment s malými jádry naznačuje že je to velice pravděpodobné, tak je i jasné proč AMD tak šlape na plyn a využívá svoje okno příležitosti než se uzavře a začne tuhá konkurence. A ještě víc vynikne jak se AMD doslova v poslední vteřině zachránili.
Domnívám se, že jsi mimo mísu. Intel už dnes má menší jádra (cca 3 miliardy tranzistorů) než AMD (cca 5 miliard) a i přesto to nestačí - spíše naopak. Výkon dnes roste mj. díky navyšování cache a implementaci nových "superskalárních" instrukcí. To všechno stojí křemík a tranzistory. Nevěřím, že má Intel "v šuplíku" nějakou "zázračnou" technologii, která při menší velikosti jádra a nižších frekvencích navýší znatelně IPC. Stačí se kouknout na M1, z tohoto úhlu pohledu doslova brutálních 16 miliard tranzistorů a aniž bys byl superinža přes návrhy mikroelektronických obvodů, tak ti musí být jasné, že z trojúhelníku frekvence - počet tranzistorů - počet jader omezením jednoho nebo dokonce dvou parametrů větší plochu (výkon/IPC) prostě nevydyndáš. Ale klidně můžeš věřit, že Intělo má v šuplíku "zázračnou zbraň" na kterou nepřišli ani u AMD, ani v ARMu, ani v Applu. :-)
Apropos, jakou máš jistotu, že ty vědce v Intelu nechali pobírat plat a spíše je nevyhodili? Vždyť takový Jim Keller v Intelu vydržel jen 2 roky... Ostatně tristní stav jejich výrobního procesu ukazuje, že jejich inžové už dávno nekopou za áčko.
@DDR0: "Gracemont is the 4th generation out-of-order low-power Atom microarchitecture, built on the 10 nm manufacturing process. " Wikipedia
Pořád je to Atom, který byl primárně vyvíjen pro ULV mobilní segment. Zázraky bych od toho nečekal. A kdyby to bylo tak dobré, tak proč rovnou neudělají 16-32j monolit z těchto malých jader? Vždyť by to bylo vyrobitelnější (menší) a velmi dobrou spotřebou.
Mě by zajímalo, kde se ten nárůst IPC pořád bere? Větší cache nebo lepší prediktory? Kam až to může růst? Takty nám stagnují na 5GHz a myslím si, že IPC nepůjde zvyšovat do nekonečna...
Dá sa IPC zvyšovať cez inštrukcie?
Ideální instrukce trvá 1 takt. Tzn. Za to už nejde jít.
Pokud chceš víc instrukcí musíš jich zpracovat víc. Pak máš problém s predikci. Protože v jedno jádro může mít víc jednotek, ale jejich výsledek se řadí za sebe v nějakém pořadí.
Ideální instrukce trvá nula taktů. ;) Třeba MOV R1,R2 (v "abstraktním assembleru") se dá eliminovat ve fázi přejmenování registrů.
to na ARMech zase naopak - i v C a C++ je občas na nižší úrovni někde potřeba to nejkratší možné zpoždění. používáme "MOV R0,R0" namísto "NOP"u :-)
No jo, ale MOV R1,R2 je pořád jen instrukce assembleru, čili příkazem programovacího jazyka, který se přeloží do strojového kódu. Zde tedy jako žádná instrukce. A IPC se bere právě ze strojového kódu. Takže pořád platí, že 1 instrukci nelze provést za méně než 1 takt. :)
Ta instrukce ale v tom strojaku existuje. CPU ji ale vyhodnoti tak, ze misto jejiho provedeni se jen prejmenuji registry a ona instrukce se zahodi a nejde vubec do exekucni pipeline.
Ovšem i dekódovací pipelina běží dle taktů a za 0 se ani tahle "přejmenovávací" operace nezvládne, že?
Nastudujte si to z Agnera, tam máte dopodrobna rozebrané všechny instrukce, jejich latence a propustnosti pro jednotlivé architektury CPU.
https://www.agner.org/optimize/instruction_tables.pdf
Pro Coffee Lake a MOV r32/64,r32/64 uvádí latenci 0-1 taktů a reciproční propustnost 0.25 . Takže za určitých okolností je zřejmě může být přejmenovávací operace vykonána za 0 taktů.
Ano, ale i tam je potřeba dekódovací 1 μops. Jasně, že díky pipeliningu, branch prediktorům atd. se dá dosáhnout i efektivní propustnosti vyšší než 1 instrukce/takt, ale to nic nemění na faktu, že zmiňovaná ideální instrukce, která by měla v řádku v tom dokumentu samé 0, neexistuje. Nebo se špatně dívám? .)
Dekodovaci μops neexistuji. Pokud stiha frontend, tak je ta instrukce skutecne "free" - 0 μops v backendu.
Myslel jsem tím pochopitelně 3. a 4. sloupeček "The number of μops at the decode, rename and allocate stages in the pipeline."
Ano, technicky vzato, mate pravdu. Dekodovani apod. se ale do latenci instrukci nepocita, protoze to bezi paralelne a nezavisle. Pokud techto MOVu neni moc a neco "neucpou", tak skutecne vykon ovlivnuji jen neprimo (napr. zabranim mista v cache).
Navíc instrukční dekodéry běžně zvládají až dekódovat 4 instrukce za takt. Závisí to na konkrétní kombinaci instrukcí, jejich délce a složitosti.
Pokud ovšem už instrukce byly dekódovány dříve (např. v cyklu) a jejich mikrooperace jsou uloženy v 'trace cache', tak se z trace cache načtou jako celek a pošlou se rovnou do fronty na vykonání.
V dobře napsaném nebo přeloženém kódu je možné vykonávat více než 1 instrukci na takt současně, tj. IPC > 1.
To platilo mozno za cias povodneho procesora RISC1 (a tam asi ani nie) a mozno tak 386tky alebo 486tky. Dnes ziadna instrukcia nikde na niecom aspon tak velkom ako ARM 1 takt netrva. U RISCov trva tak 4 - 7 taktov, u x86 od 5 do nekonecna. Zvysovanie IPC sa deje paralelizmom na urovni procesora, kedy procesor rozpracuvava viac instrukcii bud striktne paralelne, alebo s roznym posunom v ramci toho poctu taktov, ktore instrukciu trva vykonat. Zvysovanie IPC potom teoreticky nema hranicu, lebo ked chcem, dam do procesora 15x ALU a v cisto teoretickej rovine budem mat 15x vyssie IPC ako keby som mal ALU len jedno. Co mi v tom brani? Teoreticky nic, ALU je relativne male, takze ak som ochotny obetovat kremik, mozem ho tam mat 15x, ak chcem. Prakticky je problem v tom tych 15 ALU vytazit na maximum. Bezne programy (a principialne vypocty) su dnes +- sekvencne, co znamena, ze aj ked mam napr. 15 aritmetickych operacii po sebe, tak casto jedna zavisi na vysledku druhej. T.j. ich nejde tak uplne paralelizovat. Da sa s tym spravit to, ze sa instrukcie vo fronte preusporiadaju tak, aby ich islo do procesora napechovat co najviac naraz. To sa da u tych instrukcii, ktore nepocitaju so vzajomne zavislymi datami. To ale vyzaduje do procesora pridat jednotku na reordering instrukcii, ktora je zrejme zlozitejsia ako samotne vykonne jadro procesora. Dalsia strategia je premenovanie registrov, ktora umozni uplne eliminovat niektore presuny, alebo skratit cestu dat v ramci pipeline.
Preco dnes nemame v procesoroch 15x ALU a IPC o 1350% vyssie? No jednoducho preto, ze prakticky je limitacia v tom, ako dobre sa da procesor vytazit. Rozne spekulativne techniky, prediktory a podobne umoznuju zvysit zaplnenie pipeline, ale to ide za cenu dodatocneho kremika.
Dalsi faktor specificky pre x86 je, ze x86 ako architektura v podstate neexistuje. x86 je dnes v podstate len frontend pre proprietarne procesory Intelu a AMD. To, co sa deje interne v procesore je prakticky nezavisle od toho, co je vidno zvonku. Mikroarchitekturu mozno dost zasadne zmenit bez toho, aby to malo vplyv na kompatibilitu s existujucimi programami a tym mozno opat zvysit IPC. Napriklad preto, ze nova mikroarchitektura moze mat interne vyssi pocet registrov, co umozni vacsi pocet paralelne vykonanych instrukcii vdaka dostupnosti volnych slotov na premenovanie.
Dovolil bych si nesouhlasit s tvrzením, že žádná instrukce netrvá jeden takt. Všechny základní operace jako sčítání, odčítání, bitové operátory atp. opravdu na současných x86 trvají (latence) pouze jeden takt. Dokonce včetně jejich SIMD verzí. Aby to bylo možné, musí být architektury celkem dost přizpůsobeny dané instruční sadě, takže to není jen o odlišném frontendu.
Př.:
2059 AVX2 :VPADDD ymm, ymm, ymm L: 0.25ns= 1.0c T: 0.08ns= 0.33c
(Skylake, vektorové sčítání 8x32b (256b) celých čísel - latence 1 takt, throughtput 3 / takt.
Zajimalo by me, za co mam minus, kdyz je to i s dukazem :).
Nevím. Všechny naše odpovědi dostali jeden mínus. Možná dokonce od stejného člověka ;-)
Čas od času se objeví nějaký „uživatel“, který se baví tím, že každému příspěvku v diskuzi dá mínus. Logiku za tím není potřeba hledat, děti nejsou ve škole a nudí se.
mozno je to buduci nadejny web vyvojar, skusa si tak nejake skripty :)
No základní předpokladem pro to aby něco bylo RISC je právě to, že instrukce trvá 1 takt. Proto také RISC CPU mají jednodušší návrh, méně instrukcí a více registrů.
Ve výsledku při dobrém kódu můžou mít vyšší výkon než CISC. Jak se měnily jak RISC tak CISC procesory tak se postupně prolnuli. Řada CISC měla vnitřně architekturu RISC a navenek se chovají jako CISC.
Naopak RISC už mají instrukční sadu skoro tak bohatou jako CISC.
Každopádně x86 (x64) ne všechny instrukce trvají jende takt. Problém je, že jejich zapracování do CPU tak aby jeden takt trvaly, by bylo velice náročné na křemík.
Přidávat ALU do nekonečna taky není řešení, protože každá další jednotka komplikuje predikci, stejně jako nefunguje přidávání dalších FPU a MMU jednotek. Je to dáno tím, aby to mělo smysl, musela by INT instrukce trvat například polovinu času co jedna FPU.
Takže než proběhne FPU instrukce, zpracují se dvě INT instrukce. Nejde to, ale vždy. Od toho jsou predikce a řízené větvení kódu.
Problém je, že predikce taky zabere nějaký čas. Navíc k tomu potřebuje práci s cache tem do toho vstupují latence. atd.
Takhle lze pokračovat až do nekonečna.
> No základní předpokladem pro to aby něco bylo RISC je právě to, že instrukce trvá 1 takt
... wat ? jsem si na 98% jist, ze podle tohodle kriteria zadnej RISC procesor nikdy neexistoval :)
Ačkoli x86 je za dekodérem instrukcí stejný RISC jako např. ARM, i ten dekodér má vliv na IPC. Konkrétně x86 (64bit) je prakticky limitovaný dekódováním 4 instrukcí za cykl, zatímco ARM (64bit) zvládne 8 (nevím, jestli půjde časem jít i výš - Apple M1 je koneckonců jen lowend, tak uvidíme). x86 to obchází 2 dekodéry na jádro (HT - hyperthreading), tj. jednojádrové IPC je podobné M1, ale jednovláknové je menší.
PS: Už 486 se chlubila, že základní operace zvládá za 1 cykl. Pak následoval slepenec 2x 486 v prvních Pentiích a nakonec to vzdali a šli cestou AMD (K5 je RISC s CISC frontendem - bohužel si to pokazili nepipelineovaným FPU, které zabilo výkon v Quake 1 - plus pár chyb v jiných hrách kvůli ne úplně dokonalému překladu z CISC na RISC).
Ohledně max IPC mají stále x86 CPU velké rezervy, viz. Apple M1. Na anandtechu je rozbor architektury M1 včetně odhadu velikosti datových struktur potřebných pro dosažení vysokého IPC.
Instruction decoder
M1 - 8-wide
Intel & AMD - 4-wide
Out of order window
M1 - 630 instrukcí
Intel Sunny Cove - 342 instrukcí
AMD Zen3 - 256 instrukcí
Výkonné jednoty
M1 - 6-ALU
Intel & AMD - 4-ALU
https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2
Jó ALU, těch není nikdy dost:).
Pak ještě zrušit (při návrhu architektury) všelijaké SMT, které nikdy nebude blbuvzdorné a jedem dál.
To je dáno instrukční sadou.
ARM jí má daleko menší a tím pádem si může dovolit dělat některé věci jinak než X64.
To, ale neznamená, že to bude fungovat pořád a vždy.
Navíc v přepočtu na tranzistory si M1 moc dobře nevede.
Nesmíte brát celkový počet tranzistorů M1. Nezapomeňte, že je tam i výkonná iGPU, oproti x86 taktéž výkonný ISP (Image Signal Processor - např. proč je editování a kódování videa na lowend M1 tak rychlé i na fanless zařízení), k tomu NPU a rychlé I/O (např. integrovaná široká RAM). Navíc cena (za počet tranzistorů) je diskutabilní - SoC je sice o dost dražší než v PC, ale protože je celý od Apple, tak si za něj nemusí účtovat marži (účtuje si až tu za finální výrobek).
EDIT: To s tou marží není specifikum jen Apple. Dokud USA nezakleklo na Huawei, tak to dělali taky (výkonnější SoC než konkurence v dané cenové kategorii). Možná proto byli úspěšní (nevím, moc mobily nesleduju).
ISP uplne nesouvisi s kodeky, byva to vec ohledne reseni live kamery. Ale nevylucuji, ze apple tam ma svuj hw kodek, pro ProRes / ProResRAW, coz je vec, ktera v hw jinde neni, a testy tomu napovidaj (napr. v BRAW to je totalni propadak, a v PRR to exceluje)
Siroka RAM? Vzdyt je tam cca 128bit LPDDR4, takze klasicky ekvivalent dual channel dimm, jen taktovan vyse, kvuli onboard pajeni (spis by-package, protoze za PoP bych tohle reseni co maj nepovazoval). I nvidia TX2 ma podobne sirokou pamet, a rekl bych ze mozna i silnejsi GPU.
Jak to je s instrukční sadou těch malých jader u golden cove? Stále má být jiná než u velkých? Pokud ano tak se bojím že v testech to bude pěkné, ale v reálu tam budou skoro k ničemu. Samozřejmě by to využít šlo, ale s ohledem na dnešní SW svět nic moc.
No pokud by byla stejná nebyly by to malá jádra ;)
Bohuzel ma byt stale jina/horsi. Nastesti uz ne tak orezana, jako driv (ma podporovat napr. AVX2), ale vypada to, ze si budeme muset vybrat, jestli chceme mala jadra, nebo lepsi instrukce (AVX512 atd.). Oboje soucasne nepujde.
Pokud nějaký software detekuje u neznámé architektury 2 frekvence a jedna z nich je naprostý nesmysl, tak proč očekávat, že to druhé naměřené číslo je zcela správné a dá se dle něj vadná hodnota opravit a dělat přesné výpočty trojčlenkou?
17,6 : 4 = 4,4GHz :-)
To by bylo IPC pod úrovní Skylake. Smysl by dávalo 17,6 : 8 (což je shodou okolností počet velkých jader) = 2,2 GHz, což by znamenalo IPC 25 % nad Rocket Lake.
BTW, dajú sa frekvencie Alder Lake-u „vypočítať“? 3. gen. 14nm procesu alias Kaby lake nemala vysoké frekvencie (a to šlo o 8t), tak tretí 10nm proces IMHO tiež nebude mať 4,7 GHz u 16vláka ako Commet lake. Alebo sa úplne mýlim?
Pokud AMD honi Zen3 ve 7nm TSMC kolem 5 GHz, tak bych ocekaval ze vyladeny 10nm Intel proces tohle dorovna (s rocnim az dvouletym odstupem - v dobe uvedeni AL).
Těch 50% dává smysl. Alder Lake je ve skutečnosti takový Buldozer, a každé to malé jádro je spárované s velkým, aby si v případě potřeby mohlo využít možnosti toho velkého - přehodit na něj svoje vlákno. Takže single thread není výkon jednoho velkého jádra, ale spojený výkon velkého a malého.
No, možná je to blbost ...
to by dávalo (výkonově) smysl, méně pak už při přepočtu na plochu a hlavně počet tranzistorů.
Jenže jak chceš spojit výkon dvou (navíc odlišných) jader u ST aplikace?
Musel by tam být řadič, který je schopen poslat instrukci na libovolnou jednotku. Proto by to muselo být společný jako u Buldozeru. Ty základní jednotky (ALU) se asi moc lišit nebudou.
Taky si myslim, ze by to slo udelat "chytre", namisto armoveho big-litle, kde jsou mala/velka jadra vedle sebe, tak by si Intel mohl rict, ze ten nahromadenej reoder balast udela on-demand. Tj. pri pozadavku na beh zakladu OS / nekriticke ulohy / se to bude chovat jako in-order cpu, s veskerou chytrosti uspanou. V pripade ze spotreba stoupne, tak podobne jako u AVX, se zapne power island a jednotka ktera tohle resi - tak tady se zapne ta chytristika v podobe reoder jednotky a stane se z toho slusne chroustajici velky CPU.
(ale z praktickeho hlediska, je porad asi lepsi stridat cela hotova jadra, nez delat tu runtime zmenu z in-order na out-of-order).
No ale tohle řeší tak max. spotřebu, ale ne výkon (natož jeho "znásobení"), tam dojde spíše k navýšení latencí.
"50% zvýšení IPC" <= Neuvěřím, až dokud nebudou dostupné nezávislé testy. Mě by ani v nejmenším nepřekvapilo, kdyby Adler Lake přišel až v roce 2022.
Dále se tu v článcích i diskusích řeší jen ta velká jádra, ale velké divadlo asi nepůjde uhrát pokud ty malá jádra (Atomy) Gracemont nebudou podobně pokročilá jako ta velká, tedy o pár úrovní dál než je Tremont či Goldmont Plus. Pokud je mi známo, tak se na ně žádné ódy nepějí.
http://en.wikipedia.org/wiki/Gracemont_%28microarchitecture%29
Taky mi přijdou pofidérní ty Intelovy architektonické skoky ...
4 generace Skylake (Kaby lake > Coffee lake > Comet lake)
žádné generace Palm Cove
1 generace Sunny Cove (Ice lake & Rocket lake)
1 (mobilní) generace Willow Cove (Tiger lake)
1 generace Golden Cove (Adler lake).
To muselo lézt strašně do peněz, když mezi lety 2015 a 2020 stačila jediná architektura Skylake a nyní mají X architektur a produkty z nich jsou dostupné jen ve velmi omezené míře.
Vůbec by mě nepřekvapilo, kdyby ty "architektury" Palm Cove, Sunny Cove a Willow Cove byly v podstatě totéž, co byly "generace" architektury Skylake ... Tedy by šlo o pokusy dodat produkt, který nějak ne a ne vyjít - přinejmenším ne tak, aby saturoval všechny tři hlavní segmenty (desktop, mobilní a servery).
Ty architektury byly vyvinuté ještě před problémy s 10nm procesem, jen nastal problém s jejich realizací. SunnyCove byla hotova (na papíře) minimálně v roce 2016.
PalmCove - něco mezi Skylake a SunnyCove, spíše blíž ke Skylake
SunnyCove - dost velké změny
WillowCove - SC s předělanou L2 cache a pár dobnostma
GoldenCove - nejspíš opět velké změny v architektuře
4 generace Skylake (Kaby lake > Coffee lake > Comet lake) = žádné změny, jen optimalizace 14nm procesu?
Hlavně Intel za ty roky nedodal žádný produkt na 10nm do desktop / server segmentu. Není přehnaně optimistické, že by to nyní měl být schopen vyrábět půl roku poté, kdy uvádí původně 10nm architekturu předělanou na 14nm?
Vydání architektur vyvíjených pro 10nm proces bylo podmíněné dokončením použitelného 10nm procesu. Ten nyní Intel má, takže může každý rok přijít s novou architekturou (což se děje):
2018 - Palm Cove
2019 - Sunny Cove
2020 - Willow Cove
2021 - Golden Cove
Intel má 10nm proces od roku 2018, proč by to nyní mělo být jiné? Zatím se zmohl jen na mobilní čtyřjádro, nic většího / výkonějšího ani v náznacích za dva roky co má tento proces nepřinesl.
Protože to není tentýž proces. Intel několikrát začal s vývojem znovu a současný proces používaný pro Tiger Lake má zcela jiné základy než původní používaný pro Cannon Lake. Současných 4,8 GHz na Tiger Lake je dost jiných než 3,2 GHz na Cannon Lake. 50% posun taktovacích frekvencí během dvou let dalšího vývoje je myslím dostatečná ilustrace toho, že „by to nyní mělo být jiné“.
HOLLY: Dobrá otázka! Došlo k chybě ve výpočtu. Moje IQ je vyšší, ale životnost se zkrátila geometrickou řadou.
TOASTOVAČ: Takže, jaká je tvoje životní prognóza?
S pípnutím na obrazovce naskočí údaj:
ŽIVOTNÍ PROGNÓZA: 3,45
TOASTOVAČ: Tři sta pětačtyřicet let? No, to je lepší než pár facek přes plotýnku.
HOLLY: (Ustaraně) Je tam desetinná čárka.
TOASTOVAČ: Zbývá ti jen 3,45 setin let života?
HOLLY: (V panice) To nejsou roky, ale minuty: 3,41!
TOASTOVAČ: Mám otázku: Co s tím, u všech toastů, uděláš?
HOLLY: Abych si nevyplýtvala čas, který mi zbývá, tak se radši …vypnu.
Abych se taky vyjadril, ikdyz teda tipovat vykon Alder Lake, kdyz jeste nevysel Rocket Lake, se mi zda mirne predcasne.
Ja proste smyslu big.LITTLE v desktopu nerozumim. Sice tady budou zeleni uzivatele Intelovu setrici architekturu jiste milovat, ale ja teda ne!
Bud v desktopu potrebuju vykon nebo potrebuju setrit. Vzdyt dneska existuji kancelarske Atomy pro ultrabooky a ono to dost dobre na tu kancelar staci. Naopak, kdyz potrebuju na pocitaci cele dny renderovat grafiku ci enkodovat video, proc mam platit za naprosto zbytecna mala jadra? Ja potrebuji predevsim ty velka jadra, ten vykon a nejake cicmundy navic tam vubec nechci a hlavne za ne nehodlam vydavat zadne penize. Ze by Intel daval jadra Gracemont zdarma, tomu neverim. :-)
Proste big.LITTLE v mobilu nekde na cestach na baterce ok, ale na desktopu kdyz mam stavu ve zdi trvale, proste ne. Muj nazor a netvrdim, ze se nemohu mylit, tak mozna muj tip nejmene tri ctvrte roku pred vydanim, bude to pro Intel konecna. Minimalne v retailu definitivni tecka, ktera jim v tom segmentu znacku zakonci. Herni procesor pak uz jen od AMD. :-/
bigLittle na desktopu je jen pokracovani v trendu pokryt co nejvetsi rozsah spotreb a vykonu - viz vyvoj:
- speedstep - budem setrit snizovanim freq/vykonu v idle
- turbo / tvb - budem vykonnejsi, kdyz to nahodou pujde
- biglittle - nuzky se dale rozeviraj - setrnejsi (kdyz je potreba) i vykonnejsi (kdyz je potreba)
Jenze snizeni frekvence nebo turbo (mimochodem kdysi bylo turbo na PC skrini primo jako tlacitko), to je jen o par obvodu navic, ktere to ridi. S bigLITTLE at jde Intel nekam, ja nejakou univerzalni "kravu" nechci, mne "staci" jen vykon! :-)
Jestli budeš chtít výkon, tak si koupíš CPU jen s velkými jádry. Dělají se i notebooky s desktopovým CPU a GPU, takže výběr je i tam.
kdyz mas TDP rekneme 65W, tak to podtaktovani v idle to stahne na 10W, a pretaktovani v turbo na 120W.
biglittle ti dovoli jit pod 1W u spodni hranice.
Cil je prosadit vicero always-on zarizeni (neco jako mobily)
S tim turbo se pletes - to nebylo zadne turbo, ale podtaktovani kvuli kompatibilite se staryma hrama, ktere bezeli moc rychle :-)
Proč by nemělo být možné se u podtaktování dostat na cca 1W? Vždyť už dnes to je možné - stačí stáhnout frekvence sběrnic/jader/cache/RAM, vypnout nepoužívané části procesoru. Další věc je, že "velký" počítač nebude mít nikdy tak nízkou spotřebu jako jednočip v tabletu/mobilu, a to právě kvůli věcem jako sběrnice a komponenty navěšené na nich, plus "velký" zdroj typu ATX - to prostě tak nízko nedostaneš. Stačí se kouknout, jak dnešní idlující herní (!!!) PC atakují spotřebu cca 50W - a to se tam typicky vrtí ventilátory, jede velký ATX zdroj, minimálně jeden disk a herní grafika. Nějaký G-čkový ryzen se pak tutově dostane na cca 35W (bez diskrétní grafiky). I kdybys stáhnul těch cca 10W, tak 25W nebo dokonce 40W nebude nic, zásadního pro běžného počítačníka a pro IoT (always on) použití je to zase stále až moc.
Když to vezmu z opačného gardu: jako router mi slouží PCengines APU2, kde jsou 4 jaguáří jádra, 4GB RAM a 3 síťovky (všechny využity). I s 256GB mSATA SSD je spotřeba max. 10W a výkonu to má na síťařinu habakuk, dokonce se na tom dá s určitým sebezapřením i virtualizovat linuxový desktop s klikacím GUI a RDP.
Jestli máš pár desítek mega $$ na vyhození, objednej si u Intelu nebo AMD procesor na míru. Jinak budeš muset vzít za vděk tím, co Intel s AMD uvedou na trh.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.