Intel kertoi lisää Cascade Lake -palvelinprosessoreista + uudet suorituskykytestit

[mRkukov]

Käsittääkseni nuo kellotaajuuteenja virrankulutukseen vaikuttavat valmistustekniikan variaatiot menee enemmän siten, että saman piilastun sisälle ei näiden suhteen kovin suuria eroja ei tule, vaan ero on enemmänkkn piikiekon reuna vs piikiekon keskiosa, tai eri piikiekkojen välillä. En ole tästä kuitenkaan aivan varma. Ja toki tuo on niin iso piilastu, että tuleehan siinä jo reunimmaisten ytimien välille selvästi matkaa että toinen on selvästi lähempänä keskustaa kuin toinen.

AdoredTV analyyseistä jäänyt sellainen kuva että suurempi ala = todennäköisesti huonommat kellot. Toki se sijainti kiekolla merkkaa paljon, mutta kellot jää aina sen huonoimman coren tasolle jännitteellä x. Tokihan se paras alue kiekosta voi aina sisältää liikaa virheitä tuolle monsteripiirille, jolloin yhtään täysin ehjää priimaa ei saataisi. Tai se yksi saatiin ja sitä esiteltiin 5GHz kelloilla.

Mutta joo. Chiplet videolla oli siis grafiikkaa siitä miten piirin koko vaikuttaa toteutuneisiin kellotaajuuksiin. Pienempiä piidejä -> voidaan jakaa paremmin teholuokkiin ja käyttää parhaassa tuotteessa vain parhaita piirejä. Parhaiden piirien energiankulutus pienin ja kellot suurimmat. Tuollaisen 28 core monsterin kanssa pitää vain valita ne mitkä toimii ylipäätään.

 

[mRkukov]

Jahas, sieltä olikin tullut jo uusi video aiheesta.



Eli nämä olisikin HT disabled. Oma huomio eiliseltä ei siis ollutkaan vain sattumaa.

Miksihän ihmeessä ovat disabloineet HT / SMT noissa testeissä? Intelin HT ei toimi niin pitää disabloida kilpailijan parempi toteutus?

Kyllä se varmaan siis toimisi, mutta nostaisi liikaa tdp:tä. Ilman HT saadaan huomattava parannus kellotaajuuteen.

 

[mRkukov]

Pahoittelut että monta postausta putkeen...

Jäin miettimään tuota HT mahdollista puuttumista/disablointia. Ensin julkaistiin i7 ilman HT tukea. Nyt sitten HT tuen olisi mahdollisesti menettämässä myös palvelinpuolen tehokkain prossu.

Samaan aikaan HT/SMT toteutukset on koko ajan tapetilla sivukanavahyökkäysten takia. Esim uusin https://bbs.io-tech.fi/threads/inte...uusi-portsmash-sivukanavahaavoittuvuus.129906

Olisikohan Intel pikkuhiljaa luopumassa HT toteutuksesta sen aiheuttamien ongelmien takia? Meltdown/Spectre/uudet variantit ovat heikentäneet sen kannattavuutta ja AMD SMT toteutus on ilmeisesti hieman parempi muutenkin. Jospa siis Intelin sisällä on päätetty että HT voidaan tarvittaessa uhrata kellotaajuuksien ja tehonkulutuksen pienentämiseksi? Silloin toteutusta voitaisin markkinoida myös turvallisempana kuin HT kanssa. Olisikohan tässä yhtään mitään järkeä?

 

[Kaotik]

Samaan aikaan HT/SMT toteutukset on koko ajan tapetilla sivukanavahyökkäysten takia. Esim uusin https://bbs.io-tech.fi/threads/inte...uusi-portsmash-sivukanavahaavoittuvuus.129906

En nyt sanoisi että "koko ajan tapetilla", itselle ei ainakaan tule PortSmashin lisäksi mieleen kuin vain HT:tä koskenut TLBleed

 

[Contay]

