- Íme az új Android Auto!
- Honor Magic6 Pro - kör közepén számok
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Hívószám-hamisítás
- Magisk
- One mobilszolgáltatások
- iPhone topik
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Szívós, szép és kitartó az új OnePlus óra
- Samsung Galaxy Fit 3 - keveset, de jól
Új hozzászólás Aktív témák
-
HSM
félisten
válasz
S_x96x_S
#5951
üzenetére
"Az AMD szerencséje, hogy a Desktop- AlderLake-en a Big-Little miatt ezt nagyrészt nem lehet elérni, de szerver szinten elég ütős tud lenni, hogyha a program ki tudja használni."
Nem hiszem, hogy asztali alkalmazásoknál ennek bármi jelentősége lenne. Szerveres téren sem túlzottan nagy az elterjedtsége, nem véletlen, hogy szervereken is tarolt a Zen3, hiába nincs AVX512 benne."A korai Inteles AVX-512 implementációknál - annyira átmelegedett a chip; hogy az AVX-512 -es utasításoknál vissza kellett szabályozni magát .. csak, az volt a probléma, hogy a teljes rendszert lefolytotta."
Szerintem hibás a gondolatmeneted. A probléma abból eredt, hogy Intel rendszereken minden magnak közös a szorzója, nem tudnak különböző órajeleken és feszültségeken üzemelni. Ez asztali CPU-k esetén is igaz, hogy pl. aktív AVX2 feldolgozás esetén csökken az elérhető maximális órajel (AVX offset). Ennek nincs köze a csip "átmelegedéséhez", főleg nem ennek következtében történő szabályozási folyamatokhoz. Természetesen AVX mellett nagy valószínűséggel melegebb lesz a csip, valamint a jelenlegi Intel implementációkon az AVX-mód váltásnak is van némi költsége, ezeket is írja is részletesen az optimalizálási dokumentáció. Ugyanakkor a tapasztalatom az, hogy tömény AVX feldolgozás esetén sokkal nagyobb mértékben nő a teljesítmény, mint a fogyasztás, ami kompenzálja az órajel csökkenést: [link] (AVX1 vs. AVX2, "POUT" vs Gflops.).
Probléma leginkább az általad linkelt cikkben szépen leírt esetben van, ahol nagyon sokféle a feldolgozás, és az utasítások nagyon kis része AVX-es, így a módváltás költsége és az órajelcsökkenés már nagyobb veszteség, mint amennyi tempót hoz maga az utasítás készlet abban a kevés utasításban.
Ilyen esetben pl. a jelenlegi Ryzenek máris komoly előnyben vannak, hiszen azok képesek magonként eltérő órajelen üzemelni és AVX-offset sincs legjobb tudomásom szerint.
Én amúgy továbbra sem vagyok meggyőződve róla, hogy az AMD-nek valóban az AVX512-t kellene erőltetnie, én jobban örülnék egy inkább általánosabb felhasználásban erős koncepciónak (ahogy a korábbi Zen-ek), ahol pl. csak kiegészítő feture az AVX512, kb. mint az első Zen-eknél a sima AVX2, ahol az alapvetően 128bit széles architektúra két órajel alatt végezte el a 256bites műveleteket. "In the Zen/Zen+ microarchitecture the floating point physical registers, execution units, and data paths are 128 bits wide. For efficiency AVX-256 instructions which perform the same operation on the 128-bit upper and lower half of a YMM register are decoded into two macro-ops which pass through the FPU individually as execution resources become available and retire together. Accordingly the peak throughput is four SSE/AVX-128 instructions or two AVX-256 instructions per cycle." [link]
-
HSM
félisten
Volt egy jó írás még a Renoir-ról, van benne magméret összehasonlítás a teljes L3-as verzióval: [link]
Illetve szerintem érdekes, hogy egy ilyen Renoir 15W-os verzióban gyorsabb Cinebench-ben (2935 pont, forrás: [link] ), mint az új 12900K takarékos magjai (2572 pont, [link] forrás: [link] ).
Illetve az is rendkívül érdekes lenne, illetve szerintem akár alternatív opció lehet AMD oldalon, hogy különbözőképpen paraméterezni firmware-ből a magjaikat. Pl. egy "szoftveres" takarékos mód, ahol néhány magot megjelölnek "takarékos" magnak, és az OS ide rakhatja a kis igényű dolgokat, és ezek a magok ilyenkor nem turbóznának, hanem egy hatékonyságra optimalizált órajelen működnének, mint a mobil csipek esetén is.
Egyébként a jelenlegi magjaikon is lehet ilyesmit "buta" módon, én pl. előfordult, hogy kikapcsoltam a turbót a Ryzen 3600-asomon, mert kb. elfelezte a fogyasztást és bőven elég nagyon sok mindenre 3,6Ghz-en is, lásd mérésem [link] .
Ha a hybrid magdizájn rákényszeríti a szoftvereket, hogy külön kezeljék az erős/hatékony magokat, így külön magdizájn (és ezzel járó hátrányok) nélkül is tudnának ebből profitálni.Az meg már csak hab lenne a tortán, ha pl. lenne egy magasabb és alacsonyabb cache méretű verziója a csipleteknek, amiket lehetne kombinálni. Pl. elvileg lesz egy speciális Zen4 verzió [link] , elég komoly számok a dupla sűrűség és energiahatékonyság, több, mint 1.25X-ös sebesség mellett, bár nyilván itt azért érdemes megvárni azért a tényleges eredményeket.
-
HSM
félisten
-
#5869
HSM
félisten
Armagedown
#5868
HSM
félisten
válasz
Armagedown
#5868
üzenetére
Haha, és épp a konkurens CPU gyártó friss termékének tesztelésének hetében jönnek elő ezek a lassulásos "gyerekbetegségek"...
-
#5857
HSM
félisten
Petykemano
#5856
HSM
félisten
válasz
Petykemano
#5856
üzenetére
Magonkénti feszültség állítás, CPPC, mélyalvást tudó memória vezérlő a lényeges pontok. Érdekes innen az utolsó fejezet, de felsorolnak minden "újítást": [link] .
Főleg a P-states CPPC helyett azért számomra kicsit fájó, főleg, hogy a CPPC még az asztali Renoir-ban is úgy tudom aktív.Persze, ettől függetlenül jó és gyors a Renoir, de erősen úgy tűnik, hogy nem minden funkciója készült el "időre".
-
#5855
HSM
félisten
Petykemano
#5854
HSM
félisten
válasz
Petykemano
#5854
üzenetére
Úgy látszik, ez most a szokás, hogy a következő generációban adják el a "befejezett" terméket. Renoir->Lucienne, most a Cezanne->Barcelo. Vajon mi "maradt le" a Cezanne-nál?
-
#5852
HSM
félisten
Petykemano
#5850
HSM
félisten
válasz
Petykemano
#5850
üzenetére
Annyit tennék hozzá, hogy a mostani, GPU-s monolitikus megoldás biztosan "drága", gyakorlatilag két chipletnyi területű 7nm wafer kell hozzá. Tehát egy 5900X/5950x-hez elegendő 7nm kapacitást visz el, ami igencsak nem kevés. Ezt nem hiszem, hogy a csomagolás és IOD költsége ellensúlyozni tudná. Persze, a belépőkategóriára egyik sem ideális. Arra a kékek is egy alaposan megkopasztott monolitikus megoldást szoktak hozni, kérdés, egy kisebb költségvetésű szereplőnek megérné-e egyáltalán ebbe invesztálni.
-
HSM
félisten
válasz
S_x96x_S
#5845
üzenetére
"és az AMD eddig is egy picit rugalmasabb volt"
Önállósodásra ez a fajta "semi-custom" szvsz egyáltalán nem megfelelő, amit az AMD kínál. Ez más, mint mikor kapsz egy licenszt és tervezhetsz sajátot.Megnéztem mit mond erről a wikipedia: "Partly. For some advanced features, x86 may require license from Intel; x86-64 may require an additional license from AMD. The 80486 processor has been on the market for more than 30 years[1] and so cannot be subject to patent claims. The pre-586 subset of the x86 architecture is therefore fully open." [link]
Én erről a témáról azt gondolom, nem feltétlen az utasításkészlet, amin állni vagy bukni fog a dolog. Persze, egy jól megtervezett ISA azért előny lehet. Illetve kritikus fontosságú a szoftveres oldal, az x86 jelenlegi legerősebb oldala szvsz ez, az elérhető szoftveres infrastruktúra és kompatibilitás.
-
#5832
HSM
félisten
Petykemano
#5829
HSM
félisten
válasz
Petykemano
#5829
üzenetére
"Az eredeti kérdés az volt..."
Lehetetlennek tűnik a feladvány, úgy általánosságban.
"Jó hát azért a 6/12 még látótávolságon belül van az azt megelőzően standard 4/8-tól."
Nálam egy i5-8250U-t váltott, Cinebench R20 szemüvegen keresztül nézve kb. 1200 multi pontból lett 2200 azonosan 15W-ból, ez már inkább a porban sem látszik a hátunk mögött kategória....
A négymagos Tiger Lake, ha adunk neki 10W fogyasztás előnyt, na, akkor már látótávolságban van a ~2000 pontjával, ami szintén eltűnik a porban azonos fogyasztási keret esetén. (Nálam a 4650U 23W-ból 2600 pont....)"mert akkor pillanatok alatt lemerül"
Full terhelésen a 15W-os CPU-val mondjuk 20W az egész gép, egy átlag ultrabook 40-50Wh körüli akkuval így is bőven 2+ órát elmegy."Én most nem tudnék neked olyan programot vagy eszközt mondani, amit így már lehetővé tett"
Nem feltétlenül ez a lényeg. Egy kétmagoson is meg lehet mindent csinálni, csak nagy kérdés, mennyi idő alatt.
Aki pedig dolgozik a gépén ez egyáltalán nem mindegy."nem lesz még átütő erejű"
Én továbbra is jobb kompromisszumnak tartom a Ryzeneket. Legalábbis amíg nem megoldott, hogy direkt szoftveres optimalizáció nélkül is jól működjön a hybrid dizájn. Lásd pl. [link] . Aztán meglátjuk mi lesz.#5831 Petykemano : "ennek a procinak nem szabadna 45W (TDP) felett üzemelnie"
Én inkább ilyen 60-100W-os limiteket látok nála a konfigoknál [link] ...
Azt a "nagyjából pariban"-t nem nézted meg szerintem elég alaposan. Lásd: [link]
Ennyi tranzisztorból az AMD is bele tudna még rakni pár magot, és elég durva multis perf/watt lenne. Elég, ha megnézed mit művel ma egy 5800U 15W-on: [link] . Képzelj el ebből kettőt egymás mellett, még mindig csak 30W, és ebbe két IOD került így... -
HSM
félisten
válasz
S_x96x_S
#5825
üzenetére
"Az 5nm sokat számít."
Igen.
Illetve arra akartam célozni, hogy tényleg durva nagy szám, amiből az is következik, hogy így "könnyű" 70%-al megverni a konkurenciát perf/watt, ráadásul +2 maggal, jelentsen bármit is a különösebb konkrétumokat nélkülöző ábra.
És még csak nem is egy takarékosra hangolt aktuális Ryzent, hanem egy 45W-os Core i7-11800H-t szerepeltettek ellene, amiről nekem nem épp az ideális perf/watt jut eszembe... -
#5822
HSM
félisten
Petykemano
#5821
HSM
félisten
válasz
Petykemano
#5821
üzenetére
"marketing szempontból nem átütő erejű"
Nehéz is lett volna átütő marketinget tenni egy olyan termék mellé, ami:
- már megjelenésekor gyengébb volt, mint a kokurencia
- nem is tudtak belőle eleget gyártani"azzal lehetne csökkenteni, ha valami TSV-s megoldást használnának"
Tulajdonképpen igen, a TSV realitás, azzal megcsinálhatnák a mostani APU felhozatalt kétrétegben, alul a standard nyolcmagos chiplet, felül a GPU és IOD. De ez az én szótáramban maradna a "monolitikus" felépítés, csak 1 helyett 2 "emeleten" megvalósítva. De azt gyanítom, ezt ésszerűbb/gazdaságosabb a mostani értelemben integrált APU-s megoldással megoldani, amibe így egyéb optimalizálások is kerülhetnek, mint pl. felezett L3."Nem kapcsolják ki, hanem csak úgy otthagyják, és az az elvárás, hogy olyan gyorsan térjen magához, mint egy telefon."
Ez nálam is felhasználás, ilyenkor szoktam a hagyományos (Linux / "S3") módon altatni, ami azt jelenti, hogy a gép kikapcsolódik, és csak a memória marad áram alatt. Így is gyakorlatilag azonnal használható, amint felébresztem, az áramfogyasztása a lehető legalacsonyabb, és biztosan nem kezd el a tudtom nélkül dolgokat csinálni, hiszen a memórián kívül kikapcsol minden. Ez a "modern standby" elvileg arra lenne jó, hogy az "alvó" gép rendszeresen felkel és pl. letölti az e-maileket, meg ilyen hülyeségek, hogy amikor leülsz elé, ott legyen már az értesítés. Amellett, hogy a koncepció gyakorlatban több sebből vérzik, egyébként nem lenne butaság, de ez szvsz nem alvás, én ha erre vágyom egyszerűen nem kapcsolom ki, és úgy is alig fogyaszt energiatakarékosra tekerve a megfelelő profilt és kikapcsolt kijelzővel. Tehát ehhez sem kell Alder Lake, mert már a Skylake is alig kért valamit így, bekapcsolva."mint arra a kérdésre, hogy tavaly kinek kellhetett egy 8/16 magos 15-35W-os Renoir."
Haha, jelenleg 23W 6/12 Renoir felhasználó vagyok.
Jó dolog, ha kicsi és könnyű lehet az ember relatív erős munkaállomása, és nem merül le csak attól, ha ránézek. A Pollack szabály helyénvaló, azt is értem, hogy próbálják valahogy kimaxolni az áteresztőképességet és egyszálas tempót is, ugyanakkor nekem ezekkel ugyanaz a bajom, mint a CCX-ekkel a Ryzenekben, miszerint ha nem homogén a processzor, arra speciálisan optimalizálni kell, és optimalizálás nélkül könnyen sokkal többet bukhatunk az egészen, mint amennyit nyerhettünk volna ideális esetben. És itt az Aldernél lényegesen kritikusabbnak tűnik a megfelelő ütemezés, mint pl. egy 5950X-es Ryzenen, ahol azért sokkal kevésbé mehetnek vakvágányra a dolgok.
Ha én ezzel így célszemélynek számítok, jelenleg sokkal esélyesebbnek látom majd fejlesztésre valamely U-kategóriás 8/16-os Cezanne-t a későbbiekben, mint egy Aldert. Pedig jól jön nekem mind a single, mint a multi tempó, de nem vágyom szoftveres/szálkezelési anomáliákra, annyival nem várom gyorsabbnak az Alder nagy magjait sem, hogy ezt bevállaljam. Meglátjuk. -
#5820
HSM
félisten
Petykemano
#5819
HSM
félisten
válasz
Petykemano
#5819
üzenetére
"A 10nm miatt vált némileg ketté a mobil portfólió ami által lettek olyan 10nm-es termékek, amik nem jelentek meg a desktop kínálatban."
Igazából nem vált az külön, csak mivel a 10nm-en se nem tudták hozni az előző desktop generáció egyszálas teljesítményét (gyenge órajel) se nem tudtak kellően nagy csipet építeni (gyenge kihozatal) így inkább valahogy leizzadták 14nm+++++-ra ahogy sikerült az alapvetően 10nm-es dizájnjukat, ami egyfajta egyszeri tűzoltásnak fogható fel inkább szvsz."A nagy bravúr az lenne"
Ilyen bravúr szvsz nem reális. Mobilban elsődleges a fogyasztás és tokozásméret, így fontos a lehető legszorosabban integrálni, amit csak lehet. A desktop, workstation és szerver portfólió, ahol hatékonyan tudja ellensúlyozni a csiplet felépítés hátrányait (mint pl. az összekötő interfészek plusz fogyasztása, késleltetése) a sok mag és a jó kihozatal révén elérhető gazdaságos árazás. Szerintem okosan csinálják, hogy mobilon kívül megy a chiplet, mobilba (és IGP-igényes felhasználásra, pl. SFF kliens gépek, HTPC-k) pedig gyártanak egy azonos alapokra építő, de szorosabban integrált verziót."a kis magok jók lehetnek arra is, hogy javítsák a standby vagy idle üzemidőt"
Nem értem egyébként, mire erőltetik ennyire ezt a "modern standby"-nevű dolgot, hogy kb. bekapcsolva aludjon a gép, ez nem egy tablet/okostelefon!?
Még szerencse, hogy ki tudtam kapcsolni a laptopomon ("Linux-standby", lol), így tud kultúráltan is aludni, és nem akar pl. a táskámban fel-felébredni. 
"Másrészt viszont elég biztosnak látszik, hogy a throughput teljesítményt kis magokkal fogja megoldani."
Ez az, amire a gyakorlatban nagyon kíváncsi leszek, hogyan és mennyire fog működni, mondjuk egy szokásos 15W és 30W keretből a konkurencia homogén megoldásához képest, vagy akár a saját Tiger Lake processzoraikhoz képest. -
HSM
félisten
válasz
S_x96x_S
#5788
üzenetére
A legérdekesebb: "If rumors surrounding the late-October/early-November launch dates of 12th Gen Intel Core "Alder Lake" processors are true, then the situation with these patches will have a direct impact on AMD. Processor reviewers will be compelled to use Windows 11 for their Core "Alder Lake" testing, as the new operating system supposedly has greater awareness of the heterogeneous core design."
Majd lehet nézni a review-ok kisbetűs részeit, fenn voltak-e AMD-n a megfelelő patchek (ha addig valóban a helyükre kerülnek egyáltalán a dolgok).... -
-
HSM
félisten
-
HSM
félisten
"mert mi ertelme lenne valamit lassabban elvegezni?"
Erre mondjuk azért vannak elképzeléseim, pl. hasznos lehet a háttérben futó pl. weblap fülek kódjait a takarékosabb magokra ütemezni. A felhasználói élmény nem csökken, de a fogyasztás igen. Amivel inkább szkeptikus vagyok, mennyit hoz ez a konyhára a gyakorlatban? Szvsz túlzottan nem sokat. Erre bőven elég, ha ilyenkor az OS nem turbózza ki a világból a CPU-t.A drivereket én épp nem tenném a takarékos magokra, mivel azok kritikusak lehetnek sok szempontból.
-
#5764
HSM
félisten
Petykemano
#5762
HSM
félisten
válasz
Petykemano
#5762
üzenetére
Mármint, azzal próbálhatják majd eladni, egyetértek.
Hiszen alapvetően itt lehet óriási előny, hogy kifejezetten energiahatékonyságra optimalizált magok találhatóak a processzorban.Egyébként a nagy kérdés, szükség van-e ilyesmire, és ezzel kapcsolatban kicsit szkeptikus vagyok. Az i5-8250U-mon, ami egy 2017-es termék, vidáman be tudtam állítani, hogy akkuról max 2,6Ghz, illetve XTU-ból, hogy max 12W fogyasztás és olyan szépen beszabályozta magát a win10 "balanced" sémájával hogy öröm volt nézni. Tehát ha valaki vette a fáradtságot kicsit szoftveresen okosan használni, már azzal is igen sokáig el lehetett lenni egy átlagos 50Wh körüli ultrabook akku kapacitással.
Meg lehet nézni, pl. egy ekkori Thinkpad X1 Carbon még különösebb hozzányúlás nélkül is 1,13KG-ból 10+ órás akku időket tudott hozni netezés és videó nézés közben értelmes fényerőn... [link]
Egyébként az is érdekes kérdés, hogy a modern böngészők sokszálas motorjai mennyire lesznek jóban a pici magokkal. Ugyanis gyors net mellett igencsak érezni a különbséget pár komplexebb weblap betöltési sebességén, milyen CPU ül alatta. Nekem eszembe sem jutna általánosan a gyengébb magokra tenni emiatt a böngészőmet.
Persze, itt is érdekes kérdés, mennyivel lassabb, és mennyivel takarékosabb, és ez összességében mire lesz elég az amúgy szintén igen erős perf/watt-ú Zen-ek ellen. -
HSM
félisten
válasz
S_x96x_S
#5760
üzenetére
Az impulzus vásárlónak szvsz édesmindegy az is, hány magos. Neki megtetszett az a szép zöld pici gép a kirakatban, megveszi, kész.
Szvsz nagyobb baj, hogy a technikai hátterűeknek is egyre nehezebb eligazodni, mert egyre kevesebb a pontos, technikai specifikáció.
Én pl. elég durván meglepődtem, mikor kiderült, hogy a 4650U-s Renoir CPU-m nem támogatja a CPPC-t és a magonkéti feszültség szabályozást, csak az asztali és "Lucienne" átmatricázott kiadásai.
Ettől persze nem lett kevésbé jó CPU, de a felfedezés eléggé váratlanul ért "CPU-érdeklődőként" is. -
HSM
félisten
válasz
S_x96x_S
#5758
üzenetére
Ezt a marketinget már eljátszották a négymagos "Pentium" atomokkal, amiket egy picit drágább nem-atom alapú kétmagos Celeron is körberöhögött.
Ilyen szempontból a 2 > 4 néha mégis igaz.De szerintem ilyen árkategóriájú gépet, mint egy ilyen Alder/Zen már többségében nem olyanok vesznek, akik nem néznek utána. Ott pedig igen hamar ki fog derülni, kinek milyen kártyái vannak.
Az energiatakarékossághoz szerintem hozzátehet majd az új GPU, és a modernebb gyártástechnológia is, mégha ez csak egy half-node is.
No, és persze a pontos konfigurációt, vezérlő szoftvert is lehet mindig kicsit csiszolgatni. -
HSM
félisten
válasz
S_x96x_S
#5756
üzenetére
Volt róla szó, hogy ez lesz a "standard" mobilos lapka (BGA Type3 [link] ).
Ami nekem újdonság, hogy ezt már 12W-tól be lehet vetni.Én amúgy erre a szegmensre vagyok a leginkább kíváncsi, mit tudnak ebből a konstrukcióból kihozni, akkus üzemidő kontra sebesség az ultrahordozható kategóriában (~12-25W). Ebben egyébként az AMD jelenlegi nyolcmagosa erős terhelés mellett igen jó, de folyamatos alacsony terhelésen szvsz nem a leghatékonyabb.
-
HSM
félisten
"A 12600K 6+4 kis maggal erősebb lesz Multi Threadban mint egy 5800X, ami 300 dollár alatt nem kis teljesítmény."
De milyen "teljesítmény"-felvétel mellett konnektor felől?![;]](//cdn.rios.hu/dl/s/v1.gif)
A Zen3 egyik nagy erőssége, hogy igen jó perf/watt mutatójú magokat használ. Kazán üzemmódban pedig eddig is volt konkurens, igaz, valamivel drágábban. 11700K (~400$) és 10900K-ra gondolok főleg.
Ezen kívül az is "probléma" lehet, hogy az 5800X heterogén megoldás, míg az 12600K nagyon nem. Ezeket mind figyelembe érdemes venni majd az árazás mellett. -
#5738
HSM
félisten
Petykemano
#5735
HSM
félisten
válasz
Petykemano
#5735
üzenetére
Nem lennék meglepődve, ha érkezne Zen3-ból egy olcsóbban gyártható 6nm verzió a 3D-s mellé. Elvileg azt magyarázták, hogy relatív olcsó 6nm-re áttérni, jó hozzá a 7nm gyártósor és így több csip férhet el ugyanakkora waferre, tehát ~azonos költséggel több termék lenne gyártható, ami nem kis fegyvertény ilyen hiány mellett.
Itt a buktató a 6nm és a V-cache összeférhetősége lehet, erről nem olvastam eddig semmit.A Zen4 / 5nm nem csodálkoznék, ha csak a legdrágább termékekre mennének kezdetben, igazából a Zen3-ból is alig volt készlet fél évig, pedig abból alapból ("asztali szegmens" szemmel nézve) csak prémium opciók jöttek.
-
HSM
félisten
válasz
S_x96x_S
#5692
üzenetére
"- és az NVMe protocol overheadje ( a PCIe felett ) lehet."
Ez egy érdekes kérdés, ezt most akkor hardware vagy software kategóriába soroljuk."ettől függetlenül az ábra arra jó, hogy jelezze, hogy mennyi optimalizálandó van még a rendszerben"
Az én véleményem szerint az ábra félrevezető lehet, ugyanis nagyvonalúan eltekint attól, hogy az a vastag "software latency" bizony hasznos és szükséges szolgáltatásokat nyújt a rendszernek.Valamint attól is eltekint, hogy a "hagyományos" NAND alapú tárolók sem véletlen lettek ilyenek, évek óta a tárterületre eső költségek durva optimalizálása folyt, főleg consumer oldalon. Én már a (2bit
) MLC-nél fogtam a fejem, TLC-nél (3bit MLC) már nagyon, erre már jönnek a hírek a PLC (5bit MLC) NAND-okról is.... [link]
Pedig már a Z-NAND is jól mutatta, milyen brutális gyorsulás lehetséges már a meglévő infrastuktúrán is csupán azzal, hogy nem a tárterületre és olcsóságra van az egész optimalizálva.A DDR "halálát" én annyiból nem tartom realitásnak, hogy nem véletlen használunk olyanokat, a bővíthetőség fontos opció a legtöbb szegmensben. Persze, egy CPU mellé integrált HBM, mint nagyméretű gyorsítótár nagyon hasznos újítás lehet, de emellett komoly korlátja is lenne a fejleszthetőségnek, ha nem lenne mellé még valami.
Persze, idővel igen hasznosak lehetnek ezek a CXL kütyük, ugyanakkor technikailag szerintem nem reális, hogy az alacsony késleltetés a DDR busz késleltetésének szintjére csökkenjen, pont az univerzalitás/kompatibilitás miatti "vastagabb" hardware/software stack miatt.#5694 Petykemano : Önmagában szerintem kevés lesz a sávszélességben utolérni.
-
HSM
félisten
válasz
S_x96x_S
#5690
üzenetére
Az ábra alapján a szoftver késleltetése a leginkább számottevő, így szemre kb a fele a 10µs késleltetésnek, ami nagyon sok. Ennek semmi köze a PCIe-hez. A PCIe ~1µs-je persze egy számottevő faktor, de szvsz nem ezen fog elúszni még a nextgen megoldások tempója sem.
Hogy a maradék 4µs hardware latency mire megy el az ábrán, az nekem nem világos.Azon meg nincs mit csodálkozni, hogy ha gyakorlatilag DDR memóriaként, a tárolási rendszer "szoftveres" oldalát teljesen kihagyva/megkerülve gyorsabb, főleg hogy ott már csak 64B-ot néztek, míg a többinél 4kB-ot. Viszont így nyilván a szoftveres tárolórendszer szolgáltatásainak is búcsút lehet inteni.
Az sajnos nem derült ki a cikk utáni kisbetűs részekből sem, hogy az "Idle" itt pontosan mit is jelent, pl. egy mélyalvásból ébresztett PCIe nyilván lényegesen magasabb latency-t fog produkálni, mint egy épp használatban lévő, vagy kevésbé energiatakarékos módban lévő PCIe.
-
HSM
félisten
válasz
S_x96x_S
#5685
üzenetére
"A mostani PCIe -nél már maga a PCIe a szük keresztmetszet."
A PCIe késleltetése rendszerenként eltérő lehet, de amiket találtam méréseket, alapvetően szűk 1µs nagyságrendű értékekről beszélünk, lásd pl [link] .
Ehhez képest egy átlag NAND olvasási késleltetése nagyságrendekkel magasabb, lásd pl. [link] (~50µs) , de még a kifejezetten latency-re kigyúrt Z-NAND is többszörös késleltetésű (a cikkben 3µs).
Meg lehet nézni a teszteket is, a Z-NAND-os SSD elég szépen lesöpörte a hagyományos NAND-os konkurenciát, hiába ugyanúgy PCIe-es."És a Gen4-nek ugyanolyan sz*r a latency-je mint a Gen3-nak"
Ezzel sem értek egyet. Kellőképpen meg vagyok róla győződve, hogy pl. egy 1GB-os állomány lényegesen hamarabb (azaz alacsonyabb késleltetéssel) fog azonos szélességű 4.0-s PCIe-en átcsorogni, mint 3.0-on.
Itt azért azt hozzátenném, hogy a késleltetés megítélése (alacsony, magas, stb) erősen függ attól, milyen felhasználáshoz. Hagyományos NAND alapú tárolók mellé úgy tűnik bőven elég gyors, de mondjuk egy dedikált VGA memóriájának rendszerbe bekötéséhez fájóan lassúnak tűnik."A NAND mellé sokszor tesznek be DRAM cache-t ; Én amúgy nem vennék "DRAM-less SSD" ."
Én sem vennék (és nem is vettem soha). De a cache az SSD esetén úgy tudom nagyrészt az írási műveletek és a "cellatérkép" gyorsítótárazására használatos, tehát ugyanúgy ott tartunk, hogy a NAND késleltetése a szűk keresztmetszet így is. -
HSM
félisten
válasz
S_x96x_S
#5677
üzenetére
"virtuális valóság kütyüknek ( headset) és játékoknak azért nem árt a latency."
Így igaz. Ugyanakor nem vagyok meggyőződve róla, hogy a PCIe latency okozna ott gondot, és nem egyéb szűk keresztmetszetek, pl. CPU/GPU. Ilyen szempontból én nem vagyok optimista az Alder Lake-el, több ponton is előjöhetnek problémák. Pl. a 4 kis mag csak egy "ring állomás", valamint az átütemezés késleltetése a kis nagy magok között. A késleltetés minimalizálására éppen az architektúra kiszámíthatósága lenne a legfontosabb és specifikus optimalizálás."Az egységes memóriát használó újgenerációs konzolokról áthozott játékoknak - is jót tehet a Gen5-ös latency csökkentés."
Tehetne, de nem fog. Mert nem fogják áthozni, mert a játékmenetet érintő dolgoknak skálázódnia kell, hiszen nem rakhatják túl magasra a minimum gépigényt, mert az eladásokból élnek. Ezeket a dolgokat eddig is emiatt átírták/kukázták PC portnál."amikor már van Nvme SSD-ből és GPU -ból
is CXL/Gen5-ös választék."
Itt azért a NAND-ok késleltetése is okozhat még némi fejfájást, elvileg a mostani PCIe-nél is az a szűk keresztmetszet. -
HSM
félisten
válasz
S_x96x_S
#5672
üzenetére
Én a CXL-ben és PCIe5-ben rövid távon nem nagyon látok fantáziát.
Az összes játék ma úgy van megírva, hogy még véletlen se legyen érzékeny a latency-re, hiszen időtlen idők óta magas. Mielőtt az alacsony latency-re épülő bármi megjelenhet, azelőtt kellene alá felhasználói bázis valamint rengeteg fejlesztés. Ez minimum évek. Mire ezeknek jelentőségük lesz, szvsz már rég kidobtuk az összes AL vagy Zen4 CPU-t. -
HSM
félisten
válasz
S_x96x_S
#5646
üzenetére
"vagy az új 6950X - nél csak az egyik chiplet lesz 3DVcache tunningolt."
Ennek mutatták be először a prototípusát. [link]Érdekes gondolat egyébként, a big-little első megközelítésének is megfelelne.
Az ütemező miatt túlzottan nem aggódnék, a CPPC-ből konfigurálható mag-preferencia eddig is adott volt, és a Ryzeneknél eddig is voltak erősebb és gyengébb magok, hiszen nem egyforma volt a magok maximális BOOST órajele, tehát simán SMU-ból is kezelhetőnek tűnik a dolog ahogy jelenleg is. -
HSM
félisten
válasz
hokuszpk
#5637
üzenetére
Akár az is opció lehet szvsz.
#5638 wwenigma : Ez a "hány magos" kérdés régóta nem egyértelmű sajnos. A Bulldozer is nézőpont kérdése, 4 vagy 8 magosnak tekinted, de a Zen-eknél is bizonyos kódokak igencsak árt, ha át kell nyúlkálni a szomszédos CCX-ekbe, tehát ott is bejött a "nézőpont kérdése", hány magot tudsz hatékonyan használni a különféle alkalmazásokban. Aztán persze most már a kékek is beálltak a sorba az Alder Lake-el.
Valószínűleg itt is más, mélyebb metrikák után kell majd nézni, ahogy a gyártástechnológiai elnevezéseknél is volt. A user meg csak vakargathatja majd a fejét. -
#5636
HSM
félisten
Petykemano
#5635
HSM
félisten
válasz
Petykemano
#5635
üzenetére
"Az E magokat az intel throughputra akarja használni."
Szvsz nincs ellentmondás. A kulcs itt szerintem, hogy adott lapkaméreten belül a legjobb throughput. Tehát lehet, csak negyed tempóval aprítaná az AVX512-t, de ha ebből 4 elfér egy nagy mag helyén már lehet nyertél...
Aldernél szerintem nagy öngól, hogy a kis mag semmilyen formában nem eszi meg az AVX512-t, így a nagy mag ilyen tudása teljesen kihasználhatatlan marad. -
#5634
HSM
félisten
Petykemano
#5624
HSM
félisten
válasz
Petykemano
#5624
üzenetére
Pedig ez tűnik a legjobb megoldásnak. A kis mag utasítás szinten kompatibilis az AVX512-vel is, csak csiga lassú, ha tempó is kell, majd átrakja az ütemező a nagyobb magokra.
#5627 Petykemano :"reszelgetés (+10%) helyett elég komoly (+50+%) méretnövekedésen esnek át bizonyos alegységek"
Szerintem itt lényeges szempont, hogy mi lehetett a cél a fejlesztésnél. Az első Core architektúrák után a cél kb. a Skylake-ig az volt, hogy a mobil chipek terén legyen jelentős az előrelépés, ez volt a tervezési filozófia, hogy csak akkor építettek be valamit, ha hatékonyságban is jó volt. Nekem úgy tűnik, hogy ezt most már máshogy gondolják, a nagy magba menjen minden, amit elbír a gyártástechnológia, a hatékonyság meg majd jön a sok kis magból.#5629 S_x96x_S : "( mert az Inteltől láttunk nem annyira pöpec implementációkat, amikor pl. visszavett az órajelből avx-512 utasításoknál )"
Így volt ez az AVX2-nél is. A gyakorlatban viszont ebből nem igazán láttam problémát, nem dupla olyan gyors lett az AVX2 kód, csak mondjuk 80%-ot gyorsult.
Ami gondot okozhatott, hogy a maradék magokon is így csökkent a nem-AVX-es kódoknak elérhető órajel, de ezek már nagyon apróságok. #5630 S_x96x_S :"Personally, I think Zen 4 might have a single 512-bit FMA unit that can be addressed as 1×512 or 2×256, in a setup similar to Sunny Cove’s."
Nekem tetszene, ha ez lenne a megvalósítás. Nem gondolom, hogy jót tenne a csipnek más aspektusokból, ha túlizmosítanák a vektorfeldolgozókat, a jelenlegi Zen-nek is tetszik a kiegyensúlyozottan jó teljesítménye. -
#5597
HSM
félisten
Petykemano
#5595
HSM
félisten
válasz
Petykemano
#5595
üzenetére
Ami számomra kicsit furcsa, hogy az Alder is csak 16 sáv erejéig 5.0, a maradék 4 ott is 4.0.
Egyébként alaplap oldalról is érdekes lehet a kérdés, az 5.0 mennyivel növelné az alaplap költségét. A Zen lapkáknál épp könnyű kéne legyen az ilyesmik beépítése, hiszen csak az IOD-t kellene frissíteni és meg is lenne oldva a dolog. Illetve esetleg termékpozicionálás? Valamivel el kell majd adni a második hullám AM5 lapot is.
-
#5593
HSM
félisten
Petykemano
#5592
HSM
félisten
válasz
Petykemano
#5592
üzenetére
Azért itt nekem van két észrevételem. Az egyik, hogy relatív lassú ramokat használtak: "Also used DDR4-3200 CL14 dual-rank, dual-channel memory".
Ez korábbi tesztekből már sejthető volt, hogy így hagynak teljesítményt a CPU-ban, ez nyilván növelte a gyorsítótár-méret jelentőségét.A másik észrevétel, hogy a cache egy furcsa dolog, amíg "hasznos" a növekmény, addig remekül lehet profitálni belőle, de utána alig. Pl. a Radeon 6800-nál volt egy ilyen ábra prezentálva: [link] . Mindenesetre nagyon kíváncsi lennék a mérésekre, hogyan alakulna a 32MB vs. 96MB L3 verseny a különböző szoftverekben.
Én általánosan továbbra is jobban preferálnék +2 magot, mint nagyobb L3-at, ha hasonló áron lennének a polcon.
#5587 S_x96x_S : A WRX80 az árához képest szerintem nem durrant akkorát. Én komolyabb előnyre számítottam a duplázott memória csatornák láttán, mint amit mértek [link] .
-
HSM
félisten
válasz
S_x96x_S
#5558
üzenetére
"... és 2-3-5 év múlva képesek az M1/2/3/4 -et is lekörözni - innovációban;"
Ez még mindig nem biztos, hogy elég ellensúlyozni a hátrányt, hogy nem saját kezükben a platform. Az M1 jó teljesítménye szvsz inkább eladni volt szükséges, a gyártó számára szvsz a legnagyobb előny a teljes kontroll a hardveres rész felett.#5561 Petykemano : Azt ne felejtsük el, hogy ezek erősen optimalizált blokkok. Hiába "férne el" mondjuk +2 CU, ha mondjuk a kevésbé optimális vezetékelés miatt buknának csomót az órajelen. Nem bolondok tervezik a chipet, ha reális alternatíva lett volna jobban kihasználni a drága és korlátozottan elérhető wafert, megtették volna.
-
#5544
HSM
félisten
Petykemano
#5542
HSM
félisten
válasz
Petykemano
#5542
üzenetére
Az 5950X-en azért szigorúbb már a specifikáció és a TDP is szűkösebb.
"A 6 magos lapkák többsége szerintem nem azért 6 magos, mert hibás, hanem mert 8 magosként túl sokat fogyasztana."
Könnyen lehet. Én egyébként azt gondolom, szinte biztos, hogy desktop "flagship" CPU-kra azért igen jó lapkák (is) kerülnek a reklámérték miatt, gondolok pl. 5800X, 5950X. Persze, az 5800X lehet "forrófejű", csak tudjon magas órajelet, hiszen 140W-ig mehet a fogyasztása ami igen bőkezű, az 5950X-ért meg azért már kellően borsos összeget kell a kasszánál hagyni, hogy ne fájjon nekik túlzottan rárakni legalább egy igen jó CCD-t is.
-
#5540
HSM
félisten
Petykemano
#5538
HSM
félisten
válasz
Petykemano
#5538
üzenetére
"A kettő szerintem nem feltétlenül esik egybe, vagyis nem biztos, hogy alapjáraton az a lapka fogyaszt keveset, ami egyébként 1-2 maggal magas frekvencia elérésére képes."
Jó meglátás. De valamit kezdeni kell azokkal is, amik se különösebben magas órajelet, se különösebben jó fogyasztást nem hoznak. Én ezeket gondolnám ideálisnak pl. az 5900X-ek második CCD-jének elszórni. TDP tartalék van bőven, két mag kikapcsolható, és kb. csak a base clock van, mint kötelező specifikáció, amit a nem túl szoros TDP-n belül hozni kell. -
#5531
HSM
félisten
Petykemano
#5529
HSM
félisten
válasz
Petykemano
#5529
üzenetére
Épp tegnap olvastam én is. [link]
A kommentek között említették, hogy annyiból nem meglepő, hogy új termék, aki 5600X-et/5800X-et akart már rég vehetett, aki meg pl. az IGP miatt erre várt most lerohanta a boltot. Illetve írta valaki, hogy szép és jó az IGP, de ha veszel valami ezer éves rom VGA-t míg normalizálódnak az árak az sem feltétlen rossz opció, és akkor nem kell végig felezett L3-as processzort használj.
Én inkább HTPC-be tartom atomjó opciónak, ha nem cél a komolyabb játék és később se megy majd bele GPU.
-
#5524
HSM
félisten
Petykemano
#5523
HSM
félisten
válasz
Petykemano
#5523
üzenetére
Amit a késleltetésről írsz, az elérhető órajelekre lehet hatása az L1-L2 cache kiterjedésének a magon belül.
"3d cache épp azért lesz forradalmi"
Én sokkal inkább abban látom a forradalmiságát, hogy nem növeli a lapka méretét (kihozatal!), illetve "modulárisan" építhető, ha akarják rárakják, ha nem akarják nem, így többféle termékből építhető portfólió anélkül, hogy külön gyártósor és lapka tervezése válna szükségessé. -
#5485
HSM
félisten
Petykemano
#5484
HSM
félisten
válasz
Petykemano
#5484
üzenetére
"Logikus lenne inkább még két zen3-as lapkát gyártani"
Igen, terület alapon. De gyanítom, azért nem költségmentes az átállás a gyártósor és gyártott lapka tekintetében (arra gondolok, nem biztos, hogy hirtelen tudnának Cezanne helyett Vermeer-t gyártani adott 7nm kapacitás mellett a pillanatnyi kereslet függvényében), a Cezanne-t pedig amúgy is gyártják a notebookok miatt. Illetve a gyártást korlátozhatja/drágíthatja a máshol gyártott IOD beépítése, ami szintén nem gond a Cezanne-nél, ahogy írod is.Egyébként jó meglátás az is, hogy lehet bőven a notebookos fogyasztás keretből kilógó Cezanne, amit így szépen lehet értékesíteni olyan piacra, ahol nem gond pár W plusz fogyasztás.
Illetve a mostani GPU árak/ellátás mellett a beépített IGP is szerintem hasznos extra, ami ráadásul a konkurenciánál is a legtöbb modellnél adott. -
#5464
HSM
félisten
Petykemano
#5462
HSM
félisten
válasz
Petykemano
#5462
üzenetére
Szerintem épp arra lesz jó, amire demózták... Leginkább játék + 6900X(V) és 6950X(V).
Jobban átgondolva ott azért emiatt jobban az AL nyakán lehet majd, mint CB alatt, ami azért jelentős tényező a prémium gamer piacon.
Szerintem a CCD-s előny maradna, hiszen fizikailag ugyanaz a CCD van a V verzión, csak máshogy megmunkálva. A CCD probléma akkor jönne, ha Zen3+ kellene, hiszen a szerverekbe még csak most kezdik a sima Zen3-at teríteni, nem biztos, hogy kihozatal szempontjából szerencsés lenne most kihozni egy új dizájnt. Bár ki tudja.
Illetve árban is bőven lehetne versenyezni, igen jó processzorok ezek a mostani Zen3-ak, biztos vagyok benne, hogy megfelelő árazás mellett ugyanúgy vinnék az emberek, mint a cukrot, és szerintem van még tér akár kicsit olcsóbban adni őket, maximalistáknak meg mehet a V-modell kis prémiumért. -
#5461
HSM
félisten
Petykemano
#5459
HSM
félisten
válasz
Petykemano
#5459
üzenetére
"hogy reszelnek picit az órajelen, akkor 650-660-ra felmehet, de azért ez még kevéske"
Hát ezaz... És ezen szvsz nem fog javítani a V-cache egy cseppet sem. Lásd pl. a 3100 és 3300X-et, single core-ban gyakorlatilag egy az egyben az órajelkülönbség jön vissza [link] , ~12% előny, ebből ~10% az órajel. És ez még csak nem is a 32MB magassága, hanem szerény 8MB szemben a 16-al.
De nézhetjük architektúrán belül is, 5600X vs 5700G, kerek 20 pont azonos órajelen, azaz 3,5% az előny 16MB helyett 32MB-al.... [link]
Szóval szvsz éppen ez lesz a gond, hogy a V-cache nem sokat fog lendíteni a hat-nyolcmagoson sok appban, míg az előállítás költségét emeli. Ide sajnos mindenképpen kelleni fog egy kicsit komolyabb beavatkozás, ha nem akarják elveszteni a koronát.
Feltéve, hogy a kiszivárgott AL számok valósak.
#5460 poci76 : Az a 100Mhz BOOST emelés kb semmit nem fog dobni a számokon, már a mostani verziók is igen magas órajelen járnak.
Azt nem hinném, hogy miután ennyit szívtak az új gyártástechnológiáikkal, árversenybe kezdenének, főleg, ha igen erős lesz az ajánlatuk anélkül is. -
HSM
félisten
"Ha pl. az x-es verziókon lenne v-cache, a simákon meg nem, akkor akár ennyi is elég lehet egy új generációhoz"
Szerintem azért nem, mert azt szerintem igen nehéz lenne eladni, hogy néhány alkalmazás gyorsul, néhány meg semmit. Illetve vélhetőleg inkább a nagyobb magszámú modelleken tud segíteni (12-16), ahol szűkebb keresztmetszet az elérhető memória sávszélesség.Ezzel szemben egy kis CCD felvarrás az mindenhol hozhatna pár százalékot, az inkább tűnik nekem eladhatónak, a drágább modelleket pedig megfűszerezhetik a V-cache-el is, pl. a sima és X-es modellek magukban, drágább XT modellek a V-cache-el.
#5457 Petykemano : "$300-ba azért már csak bele kéne férjen +10$ költség"
Nem vagyok benne biztos, hogy ilyen olcsón megúsznák. A magot azért ehhez rendesen meg kell utómunkálni, elvékonyítás, plusz hézagkitöltő lapkák illetve a plusz L3 lapka az egész tetejére. Vélhetőleg a selejt-hajlamot is növelné ez az extra igénybevétel és munkafolyamatok. Illetve nyilván tudjuk, hogy ami a polcon 300 dollár, abból ennél jóval kevesebb a gyártó profitja, amiből lejönne az a tegyük fel, 10 dollár. Én ennek jelenleg is inkább a prémium kiadásokon látom értelmét, nem az olcsóbb "tömeg" modelleken. -
HSM
félisten
Egyébként egyetértek ezzel az oldallal.
Viszont ehhez szerintem komolyabb fejlesztés fog kelleni, mint a V-cache és esetleg minimális órajel emelés. Főleg, hogy a V-cache nekem nem tűnik ésszerűnek az olcsóbb termékekre (4 - 6 mag), és azokból a mostani 5000-es széria is foghíjas. Tehát ebben az esetben szükség lenne egy hézagkitöltő Zen3+ magra némi fejlesztéssel, amivel a teljes palettát fel lehetne frissíteni. -
#5451
HSM
félisten
Petykemano
#5449
HSM
félisten
válasz
Petykemano
#5449
üzenetére
A V-cache egy teljes új generációnak nekem kevésnek tűnik, főleg, hogy nem is minden gyorsulna tőle, hiszen a meglévő 32MB is igencsak méretes.
Én azt tudnám elképzelni, hogy kijönnek valami prémium kiadással, kicsit emelt órajelek + V-cache, pl. XT végződéssel a mostani modellek mellé, úgy tökéletesen beleillene a palettába. 6000-es szériának akkor tudnám elképzelni, ha kapna egy nagygenerált az IOD és az hozna valami újítást, de annak azért kevés esélyét látom az AM4 életciklusának vélhetőleg erősen a vége felé.
-
#5437
HSM
félisten
Petykemano
#5436
HSM
félisten
válasz
Petykemano
#5436
üzenetére
Itt a fogyasztás lesz szvsz nagyon érdekes. Az a single pontszám nagyon-nagyon erős, de kérdés, hány terhelt mag mellett tudja ezt a tempót tartani és milyen fogyasztás mellett. Illetve arról a 11600 pontról is jó lenne tudni, hogy készült, mert a 140W limit feloldása után, beállítva az 5850X 12 000 felett is hoz.
V-cache-el és picit emelt órajelekkel azért bőven versenyképesek maradhatnak ezzel már a mostani Zen3-al is. Főleg, ha esetleg hoznak mellé egy továbbfejlesztett IOD-t is.
-
#5424
HSM
félisten
Petykemano
#5423
HSM
félisten
válasz
Petykemano
#5423
üzenetére
Igen, az Intel biztosan nem engedheti meg magának a hasonló mértékű finanszírozást, hiszen az esetleges veszteséget a CPU-n nem fogja tudni máshol visszahozni, mint az Apple. Ott ugye nem tudsz csak CPU-t venni, hanem egyben veszed az OS-el és mindennel együtt. És nyilván mivel azt az OS-t kell használnod rajta, mivel jelenleg nem nagyon van alternatíva, így vélhetőleg az alkalmazásboltból is utána még csorog a bevétel.... Az Apple-nek ez is az üzlet része, nekik jobb, ha nem az általános x86 a rendszer alapja, amire bármikor rádobhattál kétféle más OS-t is. A saját CPU-val viszont bármikor bezárhatják az ajtókat, ha akarják.
-
HSM
félisten
válasz
S_x96x_S
#5410
üzenetére
"mert ez az új "normális"
az Intel Alder-Lake-S akár 150W-os TDP-vel nyomulhat ..
de az is lehet, hogy ez csak az átlag - mert:
Intel: "TDP values are maintained at 125W (PL1) and 228W (PL2).""Intelnél máshogy van definiálva a TDP, mint AMD-nél, ezt itt nagyon fontos lenne figyelembe venni. Az Intel féle 125W PL1 és 228W PL2 a gyakorlatban azt jelenti, hogy a beállított időablakban (8-60 másodperc között modellfüggően) átlagosan nem mehet a PL1 azaz 125W fölé, és sehogyse mehet a PL2, azaz 228W fölé. Illetve ami fontos, itt a TDP = fogyasztás. Persze, imádják a lapgyártók a saját szájízük szerint megemelni a PL1, PL2-t, de ez egy egész más történet.
AMD-nél a TDP valami számolás eredménye, ők valahogyan a hűtő felől nézik, ott a 105W-os TDP-vel ellátot processzor vidáman fogyaszthat átlagosan 140W-ot hosszú távon is. Tehát, ha úgy tetszik, épp az AMD lépett kicsit feljebb az AM4-el a korábban szokásos max 65/95W fogyasztási keretből.
A lapgyártók persze itt is igyekeznek a konkurencia fölé kerülni, de mivel itt a gyári limiteket nem módosíthatják, így a processzor telemetriáját próbálják félrevezetni, tehát még szvsz rosszabb a helyzet, mint a konkurens processzorokon, ahol legalább két beállítás után visszakaphatod bármilyen alaplapon a gyárilag specifikált működést.#5419 Petykemano : "És azt mondom, hogy az csupán "véletlen", hogy ezt az Apple pont megengedheti magának és még így is brutálisan nyereséges."
Szerintem a véletlennek ehhez semmi köze. Azt gondolom, óriásit kaszálnak azzal, hogy a saját chipjükre zárták be a rendszerüket, és nem kell másoknak fizetniük a CPU-ért.
Így ebben a piaci helyzetben nem csoda, hogy minden pénzt megér nekik, hogy egy ideig előnyben legyen gyártástechnológiailag is, ezzel is erősítve a képet, hogy megéri váltani az új rendszerre a régiekről. -
HSM
félisten
válasz
S_x96x_S
#5397
üzenetére
Mit mondhatnék erre... Annyira csendben zajlik, hogy cirka 10 év leforgása alatt is csak néhány szoftver használja.
Ami eszembe jut, azok az RT gyorsított render szoftverek és talán egy tömörítő van/volt, ami OpenCL támogatott.Egyébként az egyértelmű, hogy hasznos lehetőségek rejlenek ebben a modellben, de úgy tűnik a PC eddig túl ingatag/fragmentált terep volt (nem volt pl. minden CPU mellett IGP) ahhoz, hogy ott is elterjedjen, mint pl. a konzoloknál, inkább megoldották amit kellett erőből a CPU-n.
#5399 Petykemano : A DDR5 és az új AM5 IOD kérdés, mennyit javít a memória alrendszer tempóján, ha sokat, akkor az óriás L3 jelentősége azért jelentősen csökkenhet, mivel a maximális magszámot (16) nem tervezik emelni és a jelenlegi alap 8mag/32MB sem éppen kevés.
#5402 Petykemano : Érdekes írás, köszi!
-
HSM
félisten
válasz
S_x96x_S
#5393
üzenetére
"Valamint a legtöbb párhuzamosítást - át lehet lökni a GPU-ra ..
Vagyis a heterogén ( CPU + GPU ( + FPGA ))
programozásé a jövő"
Ezt nyomták a Caveri APU-nál is ezer éve... [link] Aztán a forradalom valamiért mégis elmaradt, pedig a hardver azóta is adott (lenne) hozzá.#5394 Busterftw : "a CCX desgin ellegge eltero volt mindentol ami addig megjelent es mainstream volt"
Az OS és a szoftverek szintjén teljes mértékben ugyanaz a megoldandó probléma, mint a Core2 Quadnál. Vannak magok, amik egymással gyorsan tudnak adatot cserélni (közös L2 a Quadnál, közös L3 a CCX-nél) és vannak, amik lassan, és ezt a feladatok kiosztásánál/ütemezésénél érdemes figyelembe venni.Fun fact, annak idején épp az AMD demózta bőszen, mikor megjelentek a világ első natív négymagosával, hogy ez bizony mennyivel jobb, mint a konkurencia kétszer kétmagos felépítése...
"Currently Intel’s quad core implementation relies on it having two Core 2 dies on a single package. It can easily pull this off because it doesn’t integrate the memory controller into the CPU. This allows more cores to be added as needed.
However, this creates an inherent performance problem, since both die are only connected only through the CPU front side bus (FSB). Sending data from core one to three means that it has to be sent out of the CPU to the northbridge and then back again creating a massive additional latency and reducing the bandwidth available for memory access.
Discussion between cores one and two or three and four is okay, because they are on the same piece of silicon, but still 50% of the time there’s a latency problem.
" [link]
Pontosan ez történik a CCX-ek esetén is, ha a szomszéd CCX-el kell adatot cserélni, arra csak a memóriavezérlőn keresztül van mód, hiába fizikailag egy csip. Ez a probléma "szűnt meg" az 5600X és 5800X modelleken, mivel azokon egy csip egy CCX, minden mag egyforma gyorsan fér az adatokhoz.Azzal viszont teljes mértékben egyetértek, hogy a fő probléma, hogy hogyan ütemezd a feladatokat a magok között, adott esetben power plan függően, a különböző elérhető kis/nagy magszámok mellett.
Bár tegyük hozzá, 16 magot megfelelően skálázódó módon ellátni szálakkal egyébként sem feltétlenül egyszerű, hát még ilyen "egzotikus" felépítésű CPU-k esetén. -
HSM
félisten
És még egy gondolat, hogy persze borítékolható, hogy majd jönnek a "cherry picked" mérési eredmények azon néhány szoftverből, amik gond nélkül skálázódnak akárhány, akármilyen magokra is, mint pl. a Cinebench... Aztán meg lehet vakarózni, hogy bizonyos alkalmazásokban meg miért nem köszön vissza a várt eredmény... Ahogy az első három generációs Ryzenek is meglepően erős Cinebench versenyzők voltak, miközben azért néhol nem teljesítettek ilyen szépen a konkurenseikhez képest.
#5390 Busterftw : "meglevo OS-ra jott a mas felepites."
Éppen ezaz, nem jött másféle felépítés. Ilyen rendszerek a win10 megjelenése előtt már legalább 5-6 évvel is léteztek, lásd Core2 Quad és kétprocesszoros munkaállomások."Intel biztos odatette magat a Microsoftnal, hogy alljanak ra a temara."
A probléma, hogy nem lehet minden erőből megoldani. Biztos lesz pár szoftver, ami bemutatóra majd jól leoptimalizálnak, de egyébként ez nem fog jól működni automatikusan csak úgy magától, erőből. Ehhez a szoftvereket is finomhangolni kellene. Ráadásul az optimum változhat, hogy mennyire az energiatakarékos és mennyire a gyors működés a preferencia."Sok licensz az."
Nekik mindegy. Így is úgy is elkel a licensz a gépen. -
#5389
HSM
félisten
Petykemano
#5387
HSM
félisten
válasz
Petykemano
#5387
üzenetére
"Tehát a több mag (6-=>8) nem kell úgy, mint egy falat kenyér"
Ez szvsz csak attól függ, mire és hogy használod a géped. Illetve hogy pl. egy játéknál hol húzzák meg a minimum igényt. CPU-igényesebb címeknél azért már jópár éve szükséges a 6 mag az optimális futáshoz, és a 8-nak is azért jópár helyen van relevanciája, ha nem csak a V-sync + 60 FPS a cél."A mai 8 magos ugyanolyan elavult lesz 3 év (2 generáció) múlva mint a valamivel olcsóbb 6 magos."
Vélhetőleg igen. Ugyanakkor az az akár 25% exta tempó a plusz magokból lehet a különbség egy itt-ott bedadogó játék és egy végig vajsimán futó között az a 3 év alatt."a Monet is azért készül, mert "túl jó" a kihozatal"
Ez egyébként logikus lépés. A 8-magos lapka felét kidobnák a kukába, ha olcsó 4-magosként árulnák, és egy olcsó tömegterméknél a fogyasztás és órajel sem feltétlen olyan kritikus tényező, így egy olcsóbb, régebbi gyártósor bevetése teljesen logikus üzleti lépésnek tűnik. Vélhetőleg így az is optimalizálja a költségeket, hogy nem kell a kétféle lapkát egy tokozásra tenni hanem egyben van minden."Ezért fejleszttette az Intel a Windows 11-et, nem?"
Erre engedd meg, hogy röviden annyit írjak: haha.
Viccen kívül, meg lehet nézni, hány év szenvedés után is köhögős a Ryzen-CCX felépítés kezelése, pedig egy 10+ éve létező dolog, gondolj csak a Core2 Quad felépítésére, éppen ugyanez, két kétmagos lapka volt egy négymagos, de felhozhatnám példának a két vagy több foglalatos szervereket is. Az eredmény? Meg lehet nézni, hogy hol van játékokban a 3800XT egy 5600X-hez képest (sokszor sehol) [link] , amikor "nyers erőben" vagy 10%-al gyorsabb [link] .
Ha ennyire szenvedős annak is a kezelése, hogy kb. egyforma erős, egyforma felépítésű, de egymással néhány magkupac esetén nem egyforma gyorsan kommunikálni képes magokat hatékonyan használjanak, akkor az milyen lesz, amikor nem "csak" ez lesz az akadály, hanem különböző kódok különböző sebességgel is fognak a különböző felépítésű magokon futni?
Ráadásul a tervek alapján lesz mindenféle magszám, kicsi nagy ahányféle kombinációt csak el tudsz képzelni. Elég reális esélyt látok, hogy a legjobb verzió optimalizálás szempontjából az lesz, ha fixen a nagy magokra kényszerítik az appot és le is van tudva ez az őrület. Megjegyzem, úgy hallottam, androidon is sokszor így "optimalizálnak" a különböző magokra, vagy itt fusson minden, vagy ott.
Én azt gondolom, ezek a kis magok leginkább csak arra lesznek jók, hogy a gyártó ne maradjon le a "magszám háborúban". Az átlag usernek ez csak plusz fejfájás lesz, ahogy szerintem a szoftverfejlesztőknek is. -
#5386
HSM
félisten
Petykemano
#5385
HSM
félisten
válasz
Petykemano
#5385
üzenetére
Szerintem annak még épp van/lenne értelme felhasználói oldalról, hogy 6 helyett 8 magot kapj ugyanannyiért. Üzletileg viszont nem lenne túl kifizetődő, hiszen igazán olcsón a "hibatűrőbb" 6 magos verziót tudják adni, legalábbis amíg egy csipen fizikailag 8 mag van.
A jelenlegi felhozatalban éppen a 8 mag feletti, ami a jelenlegi megoldásokkal már bizonytalanabbul skálázódik (ott jön be a második chiplet), és úgy tűnik, a konkurenciánál is 8 mag lesz a plafon, ahol még nincsenek ott a kisbetűs részek (Alder Lake).
Ezek alapján én azt gyanítom, az árazási struktúra nem fog jelentősen változni a következő generációnál.
Esetleg az Alder Lake hozhat a maga módján 6+ magot olcsón, de a kis magos megoldásnak is meglesznek szerintem a maga buktatói, szoftveres oldalról a sok kis mag érzékenyebb lehet a programok skálázódási korlátaira, mint ugyanannyi, vagy akár kevesebb nagy. -
#5303
HSM
félisten
Petykemano
#5288
HSM
félisten
válasz
Petykemano
#5288
üzenetére
"ez utóbbi tulajdonképpen miben különbözik attól, mintha mondjuk egy mag áramtalanítaná az AVX512 vagy egyéb részeit (regisztereket, cache-t, ALU-kat stb), amit épp nem használ"
Abban, hogy ami ott van, azt nem tudod áramtalanítással olyanná tenni, mintha nem lenne ott. Pl. a mag többi részét is hozzá kell igazítani, a jelutakat is hosszabbítja, így kikapcsolva is indirekten növeli a többi rész fogyasztását.Ez az OS tudta nélküli kis mag használat viszont hasznos lehet áramfogyasztás csökkentő célokra, az Arm-féle megvalósításnak is volt ilyen működési módja [link] . Ebben kevesebb elvérzési lehetőséget látok, mint a konkurens elképzelésben. Bár a leghasznosabb egy kapcsolható megoldás lenne, ha működhetne automatikus átkapcsolással, de ha olyan a munkafolyamat, mondjuk egy reboot árán átkapcsolhatnád, hogy elérhető legyen minden magod külön külön a takarékos mag utasításkészletével.
Egyébként vicces valahol (miközben mérnöki szempontból tökéletesen érthető és szükségszerű), hogy a mai napig előfordulnak ilyen problémák a nem heterogén felépítés miatt. Egy CCX itt, egy CCX ott, egy erős mag itt, egy gyengébb mag ott... És ezek még viszonylag hasonló képességű holmik voltak mondjuk egy tervezett 8+16-os Alder Lake utódhoz képest...
Lesz itt felfordulás még emiatt szvsz. #5289 Petykemano : A CMT koncepciója szvsz jó volt. A Bulldozer piaci szerepléséhez más, szerencsétlen körülmények is hozzájárultak. Egyébként logikusnak tűnik az osztott FPU az AVX512-re. Kérdés, ezzel nem-e dobjuk kukába a használatának előnyeit. Illetve az első generációs Zen fele szélességű FPU-ja sem bizonyult rossz kompromisszumnak, lehet lenne értelme az AVX512-nél is bevetni, elkerülendő a mag túlzott "kiszélesedését".
-
HSM
félisten
"árazást nézve prémium a 11900K de natív teljesítmény /harci erő szinten elégé elmarad egy 5900X/5950X mellet"
Ebben az a kellemetlen, hogy a házon belüli elődjétől is elmarad.... (10900K)
Nem mondom, ettől még nem tartom rossznak, de nem épp ideális.#5281 Petykemano : "Eközben ez a 4 atom mag kb kétszer akkora teljesítményt ad le multithread felhasználás esetén, mint 1 Cove mag miközben nemom kb feleannyit fogyaszt"
Hát azért... A dupla tempó azonos fogyasztáson van csak meg, ha jól értem az ábrát [link] , és némileg nagyobb is a 4 atom, mint egy Sunny Clove, bár az ábrán nem látszik tökéletesen.A legnagyobb tervezési öngól pedig asztalon, hogy be van építve a nagy magba a durván tranzisztorevő AVX512, és nem lehet kihasználni, ha mennek a kis magok, erre Anandék is kitértek [link] .
#5282 hokuszpk: Ezért nem látom értelmét egy ilyen CPU-nak asztali felhasználásra, szvsz csak a számok fognak jól mutatni a marketing anyagon. Kb. mint amennyire nyolcmagos volt a jóhírű Bulldozer 10 évvel ezelőtt, csak ne nézd a kisbetűs részt....
#5283 carl18 : Azért itt gyorsan álljunk meg egy szóra, a Cinebench tempó erősen optimális eset többszálú feldolgozás tekintetében, életszagúbb mindennapi használatnál azért nem biztos, hogy minden olyan jól fog skálázódni a többféle erősségű magokon.
Nekem már a korai Ryzenek 4-magos CCX-es felépítése sem nyerte el maradéktalanul a tetszésem, de itt sokkal több problémát tudok elképzelni.
Egy mobilon/tableten tökéletesen értem, miért jó, ha vannak extrém energiatakarékos magok, a sok háttérfeladatra, bőven megéri az ütemezési kompromisszum, de PC-n.... Még notebookon is túlzásnak és felesleges bonyolításnak hat számomra. Sőt, egyenesen úgy fest, mintha ez azért jönne, mert sehogy máshogy nem tudnak villantani valamit, ami legalább távolról hasonlít a nagyobb AM4 processzorokra.#5285 Petykemano : Egyébként még szép kis tartalékok lehetnek a mostani Zen-ekben is, pl. egy 64MB-os Vcache-es 5950X egy modernizált IOD-el, amivel mondjuk 10-15%-al magasabb FCLK-t és ezáltal memória órajelet lehetne elérni azzal még szépen lehetne hozni ám a konyhára.
-
HSM
félisten
"A Meteor lake-S már valóban versenyképes lehet, mert 8 nagy és 16 kis mag akkár hogy nézzünk nem elhanyagolható mennyiséget tekintve. "
Bár nem látok a jövőbe, de egy ilyentől én már a mostani 5950X-et sem félteném. Szvsz csak papíron mutat jól, hogy hűha, 24 mag.... Főleg, ha megmarad az az önszivatás, hogy a kis mag nem tudja az AV512-t, és így a nagyon sem használhatod, amíg nem kapcsolod le a 16 kis magot. -
#5235
HSM
félisten
Petykemano
#5233
HSM
félisten
válasz
Petykemano
#5233
üzenetére
Valamelyik APU-hoz volt írva régebben Zen3+, az pedig nem valószínű, hogy a plusz V-cache lett volna, tehát valószínűleg van még hiányzó része a kirakósnak.
Illetve a tervek is változhattak idő közben, ezt se felejtsük el. -
HSM
félisten
válasz
paprobert
#5214
üzenetére
"Nyilván azért csinálják, mert megéri csinálni."
Nyilván, de nem mindegy, milyen szempontból éri meg... Pl. az is lehet a cél, hogy megtartsák a "leggyorsabb gaming CPU" címet, miközben nyilván a tömeg nem 5950X "triple L3" kiadásokat fog vásárolni.... #5218 S_x96x_S : A videók enkódolását/dekódolását azért már elég régóta szokás célhardverre vinni (tipikusan GPU/IGP), mivel jól gyorsítható ilyesmikkel.
-
HSM
félisten
válasz
S_x96x_S
#5206
üzenetére
"- As the V-Cache is built over the L3 cache on the main CCX, it doesn't sit over any of the hotspots created by the cores and so thermal considerations are less of an issue. The support silicon above the cores is designed to be thermally efficient."
Azért az nem túl bíztató, hogy "less of an issue". A nagy kérdés, hogy a hűtő és a tranzisztorok távolsága változott-e, ez sajnos ebből nem derült ki. Ha nőtt, akkor a hűthetősége elméletileg rosszabb lesz.#5208 paprobert : Azt lenne még érdekes tudni, a csip és kapacitás hiány miatt mennyi bevételtől esnének el, ha pl. ilyeneket gyártanának adott kapacitásokon Navi GPU-k és Zen3 CCD-k helyett. És ezt mondjuk mennyire lehet ellensúlyozni egy nyilván magasabban árazott prémium termékkel, amihez ezeket felhasználhatják. Persze, B-tervnek is jónak tűnik, ha az Alder Lake túl jól sikerülne.
-
#5195
HSM
félisten
Petykemano
#5193
HSM
félisten
válasz
Petykemano
#5193
üzenetére
"merthogy 60%-kal több 7nm-es lapkaterületre van szükség."
Ez teljesen jogos. Gyártani nem feltétlenül nagyon olcsó. Viszont mint fejlesztés, egy új csip tervezési, majd gyártás beindítási óriási költségéhez képest itt gyakorlatilag kész elemekből volt építkezve. Így értettem az "olcsót"."ilyen mértékű gyorsuláshoz vajon tényleg megéri"
Jogos ez is. Jobban átgondolva azonban így legfeljebb néhány prémium modellben lehet létjogosultsága."ha nem így gurul le minden CCD"
Szerintem ez nem kéne probléma legyen. Az alap chiplet szvsz ugyanaz, és az opcionális plusz L3-ak számához csak a kupak vastagságával és a szilícium "kitöltő" darab magasságával kell igazodni. Nyilván a variálás extra költség és bonyodalom, de nem tűnik kivitelezhetetlennek. -
#5191
HSM
félisten
Petykemano
#5182
HSM
félisten
válasz
Petykemano
#5182
üzenetére
"ha sokat tudna az AMD keresni szervertermékeken, akkor ne forgatná át a wafer felhasználást arra - olcsó apuk helyett."
Nem tudom, ezt mennyire tudja megtenni a gyakorlatban. Addig oké, hogy 7nm, de azért más csip, más folyamat, gondolok pl. a maszkokra. Illetve a nagyobb CPU-k esetén komplikáció a tokozás is, annak is véges a kapacitása, mennyit tudnak a különböző lapkákból adott idő alatt összebarkácsolni.
Illetve szerver CPU-k azért komoly tempóval szippantják be a chipleteket, a topmodellen 8db, a kisebbeken nem tudom, mennyi van pontosan. Ehhez képest egy notebookba elég egy APU "chiplet". Egyébként sokáig nagyon komoly hiány volt a két chipletes 5900 és 5950-ekből is, szvsz nem véletlenül."lehetséges, hogy ennyire sok volna a túl sokat fogyasztó CEzanne?"
Valószínűleg ez is közrejátszik. Főleg a 15W-os kategóriában 8 maggal azért eléggé meg kell húzni a nadrágszíjat. Így a kicsit torkosabb példányok is remek felhasználási lehetőséget kapnak.#5184 Petykemano : "Ha létezik és tényleg lesz desktop modell. "
Eléggé szép csúcsmodellt lehetne csinálni ezzel főleg az 5900/5950-esekből játékos szempontból, kb. egy generációnyi fejlődés, a gyártó szempontjából igen "olcsón"."vajon a B2 stepping ehhez kellett"
Bennem is megfordult a gondolat. A kapcsolódási pontok mindenesetre már mintha az eredetiben is ott lennének az L3 mellett: [link] [link] ."Akkor már a küszöbön lesz a DDR5."
Ha az elején olyan "jól árazott" lesz, mint a DDR4, akkor nem biztos, hogy érdemes lesz azt venni. #5189 hokuszpk : Azt már elsütötték az RDNA2-vel, ott még számok is vannak... [link]
Ez alapján mondjuk egy FHD-ra célzott IGP elég szépen profitálna egy 64MB-os szeletből. Én IGP tekintetében túlzottan nem féltem a diszkrét VGA-kat, amikor manapság azért egy korszerű, játékos célú VGA mondjuk egy RTX3060/6700XT és felfelé. Utóbbi pl. 7nm-en is 200+ Watt, 335mm2, és a 96MB "L3" mellett is kell alá a közel 400GB/s sávszélesség. Ez még nem mostanában lesz CPU mellé integrálható.
"az asztali cpufrekinek viszont oda fog vagni vagy azert"
Igen, éppen emiatt aggódtam a hűthetőség miatt, ha ront az elérhető BOOST-on, akkor az asztali környezetben könnyen semlegesítheti a nyert IPC-t. De ne legyen igazam. -
HSM
félisten
válasz
S_x96x_S
#5175
üzenetére
Mindkettő nagyon szimpatikus.
És ne felejtsük el, hogy a korábbi APU tapasztalatok alapján az integrált IOD miatt várhatóan magasabb ram tempó érhető el, ami kompenzálhatja a kevesebb L3-at. És még egy jó IGP is lesz benne ajándékba.#5176 Petykemano : "Kicsit talán érthetetlen is, miért ennyire olcsó."
Gondolom itt nem kell versenyeznie/osztoznia az elkészült lapkáknak a legnagyobb profitú szerver termékekkel. Valamint feltételezhetően a gyártása is egyszerűbb (olcsóbb?), hogy egy helyen gyártják, egy csippel."Kicsit csalódást keltő, hogy 3x annyi L3$ csak 12-15% IPC növekedést hoz."
Pedig ez nagyjából megfelel a várhatónak. Nem véletlen rakott pl. az Intel is inkább kicsit kevesebb, de gyorsabb elérésű gyorsítótárakat a kliens CPU-ira. És pont ugyanezért nem gyorsult óriásit az 5000-es Zen sem, pedig praktikusan duplázták a "hasznos" L3 méretet.Egyébként azt gondolom, ez leginkább memória sávszélesség hiányos helyzetekben segíthet igen sokat, azaz szerverekben és a magas magszámú modelleken, asztaliaknál pl. 5900, 5950.
Ami szerintem itt még nagyon érdekes kérdés felmerülhet, hogy hogyan fog ez hatni a csip hűthetőségére? A 7nm magas teljesítménysűrűsége miatt eddig sem volt könnyen hűthető magasabb órajelen erős terhelésen, ha még raknak a hőtermelő magok és a hűtött felső felület közé egy plusz réteget, az izgalmas kihívások elé állíthatja a hűtőket és tuningra vágyó tulajokat.
-
#5156
HSM
félisten
Petykemano
#5154
HSM
félisten
válasz
Petykemano
#5154
üzenetére
Egyébként, ami a magdömpinget illeti, szerintem semmi okunk panaszra annak ellenére, hogy nem nőtt tovább a perf/price arány a 3000-esekhez képest.
Pár éve még 2000 dollárt is ott kellett hagyni egy 18 magos szörnyért [link] , egy méregdrága HEDT alaplap mellett, ehhez képest egy mostani 5950X aprópénz, és nevetségesen olcsó lapokban is kitűnően működik. A perf/price bajnok 5900-ról nem is beszélve.
Nekem inkább az olcsó, alacsonyabb magszámú 5000-es CPU-k hiányoznak picit, amit tömegek vehetnének, pl. sima, X-nélküli 5600, 5800. Pedig már a konkurencia is vette a lapot, hogy igen komoly igény lenne ilyesmikre, lásd pl. i5-10400, i5-11400.
A régi 3600-ost én a CCX-ek miatt ezeknek nem tartom alternatívájának, személy szerint épp olyanról fejlesztenék.
Reménykedem, hogy a 6nm segít majd, hogy az olcsóbb kategóriákban is megjelenhessen végre pár harapósabb Zen3-féleség. -
HSM
félisten
válasz
S_x96x_S
#5128
üzenetére
Nekem az nem világos, asztali gépbe mi a csodának energiatakarékos mag?
Korábban megmértem a Ryzen 5 3600-asom, egy mag fogyasztása az alap 3,6Ghz-en gyári feszültségen mindössze kb. 4-5W Cinebench R15 terhelés alatt, lásd 1 szál vs. 2 szál: [link]
Nem tűnik ésszerű célnak ez alá menni, amikor egy tipikus asztali gép üresjárati fogyasztása legalább 20-30W monitor nélkül. A memóriavezérlő/IF linkek sokkal inkább tűnnek lényeges fogyasztónak, ha nincs eszetlen paraméterekkel meghajtva a CPU.Egy notebooknál értem, amikor üresjáratban az egész fogyaszt monitorral együtt 5W körül, de asztalon más a nagyságrend, ahova az AM5-öt szánják.
A háttérfeladatok hatékony végzésére pedig sokkal inkább valami szoftveres megoldásnak látnám értelmét, ami ezekre nem aktiválja a magas, tipikusan nem energiahatékony turbó/boost órajeleket.
Nekem két 8 magos erős CCD és egy GPU csiplet tetszene, lehetőleg CXL-es PCIe5-el.
-
#5126
HSM
félisten
Petykemano
#5120
HSM
félisten
válasz
Petykemano
#5120
üzenetére
"Én valahogy nem tudom elképzelni hogy erre - hogy csak egyszer kelljen megvenni a procit,de a kupak alatt kétféle maximálisan profi rendszer legyen"
Cloud szolgáltatóknak pl. jól jöhetne. Ezzel amúgy szerintem a fő probléma, hogy két processzor költségét fizethetnéd ki, használni viszont egyszerre csak az egyiket tudnád. Viszont az eredeti koncepció szerintem jó volt, hogy a fő beruházás, azaz a szerver kompatibilis X86 és ARM CPU-val is, így ha növelni kell valamelyik kapacitást a másik rovására, akkor csak a CPU-t kell cserélni, nem az egész szervert, amivel nyilván rengeteg idő és költség megspórolható. -
HSM
félisten
válasz
S_x96x_S
#5094
üzenetére
Ezzel kapcsolatban a Cyberpunk esete volt pl. nagyon érdekes... [link]
Sok idő, mire ezek a kikopnak.Én egyébként óriási előnyként tekintek az X86 széleskörű, több évtizedes kompatibilitására. Az ember szabadon használhatja a jól bevált, adott esetben nem feltétlen "naprakész" szoftvereit is amíg csak szeretné.
Amúgy a Skylake architektúrában is bejött egy érdekes "újdonság", ami komoly optimalizálási nehézségeket okozhatott bizonyos szoftverekben, a PAUSE utasítás "energiatakarékosabbá" tétele [link] [link] .
-
-
HSM
félisten
válasz
S_x96x_S
#4575
üzenetére
A C-Ray-nél az AVX optimalizációk is erősen számíthatnak. Látszik is, az -O3 kapcsoló ad sokat, nem az architektúra specifikus optimalizáció. A másik teszt viszont azért szépen hoz a konyhára zen2 vs zen3 finomhangolással az általános X86-hoz képest.
#4576 S_x96x_S : Ezekben a fogyasztási osztályokban nagyon nem mindegy a hűtés, és a konfigurált limitek, amik főleg a többszálú eredményekben látszanak. Amúgy szerintem jók az eredmények ennek ellenére, elfogadnám így is.
-
HSM
félisten
"tehát mindenképpen plusz (emberi) munkaráfordítás kell."
Nem vagyok különösebben jártas a fordítók lelkivilágában, de nem úgy van, hogy ha lehetőséget biztosítasz bizonyos utasítások használatára, akkor azokat akár automatikusan is képes bizonyos szituációkban felhasználni? Nyilván, az ideális eredményhez kell emberi ráfordítás is (optimalizáció), de tudtommal nem minden esetben elengedhetetlen.#4569 S_x96x_S : Valami kavarás dereng régebbről, AVX1-2, FMA3-4, ez sem ment egyszerűen...
[link] -
HSM
félisten
válasz
hokuszpk
#4539
üzenetére
"nemveszi figyelembe a létező szoftvereket és a szoftverfejlesztők lustaságát"
Valóban nem. Ezért óriási előny az Apple-nél, hogy egy határozott lépéssel az egész infrastruktúrát át tudja kényszeríteni egy új platformra, "lusta" fejlesztő ide vagy oda.Ugyanakkor ez X86 vonalon egy megoldandó probléma, mert most az M1 használók hirtelen azt látják, hogy az M1 mennyivel takarékosabb, milyen sokáig elmegy egy töltéssel, milyen hűvös, stb. Ezt utolérni viszont kelleni fognak az extrém takarékos magok elsősorban a háttérfeladatokra. Asztali fronton persze én is csak a nyűgöt látom benne, de notebookoknál más a helyzet.
Egyébként nem feltétlen van szükség olyan nagyon komoly optimalizációra, Androidon sincs túlbonyolítva, bizonyos ütemezők csak annyit csinálnak, hogy egy bizonyos processzorterhelés felett átrakják a feladatot a teljesítménycentrikus magokra, és szépen működik is a rendszer.
-
HSM
félisten
válasz
hokuszpk
#4537
üzenetére
Az "ezerszer váltok állapotot" filozófia nem fog segíteni hatékonyabbá válni a néhány wattos fogyasztási tartományban.
Ehhez alapvetően egyszerű felépítésű magokra van szükség, ami viszont nagy teljesítményre nem hatékony, ezért jött létre a big.LITTLE koncepció is eredetileg. A Lakefield-nél volt erről szemléletes dia: [link] . De ARM-os vonalon is számtalan mérés volt erről, a kis magokkal mindig lényegesen alacsonyabb fogyasztás volt elérhető alacsony terhelésen.Mobil vonalon igen hasznos lehet egy ilyen felépítés, bár a siker erősen fog múlni, hogy az utasításkészlet különbözéségét hogyan sikerül a gyakorlatban áthidalni.
-
HSM
félisten
válasz
S_x96x_S
#4518
üzenetére
Annyiból nem vagyok meglepve, Apple-nek nagyon kell a kapacitás, ők vélhetőleg sokat nyernek a saját SoC-on, így a liciten akár jó magas árat is kínálhattak érte. Míg mondjuk az AMD-nek most még talán annyira nem égető, lehet még faragni a 7nm-en, és amúgy is X86-on és GPU fronton is látszólag előnyben vannak azzal is.
#4519 Petykemano : "azzal küzdenek, hogy a fejlesztéseket gyártástechnológia (sűrűség és fogyasztás) - független módon tudják implementálni"
Itt pont az a gond, hogy sok mindent nem lehet gyártástechnológia függetlenül implementálni. A gyártástechnológia erősen beleszól a szükséges kompromisszumokba, optimumokba, ami sok mindent boríthat az összefüggéseken keresztül. Emiatt igen kíváncsi leszek, a Cypress Cove esetén hogyan fog sikerülni a mutatvány, pl. a szükségszerűen megnyirbált gyorsítótár méretekkel. -
#4471
HSM
félisten
Petykemano
#4470
HSM
félisten
válasz
Petykemano
#4470
üzenetére
Elvileg új, lényegesen erősebb RDNA2 GPU-t kap, nem átnevezett Renoir lesz. [link]
A Cezanne meg marad az alaccsony tranzisztor költségű VEGA GPU megoldásnál, de erős Zen3 magokkal és nagyobb gyorsítótárral a CPU-ban. -
HSM
félisten
válasz
S_x96x_S
#4463
üzenetére
Ami szerintem érdekes és számomra új infó, hogy 2008-ban a tranzisztor keret 10%-a ment el a dekóderre, ami azért kiélezett versenyben nem tűnik kevésnek, bár tény, hogy nem is vállalhatatlanul sok. Ez ha nem tévedek K8-K10 architektúra, és 3 dekóder esete magonként, ahol ráadásul erősen dekóder limites volt a rendszer. Érdekes lenne mai környezetben egy hasonló adat.
#4467 Petykemano : Az Arm A5x magok valóban lényegesen jobb perf/watt-ot tudnak, csak éppen meglehetősen alacsony abszolút teljesítmény mellett. Hiszen arra tervezték őket.
Lásd: [link] [link] -
HSM
félisten
válasz
S_x96x_S
#4459
üzenetére
"vagyis a komplexitáson többet veszít az X86-64-ISA - mint amennyit nyer a "tömörségével"
Ehhez azért komolyabb analízis lenne szerintem szükséges. Csupán arra akartam ráirányítani a figyelmet, hogy óriási előnynek tűnhet, hogy több a dekóder, de többre is van szükség, mert ugyanazt a munkát egy RISC architektúra több utasításból végzi el, tehát nem megalapozott az órajelenként dekódolt utasításokból és órajelből kiindulni, mert más az utasítás architektúra."making designing decoders that are able to deal with aspect of the architecture more difficult"
Itt azért a tranzisztorköltségre vetített extra teljesítményt is érdemes számba venni. Lehet érdemesebb pl. két egyszerűbb magot beépíteni, mint egy túlzottan komplexet, ha egyébként az egy szálon elért teljesítmény megfelelő.#4460 hokuszpk : Ez kinek és miért lenne jó?
Viszont abban látok fantáziát, ami az eredeti koncepció volt, hogy minden chiplet K12, ugyanazzal az IOD-vel, tehát csak CPU-t kell cserélni a szerverben, és át is álltál egyikről a másikra. Ez azért elég egyedi és rugalmas is lenne. -
HSM
félisten
válasz
S_x96x_S
#4439
üzenetére
Közben jobban megnézve látom, írják ők is, pl. 3DPMavx: "On the power side, we can see why SMT Off mode is warmer – the cores are drawing more power. Looking at the data, SMT Off mode is running ~4350 MHz, compared to SMT On which is running closer to 4000 MHz."
Mikor írtam, nem volt időm alaposan végigolvasni, ebből a részből csak az ábrákat néztem át.#4442 S_x96x_S : "az csak a programkód méretére van kihatással, de a végrehajtás már más"
Miért lenne más? Ha egy X86 utasítás-sor "tömörebb", akkor adott számú utasítást dekódolva órajelenként, azonos órajelen mégiscsak több hasznos "munka" lesz elvégezve, mint egy RISC architektúrán. Az, hogy belül a dekóder hány belső utasításra bontja, már más részegységek baja lesz."persze lehet vitatkozni, de szerintem az X86-64-ISA elég komplex az AArch64 -hez képest."
Nem fogok veled vitatkozni, ez így van. És ez az előnye és hátránya is. Előnye, mert toldozgatják foltozgatják évtizedek óta, alapvetően a kompatibilitás megtartása mellett. Hátránya, hogy többnyire nem optimális egy ennyire komplex, toldozgatott foltozgatott architektúra egy alapokról bizonyos célokra kifejlesztetthez képest."izgalmas évtized jön"
Efelől semmi kétségem.#4446 Petykemano : "Azt mondod, hogy az AT tesztjében nem a backend fogyott el, hanem a TDP?"
Pontosan. Főleg a 12-16 magosok igen könnyen limitessé válnak, sok a mag, valamint a maximális BOOST órajelek is magasak."Vagy megfordítva. a kikapcsolt SMT-t a TDP kereten belül kompenzálja valamivel magasabb frekvenciával."
Pontosan. Az SMT OFF alacsonyabb magszintű kihasználtsága alacsonyabb fogyasztással jár azonos feszen/órajelen (kevesebb a "hasznos" órajelciklus, több a várakozás), amit némileg magasabb órajellel tud orvosolni a boost, ha van még elérhető, nyilván így azért rosszabb hatékonyságot felmutatva. Ezt erősíti meg, amit idéztem az AT méréséből az első bekezdésben.#4449 S_x96x_S : " Ha 4 erős lenne, akkor multi core-ban is verné a zen3-at."
Azért azt ne felejtsük el, hogy akkor a fogyasztás sem ennyi lenne... Valamint a laptopokba szánt Zen APU-k is lényegesen magasabb perf/watt aránnyal üzemelnek, nem olyan nagyon sokkal lassabban, mint asztali társaik. Asztali Zen-nél komoly kompromisszum, hogy csipletekre szedték a hatékonyabb gyárthatóság kedvéért, de ennek fogyasztás és memória késleltetés terén bőven van ára. -
#4438
HSM
félisten
Petykemano
#4436
HSM
félisten
válasz
Petykemano
#4436
üzenetére
"Na nézzük, igaz-e?"
Szerintem itt a méréssel van azért baj. Leginkább, hogy így beleszámoltuk a különböző fogyasztás alapú korlátozások hatását. A TPU-n első ránézésre nem volt túlzottan elengedve a 3900X ( [link] , gyári PPT max 140W, kb reális lehet a számok alapján).
Az AT tesztjéből ennyi sem derül ki sajnos, de erős a gyanúm, hogy a gyári PB beállításokkal mehetett, hiszen nem írt mást, ahol a kikapcsolt SMT rosszabb kihasználtságát és ezáltal fogyasztását pl. magasabb órajellel kompenzálhatta a csip. A fogyasztásméréses adatok is ezt látszanak alátámasztani.
Nekem van egy Ryzen 5 3600-as mérésem Cinebench R15-ben, pontosan ugyanúgy, mint itt [link] írtam, allcore 4,2Ghz-en, limitek nélkül lefuttattam SMT OFF is, és úgy 1145 pontot kaptam, ami alapján a 3600-asom a gyors memóriák mellett is profitált 43%-ot az SMT-ből, ami azért nem kevés. Így lenne érdemes megmérni az 5000-eseket is, fix órajel, limitek nélkül, SMT ON és OFF. Ahogy az AT is megállapította, még úgy sem érdemes kikapcsolni az SMT-t, ha az 5950X-es egészen jól kompenzálja órajelből. A cikkbeni állítással ellentétben nem véletlenül van engedélyezve szinte az összes kis fogyasztású Intel notebook CPU-ban i3-tól felfelé kb. mióta létezik.
-
#4427
HSM
félisten
Petykemano
#4413
HSM
félisten
válasz
Petykemano
#4413
üzenetére
Egyébként, hatékonyság témakör. Szerintem érdekes, a gyári BOOST-hoz képest mekkora tartalék van akár egy Zen2-ben is. Én ezt mértem: [link] . Elég impozáns szvsz perf/watt-ra amit a boost nélküli 3,6Ghz órajelén produkált.
#4415 S_x96x_S : A dekóderes rész nekem ott nagyon sántít, hogy nincs figyelembe véve, hogy az x86 komplex utasítás architektúra, azaz elviekben (!!!) kevesebb utasításból meg tudod csinálni ugyanazt, tehát a "dekóderszám x órajel" metrikát erős fenntartásokkal kezelném egy RISC rendszerrel összehasonlítva.
#4426 Petykemano : "Minél nagyobb a ROB (Re-order buffer), annál nagyobb a soron kívül, párhuzamosan végrehajtható utasítások száma"
Ami a ROB-ot illeti, vélhetőleg ott is azért sok tényezős az egyenlet. Például felső korlát a végrehajtó egységek száma a CPU-n belül. Annál nagyobb ROB-ot beépíteni pazarlás, mint ami a végrehajtó egységek hatékony működéséhez az adott csipen indokolt. A Ryzeneken pl. ott az SMT és az óriás L3, ami szintén sokat segíthet utasításokkal ellátni a végrehajtókat és átlapolni az esetleges várakozási időket.Ami az X86 utasításkészlet átalakítását illeti, az erősen problémás, hiszen az X86 legnagyobb előnye a kompatibilitás. Ha csinálsz belőle egy inkompatibilis verziót, akkor már jobban járnál, ha alapoktól átterveznéd az egészet egy hatékonyabb rendszerre.
"Vajon elképzelhető-e, hogy a 8 decoder beépíte azért lehetséges, mert a sűrű 5nm-en elképesztően rövidek a késleltetések, kicsi a delay."
Szvsz ezt máshogy értik.Ha lassú lenne a dekóder (azaz túl komplex), akkor csökkenne az elérhető órajel, ez nyilván az x86-nál okozhatna problémát. -
#4396
HSM
félisten
Petykemano
#4393
HSM
félisten
válasz
Petykemano
#4393
üzenetére
Ebben a latency dologban az a rendkívül érdekes, hogy korábban CCX-en belül ugyanúgy 17ns körül mértek a 3950X-en, a távoli CCD-n belül viszont lényegesen magasabb volt, mint amit linkeltél: [link]
Valamint volt egy gyorsabb és egy lassabb CCD. Valamelyik AGESA kódban úgy tűnik stratégiát váltottak, ami a CCX-ek szinkronban tartását illeti.
Tehát ezt az "óriási előrelépést" én azért így nem jelenteném ki. Azért a pontos okokra igen kíváncsi lennék. #4395 Pinky Demon :
"De mivel az L3 igy is marha nagy es tovabbi duplazast varok 5 nanon, L4-nek is csak akkor van ertelme, ha szignifikansan tobbet tud nyujtani mint az L3"
Nem helyettesítik egymást. Egy IOD-be rakott L4 éppen a CCD-k közötti szinkronizációt gyorsíthatná, ha ehhez nem kellene a ramig elmenni. A nagyobb L3 pedig a CCD-n belüli teljesítményt tudná javítani, ami egyébként jelenleg is elég jó, de ettől semmivel sem gyorsul a CCD-k közötti kommunikáció. -
-
HSM
félisten
válasz
wwenigma
#4311
üzenetére
Szalmabáb érvelést nem kérünk.
Tehát, Intelen átlagosan maximum annyit fogyaszthat, mint a ráírt TDP (kivéve néhány tuninglap, ahol ehhez 3 paramétert be kell állítani a gyári ajánlásnak megfelelően). Míg AMD-n minden lapon egy magasabb fogyasztási limit van érvényben, mint a ráírt TDP, méghozzá ez a gyári elvárt működés, nincs is mit beállítani. Ezek a száraz tények. -
HSM
félisten
válasz
wwenigma
#4307
üzenetére
Pedig ez a normálisabb hozzáállás, a partner, OEM úgy hangolhatja, ahogy az adott hardver környezet képességei megengedik, elsősorban a VRM és a hűtés. A usernek pedig ha nem tetszik, korrigálhat.
Három paramétert kell a standard értékeket nem követő lapokon a helyére billenteni, és gyári működést kaptál. AM4 lapokon viszont, ha a gyártó picit előnyt akart, akkor buktad, ha megfeszülsz se lesz gyári működésed. [link] Ez szvsz sokkal komolyabb probléma, mint a másik oldalon, hogy az erősebb, tuning központú lapokon tipikusan magasabbak a gyári limitek, mint az ajánlott.
Sőt, itt meg azt írják, amire én is eredetileg emlékeztem, hogy ugyanaz a 32EU-s verzió, ami az Alderbe is kerül. 
Ez elvileg 48 GPU-magból, asztali Alderre még ennél is kevesebbet, 32-t mondanak.
Jó dolog, ha kicsi és könnyű lehet az ember relatív erős munkaállomása, és nem merül le csak attól, ha ránézek. 
Még szerencse, hogy ki tudtam kapcsolni a laptopomon ("Linux-standby", lol), így tud kultúráltan is aludni, és nem akar pl. a táskámban fel-felébredni. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
A Zen3 egyik nagy erőssége, hogy igen jó perf/watt mutatójú magokat használ. Kazán üzemmódban pedig eddig is volt konkurens, igaz, valamivel drágábban. 11700K (~400$) és 10900K-ra gondolok főleg.
Új hozzászólás Aktív témák
Hirdetés
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- eMAG vélemények - tapasztalatok
- Íme az új Android Auto!
- Milyen NAS-t vegyek?
- Teljes verziós játékok letöltése ingyen
- Óra topik
- Tudományos Pandémia Klub
- Honor Magic6 Pro - kör közepén számok
- A fociról könnyedén, egy baráti társaságban
- Milyen billentyűzetet vegyek?
- További aktív témák...
- Eladó konfig! Ryzen 7 7800X3D 2TB SSD 64GB DDR5 RX9070XT 16GB!
- Új, makulátlan állapotú Samsung Galaxy Buds FE, fehér, fél év garancia
- Új, makulátlan állapotú Samsung Galaxy Watch7 44mm ezüst, 2 év garancia
- Új, makulátlan állapotú Samsung Z Fold 6 256GB Tengerészkék, független, 2 év garancia
- Használt TP-Link Deco M4 - AC1200 Router (Mesh-ként is használható)
- Telefon felvásárlás!! iPhone X/iPhone Xs/iPhone XR/iPhone Xs Max
- NJOY Aster 3K 3000VA/2700W Rack Szünetmentes Táp
- Bomba ár! Dell Inspiron 15 3511 - i5-11GEN I 8GB I 256SSD I HDMI I 15,6" FHD I Cam I W11 I Gari
- BESZÁMÍTÁS! ASUS B450 R7 1700X 16GB DDR4 512GB SSD RX 580 8GB Rampage SHIVA Corsair 450W
- Lenovo Legion 5 Gaming. Az ár irányár, komoly érdeklődés esetén van lehetőség egyeztetésre
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest