Kahdella 64-ytimisellä Milan-prosessorilla varustettu järjestelmä testivuodoissa (Zen 3)

[Kaotik]

Kaotik kirjoitti uutisen/artikkelin:
AMD julkaisi Zen 3 -arkkitehtuurin työpöydälle suunnattujen Vermeer-koodinimellisten Ryzen 5000 -prosessoreiden mukana. Yhtiö on aiemmin jo varmistanut, että se aloittaa myös samaan arkkitehtuuriin perustuvien Milan-koodinimellisten Epyc-prosessoreiden toimitukset kuluvan neljänneksen aikana, vaikka virallinen julkaisu saattaakin siirtyä ensi vuoden puolelle.

Nyt Twitterissä ExecutableFix-nimimerkillä tunnettu henkilö on saanut käsiinsä palvelimen 64-ytimisellä Milan-prosessorilla ja ajanut sillä testejä Zen 2 -arkkitehtuuriin perustuvaa 64-ytimistä Rome-prosessoria vastaan.

[gallery link="file" ids="56235,56236,56237"]

Yhdellä säikeellä Cinebench R15-testissä Milan tarjoaa ExecutableFixin mukaan 18 %:n parannuksen Romeen nähden, kun R20:ssa ero on 11 % ja CPU-Z:n testissä 13 %. Molemmat prosessorit toimivat testissä lukitulla 2,4 GHz:n kellotaajuudella. Kun kellotaajuus vapautetaan, kasvaa Zen 3 -arkkitehtuuriin perustuvan Milanin etumatka selvästi. Prosessorin Boost-kellotaajuus on peräti 400 MHz korkeampi, kuin vastaavan Romen, minkä myötä R15:n ero kasvoi 32 %:iin, R20:n 22 %:iin ja CPU-Z:n 27 prosenttiin. Kaikkien ydinten testissä erot jäivät pieniksi, sillä R15:ssa ero oli vain 11 ja R20:ssa 9 %, vaikka Milan toimi testissä noin 12 % Romen 3,3 GHz:iä korkeammalla 3,7 GHz:n kellotaajuudella.

Lisäkuriositeettina ExecutableFix ajoi vielä Cinebench R23 -testin 128-ytimisellä eli kaksi 64-ytimistä Milan-prosessoria sisältävällä järjestelmällä. Kokoonpanon yhden säikeen tulos oli testissä 1215 pistettä, kun kaikkia ytimiä hyödyntävässä testissä maksimissaan 3,7 GHz:n kellotaajuudella toimivat prosessorit nappasivat yhteistuumin 87878 pistettä. Kuvankaappauksen tuloksesta löydät uutisen pääkuvasta.

Lähde: ExecutableFix @ Twitter

Linkki alkuperäiseen juttuun

 

[Xemanth]

Kyllähän noil kivillä kelpaa jo Facebookkia selata.

 

[JuusoX]

Jytky tuli

 

[hsalonen]

Epyc on palvelinprosessori, nämä ei ole teidän pelikoneisiin

 

[Lucas]

Epyc on palvelinprosessori, nämä ei ole teidän pelikoneisiin

Jos riittää liitua millä piirtää, niin eiköhän tuollaisellekin "kaksi 128-ytimistä Milan-prosessoria sisältävällä järjestelmälle" löydy rautaa johon saa kiinni huippunäytönohjaimen tai useammankin ja pääse pelailemaan vaikka vanhaa Minecraft peliä. Voisi kuvitella että FPS olisi aika korkea ainakin matalimmilla grafiikka-asetuksilla.

 

[hsalonen]

Jos riittää liitua millä piirtää, niin eiköhän tuollaisellekin "kaksi 128-ytimistä Milan-prosessoria sisältävällä järjestelmälle" löydy rautaa johon saa kiinni huippunäytönohjaimen tai useammankin ja pääse pelailemaan vaikka vanhaa Minecraft peliä. Voisi kuvitella että FPS olisi aika korkea ainakin matalimmilla grafiikka-asetuksilla.

Palvelinprosessoreissa on vedetty kellotaajuudet kohtuullisiksi ja se taas tarkoittaa, että pelit toimii noilla kuluttajaprosessoreilla paremmin - kun yhden säikeen suorituskyky on maltillisempi serveripuolella ja siihen on panostettu kuluttajavehkeissä.

 

[TunTuri]

Aika kovaa murskainta luvassa. Vielä threadripperit Zen3:sta, niin AMD pääsee kivasti keskittymään DDR5 laitteisiin.

ja joo, ei ole peliprossu tietenkään, kuluttajakuormissa varmasti joku ryzen 5600x-kokoonpano päihittää pääsääntöisesti tuommoisen 2x128 ytimisen palvelinkokoonpanon, mutta konesaliin tuo on aika huhhui!

 

[mRkukov]

Lisäkuriositeettina ExecutableFix ajoi vielä Cinebench R23 -testin kaksi 128-ytimistä Milan-prosessoria sisältävällä järjestelmällä.

Ei vaan järjestelmällä missä kaksi 64 ytimistä.

Cinebench R23 on a 128-core Milan system (3.7GHz max boost)

 

[Hannibal]

Hieman hymähdytti yhden ytimen testit noilla vehkeillä
Eiköhän noilla 99.9% ajeta moniytimisiä tehtäviä.
Mutta hyvin etenee tämäkin puoli.

 

[prc]

Hieman hymähdytti yhden ytimen testit noilla vehkeillä
Eiköhän noilla 99.9% ajeta moniytimisiä tehtäviä.
Mutta hyvin etenee tämäkin puoli.

Veikkaan ST kuormien osuudeksi tuotannossa 0.0%. Eiköhän kaikki ST kuormat ole jotain testejä. Varsinkin nuo järeät serverit menee joko laskentaan tai sitten virtualisointialustoiksi. Harvemmin "rauta serverit" noin järeitä on paitsi laskentaklusterit. Rauta servereistä yleisesti ottaen on pyritty/pyritään eroon. Helpottaa kaikkea ylläpitoa ja muutoksia niin hitosti kun voi serverit, verkot yms virtualisoida. Tulee vaikka joku organisaatio muutos ja asioita pitää rajata eri verkkoihin, niin conffiminen riittää eikä kenenkään tarvitse lähteä saliin lakutalkoisiin.

 

[tume86]

Millä muulla testaat arkkitehtuurin tuomaa IPC-parannusta (järkevästi) kuin 1T testeillä?

 

[demu]

Veikkaan ST kuormien osuudeksi tuotannossa 0.0%. Eiköhän kaikki ST kuormat ole jotain testejä. Varsinkin nuo järeät serverit menee joko laskentaan tai sitten virtualisointialustoiksi. Harvemmin "rauta serverit" noin järeitä on paitsi laskentaklusterit. Rauta servereistä yleisesti ottaen on pyritty/pyritään eroon. Helpottaa kaikkea ylläpitoa ja muutoksia niin hitosti kun voi serverit, verkot yms virtualisoida. Tulee vaikka joku organisaatio muutos ja asioita pitää rajata eri verkkoihin, niin conffiminen riittää eikä kenenkään tarvitse lähteä saliin lakutalkoisiin.

Rautaserverit niissä virtualisoiduissa / pilvipalveluissakin on takana.
Mutta totta on, että asiakaskohtaisia palvelimia ollaan paljolti vaihtamassa virtualisoituihin/pilviympäristöihin.
Jonkin verran on sitten ollut myös paluuta pilvipalveluista asiakaskohtaisiin servereihin.

 

[mRkukov]

Veikkaan ST kuormien osuudeksi tuotannossa 0.0%. Eiköhän kaikki ST kuormat ole jotain testejä.

Myös palvelimilla on hyvin paljon single thread kuormaa. Niitä single thread tehtäviä vaan voi olla se 100+ samaan aikaan, jolloin kaikki coret saadaan kivasti taas käytettyä. Single thread nopeus kertoo paljonko yksittäinen tehtävä tulee kestämään.

 

[Kaotik]

Ei vaan järjestelmällä missä kaksi 64 ytimistä.

Tietenkin, mikälie ajatuskatkos käynyt

 

[prc]

