-
Fototrend
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
#18151
dezz
nagyúr
Petykemano
#18150
dezz
nagyúr
válasz
Petykemano
#18150
üzenetére
Gondolom, igen. Bár a cégek eleve igyekeznek bebiztosítani magukat. És az Intelnek ehhez jelenleg több a hitelessége, azaz simán megtehette. És akkor ugye miért ne tegye meg - akár az AMD-től teljesen függetlenül. Korábban az AMD is tudott ilyen korai megállapodásokat kötni.
-
dezz
nagyúr
Lehet, hogy addig altatják az Intelt, amíg lehet. Persze csodálkoznék, ha a kémeik nem jelentettek volna már régen.
Összeesküvéselmélet 2. szint: némileg kedveznek az Intelnek azzal, hogy nem verik túl nagy dobra idejekorán a teljesítményt, így nem befolyásolják az Intel eladásait a Zen piacra kerüléséig, cserébe a válaszcsapás sem lesz annyira agresszív. És/vagy: így nem kell az Intelnek előre árat csökkentenie, ezért nem eleve a csökkentett árakhoz kell belőni az AMD árait sem.
-
dezz
nagyúr
válasz
leviske
#17911
üzenetére
Akkor már ezt is:
This is the current state of the retail CPUs, which have been improving by the month.
- There are some errata issues present in the current testing samples, similar in a way to the TLB bug of the Phenom. The workaround right now is done via the BIOS. The workaround however, strips around 30 ~ 40% of the CPU performance.
- The CPUs are well behind schedule and every day there's real progress and bug fixing being done. Unlike with INTEL's E0 CPUs which make it to the wild that are almost completely final silicon. AMD's samples will continue to get bug fixes right up until retail spec sampling to partners.
- In August Clock speeds were 3.8GHz, right now 4.2GHz overclocking is possible, with LN2 5GHz is doable. Again this will change of course, but it is just the current silicon that is behaving like this.
- AM4/ZEN uses an SOC design, that means even CMOS/BIOS configuration is on package (not necessarily on silicon, I can't confirm this) so it is possible to clear the "BIOS" and still have old value applied 30 minutes later. How this will be addressed remains to be seen. Perhaps it won't be the same scenario for final silicon
- Operating voltages (nominal) are 1.3v and all the way up to 1.5v should be fine it seems for AIO cooling. Frequency scaling isn't a strong point but again that may have everything to do with the process at this point rather than an inherent design limitation.
- Performance is particularly strong at this point vs. INTEL's latest offerings. Single thread performance is matching Haswell-E and of course multi-threading performance as well. Tests that are memory bandwidth dependent may go to the INTEL platform simply as a result of having more memory channels, but I can't confirm that right now and have no info on that. The important thing here is that the 16Thread/8-Core CPU is minimum 5960X performance if not better actually. (Based on Cinebench R15) with the error fix disabled.
- Can't speak to how well the IMC is working as current samples are locked to low DRAM frequencies (2133MHz and lower) and of course this has an impact on performance.
- As stated in the beginning, every week is progress and AMD is working at an unprecedented rate to get these ready by March.
- You're unlikely to see any high end boards for the CPUs prior to launch or at launch, simply because no vendors can commit to too much right now as plenty is changing at a rapid rate.
Úgy tűnik, nem szándékos butítás volt a (korai?) ES-eknél...
-
#17875
dezz
nagyúr
Petykemano
#17871
dezz
nagyúr
válasz
Petykemano
#17871
üzenetére
Az 1.3 a legjobb eset, amihez a kód optimalizálatlansága (angolosabban optimizálatlansága) is előfeltétel, amikor is túl sok a függőség, ami rontja a superscalar végrehajtást, kevés végrehajtóegységet (ALU-k, stb.) foglalkoztat egyszerre. Így az összteljesítmény nem lesz ennyivel jobb egy jól optimalizált kódhoz képest.
(#17873): Ha a buborékot nem egész mag szinten érted, hanem a végrehajtóegységek szintjén. Ami a modern implementációkat illeti.
ui. az SMT téma önmagában nem offtopic.
[ Módosította: Karma ]
-
dezz
nagyúr
A szálak nem néhány utasításonként kommunikálnak, mert az nagyon nem lenne hatékony - és az is "rég rossz", ha egy szálnak sok-sok cikluson át kell várakoznia egy másikra. Az a kód skálázódik jól többszálúsítás terén, ahol egymástól viszonylag független szálak futnak.
Az erőforrások (végrehajtó egységek) szálak közötti átadása is időbe kerülhet. Így ha pl. egyszerre akarnak használni valamit, ide-oda kell adogatniuk, ami kimaxolja a többletidő ráfordítást.
Egy ideje a magonkénti 1. szál nagyobb prioritást kap az OS-től, mint a 2. Azt hiszem, kód szinten is meg lehet különböztetni elsődleges és másodlagos szálakat.
(#17867) Simid: Igaz. Én az időből vontam le 30%-ot, de az már közel 50%-os gyorsulás.
-
dezz
nagyúr
42
(Mint a Válasz. 
) Egyébként nem csak v. elsősorban nem a függőségektől függ (az inkább szálon belül befolyásolja a superscalar végrehajtást, szálak között nem ilyen sűrű a kommunikáció), hanem a felhasznált utasításoktól. Azt hiszem, pl. a vektoros kód inkább lassul, mert 1-1 szál is nagyon leterheli az erőforrásokat. -
dezz
nagyúr
Létezik 1-2 player kimondottan HEVC/VP9 stream lejátszására, bár nem próbáltam. Az MPC-HC is tudhatná már. (Akkor csak a linket kellene megadni.)
"Elmúlt az az időszak, hogy a procira lehet hagyni a videó dekódolást FullHD felbontás felett, muszáj a hardveres gyorsítás."
Inkább úgy mondanám, hogy visszajött az az időszak, hogy a nagy felbontás csak HW-esen megy rendesen. (Korábban az FHD-t sem tudták a kisebb procik.) És valószínűleg ez jó darabig így is marad, kivéve persze a 6-8 magosokat.
-
#17544
dezz
nagyúr
Petykemano
#17543
dezz
nagyúr
válasz
Petykemano
#17543
üzenetére
Egy Raven Ridge vagy hasonló chip simán érdekelheti az Apple-t. Azt nem tudom, miért kell custom design. ?Mindenesetre elvileg már dolgoznak rajtuk.
Adhatna, az Apple eléggé nyomja a GPU alapú számítást. Mindig is a HW rendes kihasználása mellett voltak. Sőt, az Apple az OpenCL atyja.
-
#17542
dezz
nagyúr
Petykemano
#17533
dezz
nagyúr
válasz
Petykemano
#17533
üzenetére
Meséljen neked a World Wide Web!
[link](#17531) PuMbA: Valóban rendesen viszi, vagy csak a feature listben szerepel a támogatás? Szoftveres támogatás is kell hozzá, ami meghajtja a HW-es dekódert. Pl. a Stoney Ridge-nél furcsa, hogy ott van a támogatás, de csak HD-t írnak rá, valószínűleg egyelőre nincs kihasználva.
(#17538) solfilo: Egy év múlva nem váltasz a Ravenre? Most őszintén...
(#17541) Oliverda: Néhány videó a YT-n, ami 60fps-esnek hírdeti magát, valójában csak 30-as! Főleg a nagyobb felbontásúak között. Lehet, hogy 60-asnak töltötték fel, de a YT lekonvertálta 30-ra?
Érdemes megnézni a lejátszási statisztikát. Meg hát látható is. -
dezz
nagyúr
Igen, AM4 alapon inkább embedded és más efféle alkalmazásokban képzelhető el esetleg ilyesmi. Eredetileg ezt is meg akartam említeni. Mobil vonalon persze az FP4 játszik szerepet, ami maga is egy fajta BGA tokozás. Kicsit sikerült összemosni a kettőt. Mindenesetre, kíváncsi leszek, kedvet kap-e a MS vagy mások újabb próbálkozásokhoz az x86 alapú tabletek területén. Hiperszupervékony, memóriaslotot sem tartalmazó laptopok megjelenésére is lehet számítani.
Megjegyzem, a HBM-es megoldások későbbi megjelenésével nem kizárt, hogy akár a desktopon is megjelennek memóriaslot nélküli lapok, és ott már a dGPU helyzete is bizonytalanná válik. Az alaplap lényegében csak az áramelletásért és a perifériák csatlakoztatásáért felelne. Új standard születik cigarettásdoboz mérettel és átkeresztelik pécécskére.
-
-
-
dezz
nagyúr
válasz
Oliverda
#17518
üzenetére
Igazán szép dia, csak nem sok konkrétumot tartalmaz.
"összesen maximum 24 PCI Express sávot"
Ez ellentmondásban van az itteni cikkben közöltekkel: "a Bristol Ridge APU-ban a PCI Express 3.0-s vezérlő 8 csatornát kínál, addig a Summit Ridge processzor minimum 32-vel fog rendelkezni."
-
dezz
nagyúr
Valószínűleg nem. De ez nem ezen múlik, hanem a mellé tett UVD-n. A StoneyR-be már 6.3-as került, ami már tudja a VP9-et.
Vajon nem lehet shader/DirectCompute/OpenCL alapon gyorsítani a korábbi (i/d)GPU-kon? (Az is magasabb fogyasztást eredményez, mint egy UVD, de legalább nem akadna a 4K.) Ez az AMD feladata lenne és jóval kevesebbe kerülne, mint egy "Bristol Ridge 2.0" lapka, de nyilván nem veszik rá a fáradtságot. Már ha megoldható lenne persze.
-
#17054
dezz
nagyúr
Petykemano
#17052
dezz
nagyúr
válasz
Petykemano
#17052
üzenetére
Azért már csak ne a nagymama legyen a mérce.
A kisebb gépekben és főleg mobil vonalon egyre ritkább a külön videokártya, ilyenkor egy adott AMD APU és0 annak inteles megfelelője állnak szemben egymással. A peak FLOPS és a fejlettebb architektúra alapján az AMD-nek áll a zászló. De én is hiányolom az olyan teszteket, amik a felsorolt programokat ilyen környezetben vizsgálnák. Még olyanból is nagyon kevés van, amik úgy egyátalán CPU vs. GPU vs. APU összehasonlítást tennének. Nem tudom, miért.
Amire gondolsz, az nem egy APU, hanem egy CPU és egy 4+ TFLOPS-os GPU lapka egy MCM tokban. Ugye nem várod, hogy egy ilyen GPU megelégedjen 4 DDR4 csatornával? A HBM viszont jelenleg csak 32-64 GB-os lehet, ami kevés main ramnak. (A DDR4 bank 1TB-os lehet.)
Nem csak a sávszél számít a PCI-E esetén, hanem a latency is. Az AMD szóban forgó megoldása ezt küszöböli ki, mellesleg cache-coherent módon: a HBM L3-ként funkcionál, koherenciában a CPU lapkán lévő L3-mal.
Ez nyilván egy kompromisszum, de a jelenleg nem nagyon van jobb megoldás.
-
dezz
nagyúr
Még néhány:
- SVP (SmoothVideo Project), OpenCL alapú real-time frame-rate conversion DirectShow-t támogató videoplayerekhez.
- Motion-adaptive HQ deinterlacing (shader alapú)
- WinZIP (mondjuk nem a legjobb implementáció, remélhetőleg előbb-utóbb bekerül a WinRAR-ba, 7-Zipbe is)
- Egyes antivírusok (Kaspersky, GrAVity/ClamAV).Így hirtelen nem is jut eszembe sokkal több olyan hétköznapi(bb) alkalmazás, amit teljesítményigényessége miatt érdemes lenne GPGPU-sítani...
-
#17047
dezz
nagyúr
Petykemano
#17044
dezz
nagyúr
válasz
Petykemano
#17044
üzenetére
Define "hétköznapi"! Van, akinek ezek:
- PhysX motoros játékok
- Havok motoros (több platformon GPGPU supporttal, talán PC is) játékok
- Az itteni többszáz CUDA/OpenCL alkalmazás közül is megtalálható lehet egy pár játékokban (és egyéb programokban).
- Photoshop, Premiere Pro, stb.
- GIMP (2)
- Blender és más rendererek, beépített vagy plug-in alapú GPGPU supporttal (rendering és fizika)
- Folding@home, SETI@home és egy sor más BOINC alapú vagy egyéb módon GPGPU támogatású distributed computing kliens
- cRARk / Parallel Recovery
- Fragmentarium
- ...Valamiért nem sok teszt áll rendelkezésre arra vonatkozólag, hogy AMD-n (APU/GPU), Nvidián vagy Intelen (IGP) gyorsabbak ezek. Iránymutatóak lehetnek azonban pl. az AIDA64 GPGPU-s teszteredményei. [link] [link]
Az Intel IGP-ket nem kell "aktiválni", hiszen már most is OpenCL támogatásúak.
A MuseMage Mobile Videography szoftver full GPGPU támogatású. Szinte mindegyik újabb mobil IGP OpenCL támogatású. Az első HSA alapú mobil IGP IP core az ARM Mali-G71.
Tudományos, HPC és szuperszámítógép területen főleg elterjedt a GPGPU. Az lenne a furcsa, ha nem épülnének kisebb-nagyobb HPC szerverek és szuperszámítógépek Raven Ridge alapon.
-
dezz
nagyúr
Itt. (->Applications)
És itt.
Meg itt.(#17040) apatyas: Dehogy nem terjed. Csak az ilyen trendek nem 2 nap hoznak nagy változást, hanem fokozatosan, de feltartóztathatatlanul, ami a GPGPU-t illeti. (Lásd linkek!) Hogy aztán a HSA lesz-e a befutó vagy valamely más szabvány, az más kérdés. Nagy fába vágta az AMD a fejszéjét (mint már nem először, bár talán mind közül ez a legnagyobb) a HSA-val, de neves partnerei vannak.
-
dezz
nagyúr
"Óké, megértem kemény év ez nekik. Polaris, Zen, AM4, HBM2, új konzolok és ehhez még új gyártástechnológia is. De basszus, az elmúlt jó pár évben mit csináltak? Kis túlzással néhány stepping váltáson kívül semmi dolguk nem volt."
Ez az év? Szerinted 5 hónap alatt hozták létre a felsoroltakat? Szorozd meg úgy 10-zel!
-
#16930
dezz
nagyúr
Petykemano
#16929
dezz
nagyúr
válasz
Petykemano
#16929
üzenetére
Tényleg, azt is mondja, hogy "and played back on". Ez sokak figyelmét elkerülte. Nem csoda, még össze voltak zavarodva, hogy ez a pár másodperces videó meg mi volt? Mennyivel hatásosabb lett volna, ha látható a gép is...
-
dezz
nagyúr
Naná, nekem is tökmindegy lenne, miben fut, de a Computex közönségének a túlnyomó többsége nem enthusiast. Azonban, az általad említett, hétköznapi ATX board kinézetű Myrtle lappal valóban bemutathatták volna. Így, hogy tudom, hogy az nem az a tipikus tesztkörnyezet, engem is foglalkoztat, hogy mi lehet a valódi ok. Talán az, hogy még fagyogat? Az azért elég ciki lenne ilyen széles nyilvánosság előtt.
Már úgy érted, a mikroarchitektura (mások kedvéért: CPU mag belső felépítése) szempontjábol irrelevans, nem? Az alaplapi tápáramkört is érintő tápszabályzás, ezzel összefüggő energiatakarékossági/turbó funkciók és más effélék azért mégiscsak az architektúra része.
Elképzelhető, hogy a SummitR pl. energiatakarékossági/turbó funkciókban is továbbfejlődött, a Carrizo/BristolR-hez képest is, pl. még gyorsabban kell feszültségszintek között váltogatni. Vagy pl. tovább bontották a power-plane-eket. Vagy más területen is eszközölhettek változásokat, amiket esetleg nem sikerült még véglegesíteni.
-
dezz
nagyúr
Elég furcsa, hogy pont a Zenhez, illetve két különböző generációhoz készülő platformhoz nincs "rendes" tesztplatform.
Elérhető online az a fénykép?Igen, jól néz ki a Gardenia, de a hozzánemértő nagyközönséget nem célszerű ilyen bonyolult lappal "sokkolni". Az ISSCC azért egy kicsit más, mint egy Computex, Cebit, stb.
"A BR es Summit Ridge (es nem mellesleg Raven Ridge) eseteben mar a kezdetektol fogva pontosan tudta mindenki, hogy milyen platformot fognak kapni. Hogy egyetlen foglalat lesz, egyetlen chipset, egyetlen platform. Ez eleve cel es kovetelmeny is volt a tervezeskor."
Eredetileg a Visheránál és a Keverinél is ezt volt a terv. A Vishera AM3-ba, a Kaveri pedig FM2-be érkezett volna.
"A foglalat szempontjabol irrelevans az architektura."
Nem mondanám, hiszen a Vishera a módosított energiatakarékosság és tápszabályzás miatt igényelt módosított platformot (miközben néhány letiltott funkcióval egyes AM3 lapokban is elment). A Kaverinél már nem emlékszem, mi volt a "bibi".
-
dezz
nagyúr
Nehezen tudnám elképzelni, hogy ne lenne már egy tesztplatform, azaz egy beható tesztelésre készült spéci alaplap. Az ilyenek általában jóval nagyobbak a szokásosnál és tele vannak tesztcsatlakozókkal (wifi csatira emlékeztető oszcilloszkóp mérőpontok), stb. Az ilyeneket nem szokás nemzetközi rendezvényeken mutogatni.
Az esetleg lehet, hogy retail alaplapok még nincsenek, csak 99 vagy 100%-os PCB tervek, és a gyártással megvárják a platform validálását.
"Az AM4 verziorol?"
Oké, lehet, hogy az csak a mobil vonalra vonatkozott.
Hülyeség? Gondoljunk csak az AM3 - AM3+-ra és az FM2 - FM2+-ra. Eredetileg ezeknél sem volt szó a +-os változatról, aztán mégis. Ezt itt most mindenképp szeretnék elkerülni, főleg ilyen rövid időkülönbséggel.
Az Ivy Bridge esete más, az nem vadi új (mikro)architektúra, csak egy shrink. Eleve az Intel esete más, ők megengedhetik maguknak, hogy szinte évente vezessenek be új platformot és meg is teszik, azaz nem is ígérik, hogy az újabb generációk mennek a korábbi lapokban. Másrészt náluk hosszabb a validálási-finomhangolási időszak, jóval a megjelenés előtt már rendelkeznek működő chipekkel.
-
dezz
nagyúr
Gondolod, hogy nincs mibe beledugniuk, csak úgy fogdossák, nézegetik a procit?
Nyilván van egy tesztplatform, Lisa Su bemutatott egy videót, ami állítása szerint a SummitR-en "számolódott". A BristolR-ről is elég konkrét telj./fogy. javulási viszonyszámot közöltek.Szerintem ők is és az alaplapgyártók is egy készközeli lapkát várnak a SummitR-ről, hogy lezárulhasson az AM4 tesztidőszaka és validálhassák végre. Mert szép lenne, ha kiadnák a BristolR-rel és utána kiderülne, hogy nem megy rendesen, illetve csak módosításokkal a SummitR. Nem lenne szerencsés egy AM4+ pár hónappal az AM4 piacra kerülése után.
-
dezz
nagyúr
Amúgy eléggé csodálkozom, hogy ilyen nagy hőtermelési különbségek a lapka különböző területein nem okoznak gondot az eltérő hőtágulás miatt. Illetve, gondolom, azért nem véletlen, hogy alapesetben az OS "vetésforgóban" dolgoztatja a procit 1-szálas terhelés esetén is. De mi van, ha a user fogja és egy adott maghoz rendeli a feladatot (affinity)?
-
dezz
nagyúr
válasz
Yutani
#16667
üzenetére
"2.) Egy Excavator modul (CU, compute unit) sebességének hozza 140%-át két Zen mag (The Stilt teóriája az Anandtech fórumáról)"
The Stilt azt írta, 1 Zen mag a 73%-át hozza egy XV modulénak. 2 Zen mag 100%-os multicore skálázódásnál 146%-ot hoz, 97%-nál 141,62-t, 95%-nál pedig 138,7-et (SMT nélkül). Megjegyzem, általános "Magic Number" nem létezik, legfeljebb adott alkalmazásra vonatkozó. (Lehet átlagolni, de az inkább az általános ár/telj. arányt határozza meg.)
De ez a 40-46% amúgy sem lehet valós, mert akkor az alkalmazások nagy részében lassabb lenne a Zen, mint akár az XV, legalábbis SMT nélkül, de akár azzal is, akkor pedig mi értelme lenne? [link]
ps. tényleg lehetne egy találgatós topic, mivel ez per def. mikroarchitektúrális részletezésre és a legfontosabb egyéb infók közlésére szolgál.
-
dezz
nagyúr
Még egy infó, ami segítheti a megértést: az utasításkészlet tagjainak (és azok különféle címzésmódjainak) végrehajtásához eltérő számú órajelciklusra van szükség és ezekhez más-más IPC rendelhető (ez attól is függ, hogy egyet vagy többet tud párhuzamosan végrehajtani egy mag). A tipikus IPC meghatározására különféle módszereket lehet igénybe venni, pl. az említett IPC-k egyszerű vagy előfordulási aránnyal súlyozott átlagát lehet venni, vagy egy a különféle utasításokat átlagos előfordulási arányban, átlagos függőségi helyzetben tartalmazó szintetikus mintakód végrehajtásából lehet számolni. Nem tudom, az AMD melyik módszer híve.
(#16653) Petykemano: Jó kérdések. (A Zenre vonatkozóakat valószínűleg majd élőben való tesztelgetés során lehet megválaszolni.)
-
dezz
nagyúr
válasz
Yutani
#16645
üzenetére
Nos, ha folytatni akarod az "ugatást"
, meg kell értened, hogy a tipikus IPC az összes utasítás throughputjának átlaga, miközben egy adott alkalmazásban mutatott teljesítmény eltérhet ettől, akár pozitív, akár negatív irányba, attól függően, hogy többségében nagyobb vagy kisebb throughputú utasításokat használ.Ha pl. CB-s (FP-intenzív) teljesítménytöbbletről beszélünk, az nem "IPC javulás", hanem CB/FP-teljesítmény javulás.
Mivel továbbra is +40%-kal számolod a CB-s teljesítményt is, a #16630-as vonatkozó szorzója és a többi eredmény is hibás, újra kell számolnod.
The Stilt FP-intenzív esetre írt arányszámokat, 2 Zen mag vs. 1 XV modul -> 0,73 x 2 = 1,46 -> +46%. (Ehhez jön majd az SMT által hozott többlet, amit persze még nem tudunk.) Most hogy csak a hasára ütött vagy valós alapja van, nem tudhatjuk, de el lehet számolgatni vele.
Mondhatod, hogy szerinted hasraütés, de nem/te sem tudhatod, hogy FP-intenzív esetben hogy alakul a teljesítménytöbblet.
A scenariókban miért 100 pont az alap? És miért a rosszabbik, 95%-os többmagos skálázódással számolsz AMD esetén?
"Egyébként fogalmam sincs, Stiltnek honnan jött az a 46%, amikor az AMD mindig is 40%-ot említett."
Nem tudom, de nem először írom le, hogyan lehet más az FP-intenzív kóddal jelentkező teljesítménytöbblet, mint a tipikus IPC növekedés.
(#16640) Simid: #16605
-
dezz
nagyúr
Yutani: Az AT-s topicban is a már korábbról ismert +40%-os átlag IPC növekményből indulsz ki, miközben azt írod, The Stilt CB.R15-ös számaiból indultál ki. Miért? (És miért most csodálkozol rá erre a +40%-ra?) Eleve a +46%-ból kellene kiindulnod, ha már ragaszkodsz az SMT nélküli összehasonlításhoz. Többszálas CB eredmények hasonlítgatásakor több értelme lenne az SMT-s számokkal hasonlítgatni.
105,24 * 4 * 1,1 = 463,056 (4c 8t @ 3,4 GHz, +10%-os SMT hat.)
105,24 * 4 * 1,25 = 526,2 (4c 8t @ 3,4 GHz, +25%-os SMT hat.)Az sem kizárt, hogy a Zen jobban skálázódik több magra, mint az XV, vélhetően jobb a L2/L3 kezelése és még egy pár dolog.
(#16639): Most akkor IPC-ről beszélünk (ami általában az összes utasítást alapul vevő átlagszám, kivéve persze az "up to" esetét) vagy egy adott alkalmazásbeli, esetünkben CB-s teszteredményekről? Nem ugyanaz.
-
dezz
nagyúr
válasz
Yutani
#16607
üzenetére
Kihagytad az SMT-t! Többszálas FP-intenzív alkalmazásról beszélünk...
105,12 * 2 = 210,24 (2 Zen mag SMT nélkül)
210,24 * 1,1 = 231,264 (ha az SMT +10%-ot hoz)
210,24 * 1,25 = 262,8 (ha az SMT + 25%-ot hoz)(#16619): Éppen, hogy nem az a lényegük. A +40% az az 1 mag vs. 1 mag, valamiféle átlagolt (INT+FP) IPC-ben.
Idézem magam: "Két Zen mag 0,73 * 2 = 1,46x lesz jobb, mint két XV mag [egy modulon belül], SMT nélkül és kb. 1,46 * (1,1..1,25) = ~1,6..1,8x, SMT-vel (az SMT hatékonyságától függően). Az arányszámok nagyjából stimmelhetnek egész chipre is (8 mag vs. 8 mag). Más szóval ez 46% (no SMT) - 60/80%-os (w/ SMT) teljesítménytöbblet!"
Mindez FP-intenzív kódra értendő. (És persze ha ezek a CB teszteredmények valósak, helyesek és véglegesek.) INT-intenzív kódos (pl. játékok) tesztet még nem láttunk, ott eleve mások lehetnek az arányok.
-
#16605
dezz
nagyúr
Petykemano
#16598
dezz
nagyúr
válasz
Petykemano
#16598
üzenetére
Inkább így:
"A single Excavator CU running at 3.4GHz will score 144 in Cinebench R15.
144 * 0.73 = 105.12
105.12 * 8 = 840.96The multiply the score produced by native cores by 1.10 - 1.25 to get the performance estimate for 8C/16T Zen (925 - 1051 points @ 3.4GHz)."
CU = modul (2 mag). Két Zen mag 0,73 * 2 = 1,46x lesz jobb, mint két XV mag [egy modulon belül], SMT nélkül és kb. 1,46 * (1,1..1,25) = ~1,6..1,8x, SMT-vel (az SMT hatékonyságától függően). Az arányszámok nagyjából stimmelhetnek egész chipre is (8 mag vs. 8 mag). Más szóval ez 46% (no SMT) - 60/80%-os (w/ SMT) teljesítménytöbblet! Már CB.R15-ben. Jól hangzik...
-
#16462
dezz
nagyúr
headhunter
#16460
dezz
nagyúr
válasz
headhunter
#16460
üzenetére
Pont az a kérdés merült fel bennem az elhangzottakkal kapcsolatban, hogy mióta lehet a partnereknél az A0 ES, illetve, a lapok megtervezésének melyik fázisában lehetett szükség az ZEN ES-re? (Csak utólagos tesztelés?) Vagy pedig elég volt-e a BR? És az utóbbi AM4-es változata mikor kerülhetett a partnerekhez és milyen fázisban lehetett rá szükség? (Szintén, csak utólagos tesztelés?) És mindebből mire lehet következtetni, mikor jöhetnek az AM4-es lapok?
-
dezz
nagyúr
Ebben is javulhattak az újabbak (dedikált encoder a shader alapú helyett, stb.), bár nem próbáltam.
(#16393) t72killer: Látom, GTX 970-esed van, azt nem feltétlen szükséges cserélni.
Bár ebben még VP6-os van, néhány másik 900-asban már VP7-es, dedikált HEVC és VP9 dekóderrel. Encode-ban nem tudom, változott-e valami. [link] -
dezz
nagyúr
"Azzal is lehet javítani a sebességen, hogy a forrás dekódolásnál GPU dekódolát választasz, bár ez alapból be van kapcsolva szerintem."
És valószínű attól van a drasztikus sebességkülönbség 4K vs. FHD, hogy a videokártyája még nem támogatja a 4K-s dekódolást és enkódolást. Lehet, hogy nem procit kellene cserélni, hanem videokártyát, legalább 700-as sorozatra.
-
dezz
nagyúr
Némileg meglepő a számomra, milyen nagy szórás van az azonos órajeleken végzett különféle mérések között. Tényleg eléggé felhasználási terület függő lehet, érdemes-e váltani Kaveriről/Godavariról a Carrizo+1 stepping Bristol Ridge-re. (Kár, hogy fogyasztást nem néztek azonos órajeleken.) Persze az IGP is beleszólhat APU esetén.
(#16323): Most jövök rá, hogy itt alul Steamrollert akartam írni (Kaveri, Godavari) a Piledriver helyett. (Utóbbi esetleg úgy jöhet szóba, ha valakinek 4-magos van vagy nem használ 4 magnál többet igénybe vevő alkalmazást és mostanában akar váltani: motiválóbb lehet Bristol Ridge-re váltani, mint Kaveri/Godavarira.)
-
dezz
nagyúr
Sokan vannak, akik "képesek" 10-15%-ért procit váltani, plusz az aktuális legújabb generációért. Főleg, ha kedvük támad új alaplapot venni, a régit el lehet adni a meglévő procival. De ott vannak azok is, akik Phenomról váltanának és nem nagyon tudnak tovább várni, nekik is jobban meghozza a kedvüket egy Bristol Ridge, mint egy Godavari. No de mindegy, ez innen már "majd meglátjuk"...
(#16325) stratova: Ha valaki x265 enkódolásra használja a gépét (most még kevesen lehetnek, de jön befelé az x265/H.265), megérheti az a több- v. épp sokszoros gyorsulás, amit itt hoz egy X6->szinte bármilyen újabb AMD CPU/APU váltás.
-
dezz
nagyúr
Logikus lenne. Azonban nemrég olyat olvastam valahol - alább/följebb már utaltam rá - (nem tudom, hivatalos nyilatkozat volt vagy állítólagos kiszivárgás), hogy arra jutottak az AMD-nél, hogy egy új platformot jobb csúcsprocival bevezetni, "nagyobbat szól" (presztizs és kereskedelmi szempontból is), semmint egy "érdektelen" középkategóriás procival, a csúcsproci későbbi bevezetésével. (Két ágyú egyszerre nagyobbat szól, mint külön-külön.) Felmerülhettek persze egyéb okok is, vagy ezek összessége vezethetett ilyesféle döntéshez. (Ha már úgyis csúszik, akkor bevárják vele a Zent.)
Ha valóban min. októberig kell várni az AM4-re, az megmagyarázza, miért lett olyan fontos most frissíteni az AM3+ és FM2+ lapokat. (Egyidőben a másikkal vagy kicsivel előtte nem lenne sok értelme. Azaz legalábbis a márciusi AM4 start szinte biztos kizárt.) Ebben az esetben viszont célszerűvé válik a BR kiadása FM2+-ra is a közbenső időben.
(#16310): "Arrol egy BR eleve nem igazan lesz ertelmes upgrade utvonal."
Azért egy Piledriver->Excavator váltás azonos órajelen nem elhanyagolható tényező. Az IGP és talán az IMC terén is történtek kisebb változások. (Godavari->Carrizo váltás és erre jön még egy jelentős steppingváltás.)
-
dezz
nagyúr
Nos, több pinből még mindig könnyebb kevesebbet csinálni, mint fordítva.
De viccet félretéve, tekintve, hogy a mobil Carrizo is FP4-es és ugyanaz a lapka működik FM2+-ban is (bár jelenleg csak letiltott IGP-vel, de ez valószínűleg csak a magasabb órajelhez és feszhez járuló fogyasztás miatt van), továbbá hogy a Bristol Ridge lényegében egy újabb Carrizo stepping, technikailag megvalósítható lehet és talán nem is olyan nagyon költséges művelet. (Esetleg a Carrizohoz készült substrate is felhasználható lehet, vagy kisebb módosítással.) -
dezz
nagyúr
válasz
Thrawn
#16297
üzenetére
Az FP4-es és AM4-es Bristol Ridge (új steppinges, magasabb órejelű Carrizo) ugyanaz, valószínűleg.
(#16295) leviske: Kétféle variációt lehet hallani: a. még tavasszal jön az AM4 a Bristol Ridge-dzsel; b. Q4-ben jön a Summit Ridge-dzsel (mert nem akarnak középkat. procival indítani egy új platformot). Az elsőnél azért lenne ésszerű kihozni a BR-t FM2+-ra is, mert kevesen vennék az új FM2+ lapokat az AM4+BR páros mellett, úgy viszont megveheti, aki nem akarja leváltani a DDR3-as ramjait. A második esetben pedig azért, hogy addig is legyen a Godavarinál jobb ajánlat APU vonalon.
-
#16293
dezz
nagyúr
FireKeeper
#16289
dezz
nagyúr
válasz
FireKeeper
#16289
üzenetére
Ez igaz, de aki a következő hónapokban vesz újonnan kijött alaplapokat, nyilván szeretne majd prociból is újabbat. Ha már Zen alapú nem megy, legalább a Bristol Ridge-ből. Ami azt illeti, kicsit furcsa is (lenne), hogy néhány kicsivel feljebb tornázott órajelű korábbi típus miatt hoznak ki vadi új lapokat, alig valamivel az új platform megjelenése előtt. Az AMD-nek amúgy is szokása "megtenni, amit lehet", lásd AM2+/AM3. Persze nem akarok hiú reményeket ébreszteni, de azért csodálkoznék.
(#16279) Oliverda: Akkor nyilván egy (17-)32-magos van nála, ha MCM és valószínűsíthetően nem a max. 8-magos PC-s vonalon alkalmazott chipen (die-on) alapul. De akkor miért csodálkozik az alacsony órajelen? És ha nem érdemes rajta benchmarkokat vagy más effélét futtatni, mi alapján mondja, hogy tetszik neki?
-
dezz
nagyúr
válasz
Oliverda
#16276
üzenetére
A chip ugyanaz, innentől csak döntés kérdése. Lesz is rá igény, öklüket rázó AMD tulajok képében
, akik most vettek új FM2+ lapot... (Főleg, hogy a Carrizo is megérkezett, bár letiltott IGP-vel.) Valószínűleg a vadi új AM3+ laposok is követelik majd, bár nekik kisebb az esélyük erre. -
dezz
nagyúr
válasz
Oliverda
#15071
üzenetére
Ez ugye nem insider2015-től származik?
Milyen formában várható a már korábban demózott HBM megjelenése az AMD-nél?
(#15099) Fiery: Én egy spanyol nyelvű amcsi lapon olvastam erről, ahol a megadott forrásoldalon nem volt erről szó. Neked ugye hitelesebb forrásaid vannak?
"Bristol Ridge (= Carrizo)" - Itt talán korrektebb lenne a ~ jel, hiszem új memóriavezérlőt kap (hacsak nem DDR4 kompatibilis titokban már a Carrizoé is) és valószínűleg a lapka többi része sem teljesen ugyanaz, szóval többről lehet szó, mint hogy egy kvázi Carrizot jól megküldenek fesszel néhányszáz MHz-cel többért. Minimum egy új revízió (nagyobb steppingváltás).
(#15108) Valdez: "HBM buffered alaplapot kihoznia 14nm-en"
(#15110) VirsLee: #14962
-
dezz
nagyúr
válasz
stratova
#14931
üzenetére
2008-ban készített egy képet egy 2015-ös hírhez?
Mindenesetre kapóra jött a régi kép. (A második linkre hibát dob mélylinkelés miatt, de itt van szép nagyban.)
Apropó:
(#14808) Balala2007: Blokkvázlat szinten közel állhatnak, mélyen szinteken már valószínűleg más a helyzet. -
dezz
nagyúr
válasz
Oliverda
#14929
üzenetére
A linkelt oldal szerint (szerintem is), ez a bizonyos 7th Gen A-Series Desktop APU (Bristol Ridge?) legnagyobb valószínűséggel egy órajelben feljebb skálázott és DDR4-et is támogató Karrizo-féleség lesz, továbbra is 28nm-en. (Az AMD csak a Zennel kapcsolatban emlegette a FinFET-et és amúgy sem valószínű, hogy átviszik az Excavatort FinFET-re, csak hogy a következő körben úgyis leváltsa a Zen az alacsonyabb szegmensekben is.)
Ha így van: az vajon teljesen kizárt, hogy - tekintve a DDR3 támogatását -, kihozzák FM2+-ra is?
-
#14342
dezz
nagyúr
marcell991
#14341
dezz
nagyúr
válasz
marcell991
#14341
üzenetére
Én is azt hittem, hogy már rég kifizették. Szerintem növelni kellett volna a büntetési tételt, hogy legközelebb jobban meggondolják, hogy 5 évig húzzák a pereskedést. Bár a perköltséget is nyilván nekik kell állni. (Nem mintha ez igazán számítana nekik.)
-
dezz
nagyúr
Mint tudjuk, az Intel többször túl messzire ment. Meg mintha lenne valami olyasféle szabály is, hogy önköltségi ár alatt nem lehet árulni dolgokat. (A kozoloknál sem ismerték be a cégek sosem, hogy drágább a gyártás.) Akárhogyan is, az ilyesmi eléggé aggályos:
"A vállalat már így is nagy áldozatot hoz az x86-os lapkák terjedése érdekben, hiszen a közvetlen konkurensekhez képest nagyságrendekkel olcsóbban kínálják az Atomokat, ami negyedévenként majdnem egymilliárd dolláros veszteség elkönyvelésére kényszeríti az Intelt." [link]
Hiába pereskedik a Samsung és az Apple, közben üzleti kapcsolatban állnak, többféle chipet és kijelzőt gyárt nekik a Samsung. A Google és a Samsung között is elég szoros a kötelék, sőt épp most írtak alá egy jelentős együttműködési megállapodást.
Vannak olyan területek, ahol sok éve nagyjából ugyanakkora profitot realizálnak cégek és ezzel elégedettek. Lehet, a számtechben ezt nem lehet megtenni, mert folyamatosan változnak, növekednek az igények.
-
dezz
nagyúr
De ezt a játékot is illik tisztességesen játszani.
A Google, Apple, Samsung nem arra törekszenek, hogy holnaputánra teljesen kiszorítsák vagy felfalják egymást, nem olvasztják be a SoC tervező cégeket sem. Kooperálnak velük és egymással.
Az egészséges versenyt törvények szavatolják.
A kapitalizmusban sem gondolja azt mindenki, hogy mindenáron csak nőni és nőni kell. Fenntartható fejlődés, meg ilyenek.
De kezdünk off lenni.
-
dezz
nagyúr
Szóval tisztességesen. Reméljük, valóban így lesz...
De amúgy nem nézett véletlenül túl sok Highlandert valaki ott az Intelnél, esetleg nem volt más társasjáték, mint a Monopoly? Tudtommal a mai piaci verseny nem arról szól, hogy építsünk monopóliumokat, hanem hogy legalább két versenytárs legyen, így biztosítva az optimális árakat. Egy sor ARM-os cég éldegél vígan ezen a hatalmas piacon, de úgy tűnik, az Intel nem nyugodhat, amíg nem az övé a piaci részesedés 95%-a.
-
dezz
nagyúr
A GCN alapú FirePro-k hozhatnak némi változást.
AMD FirePro S10000 Card Powers World’s No. 2 Greenest Supercomputer
"De robbanas a konzolpiacon nem lesz."
Kína most nyitotta meg a kapuit előttük. És ott a kevés is nagyon sok.
"ARM? Amivel csak most kezdenek molyolni, me'g azt se lehet tudni, hogy milyen termeket keszitenek"
Valamennyit azért lehet tudni:
A SkyBridge projektben fut össze az AMD IP stratégiája
Már 2 éve dolgoznak ezen a projekten, jövőre már termékek is lesznek belőle. Hogy mennyire lesz sikeres, az nyilván majd akkor derül ki. -
dezz
nagyúr
Néhány évig még el lehet adni a dGPU-kat, nem beszélve a nagyobb haszonkulcsú FirePro-król. Mini- vagy szuperszámítógépet is lehet velük építeni.
Ha valaki felvásárolja az AMD részvényeinek nagy részét, attól még nem száll rá át az x86 licence, és az AMD ugyanúgy gyártathatja tovább az x86 alapú procikat. (Másrészt az AMD64 licencnek is van ebbe úgymond beleszólása.)
Lényegében mindegy, hogyan veszi át az Nvidia.
Volt már olyan a világtörténelemben, hogy egy cég részvényindexe alaposan megemelkedett.
-
dezz
nagyúr
Nem a cég és a fejlesztők közötti viszonyról beszéltem, hanem a többi céghez fűződő viszonyukról.
Én sem innovációról beszéltem. A GCN (egyben) egy termékvonal, a Puma magos chipek is termékek (nem igazán az ARM-ok ellen, hanem inkább az ARM és a komolyabb x86 procik között foglal helyet) és a kozolok APU-i is, amik természetesen növelik a cég értékét. (Ha valaki megvenné, ezekből még évekig jelentős bevétele lehetne, minimális ráfordítás mellett, ha nem nem terveznek további fejlesztéseket.)
Szerintem ha valaki megveszi az AMD-t és leányvállalatként üzemelteti, akkor az utóbbi simán gyártathatja tovább az x86 procikat.
Tudtommal már van az Nvidiának APU-ja (ha nem is így hívja), vagy hamarosan lesz. Term. ARM CPU magokkal. Ha ARM vonalon elterjed a HSA (márpedig az ARM és több más ARM procikban érdekelt cég ezen van), akkor előbb-utóbb az Nvidiának is alkalmazkodnia kell ehhez.
Lehet, hogy az Nvidia 3x nagyobb, de ugyebár 3x0=0, márpedig az Nvidia értéke nem 0, tehát az AMD értéke sem 0.
(#14311): Most pont nem.
Automatikusan valóban nem. (Mint ahogy némi elfogultság nem jelent automatikusan "bérencséget".) Csak hát meg lehet nézni, hányszáz kommentben ekézed az AMD-t és élteted az Intelt.
Sokmindenben igazad van természetesen, de összességében úgy érzem, picit azért mégiscsak az Intel felé billen a mérleg. -
dezz
nagyúr
Egy OpenCL képes IGP-t tartalmazó chip az semmiképpen sem sima CPU. Más kérdés, hogy az Intelnek derogál egy AMD által bevezetett kifejezést v. betűszót átvenni. (Mint ahogy minden mást is csakis kényszerből, akármilyen jó is.) Az Intel az egyike a legbarátságtalanabb és legkevésbé kooperatív cégeknek.
"Nincs semmi erteke az AMD-nek, no offense."
No offense, de ez enyhén szólva túlzás. Vegyük pl. a GPU-it, a GCN-t, a HSA mögé is sok nagy (és kis) cég állt be, pedig nem ingyen volt a belépő, a Puma magos termékek sem olyan rosszak. A konzol-biznisszből sem kevés fog befolyni az elkövetkező 7-10 évben.
(#14307): Bizonyára így fest a világ kék szemüvegen át nézve (avatarod).
-
dezz
nagyúr
Bocsánat, 4.5 GHz-en már nagyon is többet fogyaszt. [link] De állítólag a 4 GHz-t viszi alapfeszen is. Viszont elnézve ezeket a A10 PRO-7x50B-s fogysztási értékeket, végülis el tudom képzelni, hogy a 65W fölötti rész már az, amikor már egyre jelentősebb fogyasztásnövekedést okoz az órajel egyre kisebb növelése.
-
dezz
nagyúr
Nagyon jól hangzik ez a HDL-es dolog. Ha jól értem, ez azt csinálja, hogy kevesebb tranyóból hozza össze ugyanazt a funkcionalitást.
Viszont itt a wattos és MHz-es dolognál véletlenül nem egy a Pumára vonatkozó órajel/fogy. grafikonból indulsz ki? Az azért nem feltétlen jó ötlet, mert a Puma eleve jóval alacsonyabb órajelre van tervezve, 2 GHz-en még igen alacsony a fogyasztása, de onnantól csak az utóbbi drasztikus növekedésével gyorsítható akár 100 MHz-cel is.
(A Puma+-nál vélhetően jelentős módosítások történtek a futószalagoknál, hogy alkalmasak legyenek a magasabb órajelekre.)
A Kaveri viszont nem fogyaszt sokkal többet 4-4.5 GHz-cen, mint 3.7-en - csak éppen nem fértek be vele a 95W-ba.
-
dezz
nagyúr
A néhány nappal ezelőtti hírek szerint a Carrizóból lesz FX jelölésű, csodálkoznék, ha az nem 95W-os lenne.
Nem tudom, mi mása van a GloFo-nak vagy a TSMC-nek, illetve mit licencelt nemrég az első, de a 28nm-t sem venném készpénznek, legalábbis sima bulk. Hogy tudnának ennyit javítani a teljesítményen és telj./fogy. arányon ugyanazon a node-on, hogy nem hogy jobb, de legalább azonos szinten legyen a Kaverivel?
-
dezz
nagyúr
válasz
#17954112
#14239
üzenetére
Meg lehetett volna csinálni, csak valószínűleg nem érte volna meg a ráfordítást, mert CPU erőben így sem lett volna igazán versenyképes, így csak kevesen vették volna meg. Arról se feledkezzünk meg, hogy a CPU rész többet fogyaszt, mint az IGP rész.
(Amúgy még az sem teljesen kizárt, hogy meg is csinálták, kísérleti példányok formájában, és a tesztek során arra jutottak, hogy a 2 modul + 512 SP (8 CU) felállás a legszerencsésebb.)
-
dezz
nagyúr
Ez volt az a teszt, amit emlegettem:
Can OpenGL And OpenCL Overhaul Your Photo Editing Experience?
Dátum: 2012. június 10.
Felsorakoztatott programok: GIMP, AfterShot Pro, Musemage, Photoshop CS6.Azóta sem láttam hasonlót, csak most ezt a wccftech.com-osat. Nagyobb oldalakon semmi. (Még a fenti cikkben beígért folytatás sem jelent meg.) Mintha egy kék ködbe vesző kéz megkocogtatta volna a vállukat és azt suttogta volna egy hang, hogy nono, álljunk csak le ezzel nagyon gyorsan!
-
#14212
dezz
nagyúr
Vitamincsiga
#14207
dezz
nagyúr
válasz
Vitamincsiga
#14207
üzenetére
Hmm, ahogy nézem, ez nem kimondottan HSA-s teszt, hanem CUDA/OpenCL. Kár, hogy a Scientific Analysis nevű tesztet kihagyták a tesztben.
Érdekes szalagcímek vannak a főoldalon:
Sandra 2014 : OpenCL ES Android Tablet GP(GPU) Battle ARM vs. x86: Which is the best? @ SiSoftware
Sandra 2014 : OpenCL GPGPU Android Battle : Which is the best? (Qualcomm vs. Samsung) @ SiSoftware(#14208) Fiery: A WinZIP-re gondolsz? Nos, az eléggé jelentéktelen alkalmazás. De amúgy Abu azt mondta róla, hogy nem az AMD kérésére késleltették az Nvidia/Intel supportot (nem sokat számított a dolog, mint írtam, nem egy létfontosságú alkalmazás, vannak jobbak a feladatra), hanem egyszerűen nem ment velük rendesen. Szóval, ezt nem kell túldramatizálni/túldimenzionálni.
Voltak már korábban is más jellegű OpenCL-lel gyorsított programok, amik hasonló speedupot értek el, nincs ebben semmi igazán különleges. Hozzáteszem: ezek valós alkalmazások voltak, Abuék mégsem használták a tesztekben.
Ha lesznek egyes PS4/XB1 játékoknak Kaverire külön ráoptimalizált portjai, azok szerintem nem apró látványeffektekben lesznek különbek, hanem inkább arra számítok, hogy pl. a fizikai szimuláció számítását bízzák az IGP-re, miközben a többit dGPU számolja, így egy Kaveri+dGPU konfigon is ugyanúgy vagy akár jobban futhat, mint egy drága i7 alapú konfigon, ez lehet az előnye. Más kérdés, hogy a hagyományos játékok továbbra is az utóbbin fognak jobban futni, de előfurdulhat, hogy valaki kimondottan az említett portokkal akar játszani. (Úgy vettem észre, a konzolos játékok sokszor kidolgozottabbak és/vagy jobban építenek a játékélményre.)
(#14209): Most írtad, hogy szerinted a MIC megöli a GPU-kat. Ennél nagyobb monopolhelyzet mi lenne?
Abból a szempontból tökéletes a párhuzam, hogy a MIC is nagy sebbel-lobbal jön, egyesek által előre a végső győztesnek kikiáltva, és ugyanúgy nem vált be az első 1-2 generáció.
Az AMD64 megalkotásakor minimum két teljesen nyilvánvaló igényt vettek figyelembe: x86 alapú 64 bit (nyilván) és az eddig kicsit szegényes regiszterkészlet számbeli növelése (a szélesítés mellett).
"es az Intel altal lekoppintott Intel64 lenne most az egyeduralkodo."
Ez a mondat némileg félreérthető, hiszen az AMD64 Intel-féle implementációját is így hívják. A MS azért csapott az asztalra, mert az AMD64 teljesen jó volt, el is kezdték portolni rá már a Windowst, amikor az Intel előállt a saját, hasonló megoldásával, és a MS-nak nem csak pluszmunka lett volna arra is portolni, de teljesen felesleges is (csak az Intel érdekeit szolgálta volna).
-
#14205
dezz
nagyúr
Vitamincsiga
#14198
dezz
nagyúr
válasz
Vitamincsiga
#14198
üzenetére
Nem is értem, Abuék miért nem csinálnak ilyen teszteket...? Nem csak HSA, hanem mindenféle OpenCL is. Már évekkel ezelőtt is volt egy pár ilyen program. (A LuxMark pont nem az igazi, az egy alapvetően CPU-s algoritmus áthackelése OpenCL-re.) Hiszen éppen ezekkel lehetne kézzelfoghatóvá tenni az egész APU-s koncepciót.
BTW, különösen érdekes a Sandra GP FinalcialAnalysis nevű tesztje! Egyrészt eddig csak képfeldolgozóknál láttam ilyen 50x gyorsulást eddig, másrészt a 6800K-hoz képest is 3x gyorsabb. Nem tudom, futtatható-e ez dGPU-n (GPGPU módban), kíváncsi lennék, azok hogy teljesítenek. Tehát, hogy itt a HSA dobott ennyit, vagy egyszerűen a GCN-nek fekszik a dolog.
(#14202): Ő nem úgy értette.
Hanem, hogy a GPU szerinte teljesen eltűnik, mert kiüti az Intel MIC-je (sok kis CPU mag hálózatban).(#14199) Fiery: Az miért lenne gond? Az Intel is sokmindent szponzorált már. Oké, kevés a három, de lesz majd több is, eleve csak nemrég óta elérhető a HSA fejlesztőkörnyezet. Maga a GPGPU is lassan nyer teret.
Egyébként most akkor a Sandra fenti tesztje az egyik, amit az AMD szponzorált? Titeket nem szponzorálnak?
(#14204): Azt természetesen nem tudhatjuk, hogy bukás lesz-e a MIC. Én ezekre a párhuzamokra utaltam: 1. Az Itanium is úgy jött, hogy az most aztán mindenkit letarol és átveszi az x86 helyét. 2. Az első generáció bukás lett, de az Intel nem adta fel, pumpálta bele a milliárdokat. Ez esetben hiába. 3. A MIC is új architektúra, bár az alapot képező mikroarchitektúra csak félig új.
Az utolsó bekezdésből kihagytad a játékokat (újfent), amik azért erős befolyással vannak a PC-re is. Elképzelhető, hogy lesznek majd játékok, amik - PS4/XB1-ról portolva - Kaveri+dGPU konfigon fognak a legjobban futni, ami növelheti az AMD proci-eladásait, és akár más sw-szegmensekben is kedvet csinálhat a HSA-hoz, vagy legalábbis az OpenCL 2.0-ához, amiben egyelőre szintén az AMD a jobb (már csak a jobb IGP okán is).
-
dezz
nagyúr
válasz
lezso6
#14183
üzenetére
Nem kizárt, de CPU-knál egy kicsit nehezebb ügy, mert nagyobb különbségek vannak a mikroarchitektúrák és CPU-családok között. Másrészt ez leginkább esetleges új belépőknek lenne érdeke, a meglévőknek kevésbé.
(#14184) Fiery: Igen, arra gondoltam, és egy példa volt arra, hogy bár nem mindenkinek tetszett az sem, elkerülhetetlen volt.
A Samsung azért eléggé az élvonalban van chipgyártásban, azt sem lehet mondani, hogy kis összegeket fektetnek be, most már a GloFo is tőlük licencel gyártástechnológiát. Az Apple nem tudom, mit gyárt házon belül.
Az AES pont rossz példa, hiszen céláramkör végzi el a feladatot, amit GPU-kba is simán beépíthetnek.
-
dezz
nagyúr
Oké, de a fizikai törvényeket (már ami a szilíciumra vonatkozik) ők sem tudják felülírni. Ezt a felvetést elintézted annyival, hogy "Tény." Aztán írsz egy panaszáradatot, mintha a szöveg mennyisége döntené el a kérdést.
Pedig hát nem."Ez a jovo? Tenyleg?"
Úgy néz ki, legalábbis amíg le nem cserélik a szilíciumot. De előbb-utóbb más technikánál is előjön a kérdés. A többmagúsítás sem nyerte el mindenki tetszését, de hát ugye eszi, nem eszi, nem kap mást.
Azt meg lehet érteni, hogy nem akarják kiadni a szoftverfejlesztést (mint ahogy az Intel is fejleszti a saját C compilerét), de valóban nem ártana most már gatyába rázni ott a sw-fejlesztő brigádot, komoly fejlesztőket ráállítani, komoly budgettel, stb.
Az, hogy mostanra beérték (ha valóban így van, nem tudom) az ARM-ot alacsony fogyasztásban, nem jelenti azt, hogy le is hagyják, hiszen a fizika itt is közbeszól. És hát legalább ilyen nehéz dolguk lesz ARM által birtokolt piacok meghódításával.
(#14180): "Miert kene egy adott feladatra sok szalat radobni, ha keves szal is gyors tud lenni?"
HA kevés szál is gyors tud lenni... Ez majd elválik.
-
dezz
nagyúr
"Az x86/AMD64-ben van full 32 bit UINT/INT támogatás. A GCN ezt átmentette, és lényegében ugyanazokat az integer matematikai trükköket teszi lehetővé, amiket a fejlesztők alkalmaznak a CPU-kon."
Az jó, de ez még csak egy kisebb része az egésznek. Nem vitatom, hogy közelebb állnak, mint akorábban, de egy GCN CU így is eléggé más, mint egy normál CPU mag (kevesebb benne a "sallang", sokkal inkább párhuzamosított végrehajtásra optimalizált, mintsem skalárra), és az egész GCN alapú GPU is eléggé más, mint az Intel many-core CPU koncepciója (más a buszrendszer, kevésbé önállóak a CU-k, viszont külön egységek vannak az igazgatásukra).
Az Intel egy univerzális magokat akar, az AMD viszont úgy gondolja, a CPU jobb skaláris számításokra, a GPU pedig párhuzamosra. És ugyebár van egy olyan mondás, hogy ami mindenre jó, az semmire sem jó igazán. Mint írtam, ezt az Intel a gyártástechnológiai előnyével próbálja ellensúlyozni, csak kérdés, ez meddig sikerülhet.
(#14167) Fiery: Még ha nem is lesz valamilyen kimondott OpenCL alternatíva, később az is egyfajta alternatívát fog jelenteni, hogy C/C++/Javában is le lehet majd programozni ugyanazt. A Java részévé fog válni a párhuzamosítás.
"Engem mint fejlesztot szemely szerint nem erdekel se az ISA, se a threadek szama, se az egysegnyi tranzisztorra juto fogyasztas."
Ez így azért eléggé leszűkített látómező. Egy dolog, hogy mi lenne kényelmes a fejlesztőknek (a legjobb egy több THz-es CPU lenne) és egy másik dolog, hogy a fizikai törvények mit hagynak megvalósítani, jelenleg szilícium alapon. Egy a jövőről folyó eszmecseréből ez nem hagyható ki.
"Az Intelben azt dijazom, hogy legalabb kiallnak egy adott platform (x86) mellett, azt nyomjak, azt eroltetik, arra fokuszalnak."
Még jó, hogy ezt próbálják nyomni, ez a legfőbb ütőkártyájuk.
Az előzőből kimaradt: "lefele meg az ARM-ot szorongatja"
Ez vicces, inkább talán az ARM szorongatja őket alulról (úgy is mondhatnám, a töküket).
-
dezz
nagyúr
Egyébként hogy néz ki a HSA szoftver oldalról? Lesz valamilyen (saját) OpenCL alternatíva?
"ignore-alod"
Már írtam korábban, hogy ezt felesleges így írni, rendes szótári szó az ignorál.
"Anno az IA-64-gyel is ez volt a terv, abbol is lehetett volna adott esetben x86 utani architektura..."
Mint tudjuk, nem a véletlenen múlt, hogy végül nem lett az - pedig az Intel váltig hitt benne. Csak azért hoztam fel példának, hogy az Intel sem tévedhetetlen. Lehetne más példákat is mondani.
"Amiben en maximalisan nagy fantaziat latok, az -- es most tegyuk zarojelbe az x86-ot mint architekturat, nem az itt a lenyeg -- a GPU felvaltasa egy olyan sokmagos processzorral, ami mindent hazon belul megold. Ha kell, altalanos feladatokra is hasznalhato remekul (mint most az x86 CPU magok), ha pedig az kell, akkor a compute-ot is gyorsan vegrehajtja."
Rendre kihagyod a képletből a fogyasztást és a helyigényt: egy CPU jóval több tranyóból hozza ki ugyanazt a számítási teljesítményt. Az Intel jelenleg a gyártástechnológiai előnyében bízik, de nem biztos, hogy az még sokáig fennmarad.
(#14163) Abu85: "A GCN rengeteg feladatban dettó ugyanúgy működik, mint az x86"
Ezt kifejtenéd, mert én speciel eléggé másmilyennek látom.
"csak az ISA memóriamodellje úgy van tervezve, hogy a lapkán belül 30ezer konkurens szál is futhat skálázási probléma nélkül. Az x86-ot eredetileg egy szálra tervezték."
Meg a GPU szinte teljes belső felépítése, ami lehetővé teszi ezt a 30 ezer szálat...
(#14164): Ja, akkor ugye nem lesz (saját) OpenCL alternatíva, csak a HSA keretrenszer lehetővé teszi, hogy C/C++/Javában is lehessen compute feladatokat leprogramozni. Illetve, ott van még a MS-féle C++ AMP.
(Mint a Válasz. 
) Egyébként nem csak v. elsősorban nem a függőségektől függ (az inkább szálon belül befolyásolja a superscalar végrehajtást, szálak között nem ilyen sűrű a kommunikáció), hanem a felhasznált utasításoktól. Azt hiszem, pl. a vektoros kód inkább lassul, mert 1-1 szál is nagyon leterheli az erőforrásokat.
Érdemes megnézni a lejátszási statisztikát. Meg hát látható is.
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Az ide nem illő hozzászólások topikja:[link]
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva.
- ÁRGARANCIA!Épített KomPhone i5 10400F 16/32/64GB RAM RX 7600 8GB GAMER PC termékbeszámítással
- Honor Magic6 Lite 256GB, Kártyafüggetlen, 1 Év Garanciával
- Apple iPhone 13 128GB, Kártyafüggetlen, 1 Év Garanciával
- MSI GeForce RTX 3090 VENTUS 3X OC 24GB GDDR6X 384bit
- Dobozos! Xbox Series X 1 TB + kontroller 6 hó garancia, számlával!
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest