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.
aneb klasika, ktera uz tady byla tolikrat, ze uz to ani vtipny neni
Kouřovou clonu kvůli konkurenci asi nepouští. AMD už delší dobu jede po své trati celkem bez ohledu na to, co předvádí Intel.
Nebyt 2/3 notebooku jenom s intel procesory, je intel v prdeli i tam, i tam jiz leta neni konkurencni!
Mel jsem par hernich laptopu s i7 nez jsem presel na Ryzen. Vsimnete si narustu vykonu.
2014 Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz / 650M
2017 Core(TM) i7-6700HQ CPU @ 2.60GHz / 980M
=> average cpu score +3% cpu.userbenchmark.com
2019 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz / GTX 1050
=> average cpu score +7% cpu.userbenchmark.com
AMD Ryzen 5 4600H / 1650
=> average cpu score +29% cpu.userbenchmark.com
Ten posledni laptop me stal mene penez nez ten predchozi s i7 a je to 6ti jadro. Muzete namitat ze to neni fer atp., ale to je problem Intelu ze v obdobi 5 let nebyl schopen uvest neco lepsiho nez 4 jadra s HT a ze je drahy. A to nemluvim o zanedbatelnem mezigeneracnim narustu vykonu.
Chlapci u Intelu budou mit co delat, jinak by to byl dalsi epic fail.
Snad jde jenom o nejake rumours.
zopakuje sa situcia ako i9 10900K vs. i9 11900K ... tam klesol pocet jadier o 20% (z 10 na 8) ale frekvencie o tolko nestupli, takze to nestacilo kompenzovat multiT vykon, takze v multiT 11900K zaostaval sa 10900K
tuna problem nejsu jadra (ich pocet klesat nebude), ale frekvencie a HT ... ak bude raketa refresh 8P+16E 14900K(S) aspon symbolicky vykonnejsi od rakety 8P+16E 13900K(S), tak potom sip 15900K(S) v konfiguracii 8P+16E bude naozaj epic fail (ako pri 1T tak aj multiT), pokial sa nedostanu aspon nad 5,5 ghz single core a nebude to mat HT alebo aspon 24E miesto 16E
proste od roku 2017 sa intel stale nevyhrabal zo sraciek a stale to neni ten technologicky lider, ktory hravo lavou zadnou drtil AMD (hlavne v obdobi 2011-2017 ked AMD nemalo nic ine len Stabevne Stroje), vtedy sa robila sranda ze 8-kvazi jadrak 4-modulak 8C8T alebo 4M8T 8370X v multiT ani nestaci na 4C8T haswell i7 4770K/4790K, a 1T vykon bol absolutna katastrofa, cca polovica 1T vykonu intelu
Nechapu, ze nejsou schopni restartovat vyvoj vyrobnich procesu. Pri jejich zdrojich money/stuff to je nepochopitelne.
Stavebni stroje snad radeji radsi nepripominejte, ty nebyly konkureschopne vubec.
Peníze ti jsou k prdu, když máš takhle zazmrdováno.
A kam chcete ísť
Kremík
Atómový polomer 111 pm = 0,111 nm
Atómový priemer 222 pm = 0,222 nm
Van der Waalsov polomer 210 pm = 0,42nm priemer
Ak máme 2nm technológie teda hustotu ako pri dĺžke hradla 2 nm = 2 000 pm
a urobíte chybu pri návrhu "obchádzania fyziky" ako napr. GAA atď. , tak nemáte čo reštartovať.
Problémem moderních procesorů je velmi tenká vrstva dielektrika, ta má u 65nm procesorů tloušťku pouze 1,2nm, což odpovídá pěti vrstvám molekul SiO2!
https://www.svethardware.cz/intel-uvolnuje-dalsi-informace-o-45nm-proces...
Jenze Intel zaostava, proc?
Lebo si zle vybral cestu pri 10 nm a návrat je nemožný
uz sa zobudme vsetci konecne
"x nm technologia" uz pol druhej dekady NEZNAMENA ze nieco je velke x nm
uz prinajmensom taku dlhu dobu to znamena 1/3 sirky brany ci hradla ci coho ... aj v dneskych 3-gate FinFET tranzistoroch, t.j. najmensia struktura je tam minimalne 3x vacsia
aj dnesne najpokrovejsie tranzistory vyrabane tzv. 5 nm technologiou (alebo 4 nm co je iba 5 nm+), maju plosne rozmery celkovo cca 50 nm X 50 nm
Nezda sa ti ze 16 rocny clanok o planarnych tranzistoroch je "troska" out? Uz 9 rokov existuju FinFET tranzistory, kde su veci inak.
S přínosem HT nesouhlasím. Právě ty malá jádra to zastoupí v řadě situací.
RedgamingTech plácá často.
V tomto případě bych jim i věřil. Stejně jako na Skylaku zvládnul Intel postavit 5 generací procesoru, nezbývá mu se o to samé pokusit i u Alder Lake. Změny i u 4. generace jsou zcela minimální a někdy mají i své negativní důsledky.
Že by to mělo Intel ve chvíli,kdy nasadí AMD nový Zen 5, nějak výrazně poškodit, si taky nemyslím. Intel už je tak poškozený, že už to ani víc nejde. Nálož, kterou dostává od Zenu 2 je taková, že už si asi na to, že jsou béčka i zvyknuli. :-)
'' S přínosem HT nesouhlasím. Právě ty malá jádra to zastoupí v řadě situací. ''
nonsense.. zadny maly jadra ho nezastoupi protoze tam zadny maly jadra navic nejsou.. je jich tam 16 stejne jako u raptoru.. takze vypnutim ht na velkejch jadrech se cast multithread vykonu nenavratne ztrati..
Žeby ďalšia generácia vhodná iba pre notebooky (po Meteorickom jazere). "Šípové jazero" je zase len evolúcia "meteorického jazera", Intel asi stále neriešil dôležitú vec a tým je pomer výkon/tranzistor. Keď to urobí, tak tam dostane viac silných jadier a malé potrebovať nebude...lebo si ich urobí z veľkých jadier s osekanou L3 cache, tak ako AMD.
To je myšleno jinak.
Máš HT, teda část cesty dat rozdělíš na dvě cesty, ale někde to zase spojíš a v tom místě vzniká úzké hrdlo, protože dál jedou data zase po stejné cestě. Od tohohle úzkého hrdla je ale silnice spravená a teda se tam jede rychleji. Dává smysl teda mít ten procesor rozdělený tak, že část jsou dvě cesty, které se spojí do jedné lepší cesty. Celkově to zvyšuje výkon v průměru o 25%. Jestli někdo říká až 40%, tak přehání.
Teď si představ, že budeš mít procesor se dvěma oddělenýma cestama, jedna bude pro rychlá auta (P Core) a druhá pro náklaďáky (E Core). Nedává smysl vůbec na cestu pro rychlá auta pouštět náklaďáky, takže dává smysl HT vypnout úplně.
Když teda z těch dvou rozbitých cest jednu zavřeš a i na té navazující rychlé cestě projede nejvíc tolik dat jako po té jedné rozbité cestě, přicházíš o 25% výkonu té kvalitní cesty. Jenže ty máš vedle úplně oddělenou druhou cestu, kam pouštíš pomalu jedoucí náklaďáky, takže zase na druhou stranu klidně nějakých 25% výkonu získáš zpátky, protože tu hlavní cestu ti nic nezpomaluje.
Problém je, umět manažovat cesty tak, aby ti na hlavní cestu nenajel žádný pomalu jedoucí náklaďák. A naopak, aby nepustili na pomalou cestu mezi kamióny nějaké ferrari. To je asi pro Intel velká výzva. Nakonec ale to je jejich problém.
Je zřejmé, že AMD má výhodu, že tohle řešit nemusí. U Intelu ale vypnutí HT dává smysl a už ho lidi vypínali od Alder Lake, protože přínos byl sporný díky té intelovské biglittle technologii. Že je to celé takové splácané, o tom se nemusíme bavit, to nějak tak asi tušíme tady všichni.
Tak to ale úplně není. To "úzké místo" není tak úzké, že zvládne jen jednu "odbočku". Zvládne víc. Navíc obě odbočky koukají do stejné L1 cache. Snahou je, aby se ono "úzké místo", které je relativně levné, neflákalo a bylo neustále krmené.
Takže otázka HT nebo light-jádro je postavená především na množství křemíku, které je potřeba.
Přínos HT v úplně obecném výkonu je cca 15% (generický provoz ve VMware). Ve specifických úlohách může být až desítky procent - omlouvám se, příklad nevím ...
Ano. Moderní desktopové a notebookové procesory maj už hodně dlouho dost velká jádra. Takže záleží na aplikaci, kolik výpočetních jednotek využije. Výpočetní aplikace se snaží využít jich co nejvíc (což mimochodem se zakázaným AVX-512 nejde) a běžné a business aplikace zas využívají minimum (jsou skalární a out-of-order má limity, když další kód závisí na výsledcích předchozího). Takže tady máme servery, kde CPU jen manažuje data pro spousty GPU, servery s AVX-512, kde se počítá na CPU, a servery, kde běží současně tuny business software, kterému ani SIMD 1024bit nepomůže. IBM tak pro use-casy svých zákazníků může bez obav nabídnout i SMT8. Proto je zavádějící říct jedno číslo bez vysvětlení - HT přináší někde jednotky procent, někde desítky. Záleží, na co to potřebujete.
IBM SMT 8 ale funguje jinak, technicky to jsou malá jádra seskupená do velkého s některými společnými prostředky. Hlavní rozdíl je v tom, že u IBM Power je výkon jednoho vlákna jasně definovaný, ale současně i dost malý (je to po jedné ALU, skalární FPU, vektorové, maticové a AGU jednotce + asi Load/Store pokud ta už není sdílená) Je to tedy sice plná výbava, ale velice úzké jádro.
Ano, SMT/HT je o tom, že něco je 2x (až 8x) a něco sdílené. SMT je symetric, takže jak říkáš, jasně definovaný výkon (což tedy omezuje ST výkon). Ale maj to spočítané pro use-casy svých zákazníků - skalární business aplikace, které třeba půlku času stejně čekají na I/O.
IBM Power byly v minulosti i základem superpočítačů a tam to čekání asi moc neplatí.
Minimalizování toho čekání je půlka práce na těch superpočítačích, a i tak je přenosová rychlost násobně pomalejší než CPU.
jinými slovy se to hodí na hodně specializované aplikace která se používají hlavně na práci u (polo)profesionálů. Jinak to málokdo používá denně. Co jsem vypozoroval tak smysl má SMT/HT/ tak do šesti jader kde fyzických vláken je málo a také je to i při plné náloži normálně uchladitelné. Od každého jádra navíc je to horší, tedy pokud nehodláte provozovat na nějaké frekvenci kolem 3Ghz. Dalším problémem SMT je bezpečnost jak se ukázalo poslední roky.
Proto AMD i Intel do serverů místo použití SMT preferují menší jádra než aby si ztěžovali život s jejich virtuálním zdvojováním. AMD ZEN 4c a Crestmonty v Sierra Forest (ty už lze obtížně nazvat "Atom" podle původní definice jak se zapsali jako něco hodně pomalého). Přijde mi to rozumné kdyby SMT nakonec potichu opustili - vždyť jader je v mainstreamu tolik že není třeba jádra mučit tak aby se žhavil každý jeden tranzistor. A další výhoda vypnutí SMT je zvýšení frekvence jádra o nezanedbatelných několik set Mhz.
I tak je malý zázrak, jak dlouho se SMT udrželo, když vezmu, že počátky jsou v 50. letech u IBM a u mikroprocesorů už se používá hezkých pár desítek let.
tak zpočátku to byla hodně fajn funkce, zvlášť u prvních P4 - dvě vlákna znamenala že když se nějaký proces zaseknul neznamenalo to jako na čistém jednojádru že PC se musí natvrdo restartovat. V zásadě až do čtyřjader to bylo vítané, neznamenalo to jako u 6+vysoké nároky na chlazení.
Můj názor je že jak se MT rozšířil na 8+ jader už SMT pozbývá smyslu, tedy u domácích uživatelů určitě.
Teoreticky ho mohu vytížit i já komprimací či tvorbou záloh, ale to nedělám každý týden a taky je pak slabý článek jinde - posílá se to do externího úložiště s 10Gb USB a tam to při 12+ jádrech se SMT už nestíhá zapisovat - a po cca 100GB ochabuje i zápis do TLC...
Až na to že původní myšlenkou MT dost přesahovalo domácí uživatele. Když si vezmu, že ten výkon "navíc" vlastně zvedá energetickou efektivitu, jsou primárním cílem servery.
V době malého počtu jader to řešilo čekání vláken na I/O, aby systém dál fungoval. Naopak v serverech se tato tehdy neodladěná technologie vypínala, protože výkon jader byl tehdy ještě méně prediktivní než dnes.
Tím se nabízí otázka o jaké době a jaké architektuře vlastně píšete? Ty první CPU u kterých k nasazení došlo byly RISC, když pominu fakt procesory skládané z jednotlivých samotných obvodů, u kterých to začalo. A tady právě vznikly i ty pokročilé metody zvyšující výkon jader obecně. Podívejme se na můj oblíbený a nikdy nevydaný DEC Alpha EV8. Prakticky dvojnásobné jádro proti EV6 a EV7 (ty se lišily hlavně výkonnějším řadičem RAM) Tedy ze 4 ALU. a 2. FPU na přesný dvojnásobek, ale z jednoho vlákna na čtyři. Tedy žádný vámi uvedený problém, naopak při teoretickém dělení prostředků symetricky na 4 naopak ještě zjednodušení. A v dalším vylepšení Tarantula další tři kroky k vyššímu výkonu - nárůst taktů na dvojnásobek, dvě jádra v jednom pouzdře a vektorové jednotky v jádře.
Pokud ta SMT jádra jsou na to stavěná dobře, úzké hrdlo nemají. Intel si úzká hrdla u původních big.LITTE udělal sám nemožností využít 512 bit vektory velkých jader a tím jak do struktury velkých jader přidal klastry po čtyřech malých jádrech s velkou latencí jejich přístupu na společnou sběrnici. Nevím, co z toho Intel dokázal nějak opravit a co vůbec eliminovat šlo. Ale do značné míry tím vyrušil část teoretických výhod smíšené architektury. Kdyby se soustředil na nový výkonná jádra, ale s menší plochou a lepší efektivitou, udělal by asi lépe. A možná i větší plocha a tedy šířka v kombinaci s nižším taktem by fungovala lépe.
Je neuvěřitelném, jak dlouho se Intel dokáže v tom plácat. Finančně to samozřejmě ustojí, ale za pár let tady budeme mít celou dekádu sračkových CPU, a to se holt zapíše do paměti všem, i kdyby to pak už nebyla pravda. AMD s AVX-512 dokázalo obejít limit dekodéru instrukcí x86 pro ST výkon* a s HT jeho limit pro MT výkon. Na Intelu teď nefunguje ani jedno z toho, takže pokud zrovna nepapá stovky Wattů, tak mu dá na prdel notebooková verze čipu z iPadu.
EDIT: *) Jsou i procesory, které dekódují AVX-512 instrukce za 2 cykly (myslím že ten čínský x86). Tam samozřejmě dál platí omezení x86 na pomalém dekodéru.
Nuz ale tento pohlad na multi-threading je uplne zly. Pri SMT sa veci realizuju bud tak, ze:
1) sa vytvoria dve pipeliny, dva registrove subory, dva prefetchery a dve sady load/store unitov. a to sa pripoji na zdielanu L1 cache a zdielanu sadu ALU, FPU, vektorovych jednotiek. Tych jednotiek je tam viac, pretoze procesor je superskalarny a dokaze spracovavat viac instrukcii paralelne. Ale zriedkakedy dokaze vyuzit jednotky vsetky. Takze pridanim druhej pipeline sa zvysi vyuzitelnost jednotiek. Ak sa do kazdeho jadra prisype z kazdej jednotky este jedna - dve navyse, obe vlakna maju rozumny vykon a stoji to menej kremika, nez dve samostatne jadra.
2) Niektore RISC procesory, napr. SPARC pouzivaju system barrel-roller. Viac front-endov (L1 cache, dekoder instrukcii) je pripojenych na jednu pipeline a na striedacku do nej pchaju instrukcie. Front-end, ktory je z akehokolvek dovodu stallnuty sa preskoci. Pipeline je otagovana, takze je jasne, ku ktoremu threadu ktora instrukcia patri. Vyhoda je, ze jadro je este mensie, pretoze sa zdiela aj pipeline a pri vacsine zatazi sa rozbiju zavislosti medzi instrukciami, takze je pomerne trivialne napchat do pipeliny viac spustitelnych instrukcii a jadro rozsirit.
Ani v jednom, ani v druhom pripade sa vlakna navzajom totalne neblokuju. K blokade (stall) moze dojst v pripade, ze obe jadra vykonavaju kod, ktory zatazuje vyssi pocet napr. ALU, nez je v tom-ktorom stave k dispozicii. Ako to procesor vyriesi je implementacne zavisle. Ani front-end ani back-end sa vzajomne neblokuju.
Ziadny pomalu jedouci nakladak sa nekona.
A stejně to nestačilo a FUJITSU přešlo ze SPARC na ARM. Zajímavých jader, když připočteme i ta, která už se do výroby nestihla dostat je z minulosti i současnosti dost. Jen asi neexistuje ani teoretická možnost udělat takové, které by umělo všechna možná vylepšení současně a to už proto, že se některé techniky vzájemně vylučují a jiné jsou zase blokována patenty a licencemi. Ale docela by mne takové ideální jádro zajímalo.
Já myslím, že šlo hlavně o podporu ze strany software. Prostě pro SPARC už nikdo neoptimalizoval, takže i kdyby ten CPU byl o něco efektivnější, tak to ztratí na neoptimálním software, často dokonce o víc, než kolik přidal svojí efektivitou. Mimochodem ta ARM jádra nejsou Cortexy (v té době žádné se SVE neexistovaly), ale vlastní postavená na znalostech z toho SPARC - akorát že vykonávají jinou CPU ISA. Efektivní kombinace obou světů. Navíc hlavní výkon je v SVE, který si sami navrhli a spolu s firmou ARM dohodli, aby to byl standard (tzn. programátoři se s instrukcemi seznámí na svých PC a mobilech).
EDIT: Dokonce implementovali strong memory model z x86, který implementoval i Apple a NVidia (v některých svých CPU). Díky tomu programátoři "jen" překompilují kód z x86 a nemusí řešit specifika pro multithreading na CPU arch s weak memory model (např. by do odladěného kódu z x86 museli přidávat dodatečné synchronizace vláken).
To vím, že nejde o Cortex, ostatně těch co mají vlastní jádra je i mimo Apple víc. Ale s tím SW tak úplně nesouhlasím, A64FX se stejně jako předchůdce nepoužívá do běžných serverů a už vůbec počítačů, takže tam s optimalizací SW až takový problém není. Jde spíš o to, že SPARC byl omezený na Japonsko a ARM dává šanci na větší rozšíření. S ohledem na jeho efektivitu má velké šance.
Proč by nebyl tehdy problém s optimalizací? V té době nebyly žádné počítače s výkonným ARMem (a měly i omezené velikosti RAM). Takže se kód napsal na x86, resp. minimálně části (knihovny) byly už odladěné pro x86.
není mi úplně jasné, proč psát kód pro x86, když SPARC byl v té době dostupný pro superpočítače, servery i pracovní stanice a hlavně RISC je jiné RISC blíž, než CISC a RISC. Asi na vývoj a uplatnění SPARC nejen u Fujitsu zapomínáte. Navíc procesor strukturou vnitřního uspořádání podobný A64FX byl právě poslední generace SPARC.
Kde jsem si mohl koupit počítač s profesorem SPARC? Jo kdyby MIPS, tam pro své mainframy IBM nabízel notebook - zvenku ThinkPad, uvnitř deska s MIPS a grafikou Radeon, pro kterou již existoval OSS driver (známý ho má/měl a zrecenzoval). Mluvím taky o spoustě na x86 napsaných a optimalizovaných knihoven - žádný software není napsán od nuly.
U nás ne. Je to japonská záležitost.
Myslím, že ani v Japonsku už dlouho nešlo koupit počítač, co by nebyl vykopávka ze skladu se zlomkem výkonu tehdejších procesorů x86.
To bych se hádal. Ale je taky fakt že celý trh RISC CPU je dost specifický.
Pripadov, kedy sa slabsi pamatovy model, nez TSO prejavi, je vylozene iba hrstka. Da sa povedat, ze bezny programator, pokial neprasi, to riesit nemusi.
Aj v tak low-levelovom kode ako je jadro operacneho systemu sa memory ordering riesi iba tam, kde sa robia skarede veci s procesorom, ako zmena kontextu.
Asi to nějak analyzovali, když dospěli k závěru, že se jim ta funkce hodí.
někde psali že 32 na Arrow. Tudíž pak při odstranění HT by byla logická tato řada: 15900K - 32Crestmont jader, 700K 24C, 600K 16C. Pak by opradu hw nahradili HT který je podle všeho zatížen bezp. chybami že veškerý teoretický přínos negují. Teoreticky by měla stačit i úspornější varianta tedy jen přidání osmi jader - tedy sestupně 24/16/8.
Multithrading obecně a tedy i Intel HT zvyšuje efektivitu tím, že u širokých jader využije zbytek výkonu, který je pro jedno vlákno nedosažitelný. Pokud by i dokázali výkon HT nahradit malými jádry, bude to na úkor spotřeby i plochy, logicky...
Oooo, a co vidíme u Intelu posledních pár let? Aby snížili spotřebu, nasadili biglittle, ale spotřeba se nesnížila, spíš roste. Tohle je přesně ten problém, který tam Intel má a proto je celý koncept biglittle naprostý nesmysl!
"nasadili biglittle, ale spotřeba se nesnížila, spíš roste."
Áno, rastie. Intel aby sa dorovnal k AMD aj s biglittle, tak len nezmyselne pretaktováva. Samozrejme že je to len na pár sekúnd, ale pre benchmark to bohate stačí.
Proste se zrusi P cores a prejde se na nahypovane Atomy. ;-)
njn, zpetny zrcatko..
Já bych to bral jako velké plus. O gigahertz nebo půl druhého snížený kmitočet (proti >6GHz) musí zákonitě srazit spotřebu na polovinu nebo níž. Pokud přitom ještě dokáží maličko zvednout výkon, tak je to IMHO zázrak a vůbec ne k smíchu.
Průser to bude ve chvíli, kdy se spotřeba nesníží.
O spotřebě nemusíme spekulovat, údaje o výkonu jsou měřeny při stejné spotřebě jako u Raptor Lake:
https://diit.cz/sites/default/files/intel_arrow_lake_projection_01.jpg
Tam vidím, jak je nastavená mez. Skutečnou spotřebu ne. Může jet na hranici nebo taky na polovině.
Reaguji především na větu:
„O gigahertz nebo půl druhého snížený kmitočet (proti >6GHz) musí zákonitě srazit spotřebu na polovinu nebo níž.“
Nemusí. Třeba mobilní Ice Lake měl při čtyřech jádrech podstatně nižší takty a zároveň vyšší spotřebu ne čtyřjádrový (a tuším i šestijádrový) Skylake a s chladiči dimenzovanými na vysoce taktovaný Skylake masivně throttloval.
https://diit.cz/clanek/core-i5-1035g4-v-surface-pro-7-throttluje
Uvidime, ale potom si muzou Arrow Lake strcit tak akorat do ntb.
Ještě je jedno místo, kam by si je v tom případě mohli strčit...
No jestli je to stejne misto, jake si myslim, tak tam bude problem s chlazenim jeste vetsi :-D
Myslíte serverové racky? ;-)
Tolik zbytečné práce strkat je tam, odkud vzešly. :-)
No jestli tohle bude stát proti Zen5 (kor x3D) tak má Intel asi celkem naděláno...
Proto připravují tu 8+32 variantu, ale ta bude žrát jak kráva, když už 8+16 jede na 253 W. Jediné, co je může spasit, je ta nová Panther architektura (Q4 2025) na 18A procesu.
Spasi je lepsi vyrobni proces...
Podle mě ne. Pokud by šlo jen o výrobní proces, stačilo by důležité verze procesorů vyrábět u TSMC. Koneckonců jiné věci tam už vyrábějí.
Pokud se budou spolehat na TSMC, ztrati posledni zbytky sveho postaveni jako vyrobce procesorů.
Ostatní (fabless) výrobci nemají problém se svým postavením. Jim stačí, že mají o hodně lepší procesory (a integrované grafiky).
Kdo jsou ostatni vyrobci? Kdo vyrabi, je Intel, TSMC a Samsung...
Bavíme se o outsourcování části výroby do TSMC, a proto porovnávám s fabless výrobci CPU (a iGPU).
To jsou vlastne jen navrhari, navic ARMisté si návrh architektury kupují.
Proč furt uhýbáš? Nikdo z jmenovaných nepoužívá Cortex jádra od ARMu.
Nehledě na to, že ta nejlepší ARM jádra navrhnul někdo jiný než ARM...
Právě.
To je v porádku, ale pokud se bavíme o vyrobcích jako takových, tak Intel byl a stale je velmi silnym vyrobcem.
Navrhne, vyrobí a prodá.
To proti fabless je dost velky rozdil a pokud nebude jeho vlastni vyroba konkurenceschopna, bude to dalsi snizeni konkurence.
Tak ty továrny furt bude mít, takže v případě řekněme útoku na Tajwan budou k dispozici. Nejen jemu, ale i ostatním. Jeho procesory moc lidí nechce, ale to přece nevadí, když dostane peníze za vyrobení procesorů pro ostatní. Koneckonců už v minulosti Intel kapacitu svých továren nabízel:
How Intel plans to catch Samsung and TSMC and regain its dominance in the chip market
https://www.cnbc.com/2021/11/06/how-intel-plans-to-catch-up-to-samsung-a...
"Does Intel make chips for other companies?
He also recently announced Intel Foundry Services, a business that opens up Intel's fabs to make chips designed by Amazon , Qualcomm and other customers. For decades, the markets have rewarded giants like Apple and Qualcomm for being fabless.6. 11. 2021"
( https://www.google.com/search?q=can+other+vendors+to+use+intel+chip+fact... )
Kdyz nebude mit jeden z top procesu, dopadne jak Global Foundries a ostatni. Nejde mi o zajisteni chipove bezpecnosti, ale o to, ze jde o top technologii.
Pokud by ale jediná větší konkurence zůstala v Koreji a Japonsku a Taiwan byl vyřazen, pozice Intelu by opět byla silnější.
To jsou 2 různé věci. Být top a být good enough. Pokud by byla válka s Čínou, tak nepotřebuju každý rok lepší výrobní proces, stačí mi, že když se mi rozbije počítač, že si budu moci hned ten den jít koupit nový, i kdyby s 3 roky starou výrobní technologií. V začátku tohohle vlákna jsem navíc naznačoval, že Intel má problém v návrhu svých procesorů (a grafik a jejich ovladačů) - lepší výrobní proces ten problém jen částečně zameten pod koberec. Pamatuju, jak AMD v temných dobách furt zlepšovalo své procesory (odladěné věci z vývoje jádra Zen probublávaly do vydávaných stavebních strojů), zatímco výrobní proces stál myslím na 22 nebo 28 nm..
EDIT: Global Foundries furt jede na plné obrátky a vydělává. jen už není pro top produkty.
Jeden z těch už posledních ve formě APU mi doma sloužil.
To by me zajimalo, kde vidite spolecny problem pro navrh cpu a gpu?
GF vydelavalo behem chip krize, pred tim kumulovalo ztraty.
Třeba v tom, že potřebují mnohem více tranzistorů a větší přetaktování a stejně nejsou tak dobrý jako konkurence?
u grafik je to celkem jasne, u cpu plus minus gambrinus
V cem vidis to uhybani?
Osobně si myslím že Intel nic nevydá pokud to nezvládne frekvenci magických 5Ghz.
Produkt kde by bylo 4,5Ghz by na trh nepustil.
Co se mi ovšem nelíbí je 16 little core.
Nejsem inženýr v intelu ale osobně si myslím že udělat 16x P core by bylo vhodnější než 8P+16e ..S tím že v maximální zátěži by full load by třeba jen 4Ghz.
4 E cores zabírají jen o trochu více než 1 P core. Plus jsou připojené jako čtveřice dohromady na tu sběrnici, která má omezený počet jader, které na ní jdou připojit.
8P + 16E zabere zhruba stejně místa a použije stejné množství přípojných bodů jako bylo potřeba pro 12P.
Arrow Lake a 16× P-Core je možné, ale pomer výkon/tranzistor je stále tragický a tým pádom plocha a spotreba ide do neúnosných hodnôt. Len pre porovnanie plochy jadier s L2 cache: Zen2 (2.83mm2), Zen3 (3.24mm2), Zen4 (3.84mm2), Zen4c (3.36mm2), P-core Raptor Lake (8.08mm2), E-core Raptor Lake (2.57mm2)...samozrejme Zen2 a Zen3 sú na 7nm TSMC procese, Zen4 a Zen4c na 5nm TSMC a Intel je na 10nm+++++ alias "Intel 7" výrobnom procese...Meteor Lake by mal priniesť "Intel 4" výrobný proces a Arrow Lake by chcel "Intel 20A" ...záleží od jeho parametrov (výrobný proces) a o koľko zase naboptná samotné jadro na koľkých mm2 sa to zase zastaví.
buď je to s tím HT kachna nebo zjistili další bezp. chyby které když by ozáplatovali tak nula od nuly pošla či by ve špatném případě šel ještě výkon do záporu, tedy pod samostatná fyzická jádra.
S těmi frekvencemi to určitě nebude tak horké, vždyť o Meteor se říkalo totéž a vyladili to na 5Ghz. Takže 4,5Ghz v nějakém beta stádiu nic nevypovídá.
Pokud si pamatuju dobře tak o meteor lake se původně hlásalo že prý bude sotva 4GHz..
A že hyperthreading byl při leaknutem testu vypnutý si nemyslím že je nějak zásadní protože při testování vzorků se zkouší všemožné konfigurace.
Ono to bude asi tým, že ideálny stav je niekde medzi tým čo ponúka dnes Intel a AMD....Ja ako niekto kto má skúsenosti s mnoho-jadrovým/mnoho-vláknovým (rozumej 16jadier/32 vlákien Zen3 s PBO a CO) na rôznych aplikáciách (Hry, Handbrake <H.264,H.265>, Solidworks <render>, atď.), by som si vedel predstaviť lepšiu kombináciu jadier....hypotetický Zen3 produkt, ktorý by mal kombináciu na jednom čiplete 6 jadier s 3D L3 cache bez HT <cca base-clock pre všetky jadrá 4.0Ghz, 2-core boost-clock 4.7Ghz> a na druhom by bol 24 jadrový čiplet s 24MB L3 cache <na cca base-clock pre všetky jadrá 3.7Ghz a 8-core boost clock 4.4ghz>, takýto produkt by mal vysoký výkon v hrách a vyšší výkon multi-vláknový výkon ako má 5950X...len by to stálo viacej kremíku...
Preto môžme Intelu vyčítať rôzne veci, ale situáciu má analyzovanú dobre a snaží sa ju zlepiť dohromady s tým čo má k dispozícii.
Už vidím, jak dnes někdo bude řešit ZEN 3 procesor... Jestli něco podobné bude, tak jedině v generaci ZEN 5. Ani u současné ZEN 4 tomu nevěřím.
Ale je jasné že Zen3 už nikto riešiť nebude, ale na tom príklade som chcel ukázať, že cesta AMD ani Intelu nieje tá najsprávnejšia a každý si ide svojim smerom aj keď ich cesty sa čoraz viac približujú...resp Intel vynikajúco zanalyzoval situáciu, čo sa týka využívania jadier, ale bol nútený použiť dva druhý jadier, čo bola "z núdze cnosť" ktorú mu ja ale "nezožeriem"...AMD tiež skončí na kombinácii dvoch čipletov (ekvivalentne 8×Zen4 + 16×Zen4c)...ale či to bude pri Zen5 alebo Zen6 sa uvidí.
Tak pokud Intel uvede ArrowL v kombinaci 8+16 s vypnutym HT a frekvenceme, ktere budou do 5Ghz, tak bych u AMD necekal vic jak 16C pro Zen5.
Snad jedine, kdyby Intel uvedl kmbinaci, ktera by ho v MT opravdu drtila a AMD pro to melo plan B/ jak tomu celit..
To co Intel získá na lepších jádrech ztratí na taktu a HT. Ale AMD už se na Intel neohlíží a jede si svoje. i tak si myslím že ZEN 5 ještě zůstane u dvou CPU chipletů pro běžné spotřebitele.
8P+16E/24T na taktech < 5GHz .. to zní až moc dobře (nebo blbě) aby to byla pravda.
Jen mne zaráží ty drby (rumours) o 8P+32E s doručením později.
32E zabere plochu jako 10P
a potřebuje 8 nodu na připojení k ring bus (spolu s 8P celkem 18 nodů)
To už je snad snadnější vyrobit 16P.
Jenže správná cesta může dost záviset vyloženě na každém uživatel jinak. Takže ty týmy dělají procesory universálně pro cílové dost široké skupiny uživatelů, je to hodně vidět u EPICů, kde je opravdu velká paleta cache na jádro o taktů pro stejné počty jader. Od vysokého jednovláknového výkonu už na základním taktu, po velký výcejádrový i energeticky efektivní. A s ohledem na efektivitu klasických i C jader v porovnání s velkými i malými jádry Intelu tam moc cestu pro hybridní kombinace u AMD nevidím, jednoduše kombinaci C a X3D AMD řešit nemusí a i kombinace běžných a X3D provedení je úzce zaměřená. C a X3D AMD by tedy byla ještě šílenější. To varianta X a C jader dává větší smysl právě kvůli většímu dosažitelnému turbu. Hypoteticky by šlo i něco šílenějšího. 6x X + 6x X3D a 16 C, nebo 8x X + 8x X3D a 16 C s takty do 5,7 + 5(možná 4,5) + 4 (nebo 3,5) GHz. Protože si nemyslím že C jádra půjdou přes 4 GHz bez výrazného zhoršení spotřeby.
Srani se s malymi jadrami ktere ve skutecnosti zakaznici nechteji, vypnuti jiz zadanych instrukci AVX-512, umele stani na jiz vousate 8 jaderne konfiguraci, prilisne zrani blizici se k naprosto neakceptovatelnym 300W, prohybani procesoru kuli dementne naprojektovanemu socketu, umele meneni tehleh socketu a nejnoveji i odstraneni HT/SMT, vazeny, kto chce koupit kocku v pytli, ma moznost(!), intel je naprosto na smich kdyz prodava svuj 8 jaderny nepodareny zmetek Core i9 - 13900K za cenu vyssi nez 16 jaderny Ryzen 9 7950X!
65 skvělých komentářů na kachnu na modro, hm klobouk dolů. Tady se prostě hraje liga úplně z jiné dimenze.
Okurkova sezona v plne palbe.
Ale diví se někdo, když uvážím sliby a pak reálné výsledky Intelu za posledních už víc než 10 let?
Jeste lepsi nez tech 65 komentaru je magor, ktere ho to nezajima ale ma nutkavou potrebu prijit vsem sdelit, ze si tady povidaji o nicem.. ale tak ono i ta prezdivka uz rika, co to je za....
Kde jste prisli na to, ze HT neco pridava ? - a nebo 20-40% - me zkusenosti jsou ze vsechny I/O operace jsou i vece nez 10x pomalejsi s HT nez bez nej - napr. kolega nadaval, ze pry mame pomaly raid, ze novy stroj je pomaly, ze blabla bla --- zapnuty HT - prenost max 300MB/sec ... vypnuty HT -1.7-3GB/sec - ano tahal ty data nekolik hodin, takze konstatni vykon tahani dat z mnoha serveru 4x 10Gb linkach v LACP ... u SQL na Windows je to jeste horsi, imho v Linuxu fungoval HT skvele, nebot jej preskakoval, pak prisly nove CPU, kde to linux nevypne a uz i linux bezi pomalu, tech 0.3GB/sec vs 1.7GB/sec bylo prave v linuxu
Aha a on CPU neporovnívá hodnoty, aby vyhodnotil podmínku, nic nepočítá, neprovádí operace s registry, vše jde rovnou jen přes IO operace... A naco jsou pak cache a registry? HT či obecně multithreading využívá prostředky, které nevyužilo první vlákno, takže v prvé řadě zvyšuje efektivitu.
To zpomalení I/O operací vysvětlil níže:
https://diit.cz/clanek/arrow-lake-krom-vypnuteho-ht-brzdi-i-velmi-nizke-...
Samozřejmě to je specifické hlavně pro servery.
Asi nevite jak funguje HW - becne kazdy fyzicky CPU vlastni svoji RAM, kdyz ji nevlastni, tak se prepina a vykon jde nekam, proto uz i intel ma NUMA, ale dobre mi mame 1 CPU s mnoha jadry, kde je RAM dana na dany socket, ale i tak ma kazde jadro neco naadresovano - adresovat to 2x je uplna blbost - vyseldek HT je, ze kdyz provedete na 2 vlaknech a 1 fyzickem jadru tu samou operaci v ten samy okamzik, jedna prepise te druhe RAM ;-))
Dale HT casto zpusobuje pady aplikaci - nezajima me jak to dela, ale po vypnuti prestala serverova aplikace padat - windows na vmware ... imho linux ma s HT taky problem a to i na AMD - proc
I/O a interrupt - fyzicky je IRQ jen jedno pro dany HW, ale aby to fungovalo, musi se virtulizovat a tak se pres APIC na kazde jadro a to i virtulani HT namapuje ... a kdyz to vytizite, tak jen obsaluha toho zabere klidne i 70% vykonu jadra - no vy mate fyzicky jedno a simulujte to na nem 2x - takze pretiozite jadro na 140% a stsrem s tim neic neudela a ni to nevi, pokud se jeje nenauci preskakovat jak se to pokousi delat linux - no a pretizene jadro dela neskutecne hezke veci, jako ze bez HT by vam system jel hezky plynule a jen zpomalene, zato s vysokym vykonem, zde vam vyjkon jde dopr* cele se to seka, je to zalagovane, neplynule a nic nejde, casto pak zacnou padat na windows procesy.
Linux jede stabilne, ale laguje jak prase, jen co se to vypne pri tom same dokonce stiha - dal jsme treba apce 4 jadra u AMD s 8 jader, kdyz byl zaply AMDdi HT - tak mi mozna vzal 2 fyzicka jadra a ty mi dojebaly cely system, ze se to cele lagovalo, fakt milaghoval cely system i kdyz ty dlasi jadra byly nevystizene, jen co jsme to svinstvo vypnul, vse jelo skvele - apka se 4 jadry jela rychleji a zbyutek OS nebyl postizeny i kdyz apka vytizila 4 jadra na 100% ...
A pak zde mame SQl servery, coz je jedno I/O za druhym, at uz linux, nebo windows - a cim vice mate jader a virtulanuich jader, tim je to horsi, pokud mate v OS treba 128 jader na 2x CPU - tak se z toho pos* - jen co vypnete HT, musite pouzivat NUMA !!! se razem vse uklidni, nebot razem neemuluje jedno IRQ 128x ale jen 64x - a hlavne na skutecnych jadrech, ktere existuji
takze kde je benefit HT jadra ? puvodne to byl hack na windowes, nebot ty neumely pustit vice instrukci na jednom jadre, linux to umi, nebot kazdy CPU ma vice jednotek a tak zatezoval jednotlive jednotky, dale mate 2 zasobniky a tak mate vetsi sanci na lepsi zpracovani instrukci mimo poradi, takze jsou situace, kdy HT zvysi vyjkon, ale paradoxne ne klivi tomu, ze mate jako ze 2x CPU-jadro ale kvuli jinym vbecem - relne je to malo a pri pretizeni vam HT kompletne zabije system i HW - proto je lepsi jej mit vzdy vypnuty, benefit je v 90% zaporny a tam je je lepsi to nestoji za to.
Možná vám uniklo, že multithreading vznikl v 50. letech. Tehdy stroje s 32. CPU neexistovaly. I daleko později v době vývoje legendárního Alpha EV8, který nikdy fyzicky neexistoval, měly i top pracovní stanice běžně maximálně 2 fyzické CPU, takže tehdy 4 cestný multithreading pro přesně 2x širší jádro proti EV6 a EV7 smysl měl. A znovu si uvědomte, co dnes má běžný uživatel, 4 až 8 jader, už 12 a 16 jader je hi-end CPU. Tam vámi popisovaná situace nastávat nebude, navíc server a desktop je z hlediska zátěže jiný svět. I na pracovní stanici jede jiná zátěž než na serveru.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.