AMD cpu éve?

CPU-k, Cooler-ek

A legutóbbi és korábbi Intel bakik láttán elgondolkoztam, hogy talán ideje újragondolnom az eddigi Intel-párti álláspontomat és következő PC-nél AMD-re váltani. 

A korábbi (már talán már régen megoldódott) problémák amik miatt nem vettem AMD cpu-t:
- Teljesítménybeli problémák egyes szoftvereknél, pl Matlab
- Gyengébb egyszálú teljesítmény
- Nagyobb átlagfogyasztás
- Jobban melegszik
- Hackintosh nem működik AMD cpu-n stabilan

VGA oldalon többek között tensorflow miatt marad az Nvidia, szóval csak a CPU rész érdekel.

A fentiek közül melyik problémák oldódtak meg mára és melyek nem? 

  • 2644 megtekintés

( Addam2 | 2020. 04. 14., k – 16:52 )

Fogyasztást, melegedést azonos teljesítmény mellett érted? Milyen felhasználás mellett? Mire kellene?

( Yuhl | 2020. 04. 14., k – 17:02 )

Nézzük:

- Matlab-hoz úgy hírlik már nem kell peccs az AMD procihoz, hogy használjon AVX-et is. (Van táblázat a neten, elég meggyőző eredmények vannak benne. Keress rá, hogy "AMD" "Matlab" "AVX")

- Egyszálú teljesítménye kb azonos. (Most pár % difi ide-oda van, attól függően mit futtatunk.)

- Az "átlagfogyasztást" nehezen tudom értelmezni, nem tudom mire gondolsz. Úgy emlékszem "idle" fogyasztása még mindig magasabb, mint az Intel-é, de nem olyan számottevően. (Lényegesen javult.) Most, hogy mit "kapuznak" ki tervezéskor, gondolom mindennek oka van. Ha számoltatsz vele, dolgozik a proci, akkor az idle fogyasztását nézni teljesen értelmetlen. A "TDP" mögött meg már annyiféle definíció van, hogy én sem bírom lassan követni. Nekem 2600X-em  van, 12 szálon kiterhelve, 4Ghz-el magonként 80W-ot eszik, ha hihetek a HWmonitor-nak. (95W-os névleges TDP-vel emlékeim szerint.) Intelnél én azt tapasztalom, hogy a fogyasztás kb a 4xxx-es szériától kezdődően el tud szállni, a 9xxx-es csúcsmodelljei meg híresek arról, hogy terhelve bekajálják a TDP másfélszeresét is, a 95-os proci 150 fölött eszik. (De most ugye az Intel TDP-re minimum hűtőteljesítményt ad meg.)

-  Melegedés. Hm. Relatív. Define R4-es házban, nagy Arctic toronyhűtővel most így 70C-on van, de már egy ideje pörgetem, hogy lássam mennyire melegszik fel és le tudjam írni :) Minél erősebb, annál jobban melegszik, annál jobb hűtést kell mellé raknod. Ez általános tény, ha veszel egy csúcs-procit és nem hűtöd rendesen azzal elveszted pont azt az erényét, amiért megvetted. Sosem fogja úgy elérni a teljesítménye maximumát, visszafogja magát és lebutul középkategóriás szintre.

- Hackintosh-ról nincs infóm.

Tensorflow-ról meg valami olyasmit mondott múltkor kolléga, hogy az AMD kártyák is mintha támogatva lennének már, de bent az egész eszközpark nvidia-s, nincs lehetőség kipróbálni. Lehet itthon összeütök egy rendszert, aztán megnézem, feltéve ha nagyon unatkozom :)

k10temp-pci-00c3
Adapter: PCI adapter
Tdie:         +85.2°C  (high = +70.0°C)
Tctl:         +85.2°C  

rosetta@home + folding@home megy hetek ota. A szobaban neha 31 cDeg  is van (tobb gepem van, azok futenek).

3900X  CPU -nal 95 fok sem gond .
4Ghz (~3986.091 Mhz) -megy igy is minden mag.  (Base clock (3.8Ghz) felett van igy is )

Ez nem az alap hutes (dual fan), de Haz(Define R5) oldala/teteje/ajtaja zarva .
Valamivel jobb nyitva.

105W CPU. Szerintem kicsi a CPU felulete, azert nem megy lentebb.
A ventillator bordaja a tetejen mar hideg, az alaplap a cpu kornyeken 60 cDeg.

Gondolkozom azon, hogy egy dragabb huto pasta mennyit szamitana ,
ill menyire kockazatos a folyekony fem (Nem Alu a venti alja).

Ha jol emlekszem a hutes szabalyzas csendes-re volt kerve, nem hidegre.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Igen, lehet fokozni (csökkenteni a hőmérsékletet), ha az ember teli pakolja a házat ventikkel, hidegebb levegőt keringet. Rengeteg fajta pasztát kipróbáltam. Túl nagy difi nincs, a drágább tényleg jobb. Ha bevetünk mindent praktikát, akkor le lehet faragni 10-15 fokot, de kérdés, hogy megéri-e? (Alacsonyabb értékek magasabb zajjal, klímával, költségekkel)

Elkölt az ember egy százezer forintot rá, hogy elmondhassa egy fórumban, hogy neki nem 80, hanem csak 70 fokos a procija. Megéri? Biztos van, akinek igen.

Egyébként meg: a 70-80-90 fokos processzor már 15-20 éve is létezett, csak a nem-olyan-távoli múltban rá lett sütve a konkurenciára és külön ki lett emelve mintha valami halálos vétek lenne.

De figyelembe véve, 6/12 magot/szálat 4Ghz-en tartani folyamatosan nem olyan rossz teljesítmény. Nem emlékszem olyan közép-felső kategóriás Intel generációra mióta Core i-vel kezdődik a nevük, ami tartósan tudta volna tartani akárcsak a base frekit is teljes terhelésen. (Hűtés és melegedés ide-vagy-oda.) A folyamatos throttling-olás, hullámzó órajel inkább jellemző.

Ne sertegesd a procimat. Ez 12/24 mag/szal ;-)

Az intel desktop CPU lemet -base -re, de azert ala nem megy normalis hutesnel.

Intel notebook nem birja tartani, meg legjobbak sem,
kulso hutes rasetegites nelkul IMHO.

95 Cdeg CPU ho magaban nem aggaszt,
de ha 66Cdeg -re melegiti a kozeli kondezantorokat,  az nem hosszabitja meg az
eletartamukat.

szerk:
https://www.gigabyte.com/microsite/111/tech_070112_ud_whyusesolid.htm

Erdekes itt 65 Cdeg -nel kezdoik a tablazat,
lehet nem is vagyok bajban ..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Köszi a táblázatot, ezt még (vagy hasonlót) nem láttam.

Régen, több mint tíz éve beszélgettem egy akkori kollégával aki - ha még jól emlékszem - a vezérlését tervezte egy gépsornak. Ő nekem anno 85+ fokot emlegetett, hogy ott üzemi hőmérsékletre ennyivel számolnak. (Ha az emlékezetem nem csal.) Valamint, hogy a gyártás optimalizáló és kezelő pc a gépsoron is ezen a hőmérsékleten fog üzemelni. Akkor még sima kondik voltak a lapokon, púposodtak rendesen, de házilag javították, cserélték őket.(A pc-knek 2-3 évente befigyelt egy lerohadás. Igaz az sem ipari cucc volt...) Most ezzel azt akarom mondani, hogy nem langymeleg 30 fokra tervezik legtöbbször az elektromos eszközöket. Tudják, hogy melegedni fog, bírnia kell.

Most főképpen asztali munkaállomásokkal szoktak a kollégák számoltatni. Van, hogy 2-3 napig fut egy-egy feldolgozás. Konkrét infó, hogy egy ilyen egyszerű, olcsó házas gépben a sima 7700-as 3,3Ghz-el indít, másnapra már "elfárad", leesik 2,9-re. (Ez volt tavaly nyáron, amikor meleg volt.) Szereltem bele két 12cm-es ventit, úgy végig tartja a 3,3-at. Valamint lemérték, hogy ennek arányosan hamarabb is végez.

A laptopokról meg ne is beszéljünk, az egy erősen marketing sújtotta övezet.

Ujabb sensore verzio mutatja a feszultseget es az aramot is.

10temp-pci-00c3
Adapter: PCI adapter
Vcore:        +1.26 V  
Vsoc:         +1.07 V  
Tdie:         +84.5°C  
Tctl:         +84.5°C  
Tccd1:        +84.8°C  
Tccd2:        +74.0°C  
Icore:       +95.00 A  
Isoc:        +11.50 A  

95A*1.26V+11.5A*1.07V ~ 132W on megy,
ha jol tippelem mi a keplet. (Auto tuningot nem tiltottam, nem annyira meglepo..)

cserltem pasztat  (nem volt baja az elozonek IMHO, jol volt rajta),
kicsit mintha  nagyobb lett volna a freq ~+30 mhz   egy idejig
most nem latszik jobnak.

A vicc kedvert majd egyszer kiprobalom, mi van ha fan -t maximumra veszem.

Szerk:
Tccd2 es Tccd1 kozotti kulombseg gyanus ..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( hokuszpk | 2020. 04. 14., k – 17:12 )

mathlabot hakkolni kell, hogy hasznalja az AVX -et, mert Intel forditoval van forditva, es ha nem Intel procit talal, akkor valami oldschool kodutat hasznal.

https://www.neowin.net/news/matlab-codepath-tweak-massively-boosts-amd-…

Hackintost nemtom, az egyszalu teljesitmenyen lehet vitatkozni, annyi biztos, nem veletlen erolteti az Intel az uj szeriat is 5Ghz fole, fogyaszt amennyit.

https://wccftech.com/intel-core-i9-10900f-10-core-comet-lake-desktop-cp…

Atlagfogyit igazabol meregetni kellene, nekem az 1700 ugy stock kb. tartotta a cpura megadott 65W -t, azota nem foglalkoztam ezzel.  Ha megkergeted, akkor azzal ugyanugy kiiktatod a power limitet, mint az Intelnel.

A melegedes megint egy erdekes kerdes, mert pillanatok alatt meg bir szaladni foleg a 7nm -es procik, ezt azzal magyarazza mindenki, hogy kicsi a lapka hoatado felulete, lehet benne valami.

HUP te Zsiga !

Ez meg is oldódott mára. Van még más alkalmazás ami Intel optimalizált? 

Eddig csak a Matlab-nál olvastam erről, persze erre szükségem van, így erről hallok híreket inkább. Ha később más szoftverre lenne szükségem bele lehet még futni hasonlókba? CAD szoftverek között van például Intel optimalizált? 

( ncc1701 | 2020. 04. 14., k – 18:59 )

Már 2-3 éve amd cpu éve van. Jóreggelt. De a 3000-es széria óta csak az elvakult kékek vesznek intelt. :)

Azért a Core architektúra jegelte egy időre a versenyt, de a Ryzen ismét élre emelte az AMD-t. Aztán meglátjuk, hogy mit tartogat a Zen 3 és a Zen 4.
Ezzel együtt az is nagy kérdés lesz, hogy az Intel új architektúrája, a Tiger Lake illetve Sapphire Rapids architektúrája jövőre tényleges versenyre hívás lesz, vagy a Zen-ek mellett csak kényszermosolyra lesz elég.

Az intel nagyon sokáig ült a babérjain konkurencia nélkül. Meg is látszik rajta :)

Amióta lemaradt az AMD, ellustult. Meglátjuk, hogy most jut-e valamire? Mindenesetre őket is csak a "lendület" tartja életben, mint a M$-ot, bár utóbbinak van pár sikeres terméke is újabban. Inteltől milyen innováció volt az utóbbi egy évtizedben? Amibe belefogtak, buktak rajta. Kb. 15 éve erőltetik mobil szegmensben az x86-ot, és buknak vele súlyosan. ARM részt réges-rég eladták, pár éve megváltak a wireless részlegtől is, ott is lemaradtak.

Az Amazon és Google szolgáltatásai mindenben jobbak és megbíztatóbbak. Az Officeban van jelentős előnye a Microsoftnak.

Illetve a .NET Core -ban lenne potenciál a mindenkit perelek Oracle Java miatt. Csak kár, hogy továbbra sincs platformfüggetlen gui mint a Swing javaban. Maradt a win-only wpf és ezért továbbra sem lehet Java alternatíva számtalan helyen.

Mert nem realtime chateleshez kell, hanem olyasmire, mint a Teams/Slack. Azt tudom, hogy elvileg lehet, sot, a domainben engedelyezve is van mar a guest userek meghivasa, de nem megy. A support sem tudja, miert. Szoval en arnyalnam a kepet, valamiben jobb a Google, valamiben rosszabb. :)

A Slack csak másként formázott UI. Ugyanúgy jó a Hangouts nem realtime chatelésre is. Ugyanúgy csinálhatsz témánként szobákat amikbe utólag is megtalálják a tagok az oda küldött infókat. Nem a Google mentegetése miatt írom, de tényleg nem akadály ez hangoutson.

Viszont van egy ilyen funkció hivatalosan Google Chaten, szóval ha nem működik az nincs rendben. Látatlanban abból lehet esetleg gond, hogy szinte mindenki Google accountba bejelentkezve használja a böngészőt. Ha az adott Google usert nem hívod meg de be van jelentkezve az bekavarhat. Próbálták privát módú böngészőből is a linket? 

Szolgáltatások alatt ennél nagyobb jelentőségű dolgokra gondoltam. De valóban nem szabad lenézni egy chat szolgáltatást sem. Kevés erőforrást eszik, az ilyenek hatékonyan hozzák a pénzt. 

Nem a Google mentegetése miatt írom, de tényleg nem akadály ez hangoutson.

Megnezem majd, ismerosnek segitek, nem tudom, mennyire akarja a consumer Hangouts-szal keverni a dolgot.

Ha az adott Google usert nem hívod meg de be van jelentkezve az bekavarhat. Próbálták privát módú böngészőből is a linket? 