Myös palvelimilla on hyvin paljon single thread kuormaa. Niitä single thread tehtäviä vaan voi olla se 100+ samaan aikaan, jolloin kaikki coret saadaan kivasti taas käytettyä. Single thread nopeus kertoo paljonko yksittäinen tehtävä tulee kestämään.

Lähinnä hain sitä juuri, että missään tuotantokäytössä sen palvelimen kokonaiskuorma ei varmasti ole ST kuorma. Vain testejä / IPC testejä ajettaessa.

Rautaserverit niissä virtualisoiduissa / pilvipalveluissakin on takana.
Mutta totta on, että asiakaskohtaisia palvelimia ollaan paljolti vaihtamassa virtualisoituihin/pilviympäristöihin.
Jonkin verran on sitten ollut myös paluuta pilvipalveluista asiakaskohtaisiin servereihin.

...

 

[zepi]

Veikkaan ST kuormien osuudeksi tuotannossa 0.0%. Eiköhän kaikki ST kuormat ole jotain testejä. Varsinkin nuo järeät serverit menee joko laskentaan tai sitten virtualisointialustoiksi. Harvemmin "rauta serverit" noin järeitä on paitsi laskentaklusterit. Rauta servereistä yleisesti ottaen on pyritty/pyritään eroon. Helpottaa kaikkea ylläpitoa ja muutoksia niin hitosti kun voi serverit, verkot yms virtualisoida. Tulee vaikka joku organisaatio muutos ja asioita pitää rajata eri verkkoihin, niin conffiminen riittää eikä kenenkään tarvitse lähteä saliin lakutalkoisiin.

edit: no toistoahan tämä on jo.

Melkein kaikki kuormat ovat ST-kuormia mitä palvelimissa ajetaan. Niitä vaan ajetaan monta rinnakkain.

Jos esim. web-palvelin palvelee tuhansia yhtäaikaisia käyttäjiä, niin yksi sivulataus on usein single-thread event serverin puolella käyttäjän näkökulmasta. Se, että sama palvelin palvelee tuhansia yhtäaikaisia käyttäjiä ei tätä yksittäistä käyttäjää lohduta - hänellä on serverin puolella käytössä yksi threadi joka lukee kamaa tietokannasta ja renderöi verkkosivua ja lähettää javascript-html-mössöä ulospäin.

Yksittäisen threadin suorituskyky määrittää sen, että kuinka nopealta palvelu tuntuu yksittäisen käyttäjän näkökulmasta. Corejen määrä ratkaisee sen, että kuinka montaa käyttäjää rinnakkain palvelin pystyy palvelemaan.

Tuhat mutta hitaita coreja ei välttämättä ole hyvä, koska silloin yksittäisen käyttäjän näkökulmasta palvelin voi tuntua ikävän hitaalta.

 

[mRkukov]

edit: no toistoahan tämä on jo.

Melkein kaikki kuormat ovat ST-kuormia mitä palvelimissa ajetaan. Niitä vaan ajetaan monta rinnakkain.

Jos esim. web-palvelin palvelee tuhansia yhtäaikaisia käyttäjiä, niin yksi sivulataus on usein single-thread event serverin puolella käyttäjän näkökulmasta. Se, että sama palvelin palvelee tuhansia yhtäaikaisia käyttäjiä ei tätä yksittäistä käyttäjää lohduta - hänellä on serverin puolella käytössä yksi threadi joka lukee kamaa tietokannasta ja renderöi verkkosivua ja lähettää javascript-html-mössöä ulospäin.

Yksittäisen threadin suorituskyky määrittää sen, että kuinka nopealta palvelu tuntuu yksittäisen käyttäjän näkökulmasta. Corejen määrä ratkaisee sen, että kuinka montaa käyttäjää rinnakkain palvelin pystyy palvelemaan.

Tuhat mutta hitaita coreja ei välttämättä ole hyvä, koska silloin yksittäisen käyttäjän näkökulmasta palvelin voi tuntua ikävän hitaalta.