Parhaiden piirien energiankulutus pienin ja kellot suurimmat. Tuollaisen 28 core monsterin kanssa pitää vain valita ne mitkä toimii ylipäätään.

Sama toteutus toimii hyvin eräällä toisella prosessorivalmistajalla joka valkkaa parhaat(paras 5%) 4coren piirit HEDT alustaansa. Huomattavasti toimivampi ratkaisu kuin tuollaisella monoliittipiirillä, jossa on pakko ottaa mitä saadaan, kuten sanoit.

 

[Tunkki]

WinServer 2016 Datacenter edition palvelimeen x 3 = REKT

 

[hkultala]

Olisikohan Intel pikkuhiljaa luopumassa HT toteutuksesta sen aiheuttamien ongelmien takia? Meltdown/Spectre/uudet variantit ovat heikentäneet sen kannattavuutta

Meltdownilla ja spectrellä ei ole mitään tekemistä SMTn kanssa.

ja AMD SMT toteutus on ilmeisesti hieman parempi muutenkin.

Ei, toteutus on käytännössä aivan samanlainen. Jotkut puskurien ja välimuistien koot ja laskentayksiköiden määrät Zenissä vaan ovat sellaisia, että se joillain benchmarkeilla hyötyy SMTstä enemmän. Mutta tämäkin menee enemmän sillaipäin, että yhdellä säikeellä/ydin näissä Zenistä jää enemmän paukkuja käyttämättä, ja sen kunnolliseen hyödyntämiseen tarvitaan SMTtä enemmän kuin intelillä, jolla koko ydin saadaan paremmin (muttei siinäkään kokonaan) hyödynnettyä jo yhdellä säikeellä.

Jospa siis Intelin sisällä on päätetty että HT voidaan tarvittaessa uhrata kellotaajuuksien ja tehonkulutuksen pienentämiseksi? Silloin toteutusta voitaisin markkinoida myös turvallisempana kuin HT kanssa. Olisikohan tässä yhtään mitään järkeä?

Kellotaajuuksiin SMT ei käytännössä vaikuta yhtään.

Mutta kun ytimet pienenee ja halpenee ja softia ei saada hyödyntämään uusia ytimiä samaa tahtia kuin niiden määrää raudalla voidaan halvalla lisätä, SMTn merkitys laskee.

 

[mRkukov]

Kellotaajuuksiin SMT ei käytännössä vaikuta yhtään.

Tehonkulutukseen vaikuttaa ja sitä kautta myös kellotaajuuksiin tietyllä rajoitetulla teholla. Ei toki muuten vaikuta.

 

[Threadripper]

En nyt sanoisi että "koko ajan tapetilla", itselle ei ainakaan tule PortSmashin lisäksi mieleen kuin vain HT:tä koskenut TLBleed

HT:n turvallisuuspuutteet ovat ikivanha juttu. 13 vuoden takaa:

https://www.eetimes.com/document.asp?doc_id=1154160

Percival's paper "outlines how a malicious thread can access areas of memory being run by other threads, perhaps to steal important things like cryptographic keys," according to the Geek.com Web site.

Tehonkulutukseen vaikuttaa ja sitä kautta myös kellotaajuuksiin tietyllä rajoitetulla teholla. Ei toki muuten vaikuta.

Myös korkeampi ytimien hyödyntämisaste vaikuttaa kellotaajuuteen. Ei dramaattisesti mutta kuitekin sillä pientä eroa saa.

 

[Kaotik]

HT:n turvallisuuspuutteet ovat ikivanha juttu. 13 vuoden takaa:

https://www.eetimes.com/document.asp?doc_id=1154160

13 vuotta sitten ja heti perään tänä vuonna pari, on aika kaukana "koko ajan tapetilla" tuosta (juu, varmasti väliinkin mahtuu haavoittuvuuksia mutta ei se nyt millään tasolla ole jatkuvasti tapetilla)

 

[zepi]

HT:n vaikutus prosessorin energiahyötysuhteeseen on aika vähäinen. Jos ajetaan sellaista kuormaa, joka rasittaa 16-core + HT prosessorin 50% prossukuormalle ja sähköä kuluu 80W, niin HT:n disabloimalla prossun rasitusaste samalla kuormalla nousee ehkä 60-65%:iin vähän kuormasta riippuen, mutta sähkön kulutus ei käytännössä juuri muutu tuosta 80W:stä.

 

[Threadripper]

HT:n vaikutus prosessorin energiahyötysuhteeseen on aika vähäinen. Jos ajetaan sellaista kuormaa, joka rasittaa 16-core + HT prosessorin 50% prossukuormalle ja sähköä kuluu 80W, niin HT:n disabloimalla prossun rasitusaste samalla kuormalla nousee ehkä 60-65%:iin vähän kuormasta riippuen, mutta sähkön kulutus ei käytännössä juuri muutu tuosta 80W:stä.

Tuossa skenaariossahan ei välttämättä HT-"ytimiä" kuormiteta yhtään eikä laskentayksiköitä enempää HT:n ollessa päällä. Joten tuskin virrankulutuskaan merkittävästi kasvaa.

 

[zepi]

Tuossa skenaariossahan ei välttämättä HT-"ytimiä" kuormiteta yhtään eikä laskentayksiköitä enempää HT:n ollessa päällä. Joten tuskin virrankulutuskaan merkittävästi kasvaa.

Ei ole olemassa mitään "HT-ytimiä". On vain kyky syöttää suoritusyksiköille eri threadeista käskyjä ja ylläpitää kahden threadin käskyjonoja puskureissa.

 

[mRkukov]

Ei ole olemassa mitään "HT-ytimiä". On vain kyky syöttää suoritusyksiköille eri threadeista käskyjä ja ylläpitää kahden threadin käskyjonoja puskureissa.

Joo mutta 50% kuormalla niistä HT säikeistä ei ole mitään iloa. HT säikeistä on hyötyä lähinnä maksimaalisessa 100% käytössä.

 

[Threadripper]

Ei ole olemassa mitään "HT-ytimiä". On vain kyky syöttää suoritusyksiköille eri threadeista käskyjä ja ylläpitää kahden threadin käskyjonoja puskureissa.

Siksi sanoinkin "ytimiä" lainausmerkeissä. Tuossa tilanteessa voidaan HT jättää kokonaan hyödyntämättä.

 

[JiiPee]

Ja todeta että tdp tulee olemaan järkyttävä.

Adoredtv uusimmalla videolla jutteli että nää saattaa olla HT off kamaa kaikki jotta saadaan TDP:tä hiukan alas.

EDIT: No jooh missasin seuraavan sivun tekstit jossa asiaa olikin jo käsitelty.

 

[mRkukov]

Adoredtv uusimmalla videolla jutteli että nää saattaa olla HT off kamaa kaikki jotta saadaan TDP:tä hiukan alas.

Ks toka viesti tällä sivulla.

 

[JiiPee]

Ks toka viesti tällä sivulla.

Juuh missasin toisen sivun vastaukset kun oikein kiimassa piti reply nappia painaa.

Mutta itte mietin sitä että ehkä 28-core lastusta on 4-corea disabloitu keskeltä että saadaan lämpökuorma jaettua enemmän 2 eri alueeseen, riippuu toki millaiset saannot Intelillä on että olisiko moinen kikkailu kannattavaa.

 

[Threadripper]

Juuh missasin toisen sivun vastaukset kun oikein kiimassa piti reply nappia painaa.

Mutta itte mietin sitä että ehkä 28-core lastusta on 4-corea disabloitu keskeltä että saadaan lämpökuorma jaettua enemmän 2 eri alueeseen, riippuu toki millaiset saannot Intelillä on että olisiko moinen kikkailu kannattavaa.

Tuskin menevät noin pitkälle. 4 toimimatonta tai "huonointa" corea disabloitu riippumatta siitä missä ovat. Intelillä on muutenkin kapasiteettiongelmia, joten eivät voi olla liian nirsoja.

 