Nem, nincs link, beirod az email cimet oda, ahol meg lehet hivni az embereket, de nincs tovabb, szurke az Add gomb.

Amugy nincs baj a G Suite-os cuccokkal, tenyleg jo, de az szerintem nagyon meredek allitas, hogy mindenben jobb, mint az MS-fele alternativak. (Vagy akar Google Cloud vs Azure.) Valmiben jobb, valamiben nem. :)

Szerintem a C# picit jobb nyelv mint a Java. A VS Code pedig jó fejlesztői eszköz, bár szvsz a JetBrains cuccok még mindig jobbak. Mivel később jött és copyzta a Javat, ki tudtak kerülni pár zsákutcát és másodjára tervezve sok minden letisztultabb. Viszont nem volt több platformú mint a Java, ezért így sem volt esélye megszorítani a királyságát. Ballmer alatt szerintem arra gyúrtak a Microsoftnál, hogy Windows legyen mindenütt és akkor már nem is fontos a multiplatformúság. A Code most ezt megváltoztatja a jó irányba. Ezért is érthetetlen számomra miért maradt a Windowsonly wpf? 

Kotlinnal még nincsenek tapasztalataim. Az mint a harmadjára újragondolt Java lehet mindegyiknél jobb. Az a java platform mellett tette le a garast. 

Plusz ugye az amd külön vette a proci magokat, amit az aktuális legkissebb csíkszélességen gyártat, a memória vezérlő, meg a sallangok maradtak nagyobbon. Ezeket összelegózza, és sokkal jobb a kihozatal, mert nem egy bazi nagy komplett, hibátlan csipet kell legyártani a drága technológiával. Azaz olcsóbban tudnak gyártani.

És ugye az intel az utóbbi években nem volt rákényszerítve semmiféle fejlesztésre, ezért az egyes proci cserék már ilyen 5%-on belül gyorsultak, azaz kb 4-5 családot is ugorhatott az ember, szinte érdemi nyereség nélkül. Ez kissé visszaütött nekik most.

az latszik, hogy a gyartastechnologia elony, de nem mindenkeppen. Az AMD is csinalt 5 GHZ -s cput, de sebessegben megsem volt a korabeli csucs Intelek szintjen. Mig most az Intelnek a 14nm procikkal ugyan elszallt a fogyasztasa, de a sebessege azert megvan.

VGA peldat is lehet hozni, az NV 12nm -en nyomja a Turingot, megis gyorsabbak, mint a 7nm -es Navik.

HUP te Zsiga !

Sajnos nem csak az Intel processzoroknál, de bármely bonyolultabb hardware vagy software esetén így van. Tekinthetünk rá, mint természeti törvényre is. Hasonlóak a bugok a hőmérsékletre, lehet csökkenteni, de egy érték alá nem megy. Minél közelebb vagy az abszolút nullához annál macerásabb a tovább hűtés. 

Nem indokolt itt egykutyázni. AMD sem bug-mentes de korán sincs náluk ennyi baki mint az Intelnél. Az már nevetséges, hogy veszel drágán egy Intel cpu-t és szinte biztosan komoly 10%-okkal fog csökkenni a teljesítménye a hibák javítgatása miatt. 

Ezt valahol az Intel is érzi, mert külön fizettek egy kamu-kutatócégnek, hogy lejárassák az AMD-t. De csúnyán beégtek vele:

https://hup.hu/index.php/node/158411

Jelfeldolgozó és méréstechnikai beágyazott hardverként igen gyakran használom az ARM lapkákat. Szerencsére általában nincs direktben külső szolgáltatása, inkább csak az adott cég hálózatából van ezekhez kapcsolat.
Viszont egy-egy workaround ezeknél is lassulást okozhat.

"AMD sem bug-mentes de korán sincs náluk ennyi baki mint az Intelnél."

Nem védeni akarom az intelt, de mindenki vígan használta és együtt élt a hibákkal generációkon át, amíg ki nem derültek. Az amd-nél sem azt tudod, hogy nincs hiba (nem tudhatod), csak azt tudod, hogy jelenleg _ismert_ hiba nincsen (vagy tovább megyek, ismert és _publikált_ hiba nincsen). 
Ez nyilván az intelen és a jelenlegi megítélésén nem segít, de az belátható, hogy mindegyik elég bonyolult ahhoz, hogy feltételezzük, hogy előfordulhatnak bennük hibák. Pont ahogy hibátlan szoftver sincs, legfeljebb pont nem botlasz bele.

 

Az újabb gyártástechnológiák már messze nem hozzák azokat a skálázódásokat, mint korábban.

Emellett pl. az AMD-nál is a proci jelentős részét kitevő I/O rész továbbra is 12/14 nm-en gyártódik, mert kisebb csíkszélességgel nem tudják, olyan alacsony lenne az IO feszültség.

Az RPi hasonló okok miatt állt meg 28 nm-en, ha jól emlékszem, mert ott még tudtak 3.3 V-os IO-kat csinálni, alatta nem.

Az új technológiák előnye, hogy kisebb die-ra fér ugyanannyi tranzisztor, de nagy áttöréseket szerintem már nem lehet várni.

"Emellett pl. az AMD-nál is a proci jelentős részét kitevő I/O rész továbbra is 12/14 nm-en gyártódik, mert kisebb csíkszélességgel nem tudják, olyan alacsony lenne az IO feszültség."

Ha így csinálják az egy jó módszer, mert nem az I/O-tól lesz gyors egy processzor, ha amihez ott kapcsolódik úgyis sebességben limitált. 

Esetleg a dram-ot lehetne még a processzorral egy lapkára költöztetni, az javítana a teljesítmény mutatókon, nem?

Ez egy nagyonis ügyes húzás volt, különösen az egyre több mag esetében.

Bár nem új a gondolat, a Pentium Pro-nál az L2 cache-t tették egy tokba a CPU-val.

A DRAM-t embedded rendszerekben szintén szokták beleintegrálni a prociba (egy Microchip(Atmel) processzort legalábbis tudok, ahol ezt csinálják), de desktopnál még nem divat egyelőre. Gondolom azért belül bondolgatni nem olcsó, de aztán ki tudja?

Itt vannak amúgy képek is:

https://en.wikipedia.org/wiki/Zen_2

( end | 2020. 04. 15., sze – 09:00 )

Szerkesztve: 2020. 04. 15., sze – 09:05

Én úgy látom, ez a "nanométer-háború" nem szolgálja a megbízhatóság növelését, a termék tartósságát. Azaz a fejlesztések itt sem a felhasználás érdekében történnek. A hőtermelés egyre kisebb felületen történő átadása, ismét csak nagyobb hűtőfelületeket kíván. A processzort nagyobb mértékben terhelve ugrásszerűen növekszik a hőtermelés. (Valaki itt jó hűtés mellett is 70 celsius fokot is tapasztalt a tartós terhelésnél. (Ryzen)) - Megmondom őszintén én már pánikolok, amikor 50 fok fölé emelkedik egy gépnél a processzor legmagasabb hőmérséklete. Néhány atomnyi vastagságú szigetelő rétegek esetén a "70" nem tűnik igazán fejlődésnek. (Mivel 50-70 mikron jóval korábban alkalmazott technológiánál sem ment e fölé rendes hűtés mellett a maghőmérséklet.) - Én szeretem a 10 évig is használható gépeket, és nem szeretem, utálom a kidobások miatt a Földön mindenütt képződő szeméthegyeket. Megint csak azt látom, a haszon, a harács az egyedüli mozgatója ennek az erőltetett technológia-váltásoknak. Talán egyedüli értelme lenne, a magok számának egy CPU-n belüli növelési lehetősége, az ezt kihasználni tudó szoftverek híján semmi sem indokolja ezt a nanométer-váltás-tempót. 

Van negatív elmozdulás a CPU élettartamban? 

A sokat szidott ME egyik előnye, hogy gyorsan visszahúzza a cpu órajelet ha hőmérséklet limiten túlra nő. 

Közben a mobil CPU-k amik ott SoC részei elég jó teljesítményeket tudnak, miközben szóba sem jön az aktív hűtés. Mobiloknál egyértelműen a sok cpu mag mellett tették le a garast. A gyenge és erős magok kombinálása is jó gondolatnak bizonyult. Aksi időben sokkal előrébb járnak a tabletek mint a notebookok. 

Én még nem találkoztam olyan processzorral, amit széthajtottak volna. Alaplappal igen, ami nem bírta a tartós 90-100 fokot, de ez is, kb azóta amióta kizárólag szilárd elektrolitos kondik vannak a lapokon, sem jellemző. (Elektronikában nálam járatosabbak lehet más véleménnyel vannak, nekem viszont ez a tapasztalatom.)

Volt a praxisomban ipari felhasználásra befogott nagy teljesítményű asztali pc, bezárva egy pormentes (és "légmentes") szekrénybe (minden tiltakozásom és ellenvetésem ellenére), de eleddig rácáfoltak a jóslataimra, mert tudomásom szerint még mindig hibátlanul működnek, pedig közel 90 fokban mennek, folyamatosan. 6 éve. Semmiféle extra ipari hardverre nem kell gondolni, sima PC, a legolcsóbb alaplapban egy csúcskategóriás proci, mert a gyártó ezt adta meg. (Meg volt adva, hogy Core i7, 16GB ram, úgyhogy ahol lehetett viszont spóroltak a beszerzésnél.) Anno fél évet adtam először nekik, az volt a véleményem ennyi idő alatt kinyírják őket.

Én nem tartok attól, hogy 70 fok megöl bármit is, ami processzor. A 105 fok feletti hőmérséklet is inkább a stabil működést veszélyezteti, mint a épségét.

én már pánikolok, amikor 50 fok fölé emelkedik egy gépnél a processzor legmagasabb hőmérséklete

Nekem nagyon ritkán megy 50 fok alá a CPU hőmérséklete, pedig semmi intenzív nem fut rajta (Ryzen 3600x, gyári hűtővel). Most nem tudom, hogy tartós terhelésnél mennyire megy fel, de 80 sem tűnik soknak.

Amúgy a hőt nem kisebb felületen adja le, tudtommal a CPU-k felülete mm2-ben nagyon nem változott az utóbbi sok évben, ahogy csökkent a csíkszelesség úgy növelték a tranzisztorok számat, s a fogyasztás és a leadott hőmennyiség is nagyjából változatlan maradt (azonos árkategórián belül).

Itt van egy tablzat a terulet valtozasokkal:

https://en.wikipedia.org/wiki/Transistor_count

Erdekessegkepp a 386-os 104mm2 volt, P3 coppermine 80mm2... Ingadozik fel-le az evek soran, vannak erdekes szamok :)

Azert a zen2-tol inkabb ne hagyd ki az IO die-t mert a wiki szerint az 125mm2, es fel chiplet-nyi tranzisztort tartalmaz. Igy mar nem annyira nagy a valtozas.

A wikin nem kaptam hasonlo kategoriaban szamokat, de osszehasonlitaskepp (az IO-t is beleszamolva ott ahol kulon van): Ryzen 5 1600 -> Ryzen 7 3700X : 213mm2 ->199mm2

:) mutass egyet kérlek! A hivatalos adtat szerint 95° a maximum, ott kezd el lassítani, hogy ne melegedjen tovább.  

https://www.amd.com/en/products/cpu/amd-ryzen-7-3800x