Ja tämän takia monelle web-kehittäjälle onkin yllätys kun sovellus/sivu toimiikin hitaammin siellä 1000€/kk maksavalla palvelimella, missä on miljoona ydintä, kuin omalla kehitysympäristöllä, jota ajetaan 4.7GHz boostaavalla työpöytäprossulla. Palvelimissa "yksi ydin" on ollut yleensä 2 - 2.5GHz. Nyt kun alkaa olla 3,7 GHz asti yltäviä palvelimia niin kyllähän sillä selvä vaikutus on. Chiplet arkkitehtuuri on kyllä hieno keksintö.

 

[hsalonen]

edit: no toistoahan tämä on jo.

Melkein kaikki kuormat ovat ST-kuormia mitä palvelimissa ajetaan. Niitä vaan ajetaan monta rinnakkain.

Jos esim. web-palvelin palvelee tuhansia yhtäaikaisia käyttäjiä, niin yksi sivulataus on usein single-thread event serverin puolella käyttäjän näkökulmasta. Se, että sama palvelin palvelee tuhansia yhtäaikaisia käyttäjiä ei tätä yksittäistä käyttäjää lohduta - hänellä on serverin puolella käytössä yksi threadi joka lukee kamaa tietokannasta ja renderöi verkkosivua ja lähettää javascript-html-mössöä ulospäin.

Yksittäisen threadin suorituskyky määrittää sen, että kuinka nopealta palvelu tuntuu yksittäisen käyttäjän näkökulmasta. Corejen määrä ratkaisee sen, että kuinka montaa käyttäjää rinnakkain palvelin pystyy palvelemaan.

Tuhat mutta hitaita coreja ei välttämättä ole hyvä, koska silloin yksittäisen käyttäjän näkökulmasta palvelin voi tuntua ikävän hitaalta.

En anna nimiä, enkä avaa tätä yhtään enempää, mutta tämä on oikeasta elämästä:
Asiakkaalla on vanha Oracle. Siinä on lisenssit per ydin ja asiakkaalla on 2 tai 4 ydintä, sanotaan kaksi, kun se tekee tästä mielenkiintoisemman. Oracle ei enää myy uusmyyntinä kahden ytimen lisenssejä ja uudet lisenssit ovat tuhansia euroja vuodessa enemmän vrt. vanhat ylläpitokustannukset.
Asiakas kysyy meidän asiantuntijoiltamme ja vähän pyöritämme lukuja Excelissä: tulee halvemmaksi ostaa paras ST kone, mitä löytyy ja sammuttaa siitä muut ytimet tai tehdä rautatason virtualisointi jossa tietyt ytimet on aina varattu Oracle-virtuaalikoneelle. En tarkalleen muista, kumminpäin tekivät, mutta se ST suorituskyky edellä tässä yhdessä casessa ostettiin kone ja serverimigraation yhteydessä laitettiin Oracle sinne.
Pieni asiakas, ja rajattu käyttö, mutta toimi edelleen täydellisesti - ja jopa nopeutui, kun palvelinprosessori oli 5-8v tuoreempi ja muut kuormat minimissä. Lisäksi tämä säästi asiakkaalle tuhansia euroja vuodessa nyt ja tulevaisuudessa.

Kyllä näitäkin on.

--

Sitten nyt taidan olla yliprovisioiduilla virtuaalityöasemilla, joissa on vuoden 2012 prosessoreita.. Että joo, ei ne aina mene noin hyvin nuo palvelinympäristöt.. Mutta onpa ainakin kerran elämässä sitä ST-suorituskykyä haettu ja ihan asiakkaan pyynnöstä.

 

[mRkukov]

En anna nimiä, enkä avaa tätä yhtään enempää, mutta tämä on oikeasta elämästä:
Asiakkaalla on vanha Oracle. Siinä on lisenssit per ydin ja asiakkaalla on 2 tai 4 ydintä, sanotaan kaksi, kun se tekee tästä mielenkiintoisemman. Oracle ei enää myy uusmyyntinä kahden ytimen lisenssejä ja uudet lisenssit ovat tuhansia euroja vuodessa enemmän vrt. vanhat ylläpitokustannukset.
Asiakas kysyy meidän asiantuntijoiltamme ja vähän pyöritämme lukuja Excelissä: tulee halvemmaksi ostaa paras ST kone, mitä löytyy ja sammuttaa siitä muut ytimet tai tehdä rautatason virtualisointi jossa tietyt ytimet on aina varattu Oracle-virtuaalikoneelle. En tarkalleen muista, kumminpäin tekivät, mutta se ST suorituskyky edellä tässä yhdessä casessa ostettiin kone ja serverimigraation yhteydessä laitettiin Oracle sinne.
Pieni asiakas, ja rajattu käyttö, mutta toimi edelleen täydellisesti - ja jopa nopeutui, kun palvelinprosessori oli 5-8v tuoreempi ja muut kuormat minimissä. Lisäksi tämä säästi asiakkaalle tuhansia euroja vuodessa nyt ja tulevaisuudessa.

Kyllä näitäkin on.

Tämä toi vanhoja muistoja mieleen. Vanhat kunnon Oracle lisenssit.

 

[pomk]

Millä muulla testaat arkkitehtuurin tuomaa IPC-parannusta (järkevästi) kuin 1T testeillä?

nT kuormilla? Kyllä IPC:n voi määrittää mille tahansa säiemäärälle. Suositussa SPEC benchmarkissakin on omat nT osatestit.

 

[markus]

1T nopeus on kyllä erittäin tärkeä myös palvelinympäristöissä, on sellaisiakin softia jotka perustilanteessa skaalautuvat lähes rajattomasti corejen ja muistin määrän mukaan, mutta tietyt operaatiot ovat pelkästään single threaded operaatioita. Siinä ei paljon auta, että on 64-core prosessori ja 512 GB RAM:ia kun odotetaan CPU käyttö parissa prosentissa tunteja että prosessointi valmistuu. Eihän tuo reaalimaailman tilanne ole että pelkästään tuo yksi kuorma pyörii palvelimella, mutta kuitenkin todellinen esimerkki että tällaisiakin tapauksia on tullut nähtyä. Ja ainoa tapa nopeuttaa on nimenomaan 1T nopeuden kasvatus.

Lisäksi juuri core pohjainen lisensointi on monessa softassa esim. ihan Microsoftin SQL Serverissä. Siinä että yhden coren lisenssi maksaa >5k€ haluaa ettei ole taustalla ihan nuhapumppu-coreja.

 

[tume86]

nT kuormilla? Kyllä IPC:n voi määrittää mille tahansa säiemäärälle. Suositussa SPEC benchmarkissakin on omat nT osatestit.

Kyllähän se niilläkin toki onnistuu. Jotenkin silti itse näen, että 1T testit on kuitenkin se järkevin, koska silloin ei ole riippuvainen mistään core-määrästä, vaan voidaan helposti vertailla ristiin eri prossujen välillä, ilman että tarvitsee laskea jälkikäteen vertailukelpoisia lukuja.

Niin kuin markus tuossa toteaa, niin on sillä 1T suorituskyvylläkin väliä palvelinympäristössä. Siihenhän se kaikki laskenta loppukädessä perustuu. Aina ei voida skaalata eikä kaikki skaalaudu threadien kanssa loputtomiin.

 

[pomk]

Kyllähän se niilläkin toki onnistuu. Jotenkin silti itse näen, että 1T testit on kuitenkin se järkevin, koska silloin ei ole riippuvainen mistään core-määrästä, vaan voidaan helposti vertailla ristiin eri prossujen välillä, ilman että tarvitsee laskea jälkikäteen vertailukelpoisia lukuja.

Niin kuin markus tuossa toteaa, niin on sillä 1T suorituskyvylläkin väliä palvelinympäristössä. Siihenhän se kaikki laskenta loppukädessä perustuu. Aina ei voida skaalata eikä kaikki skaalaudu threadien kanssa loputtomiin.

Jep, ja juuri tämän takia on järkevää testata suorituskyky niillä samoilla kuormilla mille järjestelmä altistetaan tuotannossa ja katsoa siten se kokonaisnopeushyöty. IPC on mielenkiintoinen vain akateemisessa merkityksessä.

ps. jos ydinten lisääminen ei nimenomaan lisäisi IPC:tä, niin niitä tuskin lisättäisiin prosessoreihin.

 

[tume86]

Jep, ja juuri tämän takia on järkevää testata suorituskyky niillä samoilla kuormilla mille järjestelmä altistetaan tuotannossa ja katsoa siten se kokonaisnopeushyöty. IPC on mielenkiintoinen vain akateemisessa merkityksessä.

