DDR5-ös fejlesztői gép

Fejlesztés

Sziasztok!

 

Upd: asztali gépekkel dolgozunk, notebook gépek nem játszanak.

Upd2: mivel alig drágábban jön ki a DDR5, mint a DDR4, meglátjuk mit tud. Köszönöm mindenkinek a segítségét és észrevételét.

Eddig DDR4-es gépeket vettünk számukra az egyedi kérések alapján, de már megnéznénk, hogy DDR5-ös kiépítéssel lehetne-e még jobb fejlesztői gép teljesítményt kicsikarni. Ehhez a témához nem értek, ezért beszéltem velük, hogy korábban mik voltak a szempontok.

Nálunk a CPU-Memória-Perifériák (elsősorban NVMe SSD) közötti sávszélesség a legfontosabb szempont. Elég sok komponensből álló rendszert szimulálunk és mivel a saját fejlesztéseinket debug módban használjuk fejlesztés közben, így a futtatott kód egyáltalán nincs optimalizálva (sőt tele van analízissel és metrikákkal amik kifejezetten performancia gyilkos dolgok) ezért fontosak számunkra a fentiek. Ezen felül nálunk fejlesztés közben akár percenként többször lefordul az éppen fejlesztett komponens kódja ami nagyon sok kis file olvasás/írás művelettel jár és memória igényes is és erősen igénybe veszi a fenti hw elemek közötti sávszélességet.

Ezek alapján így alakult a korábbi konfiguráció

  • Z590-es chipset, mert

“The B560 chipset offers a 32 GB/s interconnect bandwidth, but the Z590 has a 128 GB/s interconnect bandwidth owing to its full PCIe 4.0 capability. This is because PCIe 4.0 needs two CPU channels per port, as compared to one lane in PCIe 3.0, which means that when combined with a Z590 motherboard, compatible devices (like NVMe SSDs) will give better performance with Intel 11th Gen processor.”

  • DDR4 3200MHz
  • Samsung 980 Pro NVMe SSD
     

Szóval köszönöm, ha valaki tud tanácsot adni, hogy milyen chipset, milyen memóriával ad jó párosítást. Csak Intel 12,13-gen irányban keresünk.

  • 2626 megtekintés

( Petya28 v | 2023. 08. 09., sze – 14:40 )

Budget?

Az Asus ProArt szériás lapokra vetnék egy pillantást.

( csardij v | 2023. 08. 09., sze – 15:57 )

Ha a CPU-Memória-Perifériák közti sávszél számít, akkor arm-os mac? Pont ebben erős az integrált soc miatt.

Web, Domain, Tárhely

( dotnetlinux | 2023. 08. 09., sze – 16:01 )

Macbook pro-k nem veletlenul alkalmasak fejlesztesre, komplett k8s clustert tud futtatni, sok proci es ram van (tud lenni) benne. Nem csak mukodik, de valoban kenyelmes is a hasznalata. Sok evig birja, bar lehet hogy elsore magas az ára, de ha nem 10et kell egyszerre venni.

Korabban ket evtized Windows, vele parhuzamosan egyre emelkedo linux hasznalat. De aztan a cegnel, ahol dolgozom mac mellett kotottunk ki. Menedzsereknek csak mac air. 

szvsz, az inteles macbook pro régi és teljesítményben a desktop gépet nem éri el. Az armossal meg nincs kisegítve, ha emulátorokon át kell debuggolt intel binárisokat futtatni. A ram mennyisége is sokkal limitáltabb. Az asztali macnél vannak nagyobb memóriás opciók. De attól még az is lehet, hogy rossz nekik. A forrasztott apple ssd sem feltétlen előny.

Macbook pro-k nem veletlenul alkalmasak fejlesztesre, komplett k8s clustert tud futtatni, sok proci es ram van (tud lenni) benne.

Szinte bármi képes K8s cluster-t futtatni, a kérdés az, hogy mi fut abban a cluster-ben... na, ott lehetnek komoly szopások még.

De aztan a cegnel, ahol dolgozom mac mellett kotottunk ki. Menedzsereknek csak mac air. 

Alapvetően az MBP az előző (Intel) MBP-hez képest kiemelkedő teljesítményben és egyebekben, a kortárs cuccokhoz képest nem ad sok előnyt, pláne, ha desktop teljesítmény kell.

https://iotguru.cloud

( Sulc v | 2023. 08. 09., sze – 16:18 )

Mi az a gép amit kinőttetek?

Itt ugyanis lehet core/thread vagy memóriaméret vagy diszk IO limit.

Enélkül csak pusztába kiáltott szó a véleményünk