Egyébként az előző notimban "stabil" 105° volt a cpu teljes terhelésen. Az egy intel i5 volt a lenovo T sorozatból. A mostani pedig 100°-ra. (https://ark.intel.com/content/www/us/en/ark/products/124969/intel-core-i5-8350u-processor-6m-cache-up-to-3-60-ghz.html)

Az asztali procik is, amiket néztem mind 100°-ra. Tehát nem különösebben aggódom a 85-ön egy óra prime után...

Mondjuk a notebook processzorok hőmérsékletét és throttling-olását ne vegyük standardnak, az valami extrém divathóborton alapuló agyfasz ami ott megy 5-6 éve. Az apple is beszopta a csilivili vadiúj i9-ekkel, mert 5mm vékonyra kell azt a qrva gépet préselni, nehogy mondjuk 10mm "vastag" legyen. Cserébe a fizikát nem lehet meghágni, és nem lesz mód a hő elvezetésére. A behazudott teljesítményt ígty kemény 3 másodpercig is képes tartani, mielőtt visszavesz.

Ez igaz, csak a max. hőmérsékletre írtam. Viszont elnézést kérek a fenti hamis info-kért, hittem a grafikus megjelenítésnek hirtelen ránézve (illetve nem tudom milyen sensor értékeit mutatja vagy hogyan kalkulál). 

Szóval most kicsit jobban megnézve: 5 perce megy a prime és 59° a CPUTIN (már ha ezt kell néznem...) Szóval nem biztos, hogy annyi az annyi. Csodálkoztam is, de azt hittem, hogy a "silent" fan profil kever be.

Úgyhogy sorry.

AM4 -be ha bevagsz egy 105 W CPU -t az joval melegebb lesz full loadon, mintha csak egy 65W -teszel bele.

A hoatvitel az cpu haz es huto kozott a gond.
Ilyen `kicsi` CPU -nal , a `legjobb` leg hutesek eleri a limitet.
Ugy ertem nem az lesz a gond, hogy a bordarol, hogy jut ki a kulso terbe, hanem az hogy, hogy jut ki CPU kalitkabol.

Orultebbek szoktak olyan dolgokat muvelni, hogy CPU kulso fem hazat leveszik es specialisan rakjak
ra hutojuket.

tr4 , sp3, LGA 3647,FCBGA5903 hatalmas socket, par szaz wattos CPU -k is lehetnek.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

hat nemtom, kb. 2.5 eve vettem az 1700 -as Ryzent, az elejen meghajtottam, mint azt a bizonyos varrogepet, forro is volt, sot tuningkiserletek kozben sikerult a hovedelemmel lekapcsoltatni is; de egyelore nem mutatja a degradalodas jeleit, elketyeg 3.7 -en a 8 mag , a teljesitmenye meg perpill kb. mindenre is eleg. 10 evet lehet nem huz ki, de ha még1x ugyanennyit, az teljesen jo.

HUP te Zsiga !

( locsemege v | 2020. 04. 15., sze – 14:53 )

Meddig kell főzni, hogy ehető legyen? :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( Ice | 2020. 04. 15., sze – 15:50 )

AMD Ryzen 5 1600 AF rulz!

Ennél jobb procim még nem volt.

Az ára kb. a fele volt az előző procimnak.

( naszta v | 2020. 04. 15., sze – 23:01 )

AMD Ryzen 5 3600. Atomstabil, nagyon gyors. Mondjuk ami még sokat jelent az a 32 GB, 3200 MHz-es RAM.

https://naszta.hu

A 32 giga RAM semmit se jelent, ha nem használod ki. Épp úgy nem lenne semmi gyorsabb, ha felbővítenéd 256 gigára, hacsak nem használsz ki tényleg annyit. Én, mint átlag desktop felhasználó még 16 giga RAM-ból sem szaladtam ki soha, se Windows 7-10, se bloatabb full DE Linux, se minimalista WM-es sovány Linux alatt, igaz 1080p feletti felbontást sem használok semmiből, se film, se játék, se más tartalom. A RAM mennyisége csak addig fontos, amíg a swapolást akarod elkerülni. Onnantól, hogy a rendszer nem használja a swapot, akkor se, ha van, onnantól az egyre több RAM semmit nem javít a teljesítményen. A 3200 MHz viszont fontos, főleg AMD prociknál. Ahogy általában a dual channel is. A jövőben persze ez változhat, de 32 gigával szerintem 10+ évig teljesen jó vagy átlagosabb felhasználásnál, mezei gamerkedésnél.

De ha nem használod ki, egy 3800-3900-as Ryzen sem gyorsabb. Ugyanis hiába a több cache, meg a több mag/szál, ahhoz jól skálázódó, spéci, többszálú alkalmazásokat kell használni, hogy gyorsabb is legyen. Átlag felhasználásnál még mindig az egyszálúság a jellemző, vagy ha többszálú is egy átlagosabb szoftver, akkor sem skálázódik jól. Játékok sem használnak ki maximum 4-8 szálnál többet egyelőre. A túl sok szálas, magos proci még jellemzően játékok alatt rosszabbul is teljesít, mivel a sok mag leviszi a turbóórajelet, meg többfelé töredezik a nem sokkal több TDP. Játékra egy x600-x700(X) (x=1,2,3) az ideális, az ettől nagyobb procik nem nagyon fognak több fps-t adni. Adalék: nekem 2600-as Rizsa van, azzal is meg vagyok elégedve, ezért nem is tervezem belátható időn belül 3600-ra váltani. Majd ha kipörgettek még jó pár generációt, akkor egy 4700-5700 körüli Ryzent lehet veszek később, ha még belemennek az AM4-es B450 chipsetes lapomba.

GPU-ból meg nem is vennék mást, csakis AMD-t. NV-hez Linux alatt csak a zárt driver használható, azzal meg szopós lehet a kernel/X.org/mesa-frissítés meg a Wayland. AMD kártyákat kiválóan viszi a nyílt amdgpu kerneldriver, kevés kivétellel, amikor egy kártya még túl új. Intel IGP-nek is megfelelő ugyan a linuxos supportja, azoknak csak a nyers ereje, teljesítménye gyengusz, de nagyon.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

+1

Nekem 8Gb RAM van a fejlesztői laptopomban, és eddig még sosem volt kevés úgy sem, hogy 1-1 dolgot virtuális Windowsban csinálok. Kivéve egyszer, mikor egy stressz teszt valami hiba miatt kernel objektumokat leakelt :-) (Ez nyilván nem jelenti azt, hogy speciális vagy elcseszett rendszerekhez ne kellene több.) Sima netezős gépünkben meg 4Gb van, és ott sem éreztem szűk keresztmetszetet.

Sok magos sebességgel pedig az van, hogy a sokszálú programok jeletős része is tele van szinkronizációval a szálak között és emiatt folyton egymásra várnak, illetve nagyon sok a contextusváltás. Ilyeneket mértünk - meg lehet találni cikkeket a neten -, és a kontextusváltások nagyon sokat elvisznek a teljesítményből. Illetve az ütemező feleslegesen dobálja a taszkokat a magok között, és ez is eléggé költséges.

A gamer PC-men az összes mag ütemezőjét performance-ra állítom játékokhoz, és úgy kellemesen működik eddig. Viszont valami komolyabb hűtő is kell ehhez, hogy működjön, máskülönben nem tudnak egyszerre fullon járni. Sőt el tudom képzelni, hogy így sem teljesen, de nem mértem mivel eddig nem akadozott amikkel játszottam. De el tudom képzelni, hogy játékok esetén jobban járnánk, ha a magok felét teljesen letiltjuk, a többit viszont fullon járatjuk - ha egyáltalán lehet ilyet.

Én itthon is és a céges gépen is fejlesztek, C++-ban, viszonylag nagyobb projekteket. Bent a cégben egy 2 CPU-s Intel szörny van, nvidia workstation VGA-val, itthon a fenti vas, alap AMD WS VGA-val (2xUHD kijelző miatt). Az árcédula kb. 4-szeres a céges javára, teljesítményben meg alig több és nekem a RAM tűnik ma a szűk keresztmetszetnek. (Előtte én is 8GB-tal toltam, sose volt elég.)

https://naszta.hu

( bimi3 | 2020. 04. 16., cs – 10:17 )

AMD Ryzen 5 2400G van nekem, az integrált GPU miatt választottam. 90 %-ban Linux alatt megy stabilan, de Windows alatt is tökéletes nekem.

Egyetlen gond volt, hogy Totem alatt nem érzékelte a kattintást a gombokon, de ez megoldotta:

echo "allow_rgb10_configs=false" >> /etc/environment

( Raynes v | 2020. 04. 16., cs – 16:13 )

2017 óta, mióta kijött a Gen1 Ryzen, majd utána rá, ahogy felütötték a fejüket az inteles sebezhetőségek, azóta egyfolytában az AMD proci éve van, és min. 5 évig lesz is, ha nem tovább.

Hackintoshra léteznek hackek, hogy menjen AMD procin, mutatták az egyik Linus Tech Tip videóban. Viszont Hackintoshozni Mac-et kell venni, nem mezei PC-t.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Jó, de a te eseted speciális. Arról nem az AMD meg az AMD proci éve tehet, hogy te egy olyan zárt és korlátozott ökoszisztémára építő zárt megoldás mellett döntesz, ami csak Intelen támogatott. Egyébként nincs is ezzel semmi baj. Az Intel hátrányba kerül, ár/érték arányban rosszabb, de azért még nem értük el azt a szintet, mikor a prociai annyira elavultak, hogy semennyire nem versenyképesek. Szóval vehető az Intel is, csak nem olyan jó vétel már mostanában, így aki általános PC/gaming, stb. feladatra veszi, ők már nem mennek rá az Intelre, ahogy korábban.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Elég régóta Hackintosh-olok már, de egyre kevésbé érzem, hogy én ebbe fektetnék...annak ellenére, hogy a Clover meg az Opencore egyre natívszerűbb élményt nyújt, egyre több vele a szívás...főleg ha teljesítmény is cél (felteszem cél, a Matlab miatt). A Hackintosh-oknak néhány év múlva amúgy is valószínűleg vége a T2 chip miatt, illetve ha tényleg áttér idővel ARM-re az Apple, az meg plussz egy döfés.