[love_doctor]

Kun oikein kaivellaan niin saadaan Applen etu vain kymmeneksi prosentiksi. Intelin kääntäjä huijaa Spec-testeissä, eli siellä on vartavasten käsin optimoituja polkuja jotka korvaa koodia tehokkaammalla, tämä on ihan tunnettua ja Intelin kääntäjää ei spec-testeissä käytetä jos halutaan edes suurinpiirtein vertailukelpoisia tuloksia.

Kuten varmaan itsekin huomaat, niin siirtelet maalitolppia niin että saat väkisin vängättyä todeksi sen, mikä on tulkinnanvaraista, tapauskohtaista ja vaatisi lopullisen tuloksen arvioimiseksi vielä paljon lisätyötä. Kääntäjissä on mielin määrin sekä automatisoituja että adhoc käsin kirjoitettuja optimointisääntöjä eli jokin tiettyyn ongelmaan benchmarkia varten kirjoitettu optimointi ei varsinaisesti eroa siitä mitä kääntäjässä on muutenkin sisällä. Eikä se ole huijausta, vaan pätee ihan samalla tavalla vastaaviin muihin tilanteisiin, mihin optimointia voi vaan käyttää. Sellainen testi ei vaan ole hyödyllinen, joka nopeutuu suunnattomasti jostain tietystä spesifistä optimoinnista. Paras objektiivisuus mihin päästään on käyttää kääntäjää, joka käyttää optimointeja vain eri prosessorien suurimman yhteisen tekijän mukaan eli ei mitään toiselle edullisia ominaisuuksia. Tai sitten käytetään vaikkapa käsin koodattuna kullekin arkkitehtuurille optimaalisinta koodia. Tämäkin on vaikea kun prosessorit on tuunattu erilaisille kuormille ja käytännössä tilanne voi tasoittua jossain oikean maailman ongelmassa. Myös käyttis, käytönaikainen kirjasto jne. vaikuttavat mahdollisesti. Näistä on ihan typerää spekuloida ennen kuin on vakioitu testiympäristö saatavilla. Sitten on lopulta se, että mitä halutaan mitata - arkkitehtuurisuunnittelua urheilusuorituksena vai jotain todellisen maailman ongelman ratkontaa?

Koko homman pointtihan on että Applen prossu on niin sairaan hyvä että kusinen kännykkä kilpailee ihan tasaveroisesti Intelin parhaan pään serveriprossun kanssa Spec-tuloksissakin, tässä nyt ei kellään voi jäädä epäselväksi että Applen prossu on aivan sairaan hyvä vrt Intelin tuotokset.

Ja mopedi on tuhat kertaa kätevämpi Rooman iltapäiväruuhkissa ahtailla kujilla kuin rynnäkköpanssarivaunu.. tässä ei ole mitään tolkkua. Serveriprosessoreja ei kukaan käytä yksisäikeisesti ja niissä on mitoitus TDP:n osaltakin niin, että kaikki ytimet ovat käytössä. Jopa Intelin prossuja valitessa se kallein ja isoytimisin palvelinprosessori "ei välttämättä" ole paras esim. pelaamiseen tai web-surffailuun. Kannattaa miettiä, että Applen mobiili-cpu on aika lailla optimoitu tyypilliseen käyttöön juuri nyt. Ei välttämättä ole kaukaa haettu, että Applekin joutuu lähivuosina vaihtamaan tuota painotusta, jos ytimiä tulee lisää käyttöön mobiilissakin.

IPC ei nyt tosiaan voi arkkitehtuurien välillä vertailla suoraan mutta epäsuorasti voi esimerkiksi juuri käännettyjen Spec-tulosten kanssa aivan hyvin. Applen prossu taitaa dekoodata ja suorittaa maksimissaan 7 käskyä per kellojakso ja toteutuneetkin on hyvin korkeat, tässä lienee apua paljonkin yksinkertaisesta käskykannasta.

Kannattaa silti muistaa, että IPC on umpikuja ennen pitkää. Käskyvirrassa on aina satunnaisuutta ja epäedullisia riippuvuuksia, joita ei saa tarkasteluikkunan puitteissa sovitettua liukuhihnaan kaikille laskentayksiköitä utilisoivaksi, kun taas esim. ydinten ja vektorirekisterien osalta skaalautuvuutta on moninkerroin enemmän ihan todistetusti, jos katsotaan jo tehtyjä arkkitehtuureja. IPC-kisa on lähinnä relevantti yhdessä pienessä laskentaongelmien erikoistapauksessa, jossa on peräkkäisyyttä suosiva yleiskäyttöinen algoritmi. Muita algoritmeja ja toteutusvaihtoehtojakin on. Jos on tietty laskentakerneli, missä yksi arkkitehtuuri keulii IPC:n avulla, toinen voisi ehkä toteuttaa sen tietyn algoritmin 10 kertaa tehokkaammin DSP:llä tai vastaavalla erikoispiirillä. Mutta voi korkea IPC olla mobiilissa ihan oikeasti oikea ratkaisu, vaikka olisikin skaalautumisen mielessä umpikuja. Mobiilissa ei välttämättä tarvita tietyn rajan yli tehoja. Voi olla että pitäisikin optimoida softaa.

 

[Kaotik]

Meni ihan ohi alkuperäistä uutista kirjoitettaessa, mutta nuo Intelin Stream Triad -lukemat Epycille ovat kesältä 2017 AMD:n ajamina, eli mahdolliset parannukset sen jälkeen eivät näy

Stream Triad: 1-node, 2-socket AMD EPYC 7601, http://www.amd.com/system/files/2017-06/AMD-EPYC-SoC-Delivers-Exceptional-Results.pdf tested by AMD as of June 2017 compared to 1-node, 2-socket 48-core Cascade Lake Advanced Performance processor projections by Intel as of 10/3/2018.

Intel Shows Breadth of Data-Centric Platform with Cascade Lake Advanced Performance and Xeon E-2100 | Intel Newsroom

 

[Kaotik]

Ketjuun liitetty uusi uutinen Intel julkaisi lisää Cascade Lake Advanced Performance -tuloksia todellisissa sovelluksissa - io-tech.fi

 

[prc]

Kellotaajuuksiin SMT ei käytännössä vaikuta yhtään.

Mutta kun ytimet pienenee ja halpenee ja softia ei saada hyödyntämään uusia ytimiä samaa tahtia kuin niiden määrää raudalla voidaan halvalla lisätä, SMTn merkitys laskee.

Ja kun miettii noita coremääriä 2 socketin systeemiin niin aikalailla laskenta palvelimiin tuo on suunnattu. Tehtäviin joissa se SMT:n hyöty monesti on aika olematon. Kyllähän tuolla teoriassa ajaisi jotain ihan hervotonta vmware clusteria, mutta liekkö se oikeen hyvästä kun paljon pienemmilläkin vm-määrillä saadaan muistikanava ongelmksi. Virtualisointi kun nyt kuitenkin kasvattaa muistiliikennettä aika pahasti.

Aikaisemmin höpisin deskari puolen jutuista, kuinka saatiin eroja aikaan 2 vs 3 kalustetulla muistikanavalla Nehalem ajan Xeon työasemilla esille töissä. Ollaan myös saatu 2 socketin järjestelmässä saman aikaisilla servereillä vmwareilla muistikanavat saturoitua vaikka niitä coreja ei kovin kummoisesti sillon ollut.

Valtaosa virtuaalikoineiden ajamista palveluista oli ihan perus web palveluita ja valtaosa niistä kovin köykäistä ajettavaa per requesti CPU:lle, kun kuitenkin tietokannat yms olivat omilla nodeillaan.

 

[hkultala]

