Virallinen: AMD vs Intel keskustelu- ja väittelyketju

  • Keskustelun aloittaja Keskustelun aloittaja Sampsa
  • Aloitettu Aloitettu
Sanalla "ainut" viitataan yleensä yhteen, ja "kaikilla muilla" siihen että toista ei ole.

Sinulle on osoitettu jo kaksi eri testiä(NAMD ja Gromacs), joissa 28-ytiminen xeon on melko samaa tasoa 64-ytimisen EPYCin kanssa.
NAMD-testissä yksi EPYC 7702P / EPYC 7742 vastaa suunnilleen kahden Xeon Platinium 8280:n tehoa (kts oheinen kuva).

Mutta en jaksa jankata tästä sen enempää. AMD on tehnyt vahvan paluun palvelinprosessoreihin ja tulee tekemään huiman nousun markkinaosuudessa. Kilpailu on aina hyväksi ja nyt kilpailu on palannut markkinaan. Intelin on pakko julkistaa suuret hinnanalennukset koko tuotevalikoimaansa.

AMD-EPYC-7002-NAMD-Benchmarks.jpg
 
Menee kummalliseksi jankkaukseksi tämä näin maallikon näkökulmasta, ellei serveri-asiantuntijat tule kertomaan mikä etu saavutetaan pienemällä ydinmäärällä kun sekä tehonkulutuksessa että hinnassa AMD:n isompi ydinmäärä selvästikin vie.

Asia ei ole selvä ja yksiselitteinen suorituskyvyn suhteen, koska testien mukaan intel pärjää tietyissä kuormissa.

Jotta asia olisi yksiselitteinen, niin AMD:n täytyy petrata tuon AVX2 tuen kanssa nyt ainankin. (JA myös tuolla suorituskyvylle pelien kaltaisissa kuormissa täytyy tehdä jotain, mielellään senverran nopeasti, ettei Intel kerkeä julkaista ihan yleisesti mitään suorituskykyisempää ulos.)
 
Menee kummalliseksi jankkaukseksi tämä näin maallikon näkökulmasta, ellei serveri-asiantuntijat tule kertomaan mikä etu saavutetaan pienemällä ydinmäärällä kun sekä tehonkulutuksessa että hinnassa AMD:n isompi ydinmäärä selvästikin vie.
Pienemmän ydinmäärän etu on olemassa tilanteissa, jossa jokin tuote (esim. tietokanta) on lisensoitu prosessoriytimien määrän mukaan ja yrität saada mahdollisimman pienellä ydinmäärällä mahdollisimman suuren suorituskyvyn välttääkseksi kalliit lisenssihankinnat.

Samaan aikaan tietyt valmistajat (esim. Oracle) eivät hyväksy virtuaalisointiohjelmistolla (muulla kuin omallaan) tehtyä partitiointia, vaan haluaa lisenssimaksun palvelimen kaikista ytimistä vaikka vain osa ytimistä olisi ko. ohjelmistotuotteen käytössä.

Näissä tilanteissa voi Intel olla edelleen vahvoilla.
 
Pienemmän ydinmäärän etu on olemassa tilanteissa, jossa jokin tuote (esim. tietokanta) on lisensoitu prosessoriytimien määrän mukaan ja yrität saada mahdollisimman pienellä ydinmäärällä mahdollisimman suuren suorituskyvyn välttääkseksi kalliit lisenssihankinnat.

Samaan aikaan tietyt valmistajat (esim. Oracle) eivät hyväksy virtuaalisointiohjelmistolla tehtyä partitiointia, vaan haluaa lisenssimaksun palvelimen kaikista ytimistä vaikka vain osa ytimistä olisi ko. ohjelmistotuotteen käytössä.

Näissä tilanteissa voi Intel olla edelleen vahvoilla.

Onko sinulla tai kellään muullakaan ideaa kuinka kalliita nämä lisenssit ovat (voivat olla)? Olisi kiva tietää kuinka kilpailukykyisiä AMD:n epycit ovat käyttökustannuksiltaan.
 
Onko sinulla tai kellään muullakaan ideaa kuinka kalliita nämä lisenssit ovat (voivat olla)? Olisi kiva tietää kuinka kilpailukykyisiä AMD:n epycit ovat käyttökustannuksiltaan.
Esimerkiksi SQL Server 2017 Enterprise edition maksaa luokkaa 15000 euroa per kaksi ydintä. Eli yhden prosessorin 64-core EPYC-palvelimen lisensointi em. tuotteella maksaa melkein puoli miljoonaa.

Suuret yritysasiakkaat saavat tuon hieman halvemmalla, mutta saat tästä käsityksen missä liikutaan.

Microsoft SQL Server 2017 Enterprise | Dustin.fi
 
Viimeksi muokattu:
NAMD-testissä yksi EPYC 7702P / EPYC 7742 vastaa suunnilleen kahden Xeon Platinium 8280:n tehoa (kts oheinen kuva).

Vain, kun intelin suorituskyky cripplataan sillä ettei käytetä AV-512stä

Mutta en jaksa jankata tästä sen enempää. AMD on tehnyt vahvan paluun palvelinprosessoreihin ja tulee tekemään huiman nousun markkinaosuudessa. Kilpailu on aina hyväksi ja nyt kilpailu on palannut markkinaan. Intelin on pakko julkistaa suuret hinnanalennukset koko tuotevalikoimaansa.

AMD-EPYC-7002-NAMD-Benchmarks.jpg

Kyseisessä kuvassa/sen tuloksissa ei ole käytetty AVX-512sta

Laitoin tänne pari viestiä aiemmin linkin testiin jossa NAMDissa oli käyettty AVX-512ssta, ja tällöin 28-ytiminen zeon oli tuota nopeampi.

Tässä vielä uudestaan (kolmannen kerran) linkki Anandin testiiin, jossa on käytetty AVX-512sta

AMD Rome Second Generation EPYC Review: 2x 64-core Benchmarked

Laitetaan vielä se käppyrä suoraankin, jos linkin klikkaaminen on liian vaivalloista:

87250v212Epyc2.png
 
Vain, kun intelin suorituskyky cripplataan sillä ettei käytetä AV-512stä

Kyseisessä kuvassa ei ole käytetty AVX-512sta

Laitoin tänne pari viestiä aiemmin linkin testiin jossa NAMDissa oli käyettty AVX-512ssta, ja tällöin 28-ytiminen zeon oli tuota nopeampi.

Tässä vielä uudestaan linkki Anandin testiiin, jossa on käytetty AVX-512sta

AMD Rome Second Generation EPYC Review: 2x 64-core Benchmarked
Edelleenkin on kyse siitä AVX-512-testiskenaariosta. Ja edelleenkin EPYCillä on ko. testissä 2x hintaetu Inteliin samalla suorityskyvyllä. Miksi hankkisit Inteleitä AVX-512-numeronmurskaukseen, jos joudut maksamaan siitä ilosta kaksinkertaisesti?
 
Edelleenkin on kyse siitä AVX-512-testiskenaariosta. Ja edelleenkin EPYCillä on ko. testissä 2x hintaetu Inteliin samalla suorityskyvyllä.

:facepalm:

Kyse on AVX-512-testiskenaariosta niin sinä postasit tuloksia, joissa ei ollut käytetty AVX-512sta.

STHn NAMD-testissä ei käytetty AVX512sta, Anandin NAMD-testissä käytettiin.
 
Pienemmän ydinmäärän etu on olemassa tilanteissa, jossa jokin tuote (esim. tietokanta) on lisensoitu prosessoriytimien määrän mukaan ja yrität saada mahdollisimman pienellä ydinmäärällä mahdollisimman suuren suorituskyvyn välttääkseksi kalliit lisenssihankinnat.

Samaan aikaan tietyt valmistajat (esim. Oracle) eivät hyväksy virtuaalisointiohjelmistolla tehtyä partitiointia, vaan haluaa lisenssimaksun palvelimen kaikista ytimistä vaikka vain osa ytimistä olisi ko. ohjelmistotuotteen käytössä.

Näissä tilanteissa voi Intel olla edelleen vahvoilla.
Näissä tilanteissa päästään sitten korkeintaan puoleen suortuskykyyn 28c Xeon vs. 64c EPYC.
Samaan suorituskykyyn päästään sitten 2x28c Xeon vs 64c EPYC, jolloin corepohjaisten lisenssien hinta onkin lähellä toisiaan.

Jos sitten katsotaan tarkemmin niin EPYC tukee PCIe Gen 4, mutta Xeon PCIe Gen3.
Jos tarkoituksena on sama suorituskyky esim SSD-levyillä, joudutaan Xeoneihin laittamaan tuplamäärä SSD-levyjä. Ja jos PCIe-kapasiteetti ei riitäkkään kaikille palvelimessa tarvittaville SSD-levyille, joudutaan Xeonin kohdalla siirtymään 4P -ratkaisuun -> 4x 28c.
Effektiivinen PCIe Gen3-kapasiteetti kun yhdessä EPYC-palvelimessa suurempi kuin 4p Xeon-palvelimessa.
Ja lisäksi, laitevalmistajat voivat konfiguroida 2P EPYC-ratkaisunsa sellaiseksi, että siinä käytössä 160 PCIe-kanavaa vakio 128 kanavan sijaan.
upload_2019-8-9_13-51-9.png
 
Näissä tilanteissa päästään sitten korkeintaan puoleen suortuskykyyn 28c Xeon vs. 64c EPYC.
Samaan suorituskykyyn päästään sitten 2x28c Xeon vs 64c EPYC, jolloin corepohjaisten lisenssien hinta onkin lähellä toisiaan.
Kyllä, mutta tällä hetkellä Intelillä on tarjolla pienemmällä ydinmäärällä EPYCejä korkeammalle kellotettuja Xeoneita. Kun optimoidaan lisenssikustannusta pienellä core-lisenssimäärällä, ovat nämä palvelimet ihan hyvä vaihtoehto.
 
Kyllä, mutta tällä hetkellä Intelillä on tarjolla pienemmällä ydinmäärällä EPYCejä korkeammalle kellotettuja Xeoneita. Kun optimoidaan lisenssikustannusta pienellä core-lisenssimäärällä, ovat nämä palvelimet ihan hyvä vaihtoehto.
Tietokantapalvelimissa levyoperaatiot / IO-kapasiteetti on se keskeisin rajoite - ei prosessorin kellotaajuus tai edes prosessorin suorityskyky.
EPYCcejäkin saa 8c versioina - ja varsin halvalla, jolloin eroa Xeon-lisenssikustannuksiin ei tulekaan.
Ja näissä halvoissa EPYC-palvelimissa on edelleen sama 128PCIe Gen 4 -kanavaa käytettävissä SSD-levyihin tai muuhun tarpeelliseen.
 
Ei ole ainut.

Tässä toinen. Tämän jo joku juuri pari viestiä sitten tänne postasi, mutta et ilmeisesti huomannut.

upload_2019-8-9_12-56-14-png.260461


Vaikuttaisi pikemminkin siltä, että aina kun softa koostuu lähinnä järeästä numeronmurskauksesta, ja se voidaan tehdä AVX-512lla, tuo 28-ytiminen xeon vastaa melko hyvin tuota 64-ytimistä EPYCiaä

AVX-512 on oikeasti kiva juttu.

Mitä sä nyt höpötät. Lue se arvostelu, Intel häviää tässä murskaluvuin 40% korkeammalla virrankulutuksellaan!
 
Tietokantapalvelimissa levyoperaatiot / IO-kapasiteetti on se keskeisin rajoite - ei prosessorin kellotaajuus tai edes prosessorin suorityskyky.
EPYCcejäkin saa 8c versioina - ja varsin halvalla, jolloin eroa Xeon-lisenssikustannuksiin ei tulekaan.
Ja näissä halvoissa EPYC-palvelimissa on edelleen sama 128PCIe Gen 4 -kanavaa käytettävissä SSD-levyihin tai muuhun tarpeelliseen.
EPYC 8c 7232P:n kellot ovat 2.8 / 3.2 Ghz. Intelin Xeon E5-1680 v4:n turbo-kellot (noin esimerkiksi) menevät 4 Ghz:iin. Lisäksi Intelillä on vielä pieni yhden coren tehoetu. Jos halutaan viimeisiä tehoja irti 8 coren palvelimista, on Intel edelleen varteenotettava vaihtoehto.

Mitä tulee levyihin, niin yrityskäytössä kannat tallennetaan edelleen voittopuolisesti ulkoisiin levyjärjestelmiin. Riittävän isolla muistilla saadaan merkittävänkin kokoiset kannat mahtumaan palvelimen keskusmuistiin, jolloin IO-suorituskyvyn merkitys vähenee.
 
EPYC 8c 7232P:n kellot ovat 2.8 / 3.2 Ghz. Intelin Xeon E5-1680 v4:n turbo-kellot (noin esimerkiksi) menevät 4 Ghz:iin. Lisäksi Intelillä on vielä pieni yhden coren tehoetu. Jos halutaan viimeisiä tehoja irti 8 coren palvelimista, on Intel edelleen varteenotettava vaihtoehto.

Mitä tulee levyihin, niin yrityskäytössä kannat tallennetaan edelleen voittopuolisesti ulkoisiin levyjärjestelmiin. Riittävän isolla muistilla saadaan merkittävänkin kokoiset kannat mahtumaan palvelimen keskusmuistiin, jolloin IO-suorituskyvyn merkitys vähenee.
Ja kun se tietokanta pitää koko ajan varmistaa RAMmista ulkoisiin levyjärjestelmiin, tulee eteen taas yksi Xeonin / PCIe Gen3:n pullonkaula:
ps. EPYCit tukevat suurempaa keskusmuistia kuin Xeonit. Xeonin (paljon vakiomallia kalliimmilla) L-versioilla päästään samaan muistikapasiteettiin, ja silloinkin osa RAMmista pitää korvata Optane -muisteilla.
56C Xeonit eivät tue muuten Optanea ollenkaan, ja ne sallivat vain 1DIMM/muistikanava -> keskusmuistin maksimimäärä on puolet 28c Xeonin muistikapasiteetista.
upload_2019-8-9_14-28-5.png
 
EPYC 8c 7232P:n kellot ovat 2.8 / 3.2 Ghz. Intelin Xeon E5-1680 v4:n turbo-kellot (noin esimerkiksi) menevät 4 Ghz:iin. Lisäksi Intelillä on vielä pieni yhden coren tehoetu. Jos halutaan viimeisiä tehoja irti 8 coren palvelimista, on Intel edelleen varteenotettava vaihtoehto.

Mitä tulee levyihin, niin yrityskäytössä kannat tallennetaan edelleen voittopuolisesti ulkoisiin levyjärjestelmiin. Riittävän isolla muistilla saadaan merkittävänkin kokoiset kannat mahtumaan palvelimen keskusmuistiin, jolloin IO-suorituskyvyn merkitys vähenee.
Jos IO:lla ei ole merkitystä, niin yhtä hyvin sitten voi käyttää vaikka ryzen pro:ta joka pieksee ton xeonin 8 core suorituskyvyssä mennen tullen tukien kuitenkin ECC muisteja. Jos taas muistikanavia tarvitaan syystä tai toisesta neljä tai PCIe väyliä 24-48, niin tuleva threadripper hoitaa homman kotiin varmasti paremmin ja halvemmalla (biossista ylimääräiset coret vaan pois päältä).
 
Jos IO:lla ei ole merkitystä, niin yhtä hyvin sitten voi käyttää vaikka ryzen pro:ta joka pieksee ton xeonin 8 core suorituskyvyssä mennen tullen tukien kuitenkin ECC muisteja. Jos taas muistikanavia tarvitaan syystä tai toisesta neljä tai PCIe väyliä 24-48, niin tuleva threadripper hoitaa homman kotiin varmasti paremmin ja halvemmalla (biossista ylimääräiset coret vaan pois päältä).
Yrityskantoja harvemmin ajetaan muilla kuin kantavalmistajan sertifioimilla alustoilla. Esimerkiksi Oraclea ei tulla koskaan sertifioimaan Threadripperille.

Ja tietysti ECC-muisti on palvelinkäytössä aina välttämättömyys.
 
Ei ole ainut.

Tässä toinen. Tämän jo joku juuri pari viestiä sitten tänne postasi, mutta et ilmeisesti huomannut.

upload_2019-8-9_12-56-14-png.260461


Vaikuttaisi pikemminkin siltä, että aina kun softa koostuu lähinnä järeästä numeronmurskauksesta, ja se voidaan tehdä AVX-512lla, tuo 28-ytiminen xeon vastaa melko hyvin tuota 64-ytimistä EPYCiaä

AVX-512 on oikeasti kiva juttu.

No jos kivana juttuna pitää sitä että se intel kokoonpano kuluttaa 40% enemmän sähköä tarjoten saman suorituskyvyn niin eihän siinä sitten mitään.

Jotta asia olisi yksiselitteinen, niin AMD:n täytyy petrata tuon AVX2 tuen kanssa nyt ainankin. (JA myös tuolla suorituskyvylle pelien kaltaisissa kuormissa täytyy tehdä jotain, mielellään senverran nopeasti, ettei Intel kerkeä julkaista ihan yleisesti mitään suorituskykyisempää ulos.)

Miksi tarvii? AMD pystyy tarjoamaan nyt saman AVX tehon dual socket alustalla kuin intel, kuluttaen huomattavasti vähemmän energiaa ja maksaen huomattavasti vähemmän. Eli mielestäni tässä ei ole mitään ongelmaa. Tuolla datacenter puolella sillä sähkönkulutuksella on väliä. Tähän kun lisätään vielä jäähdytys tarve, niin yht äkkiää tollainen AMD kokoonpano onkin varsin erinomainen valinta myös siihen numeronmurskaukseen.
 
Yrityskantoja harvemmin ajetaan muilla kuin kantavalmistajan sertifioimilla alustoilla. Esimerkiksi Oraclea ei tulla koskaan sertifioimaan Threadripperille.

Ja tietysti ECC-muisti on palvelinkäytössä aina välttämättömyys.

Oraclen suosio onkin kokoajan tippunut ja MySQL kasvanut näillä näkymin MySQL nousee maailman suurimmaksi tietokanta arkkitehtuuriksi maailmassa tässä puolen vuoden sisällä. Myös muut opensource tietokannat kasvat nopeammin suosiossa PostgreSQL, MongoDB ja MariaDB. Kaupallisten tietokanta alustojen markkinaosuus on tippunut taisaisesti jo 5 vuotta ja se on jämähtänyt sellaiseksi selviämistaisteluksi jossa markkinaosuus taantuu hitaasti mutta varmasti vuodesta toiseen.

Ei tarvitse Oraclen kohta optimoida tuotteitaan Intelillekään. Kasvavat talousmahdit kuten Kiina ja Intia lisäävät vielä open source tietokantojen suosiota, koska nämä maat haluvat välttää riippuvuutta jenkki tekniikasta kuin ruttoa aina kun vain mahdollista. Muuten tulee Trump ja pistää järjestelmät poikki, mutta jos järjestelmät on rakennettu open source tietokantojen varaan ei Trumpin kaltaiset ailahtelevat johtajat voi estää niiden käyttöä.

Sanoisin, että 2025 mennessä Oracle on taantunut lähes täysin pois markkinoilta näillä näkymin yksikään järkevä talous ei sen varaan rakenna järjestelmiään. Kun ottaa huomioon nämä kiristämiset ja kauppasodat mitä siitä seuraa.
 
Onpas täällä taas kuhinaa...AMD paluulla on näin myös sosiaalistava vaikutus. :)
Ei siinä, hyviä tuotteita ovat tuoneet markkinoille ja sen kyllä näkee uutissyötteissä; joka paikasta tursuaa nyt Rome-artikkelia eli kyllä AMD on nyt jotain oikein tehnyt. Vielä @hkultala kommenttiin jossa puolusteltiin Intelin liiketoimintastrategiaa, niin se että kilpailijaa ei liiskata monopolisyytöspelkojen takia, ei ole mielestäni mikään puolustusargumentti. Terveessä kilpailussa se pienempi kilpailija jää jalkoihin tai ostetaan pois. Olisi se kyllä ollut mielenkiintoista nähdä miten Intel olisi saatu pilkottua jos AMD:n olisivat saanee pois häiritsemästä. Jotain seuraamuksia olisi kyllä varmasti tullut.

Toisekseen ei tehdä nyt tuosta AVX-512:sta mitään härkästä. Sillä on paikkansa etenkin HPC-puolella ja kotikoneissa esim. videonpakkauksessa, mutta muualla käytännön nopeushyödyt tahtovat olla hyvinkin maltillisia. Samoin Intelin AVX-offset-toiminto throttlaa prossun kellot nopeasti alas kun AVX-kuormaa tulee, mikä voi tehdä hybridikuorman ajamisesta vaikeasti ennustettavaa. AMD:n malli on mielestäni parempi eli kellot throttlaa myös AVX-kuormassa suoraan lämpökuorman mukaan, eikä keinotekoisesti jollain offsetilla. Toisekseen Intel ei itsekään tee kovin hyvää työtä tuon AVX:n populoinnissa, koska AVX-512 instruction setit vaihtelevat per prosessori ja Pentium/Celeron-prossut eivät vieläkään tue sitä. Sovelluskehityksessä siis saadaan odotella vielä melko pitkän aikaa että markkinoilla on tarpeeksi AVX-512-rautaa jotta sen varaan alettaisiin isommin rakentelemaan. Nyt alkaa vasta olemaan pelejä esim. AC Odyssey, joka vaatii ylipäätään AVX:ää eli peliä ei saa käyntiin jos on vaikka sen 10v vanha i7 920. Toisaalta Ubisoft ilmoitti että on kehittämässä peliin patchiä, jolla voi pelata myös ilman AVX:ää.

Oraclen suosio onkin kokoajan tippunut ja MySQL kasvanut näillä näkymin MySQL nousee maailman suurimmaksi tietokanta arkkitehtuuriksi maailmassa tässä puolen vuoden sisällä. Myös muut opensource tietokannat kasvat nopeammin suosiossa PostgreSQL, MongoDB ja MariaDB. Kaupallisten tietokanta alustojen markkinaosuus on tippunut taisaisesti jo 5 vuotta ja se on jämähtänyt sellaiseksi selviämistaisteluksi jossa markkinaosuus taantuu hitaasti mutta varmasti vuodesta toiseen.

Ei tarvitse Oraclen kohta optimoida tuotteitaan Intelillekään. Kasvavat talousmahdit kuten Kiina ja Intia lisäävät vielä open source tietokantojen suosiota, koska nämä maat haluvat välttää riippuvuutta jenkki tekniikasta kuin ruttoa aina kun vain mahdollista. Muuten tulee Trump ja pistää järjestelmät poikki, mutta jos järjestelmät on rakennettu open source tietokantojen varaan ei Trumpin kaltaiset ailahtelevat johtajat voi estää niiden käyttöä.

Sanoisin, että 2025 mennessä Oracle on taantunut lähes täysin pois markkinoilta näillä näkymin yksikään järkevä talous ei sen varaan rakenna järjestelmiään. Kun ottaa huomioon nämä kiristämiset ja kauppasodat mitä siitä seuraa.
MySQL:n suosio kasvaa joo, mutta sillä on edelleen Oracle-leima, josta moni ei tykkää. Sen takia monet isot jätit esim. Google ja Wikipedia ovat konvertoineet MySQL:nsä MariaDB:hen, joka siis on Monty Wideniuksen spin-off tuosta MySQL:stä. Ilmeisesti ukko ei tykännyt Oraclen kulttuuurista, lähti pois ja rakensi sitten jokseenkin täysin MySQL-yhteensopivan MariaDB-tietokantamoottorin. Nythän tuo MariaDB on esim. Redhatin repositoryissä jo oletuksena ja asentuu MySQL:n sijaan ja toimii hienosti vaikka osissa komennoista lukee vielä MySQL MariaDB:n sijaan.

Oraclen tietokannat eivät tule häviämään vielä pitkään aikaan. Nytkin niitä asennetaan pilvin pimein nimenomaan isoihin tuotantokriittisiin (lue pitkäikäisiin) järjestelmiin. Oracle on erittäin taitava tekemään diilejä isojen softatalojen kanssa tarkoittaen sitä, että se Oraclen tietokanta tulee usein ikään kuin varkain taloon, koska joku iso softajärjestelmä tukee sitä parhaiten tai kanta tulee sen kylkiäisenä. Open source-kannat kyllä kasvattavat jatkuvasti markkina-asemiaan, mutta isommat jo vuosia Oraclella tai DB2:lla ajaneet yritykset eivät helpolla lähde kantojaan konvertoimaan. Vaikka SQL:ää jokseenkin kaikki relaatiotietokannat puhuvat, niin tietokannan konverointi vaikka jossain pankkijärjestelmässä on verrattavissa johonkin sydämen vaihtoon, koska sen verran tiukasti ne ovat integroituneet ajan saatossa noihin ympäröiviin järjestelmiin.

Muuten kyllä samaa mieltä, että tämä Trumpin meuhkaaminen on ollut todellinen piristysruiske open source-skenelle. Esimerkiksi Risc-V:tä puhalletaan nyt pystyyn ja muutenkin kaikki vähänkään pidemmälle miettivät päätöksentekijät pyrkivät vähentämään riippuvuuttaan USA:n teknologiasta jos vain mahdollista.
 
Viimeksi muokattu:
Vaikka SQL:ää jokseenkin kaikki relaatiotietokannat puhuvat, niin tietokannan konverointi vaikka jossain pankkijärjestelmässä on verrattavissa johonkin sydämen vaihtoon, koska sen verran tiukasti ne ovat integroituneet ajan saatossa noihin ympäröiviin järjestelmiin.

MariaDB on suora dropin mysql:lle, eli mitään konvertointia ei tarvita. Tästä syystä mariadb myös käyttää mysql nimiä komennoissa, conffit on tismalleen samat.

Koodi:
[jiipee@box ~]$ rpm -ql mariadb
/etc/my.cnf.d/client.cnf
/usr/bin/aria_chk
/usr/bin/aria_dump_log
/usr/bin/aria_ftdump
/usr/bin/aria_pack
/usr/bin/aria_read_log
/usr/bin/msql2mysql
/usr/bin/my_print_defaults
/usr/bin/mysql
/usr/bin/mysql_find_rows
/usr/bin/mysql_waitpid
/usr/bin/mysqlaccess
/usr/bin/mysqladmin
/usr/bin/mysqlbinlog
/usr/bin/mysqlcheck
/usr/bin/mysqldump
/usr/bin/mysqlimport
/usr/bin/mysqlshow
/usr/bin/mysqlslap
/usr/share/doc/mariadb-5.5.60
/usr/share/doc/mariadb-5.5.60/COPYING
/usr/share/doc/mariadb-5.5.60/COPYING.Google
/usr/share/doc/mariadb-5.5.60/COPYING.Percona
/usr/share/doc/mariadb-5.5.60/README
/usr/share/doc/mariadb-5.5.60/README.mysql-docs
/usr/share/doc/mariadb-5.5.60/README.mysql-license
/usr/share/man/man1/aria_chk.1.gz
/usr/share/man/man1/aria_dump_log.1.gz
/usr/share/man/man1/aria_ftdump.1.gz
/usr/share/man/man1/aria_pack.1.gz
/usr/share/man/man1/aria_read_log.1.gz
/usr/share/man/man1/my_print_defaults.1.gz
/usr/share/man/man1/mysql.1.gz
/usr/share/man/man1/mysql_find_rows.1.gz
/usr/share/man/man1/mysql_waitpid.1.gz
/usr/share/man/man1/mysqlaccess.1.gz
/usr/share/man/man1/mysqladmin.1.gz
/usr/share/man/man1/mysqldump.1.gz
/usr/share/man/man1/mysqlshow.1.gz
/usr/share/man/man1/mysqlslap.1.gz

[jiipee@box ~]$ rpm -ql mariadb-server
/etc/logrotate.d/mariadb
/etc/my.cnf.d/server.cnf
/usr/bin/innochecksum
/usr/bin/myisam_ftdump
/usr/bin/myisamchk
/usr/bin/myisamlog
/usr/bin/myisampack
/usr/bin/mysql_convert_table_format
/usr/bin/mysql_fix_extensions
/usr/bin/mysql_install_db
/usr/bin/mysql_plugin
/usr/bin/mysql_secure_installation
/usr/bin/mysql_setpermission
/usr/bin/mysql_tzinfo_to_sql
/usr/bin/mysql_upgrade
/usr/bin/mysql_zap
/usr/bin/mysqlbug
/usr/bin/mysqld_multi
/usr/bin/mysqld_safe
/usr/bin/mysqld_safe_helper
/usr/bin/mysqldumpslow
/usr/bin/mysqlhotcopy
/usr/bin/mysqltest
/usr/bin/perror
/usr/bin/replace
/usr/bin/resolve_stack_dump
/usr/bin/resolveip
/usr/lib/systemd/system/mariadb.service
/usr/lib/tmpfiles.d/mariadb.conf
/usr/lib64/mysql/INFO_BIN
/usr/lib64/mysql/INFO_SRC
/usr/lib64/mysql/mysqlbug
/usr/lib64/mysql/plugin
/usr/lib64/mysql/plugin/adt_null.so
/usr/lib64/mysql/plugin/auth_0x0100.so
/usr/lib64/mysql/plugin/auth_pam.so
/usr/lib64/mysql/plugin/auth_socket.so
/usr/lib64/mysql/plugin/auth_test_plugin.so
/usr/lib64/mysql/plugin/daemon_example.ini
/usr/lib64/mysql/plugin/dialog_examples.so
/usr/lib64/mysql/plugin/ha_innodb.so
/usr/lib64/mysql/plugin/ha_sphinx.so
/usr/lib64/mysql/plugin/handlersocket.so
/usr/lib64/mysql/plugin/libdaemon_example.so
/usr/lib64/mysql/plugin/mypluglib.so
/usr/lib64/mysql/plugin/qa_auth_client.so
/usr/lib64/mysql/plugin/qa_auth_interface.so
/usr/lib64/mysql/plugin/qa_auth_server.so
/usr/lib64/mysql/plugin/query_cache_info.so
/usr/lib64/mysql/plugin/semisync_master.so
/usr/lib64/mysql/plugin/semisync_slave.so
/usr/lib64/mysql/plugin/server_audit.so
/usr/lib64/mysql/plugin/sphinx.so
/usr/lib64/mysql/plugin/sql_errlog.so
/usr/libexec/mariadb-prepare-db-dir
/usr/libexec/mariadb-wait-ready
/usr/libexec/mysqld
/usr/share/man/man1/innochecksum.1.gz
/usr/share/man/man1/msql2mysql.1.gz
/usr/share/man/man1/myisam_ftdump.1.gz
/usr/share/man/man1/myisamchk.1.gz
/usr/share/man/man1/myisamlog.1.gz
/usr/share/man/man1/myisampack.1.gz
/usr/share/man/man1/mysql.server.1.gz
/usr/share/man/man1/mysql_convert_table_format.1.gz
/usr/share/man/man1/mysql_fix_extensions.1.gz
/usr/share/man/man1/mysql_install_db.1.gz
/usr/share/man/man1/mysql_plugin.1.gz
/usr/share/man/man1/mysql_secure_installation.1.gz
/usr/share/man/man1/mysql_setpermission.1.gz
/usr/share/man/man1/mysql_tzinfo_to_sql.1.gz
/usr/share/man/man1/mysql_upgrade.1.gz
/usr/share/man/man1/mysql_zap.1.gz
/usr/share/man/man1/mysqlbinlog.1.gz
/usr/share/man/man1/mysqlbug.1.gz
/usr/share/man/man1/mysqlcheck.1.gz
/usr/share/man/man1/mysqld_multi.1.gz
/usr/share/man/man1/mysqld_safe.1.gz
/usr/share/man/man1/mysqldumpslow.1.gz
/usr/share/man/man1/mysqlhotcopy.1.gz
/usr/share/man/man1/mysqlimport.1.gz
/usr/share/man/man1/mysqltest.1.gz
/usr/share/man/man1/perror.1.gz
/usr/share/man/man1/replace.1.gz
/usr/share/man/man1/resolve_stack_dump.1.gz
/usr/share/man/man1/resolveip.1.gz
/usr/share/man/man8/mysqld.8.gz
/usr/share/mysql/README.mysql-cnf
/usr/share/mysql/errmsg-utf8.txt
/usr/share/mysql/fill_help_tables.sql
/usr/share/mysql/my-huge.cnf
/usr/share/mysql/my-innodb-heavy-4G.cnf
/usr/share/mysql/my-large.cnf
/usr/share/mysql/my-medium.cnf
/usr/share/mysql/my-small.cnf
/usr/share/mysql/mysql_performance_tables.sql
/usr/share/mysql/mysql_system_tables.sql
/usr/share/mysql/mysql_system_tables_data.sql
/usr/share/mysql/mysql_test_data_timezone.sql
/var/lib/mysql
/var/log/mariadb
/var/log/mariadb/mariadb.log
/var/run/mariadb

Tuossa siis CentOS 7 tarjoaman mariadb ja mariadb-server rpm pakettien asentamat tiedostot listattuna. Noudattaa täysin samaa rakennetta kuin mysql.
 
MariaDB on suora dropin mysql:lle, eli mitään konvertointia ei tarvita. Tästä syystä mariadb myös käyttää mysql nimiä komennoissa, conffit on tismalleen samat.

Koodi:
[jiipee@box ~]$ rpm -ql mariadb
/etc/my.cnf.d/client.cnf
/usr/bin/aria_chk
/usr/bin/aria_dump_log
/usr/bin/aria_ftdump
/usr/bin/aria_pack
/usr/bin/aria_read_log
/usr/bin/msql2mysql
/usr/bin/my_print_defaults
/usr/bin/mysql
/usr/bin/mysql_find_rows
/usr/bin/mysql_waitpid
/usr/bin/mysqlaccess
/usr/bin/mysqladmin
/usr/bin/mysqlbinlog
/usr/bin/mysqlcheck
/usr/bin/mysqldump
/usr/bin/mysqlimport
/usr/bin/mysqlshow
/usr/bin/mysqlslap
/usr/share/doc/mariadb-5.5.60
/usr/share/doc/mariadb-5.5.60/COPYING
/usr/share/doc/mariadb-5.5.60/COPYING.Google
/usr/share/doc/mariadb-5.5.60/COPYING.Percona
/usr/share/doc/mariadb-5.5.60/README
/usr/share/doc/mariadb-5.5.60/README.mysql-docs
/usr/share/doc/mariadb-5.5.60/README.mysql-license
/usr/share/man/man1/aria_chk.1.gz
/usr/share/man/man1/aria_dump_log.1.gz
/usr/share/man/man1/aria_ftdump.1.gz
/usr/share/man/man1/aria_pack.1.gz
/usr/share/man/man1/aria_read_log.1.gz
/usr/share/man/man1/my_print_defaults.1.gz
/usr/share/man/man1/mysql.1.gz
/usr/share/man/man1/mysql_find_rows.1.gz
/usr/share/man/man1/mysql_waitpid.1.gz
/usr/share/man/man1/mysqlaccess.1.gz
/usr/share/man/man1/mysqladmin.1.gz
/usr/share/man/man1/mysqldump.1.gz
/usr/share/man/man1/mysqlshow.1.gz
/usr/share/man/man1/mysqlslap.1.gz

[jiipee@box ~]$ rpm -ql mariadb-server
/etc/logrotate.d/mariadb
/etc/my.cnf.d/server.cnf
/usr/bin/innochecksum
/usr/bin/myisam_ftdump
/usr/bin/myisamchk
/usr/bin/myisamlog
/usr/bin/myisampack
/usr/bin/mysql_convert_table_format
/usr/bin/mysql_fix_extensions
/usr/bin/mysql_install_db
/usr/bin/mysql_plugin
/usr/bin/mysql_secure_installation
/usr/bin/mysql_setpermission
/usr/bin/mysql_tzinfo_to_sql
/usr/bin/mysql_upgrade
/usr/bin/mysql_zap
/usr/bin/mysqlbug
/usr/bin/mysqld_multi
/usr/bin/mysqld_safe
/usr/bin/mysqld_safe_helper
/usr/bin/mysqldumpslow
/usr/bin/mysqlhotcopy
/usr/bin/mysqltest
/usr/bin/perror
/usr/bin/replace
/usr/bin/resolve_stack_dump
/usr/bin/resolveip
/usr/lib/systemd/system/mariadb.service
/usr/lib/tmpfiles.d/mariadb.conf
/usr/lib64/mysql/INFO_BIN
/usr/lib64/mysql/INFO_SRC
/usr/lib64/mysql/mysqlbug
/usr/lib64/mysql/plugin
/usr/lib64/mysql/plugin/adt_null.so
/usr/lib64/mysql/plugin/auth_0x0100.so
/usr/lib64/mysql/plugin/auth_pam.so
/usr/lib64/mysql/plugin/auth_socket.so
/usr/lib64/mysql/plugin/auth_test_plugin.so
/usr/lib64/mysql/plugin/daemon_example.ini
/usr/lib64/mysql/plugin/dialog_examples.so
/usr/lib64/mysql/plugin/ha_innodb.so
/usr/lib64/mysql/plugin/ha_sphinx.so
/usr/lib64/mysql/plugin/handlersocket.so
/usr/lib64/mysql/plugin/libdaemon_example.so
/usr/lib64/mysql/plugin/mypluglib.so
/usr/lib64/mysql/plugin/qa_auth_client.so
/usr/lib64/mysql/plugin/qa_auth_interface.so
/usr/lib64/mysql/plugin/qa_auth_server.so
/usr/lib64/mysql/plugin/query_cache_info.so
/usr/lib64/mysql/plugin/semisync_master.so
/usr/lib64/mysql/plugin/semisync_slave.so
/usr/lib64/mysql/plugin/server_audit.so
/usr/lib64/mysql/plugin/sphinx.so
/usr/lib64/mysql/plugin/sql_errlog.so
/usr/libexec/mariadb-prepare-db-dir
/usr/libexec/mariadb-wait-ready
/usr/libexec/mysqld
/usr/share/man/man1/innochecksum.1.gz
/usr/share/man/man1/msql2mysql.1.gz
/usr/share/man/man1/myisam_ftdump.1.gz
/usr/share/man/man1/myisamchk.1.gz
/usr/share/man/man1/myisamlog.1.gz
/usr/share/man/man1/myisampack.1.gz
/usr/share/man/man1/mysql.server.1.gz
/usr/share/man/man1/mysql_convert_table_format.1.gz
/usr/share/man/man1/mysql_fix_extensions.1.gz
/usr/share/man/man1/mysql_install_db.1.gz
/usr/share/man/man1/mysql_plugin.1.gz
/usr/share/man/man1/mysql_secure_installation.1.gz
/usr/share/man/man1/mysql_setpermission.1.gz
/usr/share/man/man1/mysql_tzinfo_to_sql.1.gz
/usr/share/man/man1/mysql_upgrade.1.gz
/usr/share/man/man1/mysql_zap.1.gz
/usr/share/man/man1/mysqlbinlog.1.gz
/usr/share/man/man1/mysqlbug.1.gz
/usr/share/man/man1/mysqlcheck.1.gz
/usr/share/man/man1/mysqld_multi.1.gz
/usr/share/man/man1/mysqld_safe.1.gz
/usr/share/man/man1/mysqldumpslow.1.gz
/usr/share/man/man1/mysqlhotcopy.1.gz
/usr/share/man/man1/mysqlimport.1.gz
/usr/share/man/man1/mysqltest.1.gz
/usr/share/man/man1/perror.1.gz
/usr/share/man/man1/replace.1.gz
/usr/share/man/man1/resolve_stack_dump.1.gz
/usr/share/man/man1/resolveip.1.gz
/usr/share/man/man8/mysqld.8.gz
/usr/share/mysql/README.mysql-cnf
/usr/share/mysql/errmsg-utf8.txt
/usr/share/mysql/fill_help_tables.sql
/usr/share/mysql/my-huge.cnf
/usr/share/mysql/my-innodb-heavy-4G.cnf
/usr/share/mysql/my-large.cnf
/usr/share/mysql/my-medium.cnf
/usr/share/mysql/my-small.cnf
/usr/share/mysql/mysql_performance_tables.sql
/usr/share/mysql/mysql_system_tables.sql
/usr/share/mysql/mysql_system_tables_data.sql
/usr/share/mysql/mysql_test_data_timezone.sql
/var/lib/mysql
/var/log/mariadb
/var/log/mariadb/mariadb.log
/var/run/mariadb

Tuossa siis CentOS 7 tarjoaman mariadb ja mariadb-server rpm pakettien asentamat tiedostot listattuna. Noudattaa täysin samaa rakennetta kuin mysql.
Jeps, tätä tarkoitin tuolla MySQL/MariaDB-yhteensopivuudella. Konvertoinnilla tarkoitin kuitenkin tässä tapauksessa noiden olemassaolevien isojen proprietary-kantojen konvertointia, joka on kaikkea muuta kuin triviaali homma.
 
Kun tätä AVX-512 asiaa on väännetty, niin laitetaan tämä kaikille niille fyysikoille/kemisteille/insinööreille jotka haluaa tehdä tieteellistä laskentaa.

Laskentaa on kahdenlaista "kotikoneella tehtävää" ja semmoista johon tarvitsee oikean superkoneen. Nämä kaksi ovat sitten ihan oikeasti kaksi erilaista käyttökohdetta, joissa sama laitteisto ei välttämättä toimi.



Kotikone käyttö (tutkimusryhmän pikkuklusteri)

AVX-512 on oikeasti hyvä, mikäli ohjelma sitä tukee, ja siten intelin sitä tukevat prossut ovat hyviä. Mainittakoon että i7 9800x on nopeampi kuin TR 2990WX ja siten hyvä ostos kenelle tahansa, joka haluaa tehdä laskentaa kotona.