Akkor ez valami olyan bigyó, amivel bezárják az eszközt, s kiveszik a felhasználó kezéből azt a valamit, amiért a felhasználó még fizetett is. Biztos, hogy sohasem veszek Apple terméket, legalább is ezek alapján ez körvonalazódik bennem.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez mind OK de még a jövő és nem a közeli jövő. Évekig lehet még T2 nélküli és nem hivatalosan kompatibilis elemekből összerakott PC-re is MacOS-t telepíteni.

A jövő-biztosabb, sőt már ma is jobb megoldás a Hackintosh-KVM https://www.youtube.com/watch?v=ATnpEOo3GJA

Biztos vagy te ebben? Az Apple 2018-ban egyik verzióról a másikra dobta az nVidia supportot a Mac OS Mojave rendszerében. Azóta sincs nVidia driver Mac OS alá, nem kevés 1080Ti-t külső GPU-ként használó bosszúságára. Hogy ez most az Apple vagy az nVidia miatt történt, az szerintem a user szemszögéből lényegtelen. Gyakorlatilag a néhány hónappal azelőtt összerakott buildem egyik pillanatról a másikra sz*rt se ért onnantól a MacOS szempontjából. Te így szívesen tolnál bele valamibe fél milliót?

Jelenleg az Apple oldaláról a legrégebbi gép amit a MacOS Catalina legfrissebb verziója támogat 2012-es. Az cég 2018 óta minden új Mac-et T2 chipel szerel. 8 év támogatás van visszamenőleg a Catalina-ra (2012-2020) jelenleg. Azaz 6 év múlva a legutolsó T2 chip nélküli modell is kifut a supportból. Ha ehhez még hozzácsapjuk, hogy a 2021-es év valószínűleg felforgatja az Apple-t az ARM-el, plusz lépnek még pár olyan csodásat mint az nVidia-s történet, akkor hirtelen a 6 évből 4 lesz, és azon belül elég hamar eljöhet az idő, hogy gyakorlatilag értelmetlen lesz ez az egész.

Eredeti Apple Macintoshod van vagy PC és Hacintosh? 

Hallottam a problémáról bár nem érintett ez az Apple - Nvidia fiaskó. A harmadik generációban volt utoljára hivatalos Mac GeForce grafikával, 2014 ha jól tudom. Fel lehet haxolni hivatalos Apple Mac-re még a drivert de valóban nem erről kellene szólni az Apple felhasználói élménynek. 

A legújabb MacOS támogatás hiánya egyébként még nem jelenti a support végét automatikusan, a korábbi MacOS egy ideig még használható. 2018-ban forgalmazott Mac Pro -ban T2 még nem volt, szóval 2023-ig akkor is lennie kell új MacOS-nek ha Nvidia ügyhöz hasonlóan nem tartja mindenben a szavát az Apple, a 2018-as T2 nélküli Mac Pro miatt. Lassabban jönnek ki a Mac Pro modellek, de elég drágák ahhoz, hogy ne szarhassa le az Apple azokat a vásárlóit, akik az utolsó évben vásárolnak egy akkor még aktuális modellt. Legrosszabb esetben 2023-ban megjelenő utolsó friss MacOS is támogatása megmarad még pár évig. Szóval szerintem több év ez még, de valóban nem tart örökké. Azaz pesszimista esetben sem 4 éve szerintem hanem 6. 

A Hacintosh-KVM koncepcióban pedig még lehet potenciál olyan trükkök bevetésére, amikre eddig nem volt szükség. 

 Gyakorlatilag a néhány hónappal azelőtt összerakott buildem egyik pillanatról a másikra sz*rt se ért onnantól a MacOS szempontjából.

 

En is portoltam a mobilalkalmazasomat iosre. Az egesz vegen be kellett latnom, hogy a programozas resze a melo kb. 20%-a volt. Hivtak indiabol, meg meg vagy 3* az applesok, az atutalassal is gond volt, sztem mindenbe belefutottam amibe bele lehetett.

 

Soha tobbet. Elengedtem ezt a vonalat. Ehhez egy team kell, amibol az egyik tag az apple vilagba szuletett bele es ott nott fel.

 

Termeszetesen anyagilag se igen erte meg, a programozason kivuli reszt nemigen szamoltam bele.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( cspguy v | 2020. 04. 16., cs – 18:26 )

Szerkesztve: 2020. 04. 16., cs – 18:26

AMD elhúzott, az Intel meg csak pislog.

Sok cpu mag emberi fogyasztással, kis helyen. Ryzen 9 és Threadripper, illetve a az Epyc vonal, mind kisfogyasztású vonalon: (https://www.asrockrack.com/general/productdetail.asp?Model=EPYC3251D4I-…), mind komoly szerver vonalon bejött.

Ki is az, aki TCO-t figyelve megveszi ugyanarra a feladatra a több mint 2x annyiba kerülő intelt? Senki sem a maga ellensége zsebügyileg.

PL noti proci, amd, ez sem kaksival gurigázik. 8 mag.

 

AMD Ryzen™ 9 4900H

Specifications

# of CPU Cores 8

# of Threads 16

# of GPU Cores 8

Base Clock 3.3GHz

Max Boost Clock Up to 4.4GHz

Total L2 Cache 4MB

Total L3 Cache 8MB

Unlocked No

CMOS TSMC 7nm FinFET

Package FP6

PCI Express® Version PCIe® 3.0

Default TDP / TDP 35-54W

Max Temps 105°C

( zsolt__ | 2020. 04. 17., p – 11:26 )

Szerkesztve: 2020. 04. 17., p – 11:27

Sziasztok,

Tud valaki arról hogy a KVM illetve Virtualbox mennyire támogatott Ryzen-el (persze hw-es gyorsítással!), illetve milyen alaplapot ajánlotok virtualizációhoz - (Debian/Ubuntu támogatott legyen) ?

Ki akarom használni természetesen az összes szálat! :) 

VMWare-el mi a helyzet ?   ECC memórákkal mi a helyzet, melyik alaplap támogatja ?

Itt nem dicsérték agyon: https://www.servethehome.com/amd-ryzen-working-with-vmware-esxi-6-5/

Vagy csak gamerekre gondolnak ?

Köszi előre is a válaszokat!

Én próbáltam ECC-s rendszert összerakni Ryzen-el, de még unbuffered ECC ramot nem tudtam venni. Elég ritka.