Ja kun miettii noita coremääriä 2 socketin systeemiin niin aikalailla laskenta palvelimiin tuo on suunnattu. Tehtäviin joissa se SMT:n hyöty monesti on aika olematon.

Ei, vaan (ihan perinteisissä) palvelimissa siitä SMTssä nimenomaan saadaan paljon hyötyä, kun palveltavia requesteja tulee paljon ja käytännössä jokaista voidaan palvella omassa säikeessään joten säikeitä riittää.

Kyllähän tuolla teoriassa ajaisi jotain ihan hervotonta vmware clusteria, mutta liekkö se oikeen hyvästä kun paljon pienemmilläkin vm-määrillä saadaan muistikanava ongelmksi. Virtualisointi kun nyt kuitenkin kasvattaa muistiliikennettä aika pahasti.
Aikaisemmin höpisin deskari puolen jutuista, kuinka saatiin eroja aikaan 2 vs 3 kalustetulla muistikanavalla Nehalem ajan Xeon työasemilla esille töissä. Ollaan myös saatu 2 socketin järjestelmässä saman aikaisilla servereillä vmwareilla muistikanavat saturoitua vaikka niitä coreja ei kovin kummoisesti sillon ollut.

Virtualiikoneessa hyödyt SMTstä itse asiassa saattaa olla hiukan pienempiä kuin ei-virtualisoidussa ympäristössä, koska virtuaalikone on epäystävällisempi TLBille, harvemmin ajossa saman prosessin eri säikeet.

Ja vähän alkaa vaikuttaa siltä, että joko softanne tekee jotain äärimmäisen muistikaistariippuvaista, tai se on todella huonosti optimoitu esim. välimuistinkäytön suhteen.

Valtaosa virtuaalikoineiden ajamista palveluista oli ihan perus web palveluita ja valtaosa niistä kovin köykäistä ajettavaa per requesti CPU:lle, kun kuitenkin tietokannat yms olivat omilla nodeillaan.

Toisaalta staattiset sivut on nyyään hyvin harvinisia, nykyään melkein kaikki sivut generoidaan dynaamisesti.

 

[prc]

Ja vähän alkaa vaikuttaa siltä, että joko softanne tekee jotain äärimmäisen muistikaistariippuvaista, tai se on todella huonosti optimoitu esim. välimuistinkäytön suhteen.

No se on ainakin varmaa ettei sen suhteen ole optimoitu, kunhan on webbi devattu. =)

Valtaosa kuormasta toki tulee web palvelu rajapinnoista joita käyttää toiset automaattiset palvelut eikä luonnollinen henkilö. Hakevat jotain tai lähettävät jotain dataa joka pitää sitten käistellä ennekuin kuin menee eteenpäin. Sopivaan aikaan kuukaudesta voluumimäärät on todella isot.

Ei, vaan (ihan perinteisissä) palvelimissa siitä SMTssä nimenomaan saadaan paljon hyötyä, kun palveltavia requesteja tulee paljon ja käytännössä jokaista voidaan palvella omassa säikeessään joten säikeitä riittää.

Tulikohan tässä nyt väärinkäsitys.. varmistetaan vielä. =)

Lähinnä siis meinasin, että harva varmaan jotain perinteistä applikaatio palvelinta ajaa natiivisti 96 Coren raudalla. Näin aikana kun kaikki pitää saada virtualisoitua jos nyt ei suoraan pilveen, jotta ylläpito on helpompaa.

Mielestäni tuollaiselle core määrälle (512b AVX) tuellla ehkä luonnollisin käyttätarkoitus olisi joku raskaampi laskenta. Missä välttämättä sitä SMT:stä ei niin ole hyötyä. Se voisi myös vaikuttaa Intelin päätökseen heivata HT leikkuriin tuon osilta. (Jos nyt tuon videon tiedot pitää paikkaansa). Toki voi olla ihan TDP syistä.

Nuo lastut tulevat maksamaan niin pirusti, että tuo tuskin on kustannussoptimaali vmware alusta. :\