Új gépeket akarunk venni és ha lehet, akkor modernizálnánk, hogy ne rutinból vegyük.

A legutóbbi összetevők:

  • ASROCK Z690 Pro RS vagy ASROCK Z590M Pro4
  • CORSAIR 32GB Vengeance LPX DDR4 3200MHz CL16 KIT CMK32GX4M2E3200C16
  • INTEL Core i7-12700 1.60GHz LGA-1700 BOX Intel hűtő ventilátorral
  • SAMSUNG 500GB 980 PRO M.2 PCIe M.2 2280 MZ-V8P500BW

Ez így elég erősnek tűnik alapból is, talán a ram lehet egy kicsit kevéske.

Ha van fölös/kísérletezni vágyó pénz és ember, megnézném egy amd 7800x3d alapú konfiggal hogy a jelentős mennyiségű l3 cache mennyit dobna az adott workloadon.

Szerk.: Láttam hogy Intelt keresel, de ha azt kinőttétek akkor nem hiszem hogy az egy generációval frissebb cpu jelentős növekedést adna.

https://ark.intel.com/content/www/us/en/ark/products/134591/intel-core-…

Ark szerint is 1,6GHz a legalacsonyabb órajel a magok között az Efficient és Performance magok tekintetében.

Efficient-core Base Frequency 1.60 GHz

A 3,6GHz az

Efficient-core Max Turbo Frequency 3.60 GHz

A performance magoknak 2,1GHz alap órajele

Performance-core Base Frequency 2.10 GHz

ha mindenkepp Intel, akkor szvsz vard meg a 14-es szeriat, mar ittvan a kanyarban.

tobb memoriat el tudnek kepzelni, 64GB ddr5 is mar nagyjabol a megfizetheto kategoriaban van.

ja es tegyel ra rendes hutest, aztan lehet kitolni a powerlimiteket es kitartasi idot ( hirtelen igy hajnalban ehgyomorra nemjut eszembe, talan pl1 / pl2 ? ) ne csak 56 masodpercig legyen k* gyors.

HUP te Zsiga !

Teljesen jónak tűnik. Simán lehet ebbe DDR5-öt is tenni, bár mint mondtam, nagy teljesítménytöbbletet nem fogtok érezni. Még az is lehet, hogy jobban megéri a DDR4-nél maradni, de mondjuk abból 64 gigát belepakolni, meg agresszívabbra venni az időzítéseit.

Esetleg a fél terás SSD helyett egy 1-2 terásat, mondjuk csak 970 EVO, ha nem kell sok írás, vagy nem a lemez I/O a szűk keresztmetszet, de kell tárhely bőven. Nem tudom, mert ügyesen titkolod, hogy mliyen jellegű fejlesztésről van szó, adatbázis, web, 3D, szimuláció, AI, vagy mit fejlesztetek?

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Simán lehet ebbe DDR5-öt is tenni, bár mint mondtam, nagy teljesítménytöbbletet nem fogtok érezni.

Egyrészt melyikbe lehet tenni DDR4 vagy DDR5 memóriát is? Másrészt miért ne lehetne érezni? Kurvára érezni, ha memóriaintenzív feladatok vannak.

https://iotguru.cloud

Szia! Nem titkolni akartam, hanem amennyire lehetett általánossá tenni a dolgot. Az látszik, hogy sok az "attól függ" paraméter és nincs biztos válasz.
.net, c#, JS, docker a saját gépen

A gép egy Z690M chipset, 2x16GB DDR5-6000MHz, Samsung 990 1TB kialakítású lesz.
Lesz 2 üres slot a memóriának, ha még kellene.
Abban maradtunk, hogy megnézik hogy muzsikál egy ilyen.

az a baj, hogy ok par het mulva megjelenik az intel 14gen, de nem a magyar piacon, eleinte csak szurkeimport lesz horror aron, aztan mire lenne hivatalos csatornan is mar kozeleg a karacsony/evvege es felmennek a pc arak... raadasul az ujdonsagok eleinte mindig tularazottak.

masik gond meg az alaplap, azt is meg kell tervezni es gyartani hozza, a mostaniak vszinu nem lesznek jok a gen14-hez. az uj alaplapok mire lesz valasztek az is jopar honap, aztan meg fel ev mire a biosbol is kipucoljak a durva bugokat...

en iden tavasszal vettem gen13 rendszert, es meg olyan bugok voltak a biosban hogy a 128G memoriat nem is kezelte, en meg pislogtam mint hal a szatyorba hogy meg se nyekken a gep...  ha kivettem a fele modult (4x32) akkor elindult, 128-al nem. es ez mar jo fel evvel a gen13 megjelenese utan!

ez lenne az? https://www.amd.com/en/products/cpu/amd-ryzen-7-5800x3d

> Max. Boost Clock   Up to 4.5GHz

ezt az en 6 eves intelem is tudja. a gen13-as pedig 5.8-on megy... (Z-s alaplappal K-s procival akar mind a 8 performance core is egyszerre, amig a hutes birja)

ez meg ilyen wtf:

Liquid cooler recommended for optimal performance

Max. Operating Temperature (Tjmax) 90°C

7800/7900/7950X3D. A CPU órajel pedig tökmind1, az számít, hogy nekik a feladatra jobb-e, pláne, hogy asszem 12700-aznak.

Fogyasztás/TDP ügyben óvatosan, mert nem kicsit lettek éhesek az intel CPU-k. :) Szóval mielőtt esetleg eszedbe jut, még előtte nézzel fogyasztási adatokat, különös tekintettel a power Level 1-re és 2-re.

Mértek fogyasztást is per teszt: https://www.phoronix.com/review/amd-ryzen9-7900x3d/6   Majd lehet olajkályha intelezni... na mind1.

A CPU órajel pedig tökmind1, az számít, hogy nekik a feladatra jobb-e, pláne, hogy asszem 12700-aznak.

Az órajellel már rég nem arányos a teljesítmény, semmi értelme összevetni két különböző architektúra raw órajelét.

Fogyasztás/TDP ügyben óvatosan, mert nem kicsit lettek éhesek az intel CPU-k. :) Szóval mielőtt esetleg eszedbe jut, még előtte nézzel fogyasztási adatokat, különös tekintettel a power Level 1-re és 2-re.

Ahja, nem mindegy, hogy 5 nm a gyártás vagy 10 nm, ez látszik abban, hogy mennyire kevésbé melegszik egy Ryzen.... :)

https://iotguru.cloud

Biztos nekem akartad? :) TDP ügyben fogyasztói szempontból terméket hasonlítasz össze, hogy az most milyen nanométer, milliméter, vagy gőzzel megy, az mind1. Gyorsabb-e, jobb-e a kimondott feladatra, bár az nem árt, ha nem kell bővíteni az elektromos hálózatot. :)

Kedvencem a 2,2GHz legelső Opteronok a 3GHz+ netburst ellen.

Nem bírtam ki https://www.intel.com/content/www/us/en/products/sku/230496/intel-core-…

WTF négyzet: TJUNCTION: 100°C

Power: 125 W Maximum Turbo Power: 253 W

A 7950X3D 162W-os maximum powerrel operál, turbóstul. Az igazsághoz hozzátartozik, hogy a "sima" 7950X, az 170W-os TDP-vel jön, és az X3D-nél az HBM RAM érzékenység miatt vissza kell venniük, valszin erősen válogatott chipek kapják meg a HBM-et.

csak abban az Intelben nincs olyan bazi nagy L3 cache, mint az X3D -ben.

valoban van ahol semmit nem hoz, viszont ahol igen, ott hiaba az 5.8, kikap az Intel. Foleg ha mar 13 gen, akkor nem 5800X3D -t, hanem 7800X3D -t teszunk a merleg masik serpenyojebe.

@Andrej : a sima 12/16 magos elmegy 200+ -ba is, de nem ilyen Intelesen 56 sec -ig gyors vagyok, aztan visszaveszem magam uzemben.  A homerseklet meg mindkettonel olyan-amilyen, a Zen4 is 90-95 fokra van specifikalva.

HUP te Zsiga !

A gép egy Z690M chipset, 2x16GB DDR5-6000MHz, Samsung 990 1TB kialakítású lesz.

Miért nem 2x32 GB, ha már? 32 GB memóriával hasonló dolgokkal igen gyorsan elértem azt, hogy nem maradt memória cache célokra és hiába gyors az SSD, ha állandóan onnan olvas és oda ír, ahelyett, hogy betolná memóriába. Ha sok apró fájlt kell állandóan írni-olvasni, akkor sokkal többet számít a szabad memória mérete, ahova gyorsan ki tudja lapátolni ezeket, mint a sebessége (bár a DDR5-4800 nem annyival olcsóbb, mint a DDR5-6000, hogy megérje)... mert az SSD két nagyságrenddel lassabb mint a memória.

https://iotguru.cloud

Jól látom, hogy ez egy nem szabványos minipc, ami kis helyen sok erős hardvert és spéci megoldásokat használ? Szóval se bővíthetőség, se javíthatóság nem ideális. 

Ja és az intel pont leépíti a nuc vonalat, azt hiszem a régi cuccok supportját átadta az asusnak. 
https://www.intel.com/content/www/us/en/newsroom/news/intel-nuc-systems…

( Raynes v | 2023. 08. 09., sze – 17:29 )

Ha DDR5, akkor mindenképp Intel 12+ gen, vagy Ryzen 7+ gen. Bár annyit nem fog dobni teljesítményben a DDR4-hez képest, mint gondolnátok, meg a DDR5 RAM is drágább, de végül is az időtállóság miatt nem árt.

A pénzkeretet nem írtad, meg hogy milyen fejlesztésről van szó.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

> Bár annyit nem fog dobni teljesítményben a DDR4-hez képest, mint gondolnátok

ez nagyon fugg a workloadtol. nyilvan ha az ido 95%-ban az IDE-t nyomgatja akkor kb mind1, ha sok forditas, adatbazis piszkalas, adatfeldolgozas megy akkor azert elegge erezheto a kulonbseg. en nagyon sok esetbe tapasztaltam mar hogy a ram sebesseg a bottleneck, a cput ki se lehetett terhelni 100%-ra mert hiaba g3ci gyors, ha mindig varakozik az adatra...

( Pingvinpasztor | 2023. 08. 09., sze – 17:52 )

kicsit kukucsold+ az intel ark-t, úgy látom, az n5XX-es chipsettel, és a hozzá tartozó iGen11-el nem hajtod ki a ddr5-öt ... n6XX-től muzsikál a ddr5, és a hozzá tartozó iGen12-13-as proci széria

//az intel gyakran +szopat minket a generációk közötti chipset kompatibilitás problémákkal, de nem ezért szeretjük ... az amd-nél + más a szívás ...//

www.pingvinpasztor.hu

( Carter | 2023. 08. 09., sze – 18:25 )

Sajnálom, hogy nekem kell kimondanom, de amíg többszázezres kiadással nyertek +10%-ot a generációk közötti váltással, addig egy hasonló költségű kódoptimalizálás szerintem jóval többet hozna. Feltéve, ha az idézett szöveget nem fejlesztő írta. Ha fejlesztő írta, akkor lennének kérdéseim a menedzsmenthez. Ilyen nagyot kell meríteni, hogy valaki dolgozzon ott? Lehet alulfizetettek a dolgozók?

( n.balazs v | 2023. 08. 09., sze – 19:09 )

Mint IT üzemeltető írom az alábbiakat:
- Szerintem totál pénzégetés a DDR5 még.
- A fenti bullshiteléses indoklást egy normális vezető úgy dobja vissza, mint a huzat. Mi lassabb? Mennyire? Mik a mögötte lévő számok? Amikor üzemeltetőként elkezdtük mérni a fejlesztők gépeinek terhelését, akkor általában elég gyorsan kiderült, hogy közel sincs kihajtva a gépük. A build, CI/CD meg úgyse a fejlesztő gépén fut normális helyeken, hanem pl: Jenkins node-okon.
- Az ilyen csillagromboló gépen dolgozó fejlesztőktől szokott kikerülni olyan "produktum", hogy ha ügyfél panaszkodik lassúságra, akkor ők elintézik ennyivel: "Az én fejlesztői gépemen gyorsan működik. Vegyen ő is jobb gépet!"

Technikai részhez:
- Az a 32 GB ram elég karcsú egy fejlesztői gépbe. 64 GB alá nem mennék - persze ez programnyelv, IDE, projekt függő is.

- Szerintem totál pénzégetés a DDR5 még.

Én például nem bántam meg, pedig saját zsebből váltottam.

A fenti bullshiteléses indoklást egy normális vezető úgy dobja vissza, mint a huzat. Mi lassabb? Mennyire? Mik a mögötte lévő számok? Amikor üzemeltetőként elkezdtük mérni a fejlesztők gépeinek terhelését, akkor általában elég gyorsan kiderült, hogy közel sincs kihajtva a gépük. A build, CI/CD meg úgyse a fejlesztő gépén fut normális helyeken, hanem pl: Jenkins node-okon.

Egy Unity WebGL build esetén a CPU terhelés ~20-25 százalék körül mozog, néha-néha van egy 60-80 százalékos peak, gyakorlatilag a memória bandwidth fogja vissza a build folyamatot, három évvel újabb gép itt fele annyi build időt jelent (12 perc -> 6 perc). Nincs értelmes CI/CD hozzá, vannak barkácsolt dolgok, de be tudják szopatni az embert. És ez egy a sok dolog közül, sok esetben nem feltétlen a CPU a szűk keresztmetszet, hiába monitorozod.

Ugyanígy egy Meteor React build egy kis molyfing site esetén is el tud menni 10-15 percre, ez se CPU-t terhel alaptvetően. Nyilván lehet bullshit, de a jelenlegi mérnöki óradíjakkal kurva gyorsan összejön az elveszett percekből egy új gép ára.

- Az ilyen csillagromboló gépen dolgozó fejlesztőktől szokott kikerülni olyan "produktum", hogy ha ügyfél panaszkodik lassúságra, akkor ők elintézik ennyivel: "Az én fejlesztői gépemen gyorsan működik. Vegyen ő is jobb gépet!"

Egyrészt ne keverjük a build és a runtime teljesítményt, másrészt ezért van jobb helyeken ugye UAT/QAS, ahol ez kiderül, mert a tesztelő gépe nem csillagromboló.

https://iotguru.cloud

Amíg memóriára vár valami, 100% CPU van az adott magon, nem? Nincs interrupt, hogy bocs, várok a 12-14 cl-re a következő nem cachelinehoz, addig légyszi egy context switchet rám (nem is lenne értelme). https://people.freebsd.org/~lstewart/articles/cpumemory.pdf

Bármi lehetséges, de vaktában N darab 500k körüli gépet elég vakmerő megvenni. Azonosítaniuk kéne, hogy hol a szűk keresztmetszet, esetleg az AMD féle HBM történet (X3D) segít-e nekik, egy RAID0-s NVMe SSD megoldás mennyit javít, és így tovább.

Ha RAM sávszél kell, akkor Threadripper 8 csatornás 5000-es széria, bár ez még DDR4 szintén, viszont a 3200MHz-től feljebb lehet lépni. Ezzel együtt kapnak minimum 24-32 magot (magot, szálban 2x ennyit), ami azért nem piskóta desktopban.

Egyelőre nem maga az sw sebessége, hanem a fejlesztői környezet sebessége a kérdés, ahol full debuggal dolgoznak. Ez látatlanban sem lehet eccerű. Bármi legyen a számukra szűk, azért arra rá kénne jönniük valahogy, hogy akkor RAID0-kat kell gyártaniuk, vagy 8 csatornás Threadripperbe önteni a pénzt, vagy több mag/órajel kell.

Egyrészt nem biztos, hogy egy kb. 15 éves doksi alkalmas a mai processzorok működését megítélni... én se mélyedtem el túlságosan például a Ryzen lelkivilágában, de manapság komplexebb dolgok vannak egy CPU-ban, mint például valamilyen AI által támogatott branch prediction és memory dependence prediction, amivel előre be tudja hozni a szükséges adatot a CPU számára amúgy igen lassú memória műveletek miatt... el tudom képzelni, hogy ha nem tud mással foglalkozni, akkor nem feltétlen dolgozik 100 százalékos teljesítményen és ez mérhető is.

Másrészt olyan dolgokról beszélünk, hogy 32 GB memória transzfer oda-vissza 1-2 másodperc DDR5 esetén is, kétszer ennyi idő DDR4 esetén... ha például ennek az adatmennyiségnek a feldolgozásához elég egy mag munkája a nyolcból, akkor hét mag nem lesz terhelve, azt látod, hogy a gép unatkozik és 12,5 százalékra van terhelve, holott a memória sávszélessége fogja vissza a teljesítményt.

https://iotguru.cloud

A ramok működése még mindig hasonó, mint 15 éve. Nem biztos, hogy hülyeség elolvasni.

A CPU viszont nem olyan, mint 15 éve.

Lineáris olvasást egyszerű prediktálni, random már nem 1-2 másodperc lesz. De holnap kipróbálom :)

Aham, csak hiába prediktálod, ha lassú a lineáris olvasás és írás; random is ugyanúgy 1-2 másodperc lesz, ha csak olvasod és írod. A kérdés alapvetően az, hogy a beolvasás és kiírás közötti időben tudsz-e adni annyi feladatot a CPU-nak, hogy ne unatkozzon... kevés adaton is lehet sokat dolgozni és sok adaton is lehet keveset dolgozni.

https://iotguru.cloud

Amíg memóriára vár valami, 100% CPU van az adott magon, nem? 

Nem feltetlen. A belso allapotat tekintve a cucc akkor egy hasonlo allapotban van mintha wait for interrupt-ban lenne. Inkabb az a kerdes hogy mennyit kell atlagosan varnia ilyenkor. Ha a pipeline hosszaval osszemerhetot vagy annal kevesebbet, akkor a gyakorlatban emiatt nem fogsz latni teljesitmenyfelvetel-csokkenest.

Nincs interrupt, hogy bocs, várok a 12-14 cl-re a következő nem cachelinehoz, addig légyszi egy context switchet rám (nem is lenne értelme).

Ha olyan a front-side bus architektura, akkor ezek a "wait state" jellegu helyzetek/allapotok akarmeg megszakithatoak kulso megszakitassal is. Sot, ha megnezed, akkor a "page fault" meg hasonlo megszakitasok is pont egy memoriara valo varakozas kovetkezteben/utan alakulnak ki. Szoval ha hosszu a varakozas es engedelyezett akkor siman lehet context switch is.

Es valoban mukodik a fizika: 64 megabyte adat veletlen dword-szelessegu (32 bites) eleresekor - konkretan ennel a gepnel ahol most teszteltem - 35 fokrol 44 fokra melegszik fel, es ~200 masodperc alatt fut le, szekvencialis elereskor meg ~27 masodperc alatt fut le es mar azalatt felmelegszik 50 fokra. 

A tesztprogram kritikus resze:

uint32_t lfsr_32(uint32_t x)
{
 return ( (x & 1 ? 0xEDB88320 : 0) ^ (x>>1) );
}

uint32_t test_access_sequential(uint32_t *array,int acount)
{
 uint32_t       x;
 int            i;
 unsigned       index;

 x=0;
 index=1;
 for ( i=0; i<acount; i++ )
  {     x+=array[i];
        index=lfsr_32(index);
  }

 return(x);
}

uint32_t test_access_pseudorandom(uint32_t *array,int acount)
{
 uint32_t       x;
 int            i;
 unsigned       index;

 x=0;
 index=1;
 for ( i=0; i<acount; i++ )
  {     x+=array[index%acount];
        index=lfsr_32(index);
  }

 return(x);
}

Lefuttattam ezt én is -O2 -vel fordítva, előtte feltöltöttem egy 4GiB-s tömböt.

sequential:
real    0m1,225s
user    0m0,386s
sys    0m0,836s
 

pseudorandom:
real    0m16,368s
user    0m15,516s
sys    0m0,817s

De így ki lett optimalizálva a sequentialből a psr számítás.

Ha benne van ( x+=array[i]+index;) akkor:

sequential:
real    0m2,130s
user    0m1,333s
sys    0m0,793s

Mivel zártad ki, hogy a pszeudorandom generálást mérted meg és nem a random memória elérés sebességét?

Kicsit finomhangoltam az eljarason:

uint32_t test_access_generic(uint32_t *array,unsigned acount,uint32_t mask_array,uint32_t mask_rnd)
{
 uint32_t       x;
 unsigned       i,index;

 x=0;
 index=1;
 for ( i=0; i<acount; i++ )
  {     x+=array[(i+(index&mask_rnd))&mask_array];
        index=lfsr_32(index);
  }

 return(x);
}

A mask_array az alapertelmezetten acount-1, ahol acount=1<<24 (vagy valami nagyobb szam, lenyeg hogy ketto-hatvany). A mask_rnd-vel tudsz jatszani. Ha az (1<<0)-1, akkor visszakapod a szekvencialis olvasast, ha az (1<<24)-1, akkor a teljesen pszeduorandom olvasasast. Ha noveled a maszk szelesseget ugy egyere inkabb randomizalja az elerest. Es ezaltal no a futasido, illetve kevesbe melegszik a processzor. Ellenben a szukseges szamitasi teljesitmeny nem valtozik, nem fugg a maszk szelessegetol. 

Továbbra is azt mondom, hogy nem a RAM random vs sequential sávszélességét méred, hanem a CPU architektúrát, szálkezelést, branch prediction hit/miss arányt, L1-L3 cache hit/miss arányot, hyperthrading és context switch időket, beleértve ilyen kevés és amúgy sokszor ismételt adatnál a cache torzítását is... ezek a tesztek úgy nagyjából egyáltalán nem azt mérik, amit mérniük kellene.

https://iotguru.cloud

Továbbra is azt mondom, hogy nem a RAM random vs sequential sávszélességét méred

Valojaban a fogyasztast akartam merni, es sikerult is :) De akarok meg keriteni egy ampermeros USB sticket es egy RPi-t is, hogy ugyis lassam... Egyebkent a fenti peldaban a fordito mar semmit nem tudott kioptimalizalni mert a maszk-ertekek meg a bitszelessegek immaron command line parameterkent erkeznek. Nade akkor sorrendben:

  • itt nincs semmi extra branch prediction, vagyis a branch szerkezet az fuggetlen attol hogy az eleres mennyire random vagy mennyire szekvencialis... az LFSR szerkezet is fuggetlen ettol (ott abban ugye lehet branch, de ha a LFSR tap regiszer - ronda 32bites hexa szam - erteket mondjuk CMOV-szeruen allitja elo, akkor ott a gyakorlatban nincs is branch);
  • igen, a cache hit-miss arany az a wait state-k miatt aranyos lesz a fogyasztassal illetve az effektiv sebessggel, szoval ezt is tenyleg merjuk;
  • igen, az L1-L3 esetere is vonatkozik: ahogy viszem fel a maszk szelesseget, szepen lehet latni a futasi idokbol hogy mikor lepem at az L1-et, mikor az L2-t es mikor az L3-at. A randomizalas miatti atfedesek okan nem annyria elesek ezek a hatarok, de ott vannak kb ahol varjuk;
  • multithreading es tarsai: hat, egy headless gepen mertem ezt, semmi grafika, semmi flanc nem futott rajta, csak az a nehany tucat minimal processz amit egy "beeseshazos-dolgozos" gepen kell fusson... szoval igen, ez termeszetesen beleszolhat de a wall time vs. user time meglehetosen ugyanaz-  szoval talan nem torzitotta annyira.

Szoval egyelore igy.

root@ddr5:/home/speed/ramgather# while true; do sensors|grep ^Package|cut -c 15-25 >>temps; sleep 0.2; done &

root@ddr5:/home/speed/ramgather# for i in $(seq 0 31); do rm temps; echo $i $(./ramgather -m $i -r 1000) $(sort -g temps|tail -n 1) ; sleep 15 ; done

0 13.603669 +75.0°C
1 13.621804 +74.0°C
2 13.438334 +75.0°C
3 13.670127 +73.0°C
4 13.630969 +74.0°C
5 13.730956 +75.0°C
6 13.543490 +74.0°C
7 13.497326 +73.0°C
8 13.530971 +74.0°C
9 13.726651 +74.0°C
10 13.814084 +74.0°C
11 14.403857 +74.0°C
12 14.799720 +73.0°C
13 15.721737 +71.0°C
14 19.443828 +65.0°C
15 22.771907 +65.0°C
16 23.333968 +64.0°C
17 25.085469 +62.0°C
18 25.366361 +65.0°C
19 48.554421 +56.0°C
20 50.729266 +58.0°C
21 54.988384 +59.0°C
22 57.910230 +58.0°C
23 72.188134 +60.0°C
24 91.590651 +64.0°C
25 95.448356 +58.0°C
26 91.739873 +57.0°C
27 91.708599 +60.0°C
28 91.624484 +62.0°C
29 91.679377 +60.0°C
30 91.774816 +59.0°C
31 91.584835 +58.0°C

Szoval egyelore igy.

Értem, szóval ezek után én még mindig arra hajlok, hogy teljesen mást mérsz, mint amit szeretnél, hogy mutasson a programod, pláne teljesen értelmetlen egy 8 magos rendszerben egy DDR5 vs DDR4 kérdéskörben (ahol a DDR5 esetén van például 2x32 bit independent channel, más a burst length és burst chop működése is) és adott esetben egy magot se tud ellátni megfelelő mennyiségű adattal a memória sávszélessége...

https://iotguru.cloud

nem ismersz esetleg olyan memória sebesség tesztet, mint a régi gépeken a cache sebesség mérő TopBench volt?
https://sparcie.files.wordpress.com/2015/01/sstimg01.png

Két különböző méretű ram modul mellett lennék kíváncsi arra, hogy vajon mutat-e tényleg sebesség különbséget az alsóbb címeken, ahol mindkét modul "tart", mint a felsőbb címeken, ahol csak a nagyobb modul van.

Elvileg "flex" módban különböző sebességű lehet a terület. Bár lehet az egész mérést a throttling széttrollkodja.
Ha jól sejtem memtest csak kalkulálja, nem méri.

Milyen tevékenységre fűti el az adott CPU mag a rá eső max teljesítményt, ha amúgy vár arra, hogy dolgozzon?

Nehany (akar eleg sok) pipeline stage vagy koprocesszor az még dolgozhat, amig egy masik stage már elkezdett várakozni (konretan a memóriára). Amint kiürül a pipeline és/vagy egyik koprocesszor sem dolgozik már akkor valóban már nem igazán fűt semmi :) 

Nyilván sokféle build van, ahol lehet nyerni időt. A kérdés, hogy megéri-e.
Az elveszett perceket valahol ki is kell tudni termelni.
Sok fejlesztő sok terméknél sajnos elfelejtett optimalizálni (babzsákfejlesztők by hajbazer). Persze ez lehet felülről érkező nyomás ("legyen kész tegnapra"), lehet igénytelenség is. Berántanak 100+ libet, aminek csak egy részét használják, a többi már nem használt a projektben. Tisztelet a kevés kivételnek.

A memory bandwidth monitoring megoldása nem egyszerű, de nem is teljesen lehetetlen. Néhány próbálkozás, megoldás például:
- https://www.intel.com/content/www/us/en/developer/articles/technical/in…
- https://github.com/intel/PerTaskMemBWMonitoring
- https://github.com/LucaCanali/Miscellaneous/blob/master/Spark_Notes/Too…
- https://github.com/intel/pcm
- https://www.amd.com/en/developer/uprof.html
- https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/…

Egyrészt ne keverjük a build és a runtime teljesítményt, másrészt ezért van jobb helyeken ugye UAT/QAS, ahol ez kiderül, mert a tesztelő gépe nem csillagromboló.

Nem keverem. Éltem meg már olyan esetet többször is, hogy UAT/QAS szerint is lassú volt, ezért a ticket már a fejlesztőnél eszkalálódott. Ő meg lezárta annyival, hogy vegyenek csillagrombolót arra a feladatra. Nyilván ez a flegma hozzáállás nem volt vállalható sem befelé, sem az ügyfelek felé.

Nyilván sokféle build van, ahol lehet nyerni időt. A kérdés, hogy megéri-e.

A gép olcsó, a fejlesztő drága és főleg akkor drága, ha nem kap jó gépet és elmegy oda, ahol kap. Egy senior ember 25-30 millióba kerül a cégnek évente és ennél jóval több bevételt jelent általában.

Az elveszett perceket valahol ki is kell tudni termelni.

Általában ki szokták termelni.

Sok fejlesztő sok terméknél sajnos elfelejtett optimalizálni (babzsákfejlesztők by hajbazer). Persze ez lehet felülről érkező nyomás ("legyen kész tegnapra"), lehet igénytelenség is. Berántanak 100+ libet, aminek csak egy részét használják, a többi már nem használt a projektben. Tisztelet a kevés kivételnek.

Általában a build idő teljesen független attól, hogy mennyi library van "berántva", jelentsen ez bármit is. A build idő attól szokott növekedni, hogy a lefordított cucc runtime például gyors és/vagy kicsi legyen. Nyilván ki lehet kapcsolni mindenféle optimalizációt és egyebeket, csak akkor meg ugyanúgy jön a csillagrombolós nyökögés, amikor runtime lassú és nagy.

Nem keverem. Éltem meg már olyan esetet többször is, hogy UAT/QAS szerint is lassú volt, ezért a ticket már a fejlesztőnél eszkalálódott. Ő meg lezárta annyival, hogy vegyenek csillagrombolót arra a feladatra. Nyilván ez a flegma hozzáállás nem volt vállalható sem befelé, sem az ügyfelek felé.

Oszt? Most anekdotázunk, hogy melyik IT terület mennyire balfasz vagy problémát oldunk meg? Anekdotázással nehéz problémákat megoldani, bár jó időtöltés, mert balfaszokból mindenhol ugyanannyi szokott lenni.

https://iotguru.cloud

( PunishR v | 2023. 08. 09., sze – 19:57 )

Arra figyelj hogy a gen13-as desktop intel vonalnal sajnos nem trivialis a pci-e 5.0 m.2 slot, szoval ha tenyleg kell a gyorsabb nvme akkor ez szamithat.

( andrej_ v | 2023. 08. 09., sze – 20:16 )

Ha már a PCIe NVMe-re lőttetek, akkor a PCIe 5.0 -s SSD-ket meg kéne várnotok vele. Ha AMD akkor az 7000-es széria X3D CPU-i, ha intel, akkor azt hiszem épp jön a 14. generáció. Nem, nem kell mindíg épp várni a következő szupertechnikára, hanem pár héttel egy újdonság előtt azért azt érdemes lenne megvárni.

Ha kellően sok gépet akartok venni, akkor kell egy AMD-s és Inteles darabot összeállítani, és megnézni, hogy melyik ad többet számotokra.

Háde látod mit írt: "Nálunk a CPU-Memória-Perifériák (elsősorban NVMe SSD) közötti sávszélesség a legfontosabb szempont. Elég sok komponensből álló rendszert szimulálunk és mivel a saját fejlesztéseinket debug módban használjuk fejlesztés közben, így a futtatott kód egyáltalán nincs optimalizálva (sőt tele van analízissel és metrikákkal amik kifejezetten performancia gyilkos dolgok) ezért fontosak számunkra a fentiek. " :)

NVMe SSD-ből is lehet amúgy RAID10-et csinálni a desktopban.

Azt gyanítom, hogy a mostani gépeknél érdemben jobbat teszteléssel fognak tudni összerakni.

( trey | 2023. 08. 10., cs – 09:05 )

Linust kérdeztétek? :D

trey @ gépház