Én ezt az alaplapot találtam, ami elvileg kezel ECC-s ramot: ASUS PRIME B350-PLUS. És olvastam hogy már valakinek működött vele.

És még a hivatalos listán is szerepel EGY darab ECC-s modul :D
https://dlcdnets.asus.com/pub/ASUS/mb/SocketAM4/PRIME_B350-PLUS/PRIME-B…

Prociból szerintem az összes Ryzen tudja.

Ubuntu alatt támogatott a hardware-es virtualizáció KVM vagy Virtualbox-al ezen amit említttél:

(ASUS PRIME B450M-A) 2600X processzorral működik 4x KINGSTON 16GB 2666MHz DDR4 ECC KSM26ED8/16ME modullal.

Vagy esetleg valami driver probléma van-e ?

Elsődleges desktop gépként akarom majd használni, virtualizációra és programozásra.

Minden szálat ki lehet használni nem csak magonként 1 szálat ?

Melegedés és fogyasztás mennyire durva ?

Gondolom az biztos hogy a hűtőn nem érdemes spórolni ? :)

KVM és VirtualBox is támogatott kéne legyen:
# dmesg|grep -i kvm
[   94.512035] kvm: Nested Virtualization enabled
[   94.512041] kvm: Nested Paging enabled

Még ECC RAM előtt használtam VirtualBoxot rajta, úgy emlékszem nem volt gond a hardveres gyorsítással.

Driver problémával nem találkoztam, minden szálat használ. Az említett célokra kitűnő. :)

Most idleban 31.9°C, indítottam rajta egy 12 szálú fordítást és 61.1°C-ra ugrott. Fogyasztás tekintetében még esetleg utána tudok járni, de hirtelen annyit tudok mondani, hogy idle->max terhelés során a 700W-ra értékelt szünetmentes terhelése 33%-ról 47%-ra ugrik, és tippre 10-15%-ot kéne fogyasszon alapból a többi eszközből kiindulva.

Korábban amíg 2400G volt benne addig az asztali 2600X gyári hűtőjét használta, amióta az asztaliba került 3800X azóta az azzal jött gyárit használja 2600X-el.

Fordítási idők:

2400G:
     Wed Dec 25 15:29:05 2019 >>> www-client/chromium-80.0.3987.16
       merge time: 5 hours, 24 minutes and 16 seconds.
     Tue Dec 24 21:47:36 2019 >>> www-client/firefox-71.0-r1
       merge time: 1 hour, 49 minutes and 57 seconds.
     Tue Dec 24 06:05:14 2019 >>> sys-devel/gcc-9.2.0-r3
       merge time: 1 hour, 22 minutes and 32 seconds.
2600X:
     Fri Apr 17 12:48:35 2020 >>> www-client/chromium-81.0.4044.113
       merge time: 2 hours, 50 minutes and 1 second.
     Tue Apr  7 11:02:09 2020 >>> www-client/firefox-75.0
       merge time: 1 hour, 6 minutes and 38 seconds.
     Sun Apr  5 11:38:53 2020 >>> sys-devel/gcc-9.3.0
       merge time: 51 minutes and 18 seconds.
3800X:
     Thu Mar 19 11:12:47 2020 >>> www-client/chromium-81.0.4044.69
       merge time: 1 hour, 33 minutes and 7 seconds.
     Thu Mar 12 10:18:17 2020 >>> www-client/firefox-74.0-r1
       merge time: 42 minutes and 52 seconds.
     Fri Mar 13 21:45:50 2020 >>> sys-devel/gcc-9.3.0
       merge time: 32 minutes and 47 seconds.
     Fri Mar 20 08:39:10 2020 >>> app-office/libreoffice-6.4.2.2
       merge time: 26 minutes and 50 seconds.
i5-7600K:
     Fri Apr 17 15:45:10 2020 >>> www-client/chromium-81.0.4044.113
       merge time: 4 hours, 27 minutes and 34 seconds.
     Tue Apr  7 11:45:37 2020 >>> www-client/firefox-75.0
       merge time: 1 hour, 48 minutes and 12 seconds.
     Sun Apr  5 11:52:04 2020 >>> sys-devel/gcc-9.3.0
       merge time: 1 hour, 25 minutes and 28 seconds.
     Fri Apr 17 11:17:36 2020 >>> app-office/libreoffice-6.4.3.2
       merge time: 1 hour, 19 minutes and 1 second.
Core 2 Duo T5870:
     Tue Jan 21 20:20:49 2020 >>> www-client/chromium-79.0.3945.130
       merge time: 1 day, 12 hours, 41 minutes and 26 seconds.
     Tue Apr  7 22:16:34 2020 >>> www-client/firefox-75.0
       merge time: 5 hours, 2 minutes and 19 seconds.
     Tue Apr  7 13:49:34 2020 >>> sys-devel/gcc-9.3.0
       merge time: 3 hours, 54 minutes and 1 second.
     Tue Mar 24 04:04:43 2020 >>> app-office/libreoffice-6.4.2.2
       merge time: 8 hours, 11 minutes and 14 seconds.

Kis érdekesség: összevetettem az itt láthatókkal: https://www.cpubenchmark.net/compare/AMD-Ryzen-5-2600X-vs-AMD-Ryzen-7-3…

2600x: cpubench: 14231
   Ch: 170p FF: 67p gcc: 51perc a fenti táblázatod szerint
14.231*170 = 2419 legyen 1,00 Ch-ra
14.231*67 = 953     legyen 1,00 FF-ra
14.232*51 = 726     legyen 1,00 gcc-re

3800x: cpubench: 23354
   Ch: 93p FF: 43p gcc: 33perc   és LO 27p
23.354*93 = 2171  ---  0,90 becslési arány a legfelső általihoz
23.354*43 = 1004  ---  1,05 becslési arány
23.354*33 = 771    ---  1,06 becslési arány
23.354*27 = 630    ---  legyen most 1.05 mert nincs előbbin számom ... amolyan "behasalás"

i5-7600k: cpubench: 6609 --> Zen előtti, ahogy jött a Zen, magszámot növeltek a 8xxx szériában. i3-8xxx = i5-7xxx
   Ch: 268p FF: 108p gcc: 85perc és LO 79p
6.609*268 = 1771 ---  0,73 becslési arány
6.609*108 = 714 ---    0.75 becslési arány
6.609*85 = 562 ---    0,77 becslési arány
6.609*79 = 522 ---    0.79 becslési arány (becsült)

T5870: cpubench 660
   Ch: 2201p FF 302p gcc: 234p és LO 491p
0.660*2201 = 1452 --- 0,60 becslési arány
0.660*302 = 199 ---     0,20 becslési arány !!!!  MIÉRT ???
0.660*234 = 154 ---     0.21 becslési arány !!!!  MIÉRT ???
0.660*491 = 324 ---     0.49 becslési arány