ps. jos ydinten lisääminen ei nimenomaan lisäisi IPC:tä, niin niitä tuskin lisättäisiin prosessoreihin.

Kyllä, järjestelmät pitää testa myös hyötykuormilla, mutta niillä on aika vähän tekemistä enää puhtaan IPC:n kanssa, josta itse tuossa puhuin. Itse lienee olen sen verran akateemisesti "nörtti", että haluan tietää myös paljonko IPC on parantunut, vaikka todellisuudessa hyötykuormilla parannus ei olisikaan samalla tasolla.

 

[pomk]

Kyllä, järjestelmät pitää testa myös hyötykuormilla, mutta niillä on aika vähän tekemistä enää puhtaan IPC:n kanssa, josta itse tuossa puhuin. Itse lienee olen sen verran akateemisesti "nörtti", että haluan tietää myös paljonko IPC on parantunut, vaikka todellisuudessa hyötykuormilla parannus ei olisikaan samalla tasolla.

Mikä on sinusta ”puhdas IPC”? Se IPC on aina vaan suoritetut käskyt jaettuna kuluneilla kellojaksoilla ja sen voi periaatteessa määrittää ihan millä tahansa softalla ja raudalla ja vertailla ristiin ihan miten haluaa.

 

[tume86]

Mikä on sinusta ”puhdas IPC”? Se IPC on aina vaan suoritetut käskyt jaettuna kuluneilla kellojaksoilla ja sen voi periaatteessa määrittää ihan millä tahansa softalla ja raudalla ja vertailla ristiin ihan miten haluaa.

Huono sanavalinta, myönnän. Tarkoitin tuolla sitä, että testi on tehty sellaisilla softilla, joihon ei vaikuta muu kuin prosessori, esim. Cinebench käsittääkseni suht hyvä tässä tapauksessa.

 

[pomk]

Huono sanavalinta, myönnän. Tarkoitin tuolla sitä, että testi on tehty sellaisilla softilla, joihon ei vaikuta muu kuin prosessori, esim. Cinebench käsittääkseni suht hyvä tässä tapauksessa.

Eli haluat testata IPC:n sellaisilla softilla jotka eivät näytä eri prosessorien muistiohjaimien välisiä suorituskykyeroja? Ei se väärin ole, mutta älä nyt ainakaan sotke moista toivetta IPC:n ”puhtauteen”. Se IPC on aina järjestelmätason metriikka ja siihen vaikuttaa mm. käytetyt muistit.

 

[tume86]

Eli haluat testata IPC:n sellaisilla softilla jotka eivät näytä eri prosessorien muistiohjaimien välisiä suorituskykyeroja? Ei se väärin ole, mutta älä nyt ainakaan sotke moista toivetta IPC:n ”puhtauteen”. Se IPC on aina järjestelmätason metriikka ja siihen vaikuttaa mm. käytetyt muistit.

Käytännössä kyllä, mutta tässä oli nimenomaa kyse prosessorista ja sen arkkitehtuurista, ei koko järjestelmästä.

 

[pomk]

Käytännössä kyllä, mutta tässä oli nimenomaa kyse prosessorista ja sen arkkitehtuurista, ei koko järjestelmästä.

ajatko montaakin softaa koneellas jotka ei tarvitse a) muistikapuloita ja b) käyttöjärjestelmää? Ja muistiohjaimen arkkitehtuuri on osa prosessorin arkkitehtuuria ja siten prosessoria ei kokonaisuutena testata ellei myös sen muistisuorituskyky ole relevantti ainakin osalle testiohjelmista. IPC on aina järjestelmälle määritetty metriikka. Applen M1 taitaa olla niin pitkälle integroitu kokonaisuus, että järjestelmä = prosessori, mutta nämä epyc prossut ei sellaisia ole.

 

[knz0]

Mitään yleispätevää IPC:tä ei ole olemassakaan, vaan se on aina workload-riippuvainen.

 

[love_doctor]

