- Nyomtató topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Fejhallgató erősítő és DAC topik
- Megérkezett Magyarországra az LG 480 Hz-es OLED monitora
- Gaming notebook topik
- Samsung QN800D: Neo QLED 8K tévét teszteltünk
- Hobby elektronika
- Computex 2024: Itt az új ROG Ally
- Hisense LCD és LED TV-k
- Nem indul és mi a baja a gépemnek topik
Hirdetés
-
Killing Floor 3 - Nyúlfarknyi videón a folytatás
gp A franchise új része sajnos még mindig nem kapott megjelenési dátumot.
-
Bemutatkozott a Redmi 13 4G
ma Ne keverjük össze a Redmi Note 13 4G-vel vagy a Redmi 13C 4G-vel.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
Új hozzászólás Aktív témák
-
Petykemano
veterán
válasz Cathulhu #369 üzenetére
Vagy hogy megmérd és a mérési eredményeidet publikáld, hogy
- valaki más megtegye az összehasonlítást
= akár saját korábbi eredményekkel
= akár konkurens termékkel
(- gépjárművek esetén, hogy más is megnézhesse, hogy a mért érték tényleg megfelel-e és milyen mértékben az előírtaknak)Találgatunk, aztán majd úgyis kiderül..
-
S_x96x_S
őstag
válasz Cathulhu #369 üzenetére
>Ez legalis egyaltalan?
külön fórum:
https://prohardver.hu/tema/re_megtiltja_a_teszteket_az_intel_uj_mikrokodjahoz/friss.html
[ Szerkesztve ]
Mottó: "A verseny jó!"
-
Petykemano
veterán
válasz Cathulhu #373 üzenetére
Hát... ezek ilyen nagyon pletykák, de azt mondják, hogy a zen+ eleve azért lett, mert az AMD látván azt, hogy az intel felbukott a 10nm-en, kapva kapott az alkalmon és előrehozta a zen2-re azt a fajta moduláris felépítést, hogy már nem komplett önmagukban is működő lapkákból áll össze az MCM, hanem cpu magokat tartalmazó lapkákból és egy központi, az adatkommunikációért felelő - akár más gyártástechnilógián előállított - egységből ezeket IF-fel összekötve.
Ha ez igaz, akkor nincs kizárva, hogy a Matisse nem zen2, hanem zen++, nem 7nm, hanem 12nm+.
Nagyjából ilyesfajta számokat látunk.Aztán lehet, hogy olyan sandbagging mint amit Jensen csinált, hogy az új geforce még naaagyon távoli.
[ Szerkesztve ]
Találgatunk, aztán majd úgyis kiderül..
-
S_x96x_S
őstag
válasz Cathulhu #401 üzenetére
Én nem tudom, de nem lesz egyszerű döntés.
valószínüleg több tényezőtől is függ és nem csak az Intel-től.
például - szerver fronton kezd feljönni az ARM64 -
és a Microsoft is kisérletezik az ARM64-el
az APPLE-ről nem is beszélve, aki valószínüleg teljesen dobni akarja az X86 -os vonalat.Valami üzleti elemzésben olvastam, hogy az AMD-nek szerver fronton igazából az ARM a versenytársa ,
mindaketten az INTEL szerveres sajtjára pályáznak.
És még az IBM is ott van a saját chipjével - szerintem ott lehetnek a 4 között.bővebben:
http://www.eweek.com/pc-hardware/startup-ampere-releases-first-arm-based-server-chips----------------------
más :
bejelentették az új ThreadrippereketAMD 12 and 24-Core Threadripper 2 CPUs: 2970WX and 2920X on 29th October
https://www.anandtech.com/show/13443/amd-announces-availability-of-12-and-24core-threadripper-2-cpus-coming-late-octoberés az új "Dynamic Local Mode" -ot. (NUMA )
( szerintem a 12magos AM4-es procik is ilyen megoldást kapnak )
Previewing Dynamic Local Mode for the AMD Ryzen™ Threadripper WX Series Processors
https://community.amd.com/community/gaming/blog/2018/10/05/previewing-dynamic-local-mode-for-the-amd-ryzen-threadripper-wx-series-processors[ Szerkesztve ]
Mottó: "A verseny jó!"
-
S_x96x_S
őstag
válasz Cathulhu #408 üzenetére
>ha lesz 2800X, az cherry picked 2700X lesz azaz kb zero eroforrast vinne el
>es alaplapi tamogatas se kell hozza.- más felirat a tetejére biztos kell hozzá,
- és chip-en belül is át kell ütni a kódját, hogy a szoftverek egy külön prociként azonosíthassák:Ha nem kapna más kódszámot, akkor könnyen hamísítható lenne.
(pl. sima 2700-ast átszitáznak 2800X-re )Emiatt nem is hiszem, hogy a raktarak tele vannak valogatott 2700X-ekkel.
Ha van, akkor mért nem dobja piacra minnél korábban az AMD?
várjon még 2-3 hónapot, hogy lemenjenek az árak?
Akkor már nincs rajta annyi profit !
Amit ma eladhatsz - ne halaszd a jövő hónaprameg szerintem a threadripper-be mentek a válogatott CCX-ek - ott nagyobb a profit margin,
Mottó: "A verseny jó!"
-
Petykemano
veterán
válasz Cathulhu #425 üzenetére
De csak ezzel kéne kezdeni valamit. Mert ha az amd el is éri az 5GHz-et, akkor is alulmaradhat ezek miatt a bakik miatt. Akár gaming, akár valami többszálas production programban. Mindig lesz majd olyan, ami nincs a ccxre optimalizálva, és ezért a késleltetések miatt bukó.
Akárhogy is nézzük, ez ha nem is low hanging fruit, de musthave. Bizonyos magszám fölött ugye már az intel sem ring bust használ, hanem mesht, ami ugyanolyan rossz, mint az IF. Pontosabban magas magszámot tesz lehetővé. Tehát kB 8 mag esetén kellene csak megoldani jobbra a késleltetéseket, afölött már kB versenyképes az intel megoldásával.Találgatunk, aztán majd úgyis kiderül..
-
Petykemano
veterán
válasz Cathulhu #451 üzenetére
Ja hogy arra gondolsz, hogy halo product lenne? Papíron létezik, a 1000W-os chillerrel gyönyörűen le is tudják hűteni, kapni nem nagyon lehet majd, ha esetleg valakinek tényleg kéne, de ha mégis, inkább zárt ajtók között átbeszélik a 2S 28 magos megoldásra?
Én arra gondoltam, hogy bűzlik, hogy abból tényleg kézzelfogható, értelmes termék legyen, nem valami marketing-hack. Az nvidia például úgy szokta csinálni.
A linkpack állítólag nagyon AVX512
"The Next Platform that the 48-core Cascade Lake chip will have 21 percent more oomph on Linpack than the top-bin Skylake Xeon SP-8180M Platinum chip with 28 cores running at 2.5 GHz, and if you do some rough math, that puts the clock speed of the Cascade Lake AP at around 1.8 GHz. "
"On the STREAM Triad test, the future Cascade Lake AP MCM will beat the top-bin Skylake Xeon SP SCM by 83 percent, which is pretty good, but will only be 30 percent better than the AMD Epyc 7601."
Ha a az elég "kezdetleges" 7601-hez képest +30%-ot tud csak ebben a tesztben, azt gondolnám, hogy akkor ezt a 7nm-en készülő epyc2 még 48 maggal is megugorná.
Találgatunk, aztán majd úgyis kiderül..
-
S_x96x_S
őstag
válasz Cathulhu #453 üzenetére
>Arra van barmi esely, hogy AVX512 support jojjon a Zen2-ben? Tudom nagyon retegigeny,
>de az intel egyetlen megmaradt fegyvere benchmarkokban.szerintem kicsi az esély.
- inkább a sima AVX2 -t kellene megerősíteni.
- Az AVX512 túl sok szilikonhelyet elvesz és melegszik extrém módon.
- az AMD a GPU-val próbálja megoldani az AVX512-es feladatokat.https://twitter.com/InstLatX64/status/1057607067844911104
meg az AVX512 is finomodik még. nyugodtan lehet várni 1 évet.
https://pbs.twimg.com/media/DXSRqJXXUAE0s4J.jpg:largeAz AMD-nek más a stratégiája - Agner AVX elemzése ( ZEN-ről )
"AMD has a different way of dealing with instruction set extensions than Intel. AMD keeps adding new instructions and remove them again if they fail to gain popularity, while Intel keeps supporting even the most obscure and useless undocumented instructions dating back to the first 8086. AMD introduced the FMA4 and XOP instruction set extensions with Bulldozer, and some not very useful extensions called TBM with Piledriver. Now they are dropping all these again. XOP and TBM are no longer supported in Ryzen. FMA4 is not officially supported on Ryzen, but I found that the FMA4 instructions actually work correctly on Ryzen, even though the CPUID instruction says that FMA4 is not supported."
https://www.agner.org/optimize/blog/read.php?i=838[ Szerkesztve ]
Mottó: "A verseny jó!"
-
Petykemano
veterán
válasz Cathulhu #453 üzenetére
Én nem értek a lovakhoz, de azt olvastam, hogy az AMD-nek avx512 impelemtálása helyett praktikusabb lenne inkább az ilyen hosszú tömbök kezelésére gpu-t bevetni.
Pontosan nem tudom, mi a különbség a vliw, meg simd, meg avx512 között, de Elvileg mindegyiknek az a lényege, hogy minél sűrűbben tömbösített adatokon tudjál végrehajtani utasítás(oka)t.
Én meglepődnék ha az AMD mégis belemenne ebbe.az utcába.
Találgatunk, aztán majd úgyis kiderül..
-
S_x96x_S
őstag
-
S_x96x_S
őstag
válasz Cathulhu #473 üzenetére
>Nem, mert szoftver szinten mostmar nem kell tudnod melyik kozeli es melyik tavoli memoria
de azt nem árt tudni, hogy melyik chiplet-hez milyen core-ok tartoznak.
Ha az ütemező az összetartozó feladatokat egy chiplet-re optimalizálja, akkor jobb lesz a késleltetés.Egy chiplet-en belüli kommunikációnál a latency is jobb lehet.
persze ezt már nem numa -nak nevezik. de mi ahivatlos neve ?
lehet, hogy keverem a CCX hopping -al ..
Mottó: "A verseny jó!"
-
S_x96x_S
őstag
válasz Cathulhu #474 üzenetére
>Kivancsi vagyok a Ryzenek is kulon IO vezerlovel jonnek-e majd. Itt azert ketsegeim vannak,
>nem erne meg, viszont igy meg akkor teljesen kulon kell tervezni asztalira es szerverre.Szerintem 4 csatornás kisebb IO vezérlő lesz - kisebb tudással,
és 2 CCX -el
( vagy 1CCX + GPU)
- ami belefér egy am4 tokba.legalábbis nekem igy lenne racionális. Kevesebb PCI és IO csatorna.
de igencsak elbizonytalanítottál. nem vagyok benne biztos.
Mottó: "A verseny jó!"
-
S_x96x_S
őstag
válasz Cathulhu #479 üzenetére
>Szerintem maradnak az 1 CCX-es, max 8 magos kiszerelesnel, akinek tobb kell, vegyen TR3-at.
ha technikailag megoldható - akkor meg is fogják csinálni a 2 CCX-et ( 16 maggal az AM4-en).
Verseny van.
Az Intel most 8 magnál jár, de lehet, hogy már ők is készülnek egy 10magos asztali procival.
AZ AMD-nek válaszolni kell egy ilyen valószínű lehetőségre.
Sőt az első csapás az AMD-nek kell megépnie.A késleltetésen és a memóriavezérlőn szerintem sokat javítanak majd. De majd a teszteknél kiderül.
Mottó: "A verseny jó!"
-
HSM
félisten
válasz Cathulhu #474 üzenetére
Egy kisebb IO csip simán reális lehet asztalira is. Nagyon okos húzásnak tűnik ezt a kevésbé kritikus, de annál nagyobb méretű I/O részt az olcsóbb, de még mindig bőven jó és elérhető 14nm-es gyártástechnológián hagyni. Oda egy plusz lapkát tervezni sem akkora költség, mint 7nm-re. Aztán mehetnek asztalra is ugyanazok a 7nm csipletek.
[ Szerkesztve ]
-
TRitON
aktív tag
válasz Cathulhu #482 üzenetére
Szerintem AM4-be 2 féle CPU-t fogunk látni:
- 1 CCX chip, saját I/O-val és memóriavezérlővel, 8 maggal, "olcsón", illetve
- 2 CCX + 1 uncore chip (ami nem ugyanaz, mint az EPYC uncore chipje), közös I/O-val és memóriavezérlővel.
Meg lenne az az előnye, hogy akinek tényleg minimális delay-ekre van szüksége, megveszi a 8 magos változatot, aki pedig dolgozni akar rajta, tud venni egy olcsó platformba 16 magos CPU-t.
A nagy kérdés most már csak a fogyasztás...Mi az? 3 lába van mégsem tranzisztor? - ??? - Traffipax...
-
Petykemano
veterán
válasz Cathulhu #494 üzenetére
Biztosan.
De ha minden jól megy, egy chiplet már 1 CCX osztatlan 32MB-os L3-mal.Az sok helyütt felvetődött, hogy a közel 500mm2-es IO chip azt tartalmazza-e, ami a 4 zeppelin chip uncore része volt, vagy abban volt nem használt redundancia (pl USB, South bridge), ami felhasználásra került
Ezen a képen sok rész (kék) nincs külön megnevezve, én nem tudom megállapítani, hogy az nem megnevezett uncore rész, vagy csak huzalozás, vagy mi. Szóval a sok helytütt felvetődött kérdés, hogy vajon az IO chip tartalmaz-e L4$-t (és HBCC-t?)Az előző bejegyzés alapján "8MiB L3 block on its own is 16mm^2." könnyen kiszámítható, hogy mondjuk 256MB L4$ 500mm^2 lenne, ami képtelenség. Ennél kisebbnek, tehát bárminek, amiben nem fér el az összes CCX L3$ tartalma, pl 128MB-nak nem tudom lenne-e értelme.
A dolog elvileg nem értelmetlen, mert a Broadwell is kapott 5-10% előnyt a 128MB eDRAM hatására.
Találgatunk, aztán majd úgyis kiderül..
-
Petykemano
veterán
válasz Cathulhu #497 üzenetére
"I have a theory on the Rome I/O die. AMD is building it at 14nm instead of TSMC 16nm. One reason is GF WSA. There could be another reason. GF 14HP supports eDRAM. Bit cell size 0.0174 sq um. AMD can pack 256 MB of eDRAM L4 cache in roughly <= 120 sq mm"
Találgatunk, aztán majd úgyis kiderül..
-
válasz Cathulhu #505 üzenetére
"Ha mindez igaz lenne (nekem tetszik az otlet) akkor Lisa hatalmas dobasa, gyakorlatilag ket legyet egy csapasra, olcso IO vezerlo a GloFotol, WSA teljesitve, mehet a fontosabb chiplet gyartas a fejlettebb TSMC-hez."
Az eDRAM-ot viszont nagyon nem értem. Miért lenne az jó? Esetleg azt tudom elképzelni, hogy IGP mellé pakolnak ilyet HBC-vel, de nem tudom képes lenne-e megfelelő sávszélre.
Ugye az Intelnél az eDRAM-ra azért van szükség, mert a GPU architektúrájuk nem skálázódik jól, ezért bruteforce módon eDRAM-mal támogatják.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
Simid
senior tag
válasz Cathulhu #530 üzenetére
Oké, értem én, hogy úgy általában mi a gyorstárazás előnye. Akkor pontosítok kicsit: Mi értelme egy IF-en keresztül elérhető L4 cachenek ebben az esetben?
Itt most lehet én értem félre az IF működését (illetve erről az új fajtáról nem sokat tudunk), de a probléma eddig az volt, hogy vagy a CCX saját cache-ben volt az adat vagy az IF-en keresztül kellett azt bekérnie, ahol viszont a többi CCX L3$ adataihoz is hozzáfér. Most ez annyit változott, hogy már a RAM hozzáférés is minden esetben IF-en keresztül történik, cserébe nagyobb a cache és szélesebb lett egy-egy IF link.
Ebből nekem az jön le, hogy bármit is csinál az I/O die, azt IF-en érkező utasítások alapján csinálja. Egy itt elhelyezett nagyméretű cache is csak az IF-en keresztül lesz hozzáférhető és semmivel nem lesz gyorsabb mint egy másik CCX L3$-éhez való hozzáférés. Akkor viszont felmerül a kérdés, hogy ha már több cachet szeretnének, akkor miért nem a CCX mellé rakják azt? Így legalább az adott CCX gyorsan érné el, de a többinek is gyorsabb lenne mint a RAM. Persze, értem én, hogy 7nm vs 14nm és SRAM vs eDRAM, szóval rohadt drága lenne. De az sem mellékes, hogy így legalább több die-on lenne elosztva egy hatalmas tömb helyett és ez viszont költség csökkentő tényező.
Lehet pont ezért duplázták meg a magonkénti L3 mennyiségét, mert hasonló módon gondolkodtak.Ha jól értem, ti azt feltételezitek, hogy az I/O die-on keresztül elérni egy másik lapkát nem olyan közvetlen elérés mint most a zeppelin esetében, hanem valami két lépcsős folyamat (CCX-I/O majd I/O-CCX). Így valóban lenne értelme a két lépcső közé cachet rakni. Én viszont úgy képzeltem ezt (megintcsak laikusként, lehet teljesen hibásan), hogy az I/O die egy IF switch, hasonlóan mint az NVSwitch. Ebben az esetben az IF-en keresztül bármi elérhető közvetlenül és így késleltetés szempontjából az hogy I/O die-on lévő L4 vagy egy másik CCX L3-a, az tök mindegy.
-
Simid
senior tag
válasz Cathulhu #533 üzenetére
"egyrészt a nagy L4-be prefetcher sokkal nagyobb szeleteket tud betölteni mint L3ba"
Erről fogalmam sincs, szóval elhiszem."másrészt így mind a 64 mag között lesz egy nagy közös cache, nem csak CCX páronként."
Úgy tudom az első gennél is megosztott az L3. Fizikailag persze szét van szórva, de legalább az adott CCX gyorsan hozzáfér a saját szeletéhez.Hogy kicsit magam ellen is beszéljek. A több cache nyilván mindig jó, csak nem mindenhol éri meg. Az I/O die cachenek meg van az az előnye, hogy szabadon variálható a különböző termékkategóriákra. Desktopra/HEDT-re úgyis más I/O kell majd valószínűleg. Ha a CCX-ek mellé rakják nincs meg ez a rugalmasság.
-
Petykemano
veterán
válasz Cathulhu #548 üzenetére
De és ez a csomó késleltetés ez biztos?
Mert ha igen, akkor az meg is adja a választ arra, hogy a következőkben miért is lenne indokolt imterposer használata. Lezso azt mondta, az IF nem széles, nem szükséges az IP, de az IP miközben rövidít, aközben szélesebb buszt is lehetővé tesz. Ha az irány az IF javításán vezet, akkor az IP a későbbiekben elkerülhetetlen.Mindenesetre az jó hasonlat, hogy mintha csak közvetlen memóriaelérés nélküli TR lapkák lennének. Az biztos kolönbség, hogy az IF órajele magasabb kell legyen, ez máris csökkenthet a késleltetesen.
Viszont ha ebben igazad van, az megint csak indkolja, hogy az IO lapkán egy bazi nagy cache legyen, hogy egy útvonal minél inkább megúszható legyen. (Eddig: cpu<->ram, most: cpu<->io), amibe a prefetchelést maga az IO lapka végezze. Pont úgy, ahogy a Vega HBCC-nél láttuk. (Lehet, hogy a technológiát ott csak kipróbálták)
Az, hogy ezt a struktúrát fel lehetne használni gpuknál, nem egyedi gondolat. Sőt, kicsit a 4 Shader engine már eleve ez. De mennyivel jobb lenne minden shader enginet külön gyártani és IF-fel össszekapcsonil? Akár külön célra. Akár válogatva.
(Via)Találgatunk, aztán majd úgyis kiderül..
-
válasz Cathulhu #548 üzenetére
Jaja, korábban mondtam, hogy az AMD megcsinálta a Larrabee-t, csak rendes CPU magokkal.
A Zen3-nál az SMT4 és a Zen4-nél az AVX-512 támogatása azt mutatja, hogy az AMD az Intel eredeti ötletét fogja megvalósítani. Ugye Knights Landing-ban minden egyes CPU mag 4 szált támogat és két db AVX-512 egység van benne.
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
-
S_x96x_S
őstag
válasz Cathulhu #578 üzenetére
az a gond, hogy aki céges környezetben dolgozik, azt valamennyire érinti ez teljesítménycsökkentő "apróság",
függetlenül, hogy most merre is drukkol.
Szóval ajajj .. ( legalábbis az én nézőpontomból )
Mindenesetre ez egy igen erős érv a konzervativ biztonságot preferálók számára.>Nem csoda, hogy az intel menekul a HTtol az uj generaciokban.
>Kerdes az AMD-nek is kelleni fog-e majd?hát ha igaz a pletyka a "Zen 3: SMT4" -ről ,
akkor az már 4 szállas threading-et jelent, tehát inkább növelés irányába megy el.[ Szerkesztve ]
Mottó: "A verseny jó!"
-
S_x96x_S
őstag
válasz Cathulhu #578 üzenetére
#Security
> Beutott a spectre az intel CPUknak a 4.20-as kernelben,
újabb - részletesebb - teszt:
"The Spectre/Meltdown Performance Impact On Linux 4.20, Decimating Benchmarks With New STIBP Overhead"
https://www.phoronix.com/scan.php?page=article&item=linux-420-stibp&num=1Mottó: "A verseny jó!"
-
Petykemano
veterán
válasz Cathulhu #605 üzenetére
"As for AMD, in 2016 it launched what remained of the Arm chip it was working on with Amazon, the Opteron A1100 codenamed Seattle. The clue was in the name, we note. Today, AMD is all in with its much more successful Zen-based x86 processors, Ryzen and Epyc, and no one talks about the A1100."
"Here's what we know about the Graviton right now. Its CPU cores are based on Arm's 2015-era Cortex-A72 designs, and are clocked at 2.3GHz. They are 64-bit, Armv8-A, little endian, non-NUMA, and feature hardware acceleration for floating-point math, SIMD, plus AES, SHA-1, SHA-256, GCM, and CRC-32 algorithms.
"Other benchmarks put the Graviton on the same footing as a Qualcomm Snapdragon 835, in terms of single-core performance. CPU benchmarks don't tell the whole story: there's always networking, latency, storage access, and so on, to worry about in the cloud."
Itt még lesz fejlődés.
Találgatunk, aztán majd úgyis kiderül..
-
S_x96x_S
őstag
válasz Cathulhu #737 üzenetére
Ez részletesebb - tele "genyó" kérdésekkel.
"Mark Lipacis
Thanks for taking my question and great to hit the mid-single digit milestone exiting the year. Lisa, as you start -- I just wanted to confirm, you expect to start shipping Rome mid-year. And as you do, what's the biggest risk for Rome? Is it execution on delivering the product, or is it the sales process convincing customers to take EPYC to in volume?
Lisa Su
So I think with Rome, our biggest opportunity/risk is adoption rate. I think from a competitive standpoint, the product is very solid, everything going through our development labs looks very good, as well as our customer engagements. And so this is just about getting customers to production as fast as possible. We do expect though that the adoption rate for Rome will be faster than the adoption rate for Naples. And the reason for that is we are in a socket compatible infrastructure. And so customers who don't necessarily need the newest features of the platform can actually use the same motherboard and system that they currently have with Naples and drop in Rome. And so I think that will help us accelerate some of the adoption. But right now, it's about helping customers in their environment. We are widely sampling Rome and there's a lot of work to be done but we feel good about the trajectory.
""Mitch Steves
First on the C&G side, I realized that there's going to be a lot of sequential difficulties there. But when I think about the long-term growth rate, I know you guys have talked to high singles to double-digit growth. Is that still essential where you think that business can grow at long-term? And then secondly in terms of the next EPYC 2. Is there any reason why it would underperform Intel 10 nanometer in a testing environment? And if so, why would that be?
Lisa Su
Let me take the second question and then maybe Devinder you can take the first question. So as it relates to our ROM product, when ROM was originally planned, we had planned that it would be competing against the 10 nanometer product. So that was our expectation when we started. I think we've shown some of the generational performance advantages in terms of double digit performance on a socket basis, 4 times performance on a floating point basis. And the other thing I would say is that with our second generation Rome, the customer set is now more used to our architecture and so some of the architectural and software improvements that we've also spent quite a bit of time on over the last four to six quarters are coming into play. So I think we feel very good about the competitive positioning of Rome. And the other thing to keep in mind is we are deep in development of our next generation Beyond Rome. So the Zen 3 product portfolio is deep in development as well. And so that our goal is to ensure that we have a consistent cadence of very competitive products.
"
Mottó: "A verseny jó!"
-
S_x96x_S
őstag
válasz Cathulhu #739 üzenetére
>Ez kb el is dönti azokat a találgatásokat, hogy jön-e idén PS5
A tőzsdei szabályok szigorúak. A Sony dönti el, hogy mikor lép piacra - emiatt ezt a spekulációt nem szerepeltetheti az AMD a várakozások között.
A szerződést se ismerjük, hogy piacralépés után mikor jelenik meg bevételként a főkönyvben.Vagyis az AMD csak a konzervativ várakozásokat kommunikálhatja.
Mottó: "A verseny jó!"
-
veterán
válasz Cathulhu #743 üzenetére
A DIY piac, ahol szépen feljöttek, vélhetően rendesen eltörpül a teljes desktop piachoz képest. Ha az OEM-ek nem építenek rájuk jobban, akkor ez az arány olyan nagyon sokat nem is tud javulni így. Nálunk is jöttek most új gépek, irodai excelezésre i5-8600, pedig egy Ryzen 3 2200G is bőven elég lett volna.
De elvileg nem olyan régóta fókuszálnak rájuk, szóval várható még javulás: AMD also announced last year that it would focus on expanding its stable of OEM systems to build market share. That strategy appears to have paid off, as McCarron also attributed part of AMD's success to increased OEM adoption.
solfilo
-
S_x96x_S
őstag
válasz Cathulhu #761 üzenetére
meglátjuk ... mindenesetre nem lefutott a mecs.
az Intel-t 2 oldalról szorongatják.
valószinüleg az AMD-vel jobban jár - mert x86 -on maradnak a vevők - és bármikor visszatérhetnek az Intel-hez. de ha átváltanak ARM-re, a szoftvereket átportolják ( gcc-vel nem is olyan nehéz manapság )
akkor nehéz a visszalépés.és akkor ott van még a RISC-V -is - aminek a tervét - szinte ingyen osztogatják, bárki tudja gyártani.
>Másrészt látjuk az AMDnek mennyire nyögvenyelősen indul be az Epyc biznisz,
>pedig ott a vevőnek x86-ról x86-ra kellene váltania.a felhős cégek lehetnek motiváltak.
az EPYC1 az árán kivül nem mutatott előrelépést
( pl. fogyasztásban - ami egy felhős cég üzemeltetési költségét megdobja )Az Amazon lesz a kulcstényező. ( Az Anandtech-es cikkből másolva )
"The elephant in the room is Amazon, and last year’s reveal of a new AWS instance based on their own-in house ARMv8 Graviton processors marked a significant moment showcasing that Arm is now irrefutably becoming mainstream in the industry.
While Arm did not divulge any information on who will be employing the new Neoverse N1 platforms first – I would not be surprised if the next generation Graviton processor will based on the N1 CPU."Mottó: "A verseny jó!"
-
S_x96x_S
őstag
válasz Cathulhu #766 üzenetére
> az ARM szerverek a kísérletező kedvűeknél találhatnak eleinte gazdára,
ha az Apple tényleg dobja az Intelt, akkor az az ARM szerver elfogadottságra is jó hatással lesz.
Intel officials believe that ARM Macs could come as soon as 2020
https://appleinsider.com/articles/19/02/21/intel-officials-believe-that-arm-macs-could-come-as-soon-as-2020Apple Reportedly Shifting to Its ARM-Based A-Series Chips For Macs as Early as Next Year, States Latest Report
https://wccftech.com/apple-arm-a-series-chips-for-macs-2020/ha ténylegesen is jobb lesz a felhőkben az ár/teljesítmény mutató, akkor egyre többen állnak át.
A legtöbb rendszer OpenSource / Linux ;
- bizonyos microservizeket nagyon egyszerű átrakni egy ARM-es platformra.és ha a fejlesztőknek ARM-es platformja lesz ( ARM-es MacBook Pro ) akkor a Linus által emlitett
"Without a development platform, ARM in the server space is never going to make it. "
is kipipálva.persze ez több éves folyamat és az Intel és az ARM és közbeszól, mindenesetre a folyamat elindult
és mint a rozsda marja az ARM a x86 szerverpiacot is.[ Szerkesztve ]
Mottó: "A verseny jó!"
-
S_x96x_S
őstag
válasz Cathulhu #770 üzenetére
> Nem gondolom, hogy a Macen dolgozó programozók jelentős számban lennének jelen
én amikor elmegyek egy nemzetközi sw fejlesztői konferenciára,
akkor 50--60% -ban OSX-es gépeket látok.
( A frontend, design vonalon még több - a backend részen viszont kevesebb )4-5 ével ezelőtt elég trendi volt a MacBook. és nem csak az iPhone és a OSX-re fejlesztők között.
persze azóta már sokat változott a helyzet, de azért még manapság is észrevehető."Why do most of the developers in Silicon Valley prefer macOS over Linux or Windows?"
https://www.quora.com/Why-do-most-of-the-developers-in-Silicon-Valley-prefer-macOS-over-Linux-or-Windows"Why do most professional programmers prefer Macs?"
https://www.quora.com/Why-do-most-professional-programmers-prefer-Macs"From the top answer:
The best software for web development exists on OS X. It is believed that the best developers are on Macs, so they built the best tools on Macs for Macs. Tools such as TextMate and more."sőt amikor ilyeneket irnak, hogy miért ne használj ...
"Why Developers Should NOT Use MacBook Pro"
"About ten years ago there was an article claiming that “Every Developer should have a MacBook Pro”, which listed a bunch of reasons, for example ...."
https://hackernoon.com/why-developers-should-not-use-macbook-pro-3b6a4aeeee64> Tizenpár éves pályafutásom alatt eggyel sem találkoztam.
valószinüleg hazai Enterprise + Windows vonalon dolgozol,
ahol a fejlesztőknek kicsi szavuk, hogy milyen gépet választanak maguknak.
( de ott is a trendi projekt menedzserek már 10 éve is MacBook-al villogtak )amúgy én is elfogult vagyok ( ==> Thinkpad + Linux ) ráadásul még a Retina Display-t se birná a szemem.
mindenesetre már nézegetem a RYZEN -es Thinkpad-eket. ( "A285" , "A485" )
[ Szerkesztve ]
Mottó: "A verseny jó!"
-
S_x96x_S
őstag
válasz Cathulhu #772 üzenetére
csak arra - a szerintem tulzó- általánosításodra reagáltam, hogy:> Nem gondolom, hogy a Macen dolgozó programozók jelentős számban lennének jelen
de csak azért - mert az én benyomásaim teljesen mások.
kerestem egy survey ... lehet, hogy te jobbat találsz:
innen https://insights.stackoverflow.com/survey/2018/#developer-profilea top operációs rendszerek :
"Developers' Primary Operating Systems" - Prof Developers:
- Windows: 49.4
- MacOS 27.4%
- Linux-based: 23.0%persze ez se reprezentativ, mindenesetre sokkal nagyobb mint a jelenlegi ARM-es szerver részesedés.
Mottó: "A verseny jó!"
-
Petykemano
veterán
válasz Cathulhu #776 üzenetére
A 3D stacking videoban megfogalmazott ígéretéhez képest a zen2 nem hoz brutális cache mennyiséget. Sőt, ugye nemrég bizonyosodott be - legalábbis számomra -, hogy egy zen mag csupán 8MB L3$ közvetlen használatára képes. Mivel az L3$ victim, ezért a másik CCX L3$-ében megtalálni valamit eléggé esetleges, az egyszálas teljesítményhez meg alig van így köze.
Ezt duplázza a zen2, ami még mindig csak 16MB.Ehhez képest az intel eDRAM 128MB volt, az asszem everspin 28nm-en 256mbites STT-MRAM lapkákat (lenne) képes gyártani. Tehát itt ha csak a méretet nézzük valóban inkább többszáz MB cache hozzáadásának lehetőségéről van szó - valószínűleg egy következő layerben (L4)
a nagy kérdés persze az, hogy ezt milyen késleltetéssel tudja megtenni. Mert a késleltetes lenne itt a lényeg.
Illetve va. Még egy, ami érdekes lehet. A zenben az L3$ victim, vagyia az kerül bele, ami az L2$-ből kilökődött. De nyilván lehetne ezt valahogy okosabban, előrelátóbban csinálni. Ezt a beszélgetést lefolytattuk a zen2 io die esetén is, elvileg ahhoz képest a 3d stacking annyiból lehet előnyös, hogy a lapkák.egymásra építése miatt a rövid utak tényleg alacsony késleltetésű hozzáférést tehetnek lehetővé.A HBM nem 2.5D stacking?
Találgatunk, aztán majd úgyis kiderül..
-
Petykemano
veterán
válasz Cathulhu #779 üzenetére
Azt néhány benchmarknál láttuk, hogy hogy megtáltosodott, amikor hirtelen belefért az 512Kb L2$-be.
Nyilván egy L4$ nem rendelkezik olyan késleltetéssel, mint az L2$, de ha egy nagyobb méretű cache rendszermemóriánál jobb késleltetéssel bír, az néhány százalékot biztos segít. Sőt!
Az L3$ esetén is már tapasztalható volt, hogy nem minden szelet érhető el ugyanolyan késleltetéssel egy adott mag irányából. Ha egy nagyobb L4$-t is hasonlóan építenek fel, ami magának prefetchel a rambó', defragmentál, és a sűrűn használt adatokat áthelyezi az alacsony késleltetésű rekeszekbe, akkor az szépen gyorsíthatja a rendszert. Akár 3D, akár io die, hovatovább később akár maga az interposer is tartalmazhatja ezt.A zennel kapcoslatban én már felvetettem, hogy vajon van-e egyáltalán inter-CCX kommunikáció. Lévén, hogy victim cache az L3, amibe csak akkor kerül be valami, ha adott CCX-ben egy mag L2-jéből kihullik. Az Intel egy mérését láttam, ők 103 vs 105 ns-ra mérték ki az interCCX és a RAM kommunikációját, ami annyira kicsi különbség, hogy felvetődhet a kérdés, hogy érdemes-e egyáltalán tökölni vele. Nekem annyira gyanús, hogy nincs, hogy nagyon és bízom benne, hogy pusztán az inter-CCX kommunikáció létrejöttével megoldódnak a core-hop miatt tapasztalt lassulási jelenségek. Ez persze pusztán csak egy elmélet.
Én mindenesetre remélem, hogy a zen2-vel fogunk látni még L4$-t.
A HBM-et úgy értettem, hogy az interposeres kapcsolat a 2.5D, de akkor ezek szerint így van.
Találgatunk, aztán majd úgyis kiderül..
-
Petykemano
veterán
válasz Cathulhu #827 üzenetére
Igen, emlékszem. De a best-case scenariot ne úgy értsd, hogy a maximális teljesítmény, amit ki lehet hozni adott szilíciumból.
Ha megnézed ezeket a képeket:
tökre szépen látszik, hogy 3.3-3.5 Ghz-ig nagyjából lineráris görbe alapján emelkedik a szükséges feszültség, aztán egy meredekebb és emelkedő mértékben egyre meredekebb görbét vesz fel. A best-case scenario, tehát ahol leginkább tündökölhet minden szempontból a zen az pont ez a 3.5Ghz körüli érték. Onnantól kezdve ha emeled a frekvenciát már rohamos mértékben nő a feszültség és romlik az energiahatékonyság.
Az eddigiek alapján jó esély esély van rá, hogy amit eddig láttunk a zen2-ből az is hasonlóan egy frekvenciagörbe még nem meredeken emelkedő felső részében történt, ahol még jók a fogyasztási számok. Ez semmi másra nem utal, mint arra, hogy nem szabad abba a hype-ba esnünk, hogy most ez egy 3.4/3.7Ghz-es ES volt és úgyis biztos meglesz az 5Ghz, mert hát csak feleannyit fogyasztott, mint az intel és az úristen még akár 40% többlet is lehet. Vagy ha esetleg 4.2Ghz-en futott valójában, akkor az még 20% többlet 5Ghz-en. Mert könnyen lehet, hogy az alacsony fogyasztás a demóban csupán a frekvencia-feszültség görbe egy ideális még lineáris görbe legmagasabb pontján van és onnantól minden +100Mhz +0.1V feszültséget igényel.
Találgatunk, aztán majd úgyis kiderül..
-
Petykemano
veterán
válasz Cathulhu #830 üzenetére
AdoredTV azzal zárja ezt a különkiadást, hogy igazából mindegy hogy a 9900k (mesterségesen nem visszafogott gyári) teljesítményét frekvenciával vagy IPC-vel éri el. Egy kb 65W TDP-s verzióval elérték. Akármennyi is volt a frekvencia, a fogyasztás alapján Innen még biztos visz fel az út párszáz MHZ-t.
Találgatunk, aztán majd úgyis kiderül..
Új hozzászólás Aktív témák
- Xbox Series X|S
- Nyomtató topik
- Elemlámpa, zseblámpa
- BestBuy ruhás topik
- Féltucat régi Samsung kapott új One UI-t, köztük az A52s
- Apple iPhone X - vissza a jövőbe
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Fejhallgató erősítő és DAC topik
- Viccrovat
- Tudományos Pandémia Klub
- További aktív témák...
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen