Új hozzászólás Aktív témák
-
-
arn
félisten
Akkor irom ugy, hogy aki kesobb jon, az letudja tesztelni a rendszeret a korabbi oprsz alatt... kicsit fura, hogy ilyenkor jonnek a meglepetesek, amikor ennek az egesz dolognak mar reg nyilvanvalonak kellett volna lennie a gyarto szamara, es utolagosan kapkodva felmegoldasokkal probalja menteni a menthetot.
Ettol meg lehet utolagosan az oprszt is fejleszteni, de pontosan tudniuk kellett volna, hogy mi varhato jelen helyzetben, es erre milyen valaszt kell adniuk.
-
sb
veterán
Két hsz-edre reagáltam. Az egyikben azt írod ez lófütty, rendes optimalizálás, CCX megoldás, stb... kell.
Erre csak annyit írtam, hogy ez NEM az. Ez egy energiamenedzsment séma módosítás volt, ez ennyit tud, ennyit akartak, nem többet. Ha mást vársz akkor rossz topicba tévedtél ezzel.
Ennyi lett volna a lényege ennek a résznek.Amire nem reagáltam, de most másodszorra írod és szúrja a szemem: aki "később jön alkalmazkodjon". Ez hülyeség. Ilyen alapon senki nem fejlesztene semmit soha. 16 biten tolnánk az ipart... Azért azt látni kell, hogy az IT innovációról szól, bármennyire is leragadtunk mondjuk az x86-nál vagy grafika terén a DX akárhánynál... a fejlődés nem erről szól. Látszik is a fentiek használatából, meddig jutottunk előre 10-15 év alatt.
-
ribizly
veterán
Ahaaa.
Pont ezzel a numa-val barátkoztam pénteken redhat-on, de eddig nem állt össze a teljes kép.
Ettől még nem hiszem, hogy olyan nagyon figyelnének erre a fejlesztők, arra meg végképp nem számítok, hogy erre a vegyes felvágottra amit most az AMD behozott az eddigi mellé. -
MaUser
addikt
Khm, AMD eredeti közleménye szerint nem az MS a hibás, aztán most mégis? Valami itt nem kerek.
A korábbi idézetedhez meg: 1ms alatti vált Ryzen az egy dolog, de a) ezt az Intel is tudja már pár éve és ott még sincs gond, b) HPET mellett nem 1ms-es pontos(!) időzítésekkel dolgozunk már pár éve, hanem három nagyságrenddel kisebbekkel, c) ha hw-ből ilyen okos a Ryzen, akkor minek profil? d) linux alatt miért működik normálisan...
Röviden csak ennyi probléma az AMD-s kommunikációval.
-
Az, hogy az os még nem ismeri a háromlépcsős felépítést. Már ha gond ez. Ez egy állapot, amiről vagy lesz elmozdulás, vagy nem. Nem olyan kulcskérdés, hogy a mostani állapotban ne lehessen használni a procit akár évekig. Egy-két százalék minden prociban benne marad, intelben is, ott meg az smt kezelés nem tökéletes. Linux alatt többet hoz az inteles smt, mint win alatt, mert ott jobb a kezelése. Ott meg más hiányosságok vannak.
-
Shing
őstag
Egyébként nem csodálkoznék ha kiderülne, hogy nem működnek optimálisan a processzorok. Pl. a magok parkoltatását ha bizonyos rendszereknél feloldjuk akkor, több teljesítmény kapunk.
Vagy olyan szoftverek mint a ParkControl, nem engedik a procit semmilyen energiatakarékos állapotba és azt állítják, hogy több teljesítményt érhetünk el. Nekik van benchmark, én még nem próbáltam.
De láttam már olyat, hogy magasabb prioritást adtak egy játéknak feladatkezelőben és jobb lett a teljesítmény, mert magasabb lett a cpu kihasználás... Ilyeneknek nem kellene működnie, sztem. -
Az egész eddigi koncepció azon alapul, hogy az OS nem kell, hogy tudja melyik core a valós, vagy hogy mely thread-ek tartoznak egy fizikai core-hoz.
Dehogy. Intelnél is tökéletesen tisztában van vele, hogy melyik magpárok tartoznak össze egy fizikai mag alá. Multisocket (illetve numa) esetén az is tudja, hogy melyik magcsoportok taroknak egy nodehoz. Tehát ismeri ezt a kétszíntű szerveződést (SMT, NUMA node)
Ryzennél háromszintű a szerveződés. SMT, CCX, NUMA node Ezt kell megtanulnia. A hardverazonosítóból meg kell tudnia állapítani. Nincs ebben semmi bonyolult.
(#80) arn
Mert hiaba optimalizalnak egyfele ryzen felallasra az nem lesz univerzalis, ha az amd osszevissza kavarja majd a konfigokat (4, 2+2, 4+2, 4+4, 4+4+2, 4+4+4+4Sikerült összeírnod egy ötrekordos (nem pontos, mert a ccx-ek között szimmetria kötelező a numa node-okhoz hasonlóan) adatbázist. Ennek a kezelése már a hatvanas években sem volt informatikai kihívás.
-
ribizly
veterán
Erre szerintem senki sincsen felkészülve.
Az egész eddigi koncepció azon alapul, hogy az OS nem kell, hogy tudja melyik core a valós, vagy hogy mely thread-ek tartoznak egy fizikai core-hoz.
Biztosan ki lehetne nyerni ezeket az információkat egy megfelelő driver-el vagy újabb koncepcióval, de nem éri meg, mert a most és eddig fejlesztett alkalmazások nem úgysem használnák, ráadásul az erre való fejlesztési +költség sem volna alacsony, hiába volna lehetősége innentől kezdve jobban optimalizálni (LoL
) a fejlesztőnek.
Ezért is van az, hogy például a Greenplum DB-nél a gyártó azt javasolja, hogy szépen kapcsold ki a HT-t...
Viszont a kommented aggasztó gondolatot vet fel, mert eddig legalább arra lehetett számítani, hogy egységesen terhelhetőek a thread-ek (1 core = 1 thread vagy 1 core = 2 thread).
-
arn
félisten
válasz
#25954560
#78
üzenetére
Az lenne a legidealisabb, ha a gyartokozeli megoldas mondana meg az oprsznek, hogy milyen sorrendben ossza le a feladatokat, es akkor nem kell egy harmadik felre varni, a gyarto kitesztelhezi pontosan, melyik szamara az idealis. Pl konfigolhato lenne oprsz szinten, etc. Pl nyolcmagos ryzen eseten:
Elsodleges ccx fizikai magok
Masodlagos ccx fizikai magok
Elsodleges logikai
Masodlagos logikaiEnnek megoldasa egyre egetobb sok mag es eltero felepitesek eseten. Mert hiaba optimalizalnak egyfele ryzen felallasra az nem lesz univerzalis, ha az amd osszevissza kavarja majd a konfigokat (4, 2+2, 4+2, 4+4, 4+4+2, 4+4+4+4 stb magszamtol fuggoen es fuggetlenul). Honnan a fenebol fogja tudni pontosan az oprsz, hogy mi rejtozik a prociban, ha errol nem kap infot?
Lehet az intel sem hobbybol gyart monolitikus magokat, mert katasztrofa lenne pcszinten a skalazodas.
-
arn
félisten
Felreertesz, idealis esetben szerintem is az os (legalabbis alacsony szintu megoldas kell az egyenkenti optimalizacio helyett) dolga lenne, mint ahogy parszor mar irtam is, de az meg a gyarto dolga, hogy ezt megteremtse, es kieszkozolje. A masik, hogy aki kesobb jon, annak kell felkeszulnie a korulmenyekre, es nem uj korulmenyeket teremtek, aztan varom a csodat.
-
#25954560
törölt tag
erdekes teszt lenne bios-bol letiltott hyper-threading.
az elonye az lehet, hogy amelyik progi egyebkent sem hasznal 4 szalnal tobbet, ott eloszor is nem pakolgatna az operencias rencer a szalakat ht-rol ht-ra, masreszt a ht-parokon futo kodok nem versenyeznenek egymassal az eroforrasokert. -
sb
veterán
Kb. Az SMT pedig nincs megkülönböztetve, hogy az nem egy 100%-os mag. Nem is nagyon lehetne, mivel kódfüggő, hogy mennyit ad hozzá, mondjuk -5 - 30% között valahol.
Pl. egyszálas tesztet indítunk egy 2/4-es i3-on: 25% cpu load. Két darab 1 szálas teszt: 50% load. Pedig ilyenkor ugye a HT-n kívül már fullra terheltük a valós két magot. Lefelé csal a kijelzés - legalábbis jó esetben.
-
ribizly
veterán
válasz
Raysen623
#71
üzenetére
Igen, kis gondolkodás után én alapvetően csak addig jutottam, hogy valszeg a több szál miatt a progi amivel mért (ami ugye nem a szálankénti terhelést mutatta, hanem egy számot generált valószínűleg valamilyen osztásos módszerrel pl CPU0 x% + CPU1 y% + ... / szálak száma) torzítja eleve az eredményt, ha az adott game nem tudja hajtani az összes szálat vagy azt nem arányosan teszi.
-
sb
veterán
A cpu usage-nél számításba kell venni, hogy az SMT-t nem tudja - legalábbis régen nem tudta, szerintem azóta sem, mivel eléggé elméleti a probléma - normálisan jelezni a win. Terhelsz a 4/8-as procin 4 szálat, ezt mondjuk kiosztja a 4 fizikai magra full terhelésen, ez a kijelzőn 50% terhelés mivel 4 szál 100% és 4 szál 0% az elérhető 8-ból. Viszont ez nem azt jelenti, hogy a maradék SMT-vel még rá lehetne duplázni a teljesítményre...
-
sb
veterán
Nem hinném, hogy lehet, mivel ez az os dolga. Azért van benne ütemező meg azért pakolgatja a szálakat ide-oda. Szerintem itt eltévesztetted a házszámot... ahogy a fentebbi hsz-ben is. Lehet, hogy nagyobb ggyorsulást vársz meg gyorsabb CCX kommunikációt, de ez a hír nem erről szólt. Energiagazdálkodási profilt reszeltek, az ennyit tud. Van még ezen kívül 3-4 más problémája a Ryzennek (legalábbis átvitt értelemben, mert általában nem konkrétan a prociban van a gond ott sem). CCX-re ott az ütemezés módosítás, a ram sebesség is hat rá amit a bios-okban javítgatnak a lapgyártók. Aztán van gond a direkt szálkiosztással játékon belül, nyilván azt meg ott kell megoldani... és ezek hozzák a plusszt.
Lásd win update gyorsulások (10-15% itt-ott), gyorsabb ram szintén hozhat 10-15%-ot bizonyos felállásokban, vagy AoTS patch: +20-30%.Valószínűleg ezekre vársz inkább.
-
Raysen623
addikt
Véleményem szerint: Ryzen 1400 ugye 4 mag és 8 szál, míg az intel üdvöskéje 4 mag és nincs tovább. Ebből fakadóan a CPU-nak sokkal több tartaléka maradt. GPU esete már más, ott egy kicsit optimalizálatlan CPU miatt időnként egyes játékokban nem hajtja ki rendesen a GPU-t. Érdekesség, hogy játékonként változó a helyzet. Remélhetőleg a várva várt BIOS frissítések ezt megoldják.
Ettől függetlenül én ilyen procit vennék ha bővíteném a desktop gépemet. -
Cathulhu
addikt
Sok minden lehet, lehet pl memoria kesleltetes, vagy ahhoz hasonloan a CCX-ek kozti latency, ilyesmik nem engedik kifutni a procit az meg nem tudja etetni a GPU-t. A jo hir, hogy a kesleltetesen az aprilisi BIOSok segitenek.
#69 nem feltetlenul szar, csak eddig monolitikus CPUk voltak, es azokon volt tesztelve es optimalizalva a kod. Nem feltetlen a programozo hibaja, hogy jon evekkel kesobb egy teljesen uj architektura es azon nem fut olyan jol, attol meg lehet maga a kod elegans es hatekony, csak mondjuk nem ilyen kornyezetre szamitott.
-
-
-
Xmister
senior tag
Nem igaz. Csak szerencsére a gamersnexus megint clickbait cikket írt, és ferdít.
Now that you know a little more about the performance of our new plan, let’s talk power. The AMD Ryzen Balanced power plan does not change how our processor handles low-power idle states called “CC-States.” These CC-States number cc1 through cc6, representing increasingly aggressive clock and power gating. In fact, cc6 represents a core that is essentially turned off. The core is sleeping so deeply that only its voltage can be detected by software.
The sophisticated power management technology in the “Zen” core can autonomously enter and exit these CC-States as quickly as 1ms. Software tools, unable to see through the sleep, will simply report the last P-state known to the OS before the core entered a CC-state. Don’t be alarmed! The effective frequency of a sleeping core is much lower (generally sub-1GHz). [link]
A lényeg: A win10-es power mgmt túl lassú ahhoz, hogy váltogasson a C state-ek között. Ez a plan kikapcsolja a szoftveres managementet, és csak a hardveres lesz aktív, ami továbbra is energiatakarékos módba fogja kapcsolni a magokat, csak az op.rendszer ezt nem fogja látni, és nem fog beleszólni.
-
ViZion
félisten
OK, jogos, ebben is van vmi, hogy meg kellett volna beszélni, gondolom van olyan szerződés, ami lehetővé tenné akár AMD-nek is, h a kód egyes részeibe belenézzen és hegesztgesse.
Vagy az AMD-nek kellett volna a szükséges instrukciókat időben átadni, nem fogjuk megtudni. AMD oldalon eddig is a rev1 teszt az már az userek voltak, Phenom, FX, minden procinál ez volt, lehet megint meg kell várni a rizsszem II-t... -
MaUser
addikt
Khm, normális esetben ez úgy működik, hogy te mint hw gyártó szólsz előre a sw gyártónak, hogy frissítsék a rendszert megjelenésig. A kapcsolat megvolt az ms és az amd között, hiszen már előre szólt az amd, hogy az ms agymenésének megfelelően coki lesz a win7 tulajoknak. Erre meg sikerül benézni, hogy nem megy a win10 energiagazdálkodással normálisan a procijuk. Na most akkor itt valamelyik cég (vagy mindkettő) igencsak amatőr hibát vétett, de persze majd jönnek a szokásos win10-es, nv/amd driver-es fanboy hozzászólások hogy biztos user error.
Ez van ha egy cég szarul van vezetve. Igaz ez mindkettőre.... -
ViZion
félisten
Ezért kár volt regelni...
Szerinted ha csinálnak egy új HW-t, akkor az OS-hez tervezik, vagy majd inkább az OS-t patchelik hogy az újabb HW-vel is működjön? Igen, AMD a hibás, anno mikor jöttek több maggal, az XP meg azt sem tudta merre van előre. Vagy a 4 GB-nél több ram. Köcsög gyártók, amikor az OS 4 GB (se) kezelt, kijöttek a 8 vagy több GB-vel. Vagy az SD kártyák, képzeld anno vettem egy nagyobbacskát és az olvasóm nem ismerte az SDHC-t. Ejj, minek gyártották, ha olyan még nem volt? Mennyévissza DOSoljá' mondaná Gyuri barátom, és de igaza lenne.Nah, csak foglalkoznak a problémákkal, remélem nyárra lesz nekem való lap/CPU kombó. Most még nem igazán találtam, bár MSI Artic deszka tetszetős, csak sokallom az árat.
-
arn
félisten
De legalabb tepernenek ezerrel a msnal, hogy adjatok mar ki egy patchet... Amugy nem lehet alacsonyszinten (bios,etc) atszervezni a magok/szalak cimzeset, hogy jobban megfeleljenek a win utemezojenek? Azt megiscsak durva elvarni, hogy majd mindenki megcsinalja programszinten.
En nagyon akarnek venni egyet, de ilyen alapveto hiba kizaro ok, mert ez mashol is visszakoszon. Tobb ccxnel ez meg gazosabb lesz.
Vhogy ugy, hogy 0-3 szal fizikai mag, 4-7 masik aztan a logikai szalak.
-
#25954560
törölt tag
ehhh, minel nagyobb a ceg, annal jobban szet van osztva a melo, ki csinalja a fejlesztest, ki a tesztelest es amikor a fejlesztok osszeultek a tesztelokkel, akkor meg ottvolt a sok tesztelnivalo, de aztan a management lecsippantott a listarol ezt-azt, csak hogy a piacrakerules idoben legyen... siman lehet h zsenik a fejlesztok es szuperek a tesztelok, csak nem volt szavuk h ezt igy megsem kene...
-
Yany
addikt
A debüt óta ugyanezek a gondolataim. Meg kicsit olyan, mintha kaptak volna ajándékba valakitől egy tervrajzot, legyártatták és ők sem értették, hogy mit kéne még javítani. Szóval van egy cég, ahol géniusz agyak egy CPU-t raknak össze, ráadásul nem is akármilyet, s ott nincs egyetlen szakember, aki kiszúrná ezt a galibát még piacradobás előtt? Mintha velünk, vásárlókkal együtt ismernék meg ők is. Óhatatlan, hogy kerül elő ez+az (ahogy Intelnél is volt már rá példa), de egy generálisan jelenlévő jelenségről beszélünk, nem itt-ott ritkán előbukkanó spéci bugról.
Én csak azért puffogok ezen, mert nagyon jó a proci, csak ez az amatőr fíling picit nem kéne.
-
#48
Malibutomi
nagyúr
Malibutomi
nagyúr
Biztos az tesztelte a Ryzent aki a Mass Effect animaciokat
-
Fiery
veterán
Ebben az egeszben az a legviccesebb, hogy az AMD evekig fejlesztette a Ryzent. Mire lett belole kezzel foghato termek, me'g mindig volt a megjelenesig kb. 1 ev. A Win10 addigra mar boven piacon volt. Se a Microsoftot nem ertesitette az AMD, hogy a core parking korul gaz van (legalabbis Ryzenen), se a Win10 power beallitasait nem probalta ki rendesen, melysegeben senki az AMD-nel? Neha olyan erzesem van, hogy az AMD egy olyan processzort tervezett, amit nem celszeru Windowszal hasznalni
Linux alatt remekul megy, Windows alatt meg folyamatosan megy a mutogatas, pingvinezes meg a patchelgetes. Oke, legyen a Windows felkeszitve, de miert a Ryzen launch _utan_ kellett a kozossegnek, reviewereknek meg az AMD mernokeinek rajonnie arra, hogy hol a baj es hogyan lehetne esetleg javitani? Nem volt egyetlen nyomorult AMD mernok sem, aki egymas utan kiprobalta volna a Win7-et, Win8.1-et, Win10-et, szepen nyomott volna 20-30 olyan benchmarkot, mint amit egy tok atlagos review site is hasznal, es osszehasonlitotta volna az eredmenyeket? Azonnal kibukott volna, hogy valamit csinalni kell Win10 alatt... -
MaUser
addikt
A szándék örömteli, de egyelőre pont a lényeg marad ki a hírből:
To be more specific, there are three key differences between the High Performance mode we have been using and the new Ryzen balanced mode:
Windows 10 high performance plan sets both CPU freq_min% and CPU freq_max% to 100%. Our plan sets 90-100%.
Ergó továbbra is csak hekkelés van és várni kell a normális MS javításig, ugyanis 90%-os min CPU freq az jelenleg rosszabb, mint ha simán a high perf módban beállít az ember egy értelmes 10-20%-ot.
Hogy még energiatakarékosabb legyen, a core parking is disabled-re került...Miért nem lehet a teljes hírt lehozni normálisan, ha már hír születik?
-
ribizly
veterán
Végre egy olyan hír, ami jót tesz a versenynek meg az áraknak.
Én magam valószínűleg még pár évig nem fogom leváltani az i7-3770k@4.2-t, de így már legalább lesz min gondolkodni, amit lássunk be az elmúlt minimum 5 évben nem nagyon kellett.
Csak így tovább AMD! Már csak a VGA piacon kéne valahogy összehozni valamit. -
#41
CPT.Pirk
Jómunkásember
hyperspace
#36
CPT.Pirk
Jómunkásember
válasz
hyperspace
#36
üzenetére
Már kb. egy hónapja rágjuk ezt a HPET dolgot, mivel egyrészt eleve elavult Windowson ment a ph! teszt, másrészt nem volt mivel összehasonlítani az értékeket itt az oldalon. Jöttek magyarázatok, hogy most akkor tényleg van hpett gond vagy mégsem úgy van ez a dolog, meg aztán h. csak W10 alatt lesz erre megoldás, mert, mert csak...
Ha mellékerült volna releváns Linuxos teszt valamilyen appból ami multiplatform, legyen az mondjuk az x264 enkódolás, akkor már lett volna valami összevetési lehetőség, hogy hol kell keresni a hibát. Nyilván idő és / vagy ember hiánnyal küzd a tesztelő csapat, ezért is volt csak régi Windózzal tesztelve a proci.
Ebből a hpet szempontból meg irreleváns, hogy a desktop gamer mit használ oprendszernek. Prociról van szó, nem csak a játék számít. Én pl. az előző évben rendszeresen fordítottam Cyanogen mod romot a telefonomra, az 1,5..2 óra folyamatos munka volt a Phenom2 procimnak és lehet h. fogok még ilyet csinálni így tényleg érdekel, hogy mit produkál a RyZen nem MS oprendszeren, mivel ilyesmit nem lehet Windows alatt megcsinálni. Időnként filmeket is konvertálok, az se két perc, az is érdekel miként működik nem MS oprendszeren. Nem is beszélve az ARM-es Linuxos rendszerekre fejlesztésről, azok se mennek Windows alatt, viszont sok forrásból fordítást igényelnek, ami eléggé proci igényes.
Őszintén szólva nem nagy kaland betenni néhány tesztet Linuxra is. Ráadásul tök könnyen lehet rajta a teszteket automatizálni. Nézd meg példának a Phoronixos srác rendesen összerakott RyZen tesztjeit, pedig ő nem egy komplett cég, csak egymaga tolja.
lezso6: jah és legyen tánc!
-
Cathulhu
addikt
Múltkor olvastam egy elég kimerítő tesztet ahol pont ezt a témát járták körül. Abból az jött ki, hogy DX11 ez nem igaz, sőt inkább a fordítottja(ami tekintve, hogy ott jobbak az nV kártyák, valószínűleg kevesebbet kell a procinak dolgoznia, mint radeon alatt, így kisebb a lemaradás az intellel szemben, szerintem), DX12ben igaz a dolog, de ott az nV kártyák több dolgot emulálnak CPUn, így a driver is jobban terheli azt, így nagyobb a lemaradás az intelhez képest. Hogy ez most valós különbség, vagy van mit optimalizálni az nV driveren, az kérdés, de mindent ráfogni túlzás
-
wwenigma
Jómunkásember
LOL...inkabb olvasgassál híreket a háza tájáról az alábbiak kapcsán: Nvidia driver, ramsebesség, HPET, AGESA, AoTS patch, etc...nem meglepo hogy minden téren intelre optimalizalt kornyezetben kell fejlesztői beavatkozas az uj architekturahoz...es ahol volt ott odacsapott hirtelen.
Az viszont hogy halottnak a csók, nagyon-nagyon-nagyon messze van az igazságtól.
) a fejlesztőnek.
Ez van ha egy cég szarul van vezetve. Igaz ez mindkettőre....
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- HIBÁTLAN iPhone 15 Pro 128GB Natural -1 ÉV GARANCIA - Kártyafüggetlen, MS3501, 90% Akkumulátor
- Azonnali készpénzes nVidia RTX 3000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
- iMac Pro 1.1 2017 Intel Xeon W2150B 64GB 1TB VEGA 64 16GB!!! 1 év garancia!
- Akció! Hordozható GAMER Monitor! MSI MAG162V ! 15.6 1920x1080 FULLHD! Bolti ár fele!
- HIBÁTLAN iPhone 13 mini 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3304
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest