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.
no-X: https://youtu.be/3vyNzgOP5yw?t=2994
+ celé interview je hodně zajímavé
Je ale ja som už už linkoval do diskusie v súvislosti s tým, že pracuje na Zen8/Zen9
> Tím se dostáváme k faktu, že „D“ v tomto značení znamená Dense a označuje jádra Zen 4
>upravená tak, aby se jich na jednotku plochy vešlo podstatně více.
Ale to ide aj pomocou soIC
AMD to adopt TSMC SoIC in HPC chips
Monday 25 October 2021
https://www.digitimes.com/news/a20211025PD209.html
TSMC Teases 12-High 3D Stacked Silicon: SoIC Goes Extreme
on August 25, 2020
The test chip shown in the slide is likely to be, if it is to showcase some initial runs, only 12 layers of passive silicon with basic TSV management
https://www.anandtech.com/show/16026/tsmc-teases-12-high-3d-stacked-silicon
ale tam je skrátenie ciest do cache
https://www.youtube.com/watch?v=Uh3WobaaP70&t=240s
Takže to nemusí mať menej cache, ale teoreticky môžu byť aj registre a cache mimo logickej vrstvy....
škoda, že v tabulce nejsou odhadovane terminy uvedeni. jak je tomu tady zvykem u vetsiny prehledu. ;-)
Podľa
https://www.youtube.com/watch?v=dE9N95uSqHA&t=842s
Zen 5 - Q4 2023
Zen4 - 11-14 mesiacov pred Zen 5- Q4 2022/Q1 2023
Zen4D- Q2 2023.
do serveru jde o super reseni, protoze v dnesni dobe uz jednojadrovy vykon neni tak dulezity jako drive, zejmena pro ruzne cloud aplikace, moderni aplikace jsou psany aby skalovaly s poctem vlaken. Zasadni je energeticka efektivita a densita (a pametova propusnost), tedy kolik jader lze narvat do 1U
Nielen do serveru. Vysoky jednovlaknovy vykon nepotrebuejs ani v desktope/laptope. Mid a lowend aj v pripade CPU/APU je v pohode.
Ak sa ale nezlepsi dostupna vyrobna kapacita, tak o tom mozme len snivat.
no, ja bych spise rekl, ze dnes jedno z mala mist, kde vysoky jednovlaknovy vykon je stale potreba, je prave desktop. Souhlas, ze pro bezne browseni po webu potreba neni, ale mnoho her a ruznych aplikaci jej stale potrebuje
no neviem
Linux desktop
openSUSE KDE plasma 5 a 1000 vlákien len v idle.
možno tak Windows desktop.
pockat, vy podle poctu vlaken usuzujete, ze zadne z nich nepotrebuje vysoky vykon? to je dost zajimava uvaha, ze?
Energetická efektivita je samozřejmě pro servery nejdůležitější, ale že na jednovláknovém výkonu v "cloudovém řešení" nezáleží je spíše z nouze ctnost: co také mají cloudoví markeťáci blábolit jiného, když vlivem "katování kostů" jde jednovláknový výkon silně do pozadí.
Ve skutečnosti je v každém servrovém nasazení i jednovláknový výkon velmi důležitý: jde o rychlost vykonání různých složitých obsluh protokolů, což absolutně ovlivňuje latenci, responzivitu a průchodnost. Kolik instrukcí trvá - jednovláknově napsané, protože jinak to nejde - obsluha třeba SATA stacku? Nebo IP stacku samotného? Každá ta instrukce nějakou dobu trvá, no a čím rychleji to procesor vykoná, tím rychleji je obsluha hotová.
Jistě, jsou aplikace, kde na tom skoro nezáleží a počítá se jen souhrnný výkon na 1U mašinu a na příkon. Ale těch je naprosté minimum. Je vždy lepší server s 4x rychlejšími procesory než s 4x více jádry - i když souhrnný výkon to má jakoby stejný. V prvním případě trvá např. obsluha SQL dotazu 100 ms, ve druhém (počítám-li 4x více jader o 1/4 výkonu) 400 ms. Tedy když můžeme zanedbat rychlosti úložišť a další takové věci. Za minutu to obslouží SQL dotazů stejně, ale v prvním případě každý "user" (task, proces, jiné vlákno, ...) čeká na odpověď 4x kratší čas.
To je v nasazení dost podstatné... i v tom "cloudu". Že tohle pomalé řešení (4x více jader o 1/4 výkonu) často stačí a používá se, to je jiná věc - ale že by to bylo to nejlepší, to prostě není. Nízký výkon 1T vadí hodně i spešl "cloudově napsaným" aplikacím.
Prostě celkově, dělat schválně méně výkonná jádra, že jich tam bude více, je krvavě zaplacený kompromis, a kdyby to šlo jinak, jistě by se tomu jak výrobci, tak uživatelé rádi vyhnuli. Je to ale nejlevnější řešení, na úkor kvality služby. Dokud to jiný dodavatel cloudových služeb nebude dělat lépe, je to přijatelný kompromis...
Na tomhle zahynuly před cirka 10-ti lety AMD Opteronové servery: v 1U sice šlo koupit 4x Opteron 16C/16T, s 2x větší RAMkou než měly 2x Xeon 6C/12T servery, a ještě to bylo o dost levnější a žralo to prakticky stejně. Souhrnný výkon byl větší (o pár procent) u těch Opteronových serverů, jenže to pak fungovalo pomáááálůůůůů. Při nasazení jako sprostý web/SQL server tomu AMD serveru trvala odpověď na požadavek zhruba 4-5x déle... což při složitějších web stránkách (hovadsky napsaných, jak jinak) už byl průser.
Další věc likvidace Opteronů byla licenční politika velkých softwarových korporátů, podplacená ve prospěch Intelu...
Z důvodu nízkého 1T výkonu se až donedávna nechytly žádné ARM nebo MIPS servery, až dnes. Ale jen díky tomu, že radikálně stoupl jejich 1T výkon...
> Za minutu to obslouží SQL dotazů stejně, ale v prvním případě každý "user" (task, proces, jiné vlákno, ...) čeká na odpověď 4x kratší čas.
A už jste slyšel o paralelizaci zpracování SQL dotazu? Nebo vaší čistě hypotetickou úvahu omezujete na primitivní neparalelizovatelné SQL, aby to vyznívalo lépe ve směru k vaší teorii?
A co se stane, když na 4x výkonnějším procesoru se 4x méně jádry potřebujete spustit 2x více procesů, než ten procesor zvládá vláken? Že by šel výkon do kytek? Zatímco pomalejší procesor se 4x více jádry to dá (a single thread výkon rozhodně nebude 1/4).
Jednoduše vaší úvahu stavíte na chybném modelu a proto má chybné závěry.
Tušil jsem, že se někdo prosáklý tím "cloudovým marketingem" čapne... Píšeš úplné nesmysly.
Já psal např. o Oracle 11g, který se na výše zmíněné konfiguraci (64C/64T Opteronový server versus 12C/24T Xeonový server) takhle choval. Je myslíš Oracle 11g "primitivní neparalelizované SQL"? Přičemž tohle byl jen příklad. Stejně se chová třeba fileserver - ať už moderní super hyper paralelizovaná implementace NFS nebo CIFS nebo iSCSI - servery s rychlejšími procesory poskytují vyšší rychlosti než servery s více jádry, ačkoliv v součtu mají stejný výkon. Obsluha něčeho prostě vyžaduje zpracování určitého množství instrukcí a paralelizovat to už více nejde, takže více jader/threadů nepomůže a tím má rychlejší procesor s méně jádry/thready výhodu. To myslím není tak těžké pochopit...
Ohledně toho, když potřebuješ spustit více procesů, než má procesor vláken, už jsi slyšel o přepínání kontextu, o scheduleru a tak? Víš to, že třeba každý větší OS má tisíce procesů, aniž by procesor měl tisíce vláken?
Prostě vůbec netušíš, o čem je řeč, to je ten problém.
Vole jsem programátor, takže o tom trochu něco vím :-p. Paralelizovatelností SQL jsem myslel konkrétní dotazy, ty primitivní se dost dobře paralelizovat nedají, ale komplexnější ano. Samozřejmě na 24T procesoru lze spustit bambilion vláken, ale právě přepínání mezi nimi jsou náklady navíc, takže od určité zátěže bude efektivně 24T s vyšším výkonem na jádro pomalejší než 48T s nižším výkonem na jádro. Nelze ale operovat s tím, že ten 24T by měl 2x větší výkon na jádro, protože to je dost hypotetické, v reálu ten rozdíl tak velký nebude, zato 48T bude mít lepší energetickou efektivitu.
Pro middle tier systemy s jejich backendy, je napr podstatne dulezitejsi pocet volnych "zdroju", nez mensi pocet rychlejsich. Typicky priklad skalovani webovych aplikaci, kde je nejaky aktivni pocet concurrent pozadavku, ktery je potreba obslouzit. Pro plynulost je ideani, kdyz jde pocet requestu obslouzit stejnym poctem volnych zdroju (klidne pomalejsich), nez houfovani pozadavku do fronty a cekani na "super jadro", ktere je rychleji obslouzi.
tak nejen servery, notasy. cpat to do nejakych uspornych Brixu, Asus PnXX atd. zn. ideal ;-)
Tak mi asi něco uniká, ale v článku není zmíněné, že ta "malá" jádra použitá v serverech a APU budou v kombinaci s nějakými "velkými" jádry, aby se dalo mluvit o variaci na Intelí big.LITTLE. V celém článku jsou o tom jen následující části vět ...
Infinity Cache sdílenou pro grafické jádro i (velká a malá) jádra procesorová.
krom toho „malá“ jádra vzniklá jako derivát „velkých“ poskýtají určitý potenciál menšího vzájemného omezení
... a související článek s titulkem: „Malá jádra“ pro Zen 5 nebudou až tak malá, půjde o derivát Zen 4
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.