Suoraan sanottuna vastaavasti: Zen/Zen+ älkää ostako näitä laskentaan (ellette tiedä että ohjelmanne ei varmasti ole AVX/AXV2/AVX-512 koodia)

Zen2 näyttäisi olevan testien valossa laskentaan ihan hyvin käyvä ja ainakin henkilökohtaisesti pidän sitä hyvänä vaihtoehtona (en ole tosin itse vielä testannut).

Karkeana nyrkkisääntönä voi käyttää seuraavaa karkeaa kaavaa
Koodi:
kellotaajuus * ydintenmäärä * vakio = suorituskyky
Kaavassa olevan vakion saa seuraavasti:
  • vakio=1 jos skalaari koodia
  • vakio=2 SSE eli zen ja zen+
  • vakio=4 AVX/AVX2 eli haswell, broadwell, zen2 ja intelin kuluttaja prossut
  • vakio=8 AVX-512 eli skylake-x, cascade lake
Lisäksi itelin tapauksessa pitää vielä valita avx2/avx512-kellot, eli alemmat mitä baseclock.


Lyhyesti:
Ottaen huomioon julkaistut testin ja muut jutut, niin tutkimusryhmän laskentakoneeksi kannattaa ottaa dual Epyc2. Intel on yksinkertaisesti pelannut itsensä ulos kuvioista hinnoittelulla.

Kotikäyttöön tuo mainittu i7 9800x (tai sen tuleva korvaaja). Lisäksi 10-ytiminen i9 9820x, riippuen hinnasta. Tulevaisuudessa myös 24- tai 32-ytiminen (zen2) TR on hyvä vaihtoehto.



Superkone hommista

Tässä kohtaa sanon suoraan, että yksikään noista nyt olevista testeistä Anantech, ServeTheHome tai Phoronix ei ole julkaissut testejä, joita voisi käyttää tässä tapauksessa. Koska ne on kaikki ajettu samalla emolevyllä ja kaikissa tapauksissa ajetut testit ovat ratkaisseet "pieniä ongelmia". Lisäksi esim Phoronix on sössinyt CP2K testit ihan kuuseen (ei esim osannut ajaa ohjelmaa oikeilla input-parametreilla).

Käytännössä tämä tarkoittaa, että esim NAMD ja Gromacs ovat paljon nopempia GPUlla kuin CPUlla, kun ongelma on "yhdelle koneelle mahtuva" - Folding@Home (Gromacs) on nopempi GPUlla.

Mikäli ajetaan taas niin iso systeemiä että se ei mahdu yhdelle laskentasolmulle, niin sitten tulee peliin solmujenvälinen kommunikaatio. Tätä tapausta ei ole nyt julkaistuissa artikkeleissa testattu - missään ei ole testiä missä esim. Gromacsia olisi ajettu tuhannella ytimellä. Tässä tapauksessa Gromacsilla ja NAMDllä CPU on nopeampi kuin GPU ja olisin henkilökohtaisesti kiinnostunut näkemään tämänlaisen testin.

Näissä tapauksissa suorituskykyyn vaikuttaa verkon suorituskyky ja konen valmistajan kirjastojen (esim. Scalapac) suorituskyky. Ja tuossa ylempänä on jo linkattuna ServeTheHome:n testi, jossa näkyi kuinka PCIe4 on Mellanoxin 100Gbe verkkokortilla nopeampi kuin PCIe3. Tämä näkyy käytännössä suorituskyvyssä superkoneella.

Lisäksi jos katsotaan kuinka monta uutta superkonetta on tulossa Epyc2:lla, niin on aika selvää että se on hyvä valinta.


Summarum
AVX-512 on loistava, mutta i7 9800x on ainut järkevä sitä käyttävä prossu laskenta hommissa. Muuten Zen2 on todennäköisesti parampi.
 
Kun tätä AVX-512 asiaa on väännetty, niin laitetaan tämä kaikille niille fyysikoille/kemisteille/insinööreille jotka haluaa tehdä tieteellistä laskentaa.

Laskentaa on kahdenlaista "kotikoneella tehtävää" ja semmoista johon tarvitsee oikean superkoneen. Nämä kaksi ovat sitten ihan oikeasti kaksi erilaista käyttökohdetta, joissa sama laitteisto ei välttämättä toimi.

Kotikone käyttö (tutkimusryhmän pikkuklusteri)

AVX-512 on oikeasti hyvä, mikäli ohjelma sitä tukee, ja siten intelin sitä tukevat prossut ovat hyviä. Mainittakoon että i7 9800x on nopeampi kuin TR 2990WX ja siten hyvä ostos kenelle tahansa, joka haluaa tehdä laskentaa kotona.

Suoraan sanottuna vastaavasti: Zen/Zen+ älkää ostako näitä laskentaan (ellette tiedä että ohjelmanne ei varmasti ole AVX/AXV2/AVX-512 koodia)

Zen2 näyttäisi olevan testien valossa laskentaan ihan hyvin käyvä ja ainakin henkilökohtaisesti pidän sitä hyvänä vaihtoehtona (en ole tosin itse vielä testannut).

Karkeana nyrkkisääntönä voi käyttää seuraavaa karkeaa kaavaa
Koodi:
kellotaajuus * ydintenmäärä * vakio = suorituskyky
Kaavassa olevan vakion saa seuraavasti:
  • vakio=1 jos skalaari koodia
  • vakio=2 SSE eli zen ja zen+
  • vakio=4 AVX/AVX2 eli haswell, broadwell, zen2 ja intelin kuluttaja prossut
  • vakio=8 AVX-512 eli skylake-x, cascade lake
Lisäksi itelin tapauksessa pitää vielä valita avx2/avx512-kellot, eli alemmat mitä baseclock.


Lyhyesti:
Ottaen huomioon julkaistut testin ja muut jutut, niin tutkimusryhmän laskentakoneeksi kannattaa ottaa dual Epyc2. Intel on yksinkertaisesti pelannut itsensä ulos kuvioista hinnoittelulla.

Kotikäyttöön tuo mainittu i7 9800x (tai sen tuleva korvaaja). Lisäksi 10-ytiminen i9 9820x, riippuen hinnasta. Tulevaisuudessa myös 24- tai 32-ytiminen (zen2) TR on hyvä vaihtoehto.



Superkone hommista

Tässä kohtaa sanon suoraan, että yksikään noista nyt olevista testeistä Anantech, ServeTheHome tai Phoronix ei ole julkaissut testejä, joita voisi käyttää tässä tapauksessa. Koska ne on kaikki ajettu samalla emolevyllä ja kaikissa tapauksissa ajetut testit ovat ratkaisseet "pieniä ongelmia". Lisäksi esim Phoronix on sössinyt CP2K testit ihan kuuseen (ei esim osannut ajaa ohjelmaa oikeilla input-parametreilla).

Käytännössä tämä tarkoittaa, että esim NAMD ja Gromacs ovat paljon nopempia GPUlla kuin CPUlla, kun ongelma on "yhdelle koneelle mahtuva" - Folding@Home (Gromacs) on nopempi GPUlla.

Mikäli ajetaan taas niin iso systeemiä että se ei mahdu yhdelle laskentasolmulle, niin sitten tulee peliin solmujenvälinen kommunikaatio. Tätä tapausta ei ole nyt julkaistuissa artikkeleissa testattu - missään ei ole testiä missä esim. Gromacsia olisi ajettu tuhannella ytimellä. Tässä tapauksessa Gromacsilla ja NAMDllä CPU on nopeampi kuin GPU ja olisin henkilökohtaisesti kiinnostunut näkemään tämänlaisen testin.

Näissä tapauksissa suorituskykyyn vaikuttaa verkon suorituskyky ja konen valmistajan kirjastojen (esim. Scalapac) suorituskyky. Ja tuossa ylempänä on jo linkattuna ServeTheHome:n testi, jossa näkyi kuinka PCIe4 on Mellanoxin 100Gbe verkkokortilla nopeampi kuin PCIe3. Tämä näkyy käytännössä suorituskyvyssä superkoneella.

Lisäksi jos katsotaan kuinka monta uutta superkonetta on tulossa Epyc2:lla, niin on aika selvää että se on hyvä valinta.


Summarum
AVX-512 on loistava, mutta i7 9800x on ainut järkevä sitä käyttävä prossu laskenta hommissa. Muuten Zen2 on todennäköisesti parampi.
Olen ymmärtänyt että näissä isommissa laskentahommissa myös AVX:n riippakiveksi alkaa muodostua kommunikaatioväylien nopeus ts. kuinka nopeasti saadaan sitä tavaraa muisteista käsiteltäväksi. Siinä voisi kuvitella noista PCIe4-väylistä olevan hyötyä. Ja tuo GPU-pointti oli hyvä. Ilmeisesti GPU:lle tehokas HPC-SIMD-koodaus on vähän haastavampaa, mutta suorituskykykin on sitten melko kova. Muutenkin tuntuu että tämä Intelin AVX-meuhkaus on jonkunlaista vastaiskua konesaleissa yleistyneihin GPU-laskentafarmeihin.
 
Ja tuo GPU-pointti oli hyvä. Ilmeisesti GPU:lle tehokas HPC-SIMD-koodaus on vähän haastavampaa, mutta suorituskykykin on sitten melko kova. Muutenkin tuntuu että tämä Intelin AVX-meuhkaus on jonkunlaista vastaiskua konesaleissa yleistyneihin GPU-laskentafarmeihin.

Isoissa laskuissa ongelma on kommunikaatiossa. Mikäli laskenta tehdään GPUlla täytyy ensin siirtää data GPUlta keskusmuistiin, sitten siirtää muistitsta toisen koneen muistiin ja sieltä toisen koneen GPUlle. Jostaas tehdään CPUlla, niin tarvitsee siirtää ainoastaan keskusmuistista toisen koneen keskusmuistiin, mikä on syy siihen miksi CPU on nopeampi isoissa laskuissa.

Tämä on kylläkin tiedossa oleva ongelma, mikä kulminoituu tulevissa Exa-luokan koneissa ja tästä asiasta käydään keskustelua tiedepiireissä. Olin itse heinäkuussa konferenssissä, jossa oli tästä asiasta keskustelua.
 
Isoissa laskuissa ongelma on kommunikaatiossa. Mikäli laskenta tehdään GPUlla täytyy ensin siirtää data GPUlta keskusmuistiin, sitten siirtää muistitsta toisen koneen muistiin ja sieltä toisen koneen GPUlle. Jostaas tehdään CPUlla, niin tarvitsee siirtää ainoastaan keskusmuistista toisen koneen keskusmuistiin, mikä on syy siihen miksi CPU on nopeampi isoissa laskuissa.