Saccolásnak elég jól adta a cpubenchmark.net, bár látszik hogy az erősen eltérő architektúránál az általa adott általános becslés pontossága is erősebben romlik.
Ez egyébként eredhet olyanból is, hogy a cpubenchmark.net a float-os simd számításból és több másból is rak be a pontszámoló tesztekbe, a fordítás esetére tesztelve pedig az FPU, SIMD és annak felhúzó vagy lehúzó hatása nem érvényesül.
A T5870 viszont önmagán belül is nagy szórásával kilóg a sorból, azaz Chromium, LibreOffice <----> Firefox és gcc fordítás ugyanitt arányaiban nagyon eltér a fenti arányoktól. Valami nem stimmel. Gondolok olyanra, hogy nem ugyanazt az eredményt kellett fordítani (x86_64 <--> x86_32) vagy bármi.

Tudnál a T5870 fordítás körülményeiben segíteni? Valahogy nagyon kilóg ez és főleg a 4 fordítás (Ch, LO <--> FF, gcc) szétdivergálása miatt.
 

Igen, nem volt fair odarakni azt, mert egy olyan laptopban van (Dell Vostro 1015) ami 4GB memóriát bír el, és van hogy ahhoz is swappolnia kell, hogy összelinkelje a végső binárist. A januári fordítást még HDD-n csinálta, azóta legalább SSD-t raktam bele, meg letöröltem a Chromiumot mert erre már nekem sem volt türelmem. :) Ezzel szemben a többi gépben 32-64 GB memória van, és minden ramdisken fordul.

Súlyosbító tényező, ZFS van mindegyik alatt, erre váltás után a laptop érezhetően lassabb lett, és ramdisk hiányában ezen fordítja a csomagokat is.

Ha érdekel, tudok küldeni logokat 2009-ig visszamenőleg, hogy hogyan alakultak az egyes csomagok idejei. :) Talán még 2005-ig is, ha előkaparok régi DVD mentéseket és még olvashatóak is.

Ha visszamegyek addig, mielőtt leváltottam az i3-550-et a 2400G-re:

2600x* még asztali gépként:
     Sat Dec 22 00:32:57 2018 >>> www-client/chromium-71.0.3578.98
       merge time: 58 minutes and 21 seconds.
     Tue Dec 11 09:08:49 2018 >>> www-client/firefox-64.0
       merge time: 26 minutes and 42 seconds.
     Thu Dec 27 11:18:17 2018 >>> sys-devel/gcc-8.2.0-r6
       merge time: 27 minutes and 15 seconds.
     Mon Dec  3 12:07:48 2018 >>> app-office/libreoffice-6.1.3.2
       merge time: 47 minutes and 21 seconds.

i5-7600k:
     Fri Dec  7 09:26:38 2018 >>> www-client/chromium-71.0.3578.80
       merge time: 1 hour, 19 minutes and 39 seconds.
     Tue Dec 11 09:12:08 2018 >>> www-client/firefox-64.0
       merge time: 37 minutes and 45 seconds.
     Fri Dec 28 13:39:54 2018 >>> sys-devel/gcc-8.2.0-r6
       merge time: 37 minutes and 59 seconds.
     Mon Dec  3 12:32:45 2018 >>> app-office/libreoffice-6.1.3.2
       merge time: 1 hour, 15 minutes and 16 seconds.

i3-550:
     Mon Dec 10 21:00:34 2018 >>> www-client/chromium-71.0.3578.80
       merge time: 4 hours, 33 minutes and 2 seconds.
     Tue Dec 11 13:19:24 2018 >>> www-client/firefox-64.0
       merge time: 1 hour, 56 minutes and 42 seconds.
     Sat Dec  1 18:54:54 2018 >>> sys-devel/gcc-8.2.0-r5
       merge time: 1 hour, 35 minutes and 41 seconds.
     Mon Dec 10 12:43:10 2018 >>> app-office/libreoffice-6.1.3.2
       merge time: 3 hours, 54 minutes and 2 seconds.

T5870:
     Thu Nov 22 18:49:11 2018 >>> www-client/chromium-70.0.3538.110
       merge time: 9 hours, 54 minutes and 22 seconds.
     Tue Dec 11 15:18:34 2018 >>> www-client/firefox-64.0
       merge time: 3 hours, 20 minutes and 11 seconds.
     Mon Dec  3 14:24:04 2018 >>> sys-devel/gcc-8.2.0-r5
       merge time: 3 hours, 12 minutes and 3 seconds.
     Wed Dec 12 17:08:07 2018 >>> app-office/libreoffice-6.1.3.2
       merge time: 7 hours, 58 minutes and 47 seconds.

Meg sem merem kérdezni, hogy mire kell az ECC ram?

A Vmware Workstation rendben megy. (Abban meg ment az ESXi) (Az ESXi telepítéséhez csak annyit fűznék hozzá: Én is így csinálnám, frissiben kijött desktop processzort választanék, lehetőleg még az első BIOS verziók egyikével kiadott ó'csó alaplappal. Aztán értetlenkednék felette, hogy "De b+ mér' nem megy?!" Meg a X710-DA2 mióta 40Gb-es?)

( cspguy v | 2020. 04. 17., p – 15:25 )

Szerkesztve: 2020. 04. 17., p – 15:26

A kérdés az, hogy mennyit kell a vasnak járnia.

Ha 7x24-ben megy, akkor a desktop gép nem nyerő.

Nekem egy HP T740 van beüzemelve virtualizálásra 4 core 32GB ram, 2 ssd van benne és i350 4 portos kártya. pfsense, openvas, win10, graylog, radius, unify controller, meg egyebekre.

Ha erő kell, akkor meg itt a kis szerverem a lábamnál, epyc 8 mag 128GB ECC ram, 20TB diszk, optane900p meg még pár ssd, Freenas, alatta bhyve, 2x10gbe.

ajanlhat akarmilyen jo arat az AMD, ha a laptopgyartok

- nem csinalnak a procijaval laptopot

- ha csinalnak, direkt elbasszak ilyen 1 csatornas memoriaval meg hddvel esetleg fos kijelzovel

- ha veletlenul sikerul normalis cuccot osszerakni, akkor vastagon az Intel parja fole arazzak.

 

megint zorog a haraszt, hogy van az a penz....

HUP te Zsiga !

https://www.notebookcheck.net/Lenovo-ThinkPad-E595-laptop-review-AMD-la…

 

Most ilyent veszunk a cegnel. Talan 5-ot.

Ajanlj jobbat 280-340 kozott.

Van 14" os valtozat is (E495)

Beszelj le.

 

Thinkpad T sorozata majd dupla ennyi.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A 3700u -nál az alapfogyasztás volt talán magas. A Ryzen x 4x00u szériánál korrigálták ezt a problémát + az új architektúra számítási teljesítményben is többet kínál.
https://www.cpubenchmark.net/compare/AMD-Ryzen-7-3700U-vs-AMD-Ryzen-3-4…
Előbbi Ryzen 7  utóbbi új architektúrás Ryzen 3.
Sajnos Ryzen 5 és 7 szériából a Ryzen 5 4500u és Ryzen 7 4700u, 4800u-ra nincs még benchmark. Ezeknek az év elején bemutatott prociknak a szállítása is megakadt a vírushelyzet miatt.