
Intel julkaisi viime viikon alussa uusia tietoja tulevista Cascade Lake -arkkitehtuurin palvelinprosessoreista. Cascade Lake Advanced Performance -prosessorit tulevat olemaan parhaimmillaan 48-ytimisiä ja ne käyttävät useamman sirun MCM-paketointia.
Intelin alkuperäisessä diapaketissa oli mukana suorituskykytestit kolmesta eri skenaariosta, joista kahdessa uutta 48-ytimistä prosessoreita verrattiin kahden prosessorikannan palvelinkokoonpanoissa AMD:n Epyc 7601 -prosessoreihin ja yhdessä Intelin omaan Xeon Platinum -lippulaivaprosessoriin.
Tarkempi tarkastelu kuitenkin osoitti, että testitulokset perustuvat Cascade Lake AP:n osalta Intelin arvioihin suorituskyvystä, jonka lisäksi Epyc-prosessoreiden Stream Triad ja Xeon Platinum -prosessoreiden syväoppimissuorituskyky perustui kummankin prosessorin julkaisun aikaisiin tuloksiin. Lisäksi Intel oli jättänyt Hyper-threading- ja SMT-ominaisuudet pois käytöstä itse ajamissaan Epyc- ja Xeon Platinum -tuloksissa, mutta ei kerro pitikö sama paikkaansa myös Cascade Lake AP:n arvioitujen tulosten osalta.
Nyt Intel on julkaissut uusia testituloksia useammasta oikean maailman sovelluksesta 2S-palvelimissa. Cascade Lake AP:n tulokset perustuvat edelleen Intelin arvioihin lopullisesta suorituskyvystä prototyyppialustojen perusteella. Uusien testien Epyc-tulokset on ajettu aidoilla 2S-palvelimilla ja niissä on SMT-teknologia käytössä, mutta MILC-, WRF- ja OpenFOAM-testeissä säikeiden määrä on rajoitettu yhteen per ydin, kun NAMD- ja YASK-testeissä säikeitä on kaksi per ydin.
Intelin mukaan kahdella tulevalla 48-ytimisellä Cascade Lake Advanced Performance -prosessilla varustettu palvelin peittoaa kahdella 32-ytimisellä Epyc 7601 -prosessilla varustetun palvelimen kaikissa viidessä oikean maailman sovelluksia käyttävissä testeissä selvin eroin. MILC-testissä Cascade Lake AP -kokoonpano tulee yhtiön mukaan tarjoamaan parhaimmillaan 1,5-kertaista ja WRF- sekä OpenFOAM-testeissä 1,6-kertaista suorituskykyä Epyceihin nähden. NAMD (APOA1) -testissä suorituskykyero venähtää parhaimmillaan 2,1- ja YASK (ISO3DFD) -testissä peräti 3,1 kertaiseksi.
Lähde: Intel
Jahas, sieltä olikin tullut jo uusi video aiheesta.
Eli nämä olisikin HT disabled. Oma huomio eiliseltä ei siis ollutkaan vain sattumaa. 🙂
Kyllä se varmaan siis toimisi, mutta nostaisi liikaa tdp:tä. Ilman HT saadaan huomattava parannus kellotaajuuteen.
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ä?
En nyt sanoisi että "koko ajan tapetilla", itselle ei ainakaan tule PortSmashin lisäksi mieleen kuin vain HT:tä koskenut TLBleed
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.
WinServer 2016 Datacenter edition palvelimeen x 3 = REKT 😀
Meltdownilla ja spectrellä ei ole mitään tekemistä SMTn kanssa.
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ä.
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.
Tehonkulutukseen vaikuttaa ja sitä kautta myös kellotaajuuksiin tietyllä rajoitetulla teholla. Ei toki muuten vaikuta.
HT:n turvallisuuspuutteet ovat ikivanha juttu. 13 vuoden takaa:
https://www.eetimes.com/document.asp?doc_id=1154160
Myös korkeampi ytimien hyödyntämisaste vaikuttaa kellotaajuuteen. Ei dramaattisesti mutta kuitekin sillä pientä eroa saa.
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)
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.
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ä.
Siksi sanoinkin "ytimiä" lainausmerkeissä. Tuossa tilanteessa voidaan HT jättää kokonaan hyödyntämättä.
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.
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.
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.
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?
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.
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.
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
Intel Shows Breadth of Data-Centric Platform with Cascade Lake Advanced Performance and Xeon E-2100 | Intel Newsroom
Ketjuun liitetty uusi uutinen Intel julkaisi lisää Cascade Lake Advanced Performance -tuloksia todellisissa sovelluksissa – io-tech.fi
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.
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ää.
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.
Toisaalta staattiset sivut on nyyään hyvin harvinisia, nykyään melkein kaikki sivut generoidaan dynaamisesti.
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.
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. :