Tämä on kylläkin tiedossa oleva ongelma, mikä kulminoituu tulevissa Exa-luokan koneissa ja tästä asiasta käydään keskustelua tiedepiireissä. Olin itse heinäkuussa konferenssissä, jossa oli tästä asiasta keskustelua.
Ehkäpä tässä on juuri syy siihen miksi AMD:n kalvoilla esiintyy supertietokoneen suorittimia missä saman IF:n äärellä on niin CPU ytimiä kuin radeon laskentapiirejä :)

https%3A%2F%2Fblogs-images.forbes.com%2Fmoorinsights%2Ffiles%2F2019%2F05%2FPicture1-5.jpg
 
Isoissa laskuissa ongelma on kommunikaatiossa. Mikäli laskenta tehdään GPUlla täytyy ensin siirtää data GPUlta keskusmuistiin, sitten siirtää muistitsta toisen koneen muistiin ja sieltä toisen koneen GPUlle. Jostaas tehdään CPUlla, niin tarvitsee siirtää ainoastaan keskusmuistista toisen koneen keskusmuistiin, mikä on syy siihen miksi CPU on nopeampi isoissa laskuissa.

Tämä on kylläkin tiedossa oleva ongelma, mikä kulminoituu tulevissa Exa-luokan koneissa ja tästä asiasta käydään keskustelua tiedepiireissä. Olin itse heinäkuussa konferenssissä, jossa oli tästä asiasta keskustelua.
Mitenköhän tässä sitten on kytkennät tehty?
Summit (supertietokone) – Wikipedia
Nvlink 2.0-väylät (CPU <-> GPU) tässä tapauksessa ymmärtääkseni kommunikoivat 150GB/s nopeudella kun CPU ja DDR4 ovat noin 170GB/s luokkaa. Noodien sisällä muisti on pääosin yhteistä ja koherenttia CPU:iden että GPU:iden välillä. Erikoista tässä on ratkaisussa tosiaan se, että GPU:T on suoraan kiinni käyttömuistissa. Noodien välillä taas Mellanoxin joku 200Gb/s verkko ja jotain kiihdytyksiä päälle. Varmaan tosiaan tulee kommunikaatiohaasteita isommissa exa-laitteissa, mutta ainakin tuossa yo. linkin koneessa jokainen yksittäinen noodikin on jo melko tehokas laskentayksikkö itsessään (4xVolta yhdessä noodissa).

Aiheesta vielä ihan mielenkiintoinen linkki, jossa myös vertailua Intelin ja tämän Power-arkkitehtuurin kommunikaatioväylien eroista:
IBM AC922 Power 9 server has 6 Nvidia V100s

Edit, lisäys kirjoittelun aikana tulleeseen kommenttiin:
Ehkäpä tässä on juuri syy siihen miksi AMD:n kalvoilla esiintyy supertietokoneen suorittimia missä saman IF:n äärellä on niin CPU ytimiä kuin radeon laskentapiirejä :)

https%3A%2F%2Fblogs-images.forbes.com%2Fmoorinsights%2Ffiles%2F2019%2F05%2FPicture1-5.jpg
...että aika lailla tuon IBM Summit-koneen vastaiskulta näyttää. Muutenkin näyttäisi tuollakin rintamalla kilpailu kuumenevan kun hetki sitten Nvidia osti sen Mellanoxin, joka näitä nopeita superkoneväyliä rakentelee.
 
Ei ole ainut.

Tässä toinen. Tämän jo joku juuri pari viestiä sitten tänne postasi, mutta et ilmeisesti huomannut.

upload_2019-8-9_12-56-14-png.260461


Vaikuttaisi pikemminkin siltä, että aina kun softa koostuu lähinnä järeästä numeronmurskauksesta, ja se voidaan tehdä AVX-512lla, tuo 28-ytiminen xeon vastaa melko hyvin tuota 64-ytimistä EPYCiaä

AVX-512 on oikeasti kiva juttu.

Luepa tuosta revikasta teksti. Käsin optimoitu AVX-512 Xeonille vs täysin optimoimaton koodipolku Romelle. Ei ollut meinannut ottaa mukaan ollenkaan kun on täysin epäreilu tilanne Romelle, otti kuitenkin kun suorituskyky kuitenkin riitti sellaisenaankin olemaan kilpailukykyinen.

AVX-512 on ainoa asia jossa Xeonit ovat edes jotenkin kilpailukykyisiä - ja paremmin Romelle optimoidulla koodilla eivät siinäkään useimmiten ole kummoinen vastus.
 
Ei ole ainut.

Tässä toinen. Tämän jo joku juuri pari viestiä sitten tänne postasi, mutta et ilmeisesti huomannut.

upload_2019-8-9_12-56-14-png.260461


Vaikuttaisi pikemminkin siltä, että aina kun softa koostuu lähinnä järeästä numeronmurskauksesta, ja se voidaan tehdä AVX-512lla, tuo 28-ytiminen xeon vastaa melko hyvin tuota 64-ytimistä EPYCiaä

AVX-512 on oikeasti kiva juttu.

On kyllä. On varmaa syytä odottaa että Zen3:een tulee AVX-512? Eikö tuon 7nm+ prosessin pitäisi mahdollistaa tuon lisääminen tilansuhteen? Tuntuisi AMD:ltä vaan tyhmältä antaa Intelin nauttia noin isosta edusta, tuomatta itse vastaavaa ominaisuutta ulos.
 
Muutenkin tuntuu että tämä Intelin AVX-meuhkaus on jonkunlaista vastaiskua konesaleissa yleistyneihin GPU-laskentafarmeihin.
Jos mutusi osuu kohdilleen, niin kannattaa tarkkaila meuhkaamisen määrää sitten kun intel saa GPUnsa myyntiin :comp:
 
Jaahas AMD osake pomppasi 16% ylöspäin kun Google ja Twitter ilmoittivat miljardiluokan datakeskus hankkeista keskittyen pelkästään AMD Epyc pohjaisiin prosessoreihin: Google and Twitter are using AMD’s new EPYC Rome processors in their data centers – TechCrunch

Myös Kiinalaista maailman nopeiten kasvavat data-keskuskukset ovat siirtyneet lähes pelkästään AMD prosessoreihin, koska Trumpin meuhkaamisen takia Intel prosessorit nähdään huoltovarmuusriskinä, koska Intel valmistus on niin suurelta osin keskittynyt jenkkeihin, mutta AMD prossut valmistetaan Taiwanissa. Tämä siis tarkoittaa, että Intel on menettänyt pääsyn maailman nopemmin kasvaville datakeskus markkinoille (ehkä jopa pysyvästi) jotka ovat vuosittain noi 12 miljardin euron arvoiset ja kasvavat 30%-50% vuodessa. Tämä tarkoittaa kymmenen vuoden säteellä jopa satojenmiljardien eurojen menetettyjä kauppoja Intelin osakkeen omistajille. Niitä ketkä ostivat AMD osakkeita suhteellisen halpaan tasoon kesällä tulee taas hymyilyttämään ja moni Intelin osakkeita omistavaa ei niinkään. Tämä siis oma ennustukseni asiasta.
 
Niitä ketkä ostivat AMD osakkeita suhteellisen halpaan tasoon kesällä tulee taas hymyilyttämään ja moni Intelin osakkeita omistavaa ei niinkään. Tämä siis oma ennustukseni asiasta.

Kolmisen vuotta sitten kurssi tais olla $1.50. Kaverille jo totesin että varmaan olis hyvä paikka tehdä riskisijoitus kun vaihtoehtoina ei ole kuin firman konkka tai kurssin nousu ja kaatuminen on kuitenkin aika epätodennäköistä.
 
Niitä ketkä ostivat AMD osakkeita suhteellisen halpaan tasoon kesällä tulee taas hymyilyttämään ja moni Intelin osakkeita omistavaa ei niinkään. Tämä siis oma ennustukseni asiasta.

Voisitko nyt ensin esimerkiksi perehtyä yhtään kyseisten firmojen taloudelliseen tilanteeseen (sisältäen mm. osakkeiden PE-luvun) ennen kuin menet höpisemään yhtään mitään yritysten osakkeiden arvoista ja niiden kehityksestä.
 
Voisitko nyt ensin esimerkiksi perehtyä yhtään kyseisten firmojen taloudelliseen tilanteeseen (sisältäen mm. osakkeiden PE-luvun) ennen kuin menet höpisemään yhtään mitään yritysten osakkeiden arvoista ja niiden kehityksestä.

Katsotaan nyt rauhassa vuoden loppuun ensin miten serveripuolen myynti menee Intelillä kun suurimmat Kiinan kaltaiset kasvumarkkinat menevät Trumpin takia pysyvästi sivusuun ja kaikki merkittävät serveri farmi firmat raportoivat suurista investoinneista AMD Epyc sarjaan joka vasta juuri julkaistiin.

Intelillä on aikamoinen kiviriippa kaulassa kun pääomat on kiinni valtavan kalliissa tuotantolinjoissa jos myynti ei suju tulee suuria ongelmia aivan kuten nokian puhelimillekin tule heti kun myynti ei sujunut valtavan kalliit tuotantolaitokset ja tuotekehitys muodostui kiviriipaksi joka upotti laivan ennätysajassa. Kun pienemmällä tuotekehityksellä ja ulkoistetulla tuotannolla pelaavat kilpailijat vetivät ohi oikealta ja vasemmalta siihen tyylliin, että Nokian Puhelimet joutuvat laittamaan lapun kokonaan luukulle. AMD:lla samanlaista riskiä ei ole kuin on Intelillä kun tuotanto on ulkoistettu ja pääomia ei ole sidottu valtavia kuluja aiheuttaviin puolijohde tuotantolaitoksiin.
 
Katsotaan nyt rauhassa vuoden loppuun ensin miten serveripuolen myynti menee Intelillä kun suurimmat Kiinan kaltaiset kasvumarkkinat menevät Trumpin takia pysyvästi sivusuun ja kaikki merkittävät serveri farmi firmat raportoivat suurista investoinneista AMD Epyc sarjaan joka vasta juuri julkaistiin.

Intelillä on aikamoinen kiviriippa kaulassa kun pääomat on kiinni valtavan kalliissa tuotantolinjoissa jos myynti ei suju tulee suuria ongelmia aivan kuten nokian puhelimillekin tule heti kun myynti ei sujunut valtavan kalliit tuotantolaitokset ja tuotekehitys muodostui kiviriipaksi joka upotti laivan ennätysajassa. Kun pienemmällä tuotekehityksellä ja ulkoistetulla tuotannolla pelaavat kilpailijat vetivät ohi oikealta ja vasemmalta siihen tyylliin, että Nokian Puhelimet joutuvat laittamaan lapun kokonaan luukulle. AMD:lla samanlaista riskiä ei ole kuin on Intelillä kun tuotanto on ulkoistettu ja pääomia ei ole sidottu valtavia kuluja aiheuttaviin puolijohde tuotantolaitoksiin.
Intelin suurin ongelma on tällä hetkellä väärä prosessorin arkkitehtuuri. AMD muutti pelin sääntöjä kertaheitolla uusiksi jo kolmannen kerran historiassa (edelliset olivat x86-64-käskykannan julkaisu sekä muistiohjaimen vieminen prosessorin sisälle).

Tällä kertaa pelikentän muutos on siirtyminen monoliittisistä prosessorisiruista chiplet-arkkitehtuuriin.

Niin valtaviin ydin- ja välimuistimääriin mitä uusissa EPYC-prosessoreissa on ei pääse enää mielekkäällä kustannustasolla monoliittisella prosessoriarkkitehtuurilla. Intel joutuu siis kolmannen kerran historiassa kopioimaan AMD:tä ja suunnittelemaan prosessorinsa kilpailijansa mallia seuraten uudelleen. Työ on todennäköisesti ollut jo käynnissä vuoden pari, mutta kestää aikansa saada kilpailijat ulos tehtaalta.

Em. ongelma yhdistettynä suuriin vaikeuksiin saada 10nm viivanleveys tuotantoon tekee sen, ettei Intelillä ole tarjolla kilpailukykyisiä palvelinprosessoreita ainakaan vuoteen tai kahteen. Sitä odotellessa tarvitaan 50-80% hinnanalennukset kilpailukyvyn korjaamiseksi. Ja lisähinnan veloittaminen suuremmasta muistituesta loppuu varmastikin parin kuukauden sisällä - tämä syö katetta vielä entisestään.

Juuri nyt en haluaisi olla Intelin osakkeenomistaja.
 
Intelin suurin ongelma on tällä hetkellä väärä prosessorin arkkitehtuuri. AMD muutti pelin sääntöjä kertaheitolla uusiksi jo kolmannen kerran historiassa (edelliset olivat x86-64-käskykannan julkaisu sekä muistiohjaimen vieminen prosessorin sisälle).

Tällä kertaa pelikentän muutos on siirtyminen monoliittisistä prosessorisiruista chiplet-arkkitehtuuriin.

Niin valtaviin ydin- ja välimuistimääriin mitä uusissa EPYC-prosessoreissa on ei pääse enää mielekkäällä kustannustasolla monoliittisella prosessoriarkkitehtuurilla. Intel joutuu siis kolmannen kerran historiassa kopioimaan AMD:tä ja suunnittelemaan prosessorinsa kilpailijansa mallia seuraten uudelleen. Työ on todennäköisesti ollut jo käynnissä vuoden pari, mutta kestää aikansa saada kilpailijat ulos tehtaalta.

Em. ongelma yhdistettynä suuriin vaikeuksiin saada 10nm viivanleveys tuotantoon tekee sen, ettei Intelillä ole tarjolla kilpailukykyisiä palvelinprosessoreita ainakaan vuoteen tai kahteen. Sitä odotellessa tarvitaan 50-80% hinnanalennukset kilpailukyvyn korjaamiseksi. Ja lisähinnan veloittaminen suuremmasta muistituesta loppuu varmastikin parin kuukauden sisällä - tämä syö katetta vielä entisestään.

Juuri nyt en haluaisi olla Intelin osakkeenomistaja.
Moar cores tekniikalla "chiplet arkkitehtuuri" on kyl ylivoimainen erityisesti saantoja katsellessa, mutta huomautetaas jälleen, että intel on käyttänyt myöskin samankaltsisia ratkaisuja, joista mainittakoot pentium D ja core 2 quad, jotka molemmat koostuu kahdesta lasrätusta yhdessä paketissa
 
Moar cores tekniikalla "chiplet arkkitehtuuri" on kyl ylivoimainen erityisesti saantoja katsellessa, mutta huomautetaas jälleen, että intel on käyttänyt myöskin samankaltsisia ratkaisuja, joista mainittakoot pentium D ja core 2 quad, jotka molemmat koostuu kahdesta lasrätusta yhdessä paketissa
Joo mutta sillä erolla ytimet kommunikoivat edelleen sikahitaan FSB:n kautta ja mitään "chiplet" käyttöön optimoitua väylää niissä ei ollut. (vrt amd IF)
 
Joo mutta sillä erolla ytimet kommunikoivat edelleen sikahitaan FSB:n kautta ja mitään "chiplet" käyttöön optimoitua väylää niissä ei ollut. (vrt amd IF)
Joo, mutta silti aika samankaltainen kuin chiplet rakenne, IO-piiri vaan paketin ulkopuolella :D
 
Intelin suurin ongelma on tällä hetkellä väärä prosessorin arkkitehtuuri.

Käytät nyt sanaa "arkkitehtuuri" hyvin monimerkityksellisesti siten kuin se agendaasi sopii.

AMD muutti pelin sääntöjä kertaheitolla uusiksi jo kolmannen kerran historiassa (edelliset olivat x86-64-käskykannan julkaisu sekä muistiohjaimen vieminen prosessorin sisälle).

Intelillä oli kehitteillä integroidun muistiohjaimen sisältävä CPU jo monta vuotta ennen K8a.

Intel Timna - Wikipedia

Että jos jotain kopioimisesta puhutaan niin taitaa kuitenkin mennä sillaipäin että AMD kopioi K8lla Timnaa ;)

Mutta jospa vaan myönnettäisiin että kukaan ei kopioi ketään, vaan jos saman asian voi järkevästi tehdä n. kolmella eri tavalla niin on ihan luonnollista että eri valmistajat päätyvät välillä samaan ratkaisuun.

Tällä kertaa pelikentän muutos on siirtyminen monoliittisistä prosessorisiruista chiplet-arkkitehtuuriin.

Sinun "chiplet-arkkitehtuurisi" on vaan sen muistiohjaimen tuominen jälleen ulos sieltä samalta piilastulta, käänteinen siitä mitä AMD teki K8n muistiohjaimen kanssa. Ja intel teki juuri tuollaisen arkkitehtuurin jo clarkdalessa vuonna 2010. Mutta luopui siitä ja integroi sen muistiohjaimen samalle piilastulle CPU-ytimien kanssa Sandy Bridgessä, mm. koska integroitu muistiohjain mahdollisti pienemmän muistiviiveen ja siten paremman suorituskyvyn.

Ja se, millainen väylärakenne piirillä on ja mitä laitetaan millekin piilastulle on täysin ortogonaalinen asia sen kansa, mitä käskykanta-arkkitehtuuria piiri ajaa.

Niin valtaviin ydin- ja välimuistimääriin mitä uusissa EPYC-prosessoreissa on ei pääse enää mielekkäällä kustannustasolla monoliittisella prosessoriarkkitehtuurilla.

Siitä välimuistimäärästä.. Se osumatarkkuus on aika paljon muutakin kuin pelkkä yhteenlaskettu eri välimuistien määrä.

AMDltä puuttuu kokonaan yhteinen viimeinen tason välimuisti, ja se on selvä puute.

AMDllä millekään ytimelle (tai säikeelle) ei ole käytössä yli 16.5 megaa välimuistia. Intelin palvelinprosessoreissa kaikille ytimille on käytössä selvästi suurempi määrä L3-välimuistia.

Jos kaikki säkeet lukevat satunnaisesti samaa 33 megatavun kokoista taulukkoa, puolet accesseista on AMDllä huteja, vaikka välimuisteja on kuinka yhteensä se 256 megaa. Kun kaikki 16 erillistä L3-välimuistia joutuvat tallettamaan saman datan, eikä missään riitä tila 33 megan tallettamiseen. Intelin 38.5 megan kaikille yhteiseen L3-välimuistiin sen sijaan mahtuu koko taulukko.

Ja jos prosessoria myydään ulos 5 tonnilla, se että sen valmistaminen maksaa esim. 700 dollarin sijasta tonnin ei ole katastrofi. Se lähinnä pienentää hiukan sen piirin katetta.

Ja intel on jo julkaissut ensimmäiset cascade laket joissa on kaksi piilastua.

Intel joutuu siis kolmannen kerran historiassa kopioimaan AMD:tä ja suunnittelemaan prosessorinsa kilpailijansa mallia seuraten uudelleen.

Nyt mene pahasti pieleen. Jos puhutaan "kopioimisesta" niin sitten AMD kopioi zen2lla clarkdalea, ei intelin tarvi "kopioida AMDtä".

Ja intel on jo "kopioimassa" omaa Pentium D:tänsä ja core 4 quadiansa (joita AMD "kopioi" ekan sukupolven EPYCillä ja joillain aimmilla opteroineilla) ja tuomassa markkinoille MCM-ratkaisuita joissa 2 piilastua.

Ja se, että muistiohjain tuodaan CPU-piilastulta eri piilastulle ei vaadi mitään muutosta itse ytimin mikroarkkitehtuuriin.

Em. ongelma yhdistettynä suuriin vaikeuksiin saada 10nm viivanleveys tuotantoon tekee sen, ettei Intelillä ole tarjolla kilpailukykyisiä palvelinprosessoreita ainakaan vuoteen tai kahteen.

Jospa ensin odoteltaisiin se kuukausi niitä 56-ytimisiä cascade lakeja. (joissa on n. puolitoista kertaa enemmän muistikaistaa kuin Romessa).

Toki ne keskimäärin vielä häviävät tuolle EPYCille erityisesti kokonaislukukoodeilla, mutta kyllä todennäköisesti kilpailukykyisiä ovat. Paljon muistikaistaa vaativissa HPC-jutuissa esim. aika kovia.

Intelin 10nm myös tuottaa tällä hetkellä jo oikein päteviä Icy Lakeja läppäreihin, pahimmat ongelmat on jo ohi, vaikka edelleenkään ei saavuteta ihan samoja kellotaajuuksia kuin "14nm+++"lla.

Juuri nyt en haluaisi olla Intelin osakkeenomistaja.

Kommenttisi ilmaisee lähinnä sen, että olet todella pihalla siitä, miten pörssi toimi.

Intel on pörssiyhtiö, osakkeista pääsee tarvittaessa hyvin helpolla eroon. Ja intelin osake otti Romen julkaisusta vain n. 2% pudotuksen, että suurta tappiota ei tulisi myymällä ne nyt pois. Problem solved, vaivaisen 2% tappion realisoinnin jälkeen ei olisi enää intelin osakkeenomistaja.

Mutta Intelin PE-luku on tällä hetkellä n. 10.72 ja AMDn PE-luku on tällä hetkellä n. 200.

Ymmärrätkö mitä nämä luvut tarkoittavat?

Se tarkoittaa sitä, että vaikka intelin voitto puolittuisi, AMDn voiton pitäisi silti yli yhdeksänkertaistua että tuo osakkeen arvo suhteessa intelin osakkeen arvoon olisi oikeutettu.

AMDn osakkeen arvoon on jo leivottu sisään älyttömät odotukset Romen menestymisestä, mutta siihen ei ole leivottu sisään "imperiumin vastaiskun" vaikutusta, sitten kun se tulee.

Intelin osakkeen arvoon sen sijaan on jo leivottu sisään odotus siitä, että nykyisenkaltaiset voitot eivät tule säilymään ikuisesti, vaan ne tulevat putoamaan n.30-50%. (vähän riippuen, mitä pidetään yleisenä tuotto-odotus-tasona)
 
Viimeksi muokattu:
AMDltä puuttuu kokonaan yhteinen viimeinen tason välimuisti, ja se on selvä puute.

AMDllä millekään ytimelle ei ole käytössä yli 16 megaa välimuistia. Intelin palvelinprosessoreissa kaikille ytimille on käytössä selvästi suurempi määrä L3-välimuistia.

Tästä on viimeaikoina ollut mielenkiintoista puhetta ja spekulaatiota, ilmeisesti tuo nopean välimuistin koko on kasvavissa määrin pullonkaula näissä kymmeniä ytimiä sisältävissä palvelin/hpc prosessoreissa.

AMD on viime aikoina jättänyt patenttihakemuksia 3d pinotuille muistiratkaisuille ja keinoille niiden jäähdyttämiseen, kuinkakohan pitkässä puussa ne on.

Yhdessä kalvossa tuo ratkaisu oli mainittu olevan "On-Chip Stacked Memory 1TB/s HBM2"
 
"Imperiumin vastaiskuksi" riittäisi kuluttajapuolella oikeasti se, että olisi tehty rautakorjaukset rei'ille ilman suorituskyvyn merkittävää hidastumista. Mitähän se suorituskyky nousisi - 10%? 20%? 30%?

Serveripuolella tarvitaan enemmän ytimiä ja siellä pitäisi saada se 10nm kuntoon, tai vähintään katteista tinkiminen. Rome on järkyttävän hyvää hinta/laatu-suhdetta, niin katsotaan, kuinka Intel siihen reagoi..
 
Joo mutta sillä erolla ytimet kommunikoivat edelleen sikahitaan FSB:n kautta ja mitään "chiplet" käyttöön optimoitua väylää niissä ei ollut. (vrt amd IF)

Clarkdalessa sen sijaan oli, vuonna 2010.

Siinä oli nimenomaan CPUn kanssa samassa paketissa erillinen muistiohjain-/IO-piilastu, kuten zen2ssa. Sen ja CPUn välillä oli joku nopea tuota varten tehty intelin oma erikoisväylä ja pci expressit lähti sitten tuolta IO-piilastulta.

Siinä vaan samalle piirille oli ängetty myös (todella mopo) iGPU, ja siitä puuttui USB ja SATA yms. että sen kanssa tarvi myös aina käyttää erillistä teläsiltapiiriä.
 
Clarkdalessa sen sijaan oli, vuonna 2010.

Siinä oli nimenomaan CPUn kanssa samassa paketissa erillinen muistiohjain-/IO-piilastu, kuten zen2ssa. Sen ja CPUn välillä oli joku nopea tuota varten tehty intelin oma erikoisväylä ja pci expressit lähti sitten tuolta IO-piilastulta.

Siinä vaan samalle piirille oli ängetty myös (todella mopo) iGPU, ja siitä puuttui USB ja SATA yms. että sen kanssa tarvi myös aina käyttää erillistä teläsiltapiiriä.
Rupesin just miettimään että miksen ole koskaan kuullutkaan tuosta mutta sehän taisi olla melkoinen luuska aikalaisekseen. Ei ihan sinne hedt maailmaan suunnattu kuin mitä itse harrasteli tuolloin :D
 
Tästä on viimeaikoina ollut mielenkiintoista puhetta ja spekulaatiota, ilmeisesti tuo nopean välimuistin koko on kasvavissa määrin pullonkaula näissä kymmeniä ytimiä sisältävissä palvelin/hpc prosessoreissa.

AMD on viime aikoina jättänyt patenttihakemuksia 3d pinotuille muistiratkaisuille ja keinoille niiden jäähdyttämiseen, kuinkakohan pitkässä puussa ne on.

Yhdessä kalvossa tuo ratkaisu oli mainittu olevan "On-Chip Stacked Memory 1TB/s HBM2"

HBM*-muistin käyttämisessä muun DRAMin lisänä on sellainen dilemma, että näkyykö se normaalina DRAMina käyttikselle, vai toimiiko se vaan viimeisen tason välimuistina(LLC).

Välimuistina näkyminen olisi softille helpompaa, koska "it just works", mutta siinä ongelmaksi tulee kirjanpidon koko. Jos siitä välimuistista tekee oikeasti ison, sen kirjanpitokin olisi niin iso, että sitä ei voisi laittaa SRAMille, vaan sekin pitäisi laittaa sinne HBM*-DRAMille. Ja tämä taas lisäisi viivettä selvästi.

Jos se taas näkyy normaalina muistina, sitten käyttiksen pitäisi päättää, mitä se sijoittelee sinne, ja mitä normaaliin DRAMiin. Ja tämän optimointi on sitten jälleen yksi suuri monimutkaistus lisää käyttiksiin.

Itsehän haluaisin heittää ne DIMMeillä olevat DRAMit mäkeen, ja tuoda kaiken DRAMin samaan pakettiin prossun kanssa, ja laittaa niille DIMMeille vaan jotain NVRAMia.
 
Rupesin just miettimään että miksen ole koskaan kuullutkaan tuosta mutta sehän taisi olla melkoinen luuska aikalaisekseen. Ei ihan sinne hedt maailmaan suunnattu kuin mitä itse harrasteli tuolloin :D

Juu, clarkdale oli die-shrinkatun nehalemin halpismalli.

Jos halusi parempaa prossua, osti sen "täyden" nehalemin (tai sen die-shrinkin siitä, olen unohtanut nimen)

Ja jo halusi halvempaa prossua, osti vanhan core2n, clarkdale ei ollut sitä merkittävästi parempi.
 
HBM*-muistin käyttämisessä muun DRAMin lisänä on sellainen dilemma, että näkyykö se normaalina DRAMina käyttikselle, vai toimiiko se vaan viimeisen tason välimuistina(LLC).

Välimuistina näkyminen olisi softille helpompaa, koska "it just works", mutta siinä ongelmaksi tulee kirjanpidon koko. Jos siitä välimuistista tekee oikeasti ison, sen kirjanpitokin olisi niin iso, että sitä ei voisi laittaa SRAMille, vaan sekin pitäisi laittaa sinne HBM*-DRAMille. Ja tämä taas lisäisi viivettä selvästi.
Jos LLC sovellusta ajattelee niin missähän mahtaisi mennä raja sille että tuo kirjanpidon koko tulee ylivoimaiseksi ongelmaksi?

Arvaisin että huonoimmillaankin se hbm välimuisti olisi nopeampi kuin dram voi ikinä olla mutta tuntuvasti hitaampi kuin sram cachet prossun lastulla. Onko sitten ero sellainen että hbm on oikeasti perusteltua.
 
Joskus vuonna 2015 murossa puhuttiin suuremmista ydinmääristä ja olin silloin tätä mieltä:
Griffin sanoi:
Kun laskentayksiköiden määrä kasvaa huomattavasti, niin se tulee pärjäämään raskaassa laskennassa parhaiten, jolla on paras muistiohjain / välimuistiratkaisu, siitä vain ei pääse minnekään.
Oikeassa laskennassa kun sitä dataa joudutaan lataamaan laskentayksiköihin ja toisaalta tallentamaan muistiin jatkuvasti. ja kun on 4 ytimen sijasta esim 256 laskentayksikköä, niin muistijärjestelmältä vaaditaan todella paljon.

Jotkut testiohjelmat tietysti eivät tarvitse muistikaistaa, jos ne ovat epärealistisesti tehty. DDR4 auttaa jonkinverran VS DDR3, mutta ei riittävästi.

Pitää edelleen niin paikkansa..
 
Clarkdalessa sen sijaan oli, vuonna 2010.

Siinä oli nimenomaan CPUn kanssa samassa paketissa erillinen muistiohjain-/IO-piilastu, kuten zen2ssa. Sen ja CPUn välillä oli joku nopea tuota varten tehty intelin oma erikoisväylä ja pci expressit lähti sitten tuolta IO-piilastulta.

Siinä vaan samalle piirille oli ängetty myös (todella mopo) iGPU, ja siitä puuttui USB ja SATA yms. että sen kanssa tarvi myös aina käyttää erillistä teläsiltapiiriä.
Muistuttaisin vielä että näitä prossunvalmistajia on ollut muitakin kuin Intel ja AMD. Jos lähdetään johonkin kopiointisyyttelyleikkiin niin sitten täytyy pelikentäksi ottaa koko sirunvalmistushistoria, eikä pelkästään MIPSit, Powerit, Sparcit, Alphat jne vaan esim erilaiset konsolikivet ja muut räätälöidyt viritykset. Kaikilla tuppaa olemaan juurensa vaikka kuinka uudelta ja ennennäkemättömältä idea isolle yleisölle näyttäytyisi.
 
Muistuttaisin vielä että näitä prossunvalmistajia on ollut muitakin kuin Intel ja AMD. Jos lähdetään johonkin kopiointisyyttelyleikkiin niin sitten täytyy pelikentäksi ottaa koko sirunvalmistushistoria, eikä pelkästään MIPSit, Powerit, Sparcit, Alphat jne vaan esim erilaiset konsolikivet ja muut räätälöidyt viritykset. Kaikilla tuppaa olemaan juurensa vaikka kuinka uudelta ja ennennäkemättömältä idea isolle yleisölle näyttäytyisi.
Mutta kuinka moni on x86?
 

Statistiikka

Viestiketjuista
257 214
Viestejä
4 472 669
Jäsenet
73 897
Uusin jäsen
hal90210

Hinta.fi

Back
Ylös Bottom