Asiakas kysyy meidän asiantuntijoiltamme ja vähän pyöritämme lukuja Excelissä: tulee halvemmaksi ostaa paras ST kone, mitä löytyy ja sammuttaa siitä muut ytimet tai tehdä rautatason virtualisointi jossa tietyt ytimet on aina varattu Oracle-virtuaalikoneelle. En tarkalleen muista, kumminpäin tekivät, mutta se ST suorituskyky edellä tässä yhdessä casessa ostettiin kone ja serverimigraation yhteydessä laitettiin Oracle sinne.

Tässäkin kyse on pelkästä lisensoinnin metkuista. Toivottavasti ennen pitkää näissäkin open source mahdollistaa sen, että esim. Postgresiä tai vastaavia käyttämällä voi valita teknisesti parhaat ratkaisut. Voi olla asiakkaalle kokonaisedullisin ja myös kestävän kehityksen ja skaalautumisen kannalta parempi.

 

[tume86]

ajatko montaakin softaa koneellas jotka ei tarvitse a) muistikapuloita ja b) käyttöjärjestelmää? Ja muistiohjaimen arkkitehtuuri on osa prosessorin arkkitehtuuria ja siten prosessoria ei kokonaisuutena testata ellei myös sen muistisuorituskyky ole relevantti ainakin osalle testiohjelmista. IPC on aina järjestelmälle määritetty metriikka. Applen M1 taitaa olla niin pitkälle integroitu kokonaisuus, että järjestelmä = prosessori, mutta nämä epyc prossut ei sellaisia ole.

En ole näin väittänytkään, ja totesin aiemmin, että esim. Cinebench on käytännössä pelkästään prosessorista riippuvainen eikä muistien nopeus vaikuta sen tulokseen (ainakaan merkittävästi). Eihän se tietenkään käytäntöä palvele, jos muistiohjain on susi ja käytännön suorituskyky sakkaa sen takia, vaikka jokin prossuriippuvainen testi antaisikin hyvät tulokset. Kertoo se silti aika aika paljon itse prosessorin arkkitehtuurista, että sen osalta hommat tehty oikein. Sitä paitsi kymmenisen vuotta taaksepäin muistiohjain ei ollut osa prosessoria, vaan erillisellä piirisarjalla.

Et selvästi halua ymmärtää mitä ajan takaa, joten lopetan turhan vääntämisen kanssasi tähän.

 

[love_doctor]

Isoihin CPU:ihin liittyen, tässä oli myös mielenkiintoinen benchmark Ampere Altra -alustasta: Ampere Altra Performance Shows It Can Compete With - Or Even Outperform - AMD EPYC & Intel Xeon - Phoronix

 

[prc]

edit: no toistoahan tämä on jo.

Melkein kaikki kuormat ovat ST-kuormia mitä palvelimissa ajetaan. Niitä vaan ajetaan monta rinnakkain.

...

Okei otetaan uusiksi avaten implisiittiset asiat.

"Veikkaan ST kuormien osuudeksi tuotannossa 0.0%. Eiköhän kaikki ST kuormat ole jotain testejä."

Tässä puhun ST kuormasta prosessorin näkökulmasta (threadeista sen vuoksi, kun CPU valmistajatkin puhuvat threadeista HT/SMT (Hyper-Threading / Simultaneous Multi-Threading)). Softan kannalta ne voi olla toki prosessin threadi tai useampi).

Eli jos prosessorin kontekstissa puhutaan ST kuormasta (unohtaen OS:n omat threadit), niin esim Cinebench ST testi on (lähes (koska OS)) ST kuorma. Josta päästää siihen, että olen aivan varma ettei missään ajeta tuotantokäytössä prosssorin kannalta ST kuormaa 64 Coresella CPUlla. Mikä siis liittyi Hannibalin hymähdykseen yhden ytimen testeistä tämmöisillä prosessoreilla.

Servereihin / Web servereihin en jaksa sen enempää sulkeltaa kun että ensimmäisiä olen rakentanut ja ylläpitänyt puolen vuosikymmentä ja jälkimmäisten päälle olen kirjoitellut niitä tietokantoja ronkkivia ja kötöstä javascript-hötömöä suoltavia softia 10+v, monen muulaisen softan lisäksi.

Eipä tästä enempää.. muutenkin jo niin OT.