Virallinen: AMD vs Intel keskustelu- ja väittelyketju

[Melbac]

Mistäs asti SMT suorituskyky ja crypto suorituskyky eivät ole olleet tärkeitä?

Ja on se aika erikoista että sinä postaat videoita joissa Ryzen muka häviää ikivanhoille Intelin prosessoreille peleissä.
Ihan mielenkiinnosta youtubesta otin "Ryzen vs." haulla ensimmäisen videon jossa verrattiin suunnilleen samanhintaiseen prosessoriin ja vastaan asettui 7600K

Tämän sisällön näkemiseksi tarvitsemme suostumuksesi kolmannen osapuolen evästeiden hyväksymiseen.
Lisätietoja löydät evästesivultamme.

Hyväksy kolmannen osapuolen evästeet

Tuossa videolla R5 1600X ja 7600K ovat käytännössä täysin tasoissa pelisuorituskyvyssä.
Käsittääkseni 7600K:n pitäisi olla jonkin verran parempi kuin 4690K. Ilmeisesti se on kuitenkin sellainen jumalprosessori että se pieksee myös Intelin uudemmat prosessorit.

Vai olisiko käynyt niin että sinä olet ihan etsimällä etsinyt sellaisia videoita joissa se sinun vihaamasi Ryzen näyttää mahdollisimman huonolta? 6 peliä testattu ja 3:ssa Intel oli parempi ja 3:ssa Ryzen, miten siitä voi joku vetää sellaisen johtopäätöksen että Intel vie? Olet sinä kyllä melkoinen hupiukko.

Tässä vielä toinen video joka näyttää ihan samaa eli R5 1600X ja 7600K on pelikäytössä ihan tasoissa.

Tämän sisällön näkemiseksi tarvitsemme suostumuksesi kolmannen osapuolen evästeiden hyväksymiseen.
Lisätietoja löydät evästesivultamme.

Hyväksy kolmannen osapuolen evästeet

Ja huvittavinta tässä on se että sinun postaamallasi videolla kaveri jopa suosittelee R5 1600X, miten sinulle nyt tuollainen lipsahdus pääsi käymään?

i5-8400 maksaa n200€ eli 1600 verran ja on nopeampi useassa pelissä.Ainoa ero taitaa olla emojen hinnassa intelin emojen ollessa kalliimpia ja siinä että sieltä on tulossa zen+/zen2 jotka käy am4 emoihin kun taas intelin seuraava prossu vaatinee uuden emon.Tota ei tosin kelloteta mutta eipä pahemmin kelloteta 1600/1600x.

 

[Jage]

...mutta eipä pahemmin kelloteta 1600/1600x.

Okei jos kerran sanot niin

Mitähän tuolla "pahemmin" sanalla tarkoitetaan.

 

[hkultala]

Ohjelma mallintaa 3D-kappaleita havainnoista ja se käyttää erittäin paljon epälineaarista optimointia ja matriisioperaatiota. Se ei julkisessa levityksessä koska olen laatinut sen tutkimuskäyttöön. Mutta samoihin päätelmiin päästään vertaamalla MKL:ää muihin vastaaviin lineaarialgebran kirjastoihin Intelin prosessorilla, esimerkiksi ATLAS tai OpenBLAS. Intelin optimoinnit ovat yksinkertaisesti toiselta planeetalta. AMD:n "vastaava" BLIS on hitaampi kuin muut geneeriset kirjastot.

Uskon kyllä että AMD kirii kunhan vain kääntäjäoptimoinnit, kernel- ja mikrokoodipäivitykset saadaan kohdalleen sitten joskus, mutta tässä vaiheessa on turha väittää että AMD olisi poikkeuksetta hyötykäytössä Inteliä parempi vaikka ohjelma olisikin hyvin säikeistyvä. Suoraan sanoen olen pettynyt, mutta pitihän tuota kokeilla kun työkoneeseen sai valita. Jos nyt voisi valita uudelleen, niin ottaisin kyllä Intelin vaikka vähemmällä ydinmäärällä.

Tuollaisessa matriisinmurskauksessa Intelin tuplasti leveämmistä SIMD-yksiköistä saadaan melkein kaikki hyöty irti, eli hyvinkään optimoidulla koodilla Zenillä ei saada tuollaisella koodilla läheskään samaa ydinkohtaista suorituskykyä kuin Intelin Well- tai Lake- sarjan prosessoreilta.

Mutta: Et kai laske asioita 64-bittisillä doubleilla? Se lienee tarkkuuden kannalta overkilliä, ja hidastanee kaiken n. puoleen verrattuna 32-bittisiin floatteihin.

Lisäksi tuollainen myös vaikuttaa koodilta, jossa se numeronmurskaus kannattaisi tehdä GPUlla, eikä CPUlla.

Ja lisäksi:

Vertasin 16-ytimistä threadripperiä 4GHz kelloilla pyörivään 5960X:ään

Ohjelma säikeistyy lähes täydellisesti, ja 30:lla säikeellä Intel oli nopeampi (Intelillä ajettiin 8 säiettä kerralla, AMD:llä 16)

Miten rajoitat nuo ajossa olevat säiemäärät?

Sekä zenissä että intelin nykyprossuissa on SMT, ja ne pystyvät ajamaan kahta säiettä/ydin, ja kun molemmat virtuaaliytimet on työllistetty, kokonaissuorituskyvyn pitäisi kyllä olla yleensä selvästi parempi kuin että rajoitetaan yhteen säikeeseen/fyysinen ydin.

 

[hupiukko]

Puhuinkin tärkeillä osa-alueilla Intel vie. Ja katsoppa tätä sivua ylemmäs, video on todisteena, että R5 1600X ei antanut sen kummemmin vastusta. Ja tuo on lapsellista selittelyä, että "tasaisilla kelloilla tulos olisi eri", kun tosi maailmassa kellot vaikuttaa tulokseen ja ei ole Intelin vika, että AMD:n kello tasot on lapsen kengissä Inteliin verrattuna jopa niin että monta vuotta vanha keskitason prossu vie uusimpia Ryzeneitä

Jatkuvasti FUDia levität täällä. Nyt se tieteellinen laskenta on ilmeisesti hyvinkin tärkeää? Hetki sitten pelaaminen oli se tärkein asia mitä voi tehdä ja koska ryzen oli pari fps jäljessä, niin se on paska?

@Johan_V voisi antaa jotain konkreettista? Muuten vaikka tämä benchmarkki on validimpi jossa Intteli ottaa kuokkaan:

Ryzen Threadripper: Scientific & Engineering Computations, & HPC Performance

Parhaillaankin menee duunihommat 3d/video-videopuolella nopeammin ja halvemmalla kuin inttelillä. Mut kaipa tää Ryzen on huono kerta täällä sanotaan

 

[hkultala]

[offtopic]

OpenCL:n dokumentaatio ja ohjelmointi on ainakin ennen ollut CUDAa vaikeampaa; en tiedä onko asia parantunut viime aikoina. Ei ole mitenkään sattumaa että lähes kaikki näytönohjaimilla tehtävä tieteellinen laskenta käyttää Nvidian ohjaimia.

Ei sattumaa vaan enemmänkin nVidian onnistunutta markkinointia, sekä sitä että kun asia joskus on jotenkin niin luullaan että se on ikuisesti niin.

Koodaamalla CUDAa efektiivisesti lukitsee itsensä yhden valmistajan tuotteisiin ja sen armoille. Jos koodia kirjoitetaan yhtään pidemmän tähtäimen ylläpidettävyys mielessä, järkevämpää on käyttää hiukan enemmän aikaa siihen että koodaa sen yleisellä kaikkien tukemalla standardilla (OpenCL).

Erityisesti kun AMDn piirit on jo monta vuotta olleet selvästi nvidiaa edellä GPGPU-käytössä suorituskyky-hinta-suhteessa(koska nVidia on voinut paremman pelisuorituskyvyn ansiosta hinnoitella piirinsä ylemmäs), CUDAa käyttämällä lukitsee itsensä ulos hinta-suorituskyky-suhteeltaan parhaan raudan käyttämisestä.

[/offtopic]

 

[Johan_V]

Tuollaisessa matriisinmurskauksessa Intelin tuplasti leveämmistä SIMD-yksiköistä saadaan melkein kaikki hyöty irti, eli hyvinkään optimoidulla koodilla Zenillä ei saada tuollaisella koodilla läheskään samaa ydinkohtaista suorituskykyä kuin Intelin Well- tai Lake- sarjan prosessoreilta.

Mutta: Et kai laske asioita 64-bittisillä doubleilla? Se lienee tarkkuuden kannalta overkilliä, ja hidastanee kaiken n. puoleen verrattuna 32-bittisiin floatteihin.

Lisäksi tuollainen myös vaikuttaa koodilta, jossa se numeronmurskaus kannattaisi tehdä GPUlla, eikä CPUlla.

DP tarkkuus tarvitaan, koska iteraatiossa floattien tarkkuus ei yksinkertaisesti riitä.
GPU:lle koodia ei voi siirtää koska matriisit ovat liian isoja ja mahdollinen nopeusetu hukataan muistikopiointeihin.

Miten rajoitat nuo ajossa olevat säiemäärät?

Sekä zenissä että intelin nykyprossuissa on SMT, ja ne pystyvät ajamaan kahta säiettä/ydin, ja kun molemmat virtuaaliytimet on työllistetty, kokonaissuorituskyvyn pitäisi kyllä olla yleensä selvästi parempi kuin että rajoitetaan yhteen säikeeseen/fyysinen ydin.

OpenMP hoitaa tuon automaattisesti. Hyperthreading ei tuo mitään etua tässä tapauksessa, joten 1 säie per ydin toimii parhaiten.

@Johan_V voisi antaa jotain konkreettista? Muuten vaikka tämä benchmarkki on validimpi jossa Intteli ottaa kuokkaan:

Ryzen Threadripper: Scientific & Engineering Computations, & HPC Performance

Parhaillaankin menee duunihommat 3d/video-videopuolella nopeammin ja halvemmalla kuin inttelillä. Mut kaipa tää Ryzen on huono kerta täällä sanotaan

Noissa testeissä ei ole käytetty Intelin omaa MKL-kirjastoa. Kuten jo aiemmin sanoin, Intelin omat optimoinnit ovat aivan eri luokkaa. Jos verrataan jotain yleistä lineaarialgebrakirjastoa (e.g. OpenBLAS, ATLAS) niin AMD:n ja Intelin suorityskyky ovat lähellä toisiaan ja AMD todennäköisesti menee ohi suuremman ydinmäärän takia.
Mutta jos verrataan Intelin MKL vs mikä tahansa muu niin Intel on ylivoimainen. En väittänyt että AMD olisi laitteistotasolla varsinaisesti huonompi kuin Intel, vaan pointtini oli että optimoitujen kääntäjien ja kirjastojen puute tekee AMD:sta huonomman tyypilliseen tieteelliseen laskentaan.

Testasin juuri äsken AMD:n sivuillaan mainostamaa BLIS-kirjastoa Zen-optimoinneilla. Threadripperillä laskenta antaa muutaman kierroksen jälkeen Nan, vaikka muut kirjastot laskevat nätisti loppuun saakka.

[Offtopic]

[offtopic]

Ei sattumaa vaan enemmänkin nVidian onnistunutta markkinointia, sekä sitä että kun asia joskus on jotenkin niin luullaan että se on ikuisesti niin.

Koodaamalla CUDAa efektiivisesti lukitsee itsensä yhden valmistajan tuotteisiin ja sen armoille. Jos koodia kirjoitetaan yhtään pidemmän tähtäimen ylläpidettävyys mielessä, järkevämpää on käyttää hiukan enemmän aikaa siihen että koodaa sen yleisellä kaikkien tukemalla standardilla (OpenCL).

Erityisesti kun AMDn piirit on jo monta vuotta olleet selvästi nvidiaa edellä GPGPU-käytössä suorituskyky-hinta-suhteessa(koska nVidia on voinut paremman pelisuorituskyvyn ansiosta hinnoitella piirinsä ylemmäs), CUDAa käyttämällä lukitsee itsensä ulos hinta-suorituskyky-suhteeltaan parhaan raudan käyttämisestä.

[/offtopic]

AMD:n rauta voi olla parempaa laskentakäyttöön, mutta AMD:llä on aina ollut ongelmia softapuolen kanssa. En tiedä missä määrin tilanne on parantanut muutaman viimeisen vuoden aikana, mutta ainakin Linux-puolella tuli vannottua että ei koskaan enää AMD:n kortteja.

Vaikka CUDAa käyttäessä lukitsee itsensä nvidiaan, niin samalla tavalla OpenCL:ää käyttäessä käytännössä lukitsee itsensä AMD:hen, sillä nvidian openCL suorityskyky ei ainakaan ennen ollut yhtä hyvä kuin Cudalla.
Suorityskykyoptimoinnit OpenCL:llä ovat hankalampia kuin CUDAlla juuri softan vuoksi. Oman käsitykseni mukaan myös OpenCL vaatii huomattavasti enemmän matalan tason säätämistä kuin CUDA hyvän suorityskyvyn saavuttamiseksi, mutta voi olla että tilanne on parantunut viime vuosina.

 

[hkultala]

Miten rajoitat nuo ajossa olevat säiemäärät?

Sekä zenissä että intelin nykyprossuissa on SMT, ja ne pystyvät ajamaan kahta säiettä/ydin, ja kun molemmat virtuaaliytimet on työllistetty, kokonaissuorituskyvyn pitäisi kyllä olla yleensä selvästi parempi kuin että rajoitetaan yhteen säikeeseen/fyysinen ydin.

OpenMP hoitaa tuon automaattisesti.

Käsittääkseni OpenMP:n pitäisi kyllä oletuksena käyttää kaikkia virtuaaliytimiä, ellei sitä erikseen rajoiteta.

Hyperthreading ei tuo mitään etua tässä tapauksessa, joten 1 säie per ydin toimii parhaiten.

Tuollaisessa massiivisesti rinnakkaisessa kamassa SMT kyllä hyvin todennäköisesti toisi selvän hyödyn, ellei softasi ole täysin muistikaistariippuvainen tai aktiivinen working set ole juuri sen kokoinen että se mahtuu yhden säikeen osalta L1D-kakkuun mutta kahden säikeen osalta ei.

Nykyprossujen FPU-tehon optimaalinen hyödyntäminen yhdestä säikeestä on nimittäin aika vaikeaa, kun FPU:n käskyillä on tyypillisesti joku n. 4 kellojakson viive. Tarkoittaa, että se edellisen käskyn tulosta käyttävä seuraava käsky voidaan suorittaa vasta 4 kellojaksoa myöhemmin. Tässä neljän kellojakson ajassa pystytään suorittamaan esim 8 FMA-käskyä, koska nykyprossuilla on liukulukuyksikössä 2 FMA-yksikköä. Tarvii olla aika monta loopin iteraatiota yhtä aikaa suorituksessa, ja jos loopin iteraatioden välillä on datariippuvuuksia, kuten esim. pistetulossa(joka esiintyy myös matriisikertolaksun ytimessä), menee hankalaksi.

 

[hkultala]

[offtopic]

Vaikka CUDAa käyttäessä lukitsee itsensä nvidiaan, niin samalla tavalla OpenCL:ää käyttäessä käytännössä lukitsee itsensä AMD:hen, sillä nvidian openCL suorityskyky ei ainakaan ennen ollut yhtä hyvä kuin Cudalla.

Eikä lukitse. OpenCL on avoin standardi, jota tukee kymmenet firmat, ja se toimii myös sillä nVidialla.

Maailmassa on ziljoona mielenkiintoista pientä manycore-prosessoria, mobiili-GPUta yms. kiihdytintä jotka tukevat OpenCLää. Ja osa näistä verkottuu yhteen supertietokone-luokan suorituskykyyn asti.

ja nVidia kääntää OpenCL-koodin ihan samalla kääntäjällä kuin CUDA-koodin.

Ja jos nVidian OpenCL-suorituskyky on huonompi kuin CUDA-suorituskyky, se on joko
1) nVidian perseilyä CUDAn promotoimiseksi
2) Sitä että vanha versio OpenCL:stä ei ole tukenut jotain ominaisuutta jota CUDA tukee joka on joissain benchmarkeissa mahdollistanut nVidialle paremman suorituskyvyn. Tämä ei yleisty softiin, jotka eivät kyseistä ominaisuutta käytä, eikä tilanteeseen, jossa käytetään uudempaa OpenCL:ää joka tukee samaa ominaisuutta.

Väittäisin näitä "CUDA on nopeampi kuin OpenCL"-juttuja siis lähinnä mutuiluksi jonkun muinaishistorian perusteella.

Tosin, saattaa olla että nVidia ylipäätään vieläkin tukee vain muinaista versioita OpenCL:stä.

[/offtopic]

 

[JiiPee]

AMD:n rauta voi olla parempaa laskentakäyttöön, mutta AMD:llä on aina ollut ongelmia softapuolen kanssa. En tiedä missä määrin tilanne on parantanut muutaman viimeisen vuoden aikana, mutta ainakin Linux-puolella tuli vannottua että ei koskaan enää AMD:n kortteja.

Noh, juuri tuossa Linus hyväksyi AMD:n näytönohjain ajurit natiivisti kerneliin että sellaista kehitystä tapahtunut.
Samaa nVidian puolelta saadaan odottaa ja kauan jos tulee tapahtumaan koskaan.

 

[sushukka]

Noh, juuri tuossa Linus hyväksyi AMD:n näytönohjain ajurit natiivisti kerneliin että sellaista kehitystä tapahtunut.
Samaa nVidian puolelta saadaan odottaa ja kauan jos tulee tapahtumaan koskaan.

Ja muutenkin erikoista kuulla tällaista hehkutusta suljetuille ratkaisuille nimenomaan tieteellisen sektorin suusta jossa, ainakin kun itse aikanaan yliopistolla tallustin, kannustettiin ajattelemaan täysin päinvastaisesti. Toki tällä hetkellä tilanne on Intelin ja Nvidian käsissä, mutta sen paremmalla syyllä tiedemaailman tulisi suosia tiedon, koodin ja protokollien avoimuutta. Itse uskon kyllä että AMD:n suunta on oikea ja voittaa pitkässä juoksussa. Natiivit ajurit Linukan kerneliin on iso harppaus ja OpenCL:t, Vulkanit yms, tulevat kyllä ajan kanssa syömään suljetut kilpailijansa pois. Koska Zen tullut vasta hiljattain, niin optimointeja saadaan hetki odottaa, mutta nyt kun on AMD on taas kuvioissa mukana, niin aivan varmasti niitä tulee alueelle kuin alueelle.

 

[Johan_V]

Käsittääkseni OpenMP:n pitäisi kyllä oletuksena käyttää kaikkia virtuaaliytimiä, ellei sitä erikseen rajoiteta.

Asetin säikeiden määräksi fyysisten ytimien lukumäärän ja affinityn fyysisille ytimille, mutta loput säädöt jätin oletuksille.

Tuollaisessa massiivisesti rinnakkaisessa kamassa SMT kyllä hyvin todennäköisesti toisi selvän hyödyn, ellei softasi ole täysin muistikaistariippuvainen tai aktiivinen working set ole juuri sen kokoinen että se mahtuu yhden säikeen osalta L1D-kakkuun mutta kahden säikeen osalta ei.

Nykyprossujen FPU-tehon optimaalinen hyödyntäminen yhdestä säikeestä on nimittäin aika vaikeaa, kun FPU:n käskyillä on tyypillisesti joku n. 4 kellojakson viive. Tarkoittaa, että se edellisen käskyn tulosta käyttävä seuraava käsky voidaan suorittaa vasta 4 kellojaksoa myöhemmin. Tässä neljän kellojakson ajassa pystytään suorittamaan esim 8 FMA-käskyä, koska nykyprossuilla on liukulukuyksikössä 2 FMA-yksikköä. Tarvii olla aika monta loopin iteraatiota yhtä aikaa suorituksessa, ja jos loopin iteraatioden välillä on datariippuvuuksia, kuten esim. pistetulossa(joka esiintyy myös matriisikertolaksun ytimessä), menee hankalaksi.

Ymmärtääkseni tyypillisillä lineearialgebran laskuilla ei hyperthreading tuo juuri mitään etua. Jossain kirjastoissa hyperthreading jopa suositellaan poistamaan käytöstä, jotta säikeet ohjautuvat fyysisille ytimille. Omat kokemukset tukevat tätä, säikeitten lukumäärä ei lisää suorityskykyä kun mennään yli fyysisten ytimien lukumäärän.

 

[Melbac]

Okei jos kerran sanot niin

Mitähän tuolla "pahemmin" sanalla tarkoitetaan.

Paljos yli 4Ghz noi kellottuu?.

 

[hkultala]

[offtopic]

Asetin säikeiden määräksi fyysisten ytimien lukumäärän ja affinityn fyysisille ytimille, mutta loput säädöt jätin oletuksille.

Ymmärtääkseni tyypillisillä lineearialgebran laskuilla ei hyperthreading tuo juuri mitään etua. Jossain kirjastoissa hyperthreading jopa suositellaan poistamaan käytöstä, jotta säikeet ohjautuvat fyysisille ytimille.

Nämä ohjeet on tyypillisesti vuodelta miekka ja kypärä, kun prosessorina oli Pentium 4 jossa oli onnettoman pieni 8 kiB L1D-välimuisti, jolla kahden säikeen ajaminen usein aiheutti välimuisteissa ylimääräistä ping poing-efektiä(selvä hidastus), ja prosessori vielä replayasi käskyjä aina kakkuhudin tapauksessa, jolloin laskentayksiköiden suorituskapasiteettia myös haaskattiin eikä sitä riittänyt molemmille säikeille.

Nykyprossuilla suorituskykyhyöty SMT:stä on ihan eri tasolla kuin Pentium 4lla, kun L1D-välimuistia on 4 kertaa enemmän, replay-mekanismia ei ole ja laskentayksiköitä on enemmän.

Omat kokemukset tukevat tätä, säikeitten lukumäärä ei lisää suorityskykyä kun mennään yli fyysisten ytimien lukumäärän.

Omat kokemukset millä?

Ettei ole tullut nyt jotain mokaa? Että olet esim. mennyt BIOSista disabloimaan sen SMT:n noudattaaksesi niitä P4-aikaisia ohjeita?

[/offtopic]

 

[Jage]

Paljos yli 4Ghz noi kellottuu?.

No sano sitten se eikä mitään turhaa pyörittelyä.

 

[Threadripper]

OpenCL:n dokumentaatio ja ohjelmointi on ainakin ennen ollut CUDAa vaikeampaa; en tiedä onko asia parantunut viime aikoina. Ei ole mitenkään sattumaa että lähes kaikki näytönohjaimilla tehtävä tieteellinen laskenta käyttää Nvidian ohjaimia.

Kuten hkultala ansiokkaasti selvitti, nuo "vaikeampi tehdä ilman Cudaa"-väitteet kuuluvat kastiin uskomukset jotka joskus (ehkä) pitivät paikkaansa. Ei sekään ole sattumaa että konsolit ja Applen "työkoneet" käyttävät enimmäkseen AMD:ta. Vastaava tilannehan oli 15 vuotta sitten. AMD:n prosessorit voittivat Intelit about kaikessa, silti palvelimissa oli enimmäkseen Inteliä.

On hieman eri asia lukea asioista kuin tehdä niitä itse. Siinä mielessä olet kyllä oikeassa, AMD:n matikkakirjastoja ei moitita koska niitä ei ole.

Kannattaa käyttää jotain valmista mikäli oma tekele ei toimi kunnolla. Tai tehdä oma tekele kunnolla.

Eikö olisi kannattanut ennemminkin olla vääntelemättä muiden sanomisia!
Vai oletko siis ihan tosissaan, että
välttävä=huono?
Siihen kun ei lainausmerkit vaikuta!

Lue vielä uusiksi se mitä lainasin. Siinä ei sanota missään kohtaa sanaa välttävä.

Puhuinkin tärkeillä osa-alueilla Intel vie. Ja katsoppa tätä sivua ylemmäs, video on todisteena, että R5 1600X ei antanut sen kummemmin vastusta. Ja tuo on lapsellista selittelyä, että "tasaisilla kelloilla tulos olisi eri", kun tosi maailmassa kellot vaikuttaa tulokseen ja ei ole Intelin vika, että AMD:n kello tasot on lapsen kengissä Inteliin verrattuna jopa niin että monta vuotta vanha keskitason prossu vie uusimpia Ryzeneitä

Intelin toiseksi kallein työpöytäprosessori = keskitasoa

 

[Johan_V]

Omat kokemukset millä?

Ettei ole tullut nyt jotain mokaa? Että olet esim. mennyt BIOSista disabloimaan sen SMT:n noudattaaksesi niitä P4-aikaisia ohjeita?

[/offtopic]

Koneina Threadripper 1950x Asrock x399 Taichi emolevy ja 96GB (3000 Mhz CL15) muistia
i7-5960x (4Ghz) Asus deluxe x99 emolevy, 64GB muistia
Tulokset:
Intel 8 threads icc+mkl 7m30s
Intel 16 threads icc+mkl 6m27s
Intel 8 threads gcc+OpenBLAS 11m20s [-02 -ffast-math]
Intel 8 threads gcc+OpenBLAS 12m25s [-O3]
Intel 8 threads gcc+mkl 8m12s

AMD 16 threads gcc+OpenBLAS 14m38s
AMD 32 threads gcc+OpenBLAS 13m42s

Affinity asetettu niin että fyysiset ytimet täytetään ensin. Kuten näkyy hyperthreading vaikutus on varsin minimaalinen. Nämä ovat vain yhdestä ajosta, joten erot voivat vielä tasoittua. Kerralla käytössä on 30 säiettä, joten AMD:n ytimet eivät tule aivan täyteen. Tästä näkyy myös että Intelin icc+mkl yhdistelmä on täysin ylivoimainen verrattuna OpenBLASiin. Muistikäyttö AMD:llä oli noin 45GB.

 

[hkultala]

Koneina Threadripper 1950x Asrock x399 Taichi emolevy ja 96GB (3000 Mhz CL15) muistia
i7-5960x (4Ghz) Asus deluxe x99 emolevy, 64GB muistia
Tulokset:
Intel 8 threads icc+mkl 7m30s
Intel 16 threads icc+mkl 6m27s
Intel 8 threads gcc+OpenBLAS 11m20s [-02 -ffast-math]
Intel 8 threads gcc+OpenBLAS 12m25s [-O3]
Intel 8 threads gcc+mkl 8m12s

AMD 16 threads gcc+OpenBLAS 14m38s
AMD 32 threads gcc+OpenBLAS 13m42s

Affinity asetettu niin että fyysiset ytimet täytetään ensin. Kuten näkyy hyperthreading vaikutus on varsin minimaalinen. Nämä ovat vain yhdestä ajosta, joten erot voivat vielä tasoittua. Kerralla käytössä on 30 säiettä, joten AMD:n ytimet eivät tule aivan täyteen. Tästä näkyy myös että Intelin icc+mkl yhdistelmä on täysin ylivoimainen verrattuna OpenBLASiin. Muistikäyttö AMD:llä oli noin 45GB.

Noniin, eli siis SMT nopeutti näissä sekä Intelillä että AMDllä. 6:27 on nopeampi kuin 7:30 ja 13:42 on nopeampi kuin 14:38.

Ja onhan tuossa intelillä 16% nopeutus tuosta SMT:stä, ei se ihan olematon nopeutus ole.

AMDn 7% nopeutus toki on melko pieni, mutta edelleen nopeutus. Ei mitään järkeä jättää tätä hyödyntämättä.


Intelin AMDtä suurempi hyöty SMTstä tässä selittynee sillä, että AMD kun AMD joutuu pilkkomaan 256-bittiset AVX-käskyt kahteen osaan, FPUn utilisaatioaste yhdellä säikeellä on AMDllä suurempi, ja on vähemmän idlaavia yksiköitä, joita toinen säie voi hyödyntää häiritsemättä ensimmäistä säiettä.



Mutta jos tuota softaa ajellaan paljon ja sen nopeutus on oikeasti tärkeätä, sitten kannattanee prosessoriksi hankkia >10-ytiminen Skylake-X (core i9, vähintään 7920X). Niissä on AVX-512 kahdella 512-bittisellä FMA-yksiköllä, eli siis taas tuplattu tuo numeronmurskausnopeus/ydin. (vähempiytimisissä skylake-X:ssä 512-bittisiä FMA-yksiköitä on vain 1/ydin)

 

[JiiPee]

Intelin toiseksi kallein työpöytäprosessori = keskitasoa

´
Se varmaan länkytti siitä 4690K:sta ja 2600K:sta edelleen tuossa.

 

[JiiPee]

Kuten näkyy hyperthreading vaikutus on varsin minimaalinen.

Tuota millaisia odotuksia sinulla siitä HT tehosta oikein on?

Best case skenariossa Intelin HT antaa noin 20-25% oikean coren tehosta, AMD:llä vastaava luku on 25-30%
Ja kuten hkultala tuossa laski niin se Intel hyötyi 16% siitä HT:stä joka on jo ihan kohtalainen lisä.

 

[hupiukko]

Onko OpenBLAS-kirjasto käännetty zenille?

 

[Griffin]

Lue vielä uusiksi se mitä lainasin. Siinä ei sanota missään kohtaa sanaa välttävä.

Vielä vähemmän ko lainauksessa puhutaan huonosta. Alunperäisessä viestissä olen todennut zenin olevan perusteet esittäen välttävä julkaisu. Ja kannatta hahmottaa, että välttävän ja huonon välillä on hyvin selkeä ero, eli elä koita väännellä ja puhua soopaa, mitä on sanottu.

 

[Threadripper]

´
Se varmaan länkytti siitä 4690K:sta ja 2600K:sta edelleen tuossa.

Sitä minäkin tarkoitin.

Vielä vähemmän ko lainauksessa puhutaan huonosta. Alunperäisessä viestissä olen todennut zenin olevan perusteet esittäen välttävä julkaisu. Ja kannatta hahmottaa, että välttävän ja huonon välillä on hyvin selkeä ero, eli elä koita väännellä ja puhua soopaa, mitä on sanottu.

Kannattaa hahmottaa mitä lainasin ja mitä siihen vastasin eikä takertua yhteen sanaan. Joka ei edes ollut huono vaan "huono".

 

[sushukka]

Vielä vähemmän ko lainauksessa puhutaan huonosta. Alunperäisessä viestissä olen todennut zenin olevan perusteet esittäen välttävä julkaisu. Ja kannatta hahmottaa, että välttävän ja huonon välillä on hyvin selkeä ero, eli elä koita väännellä ja puhua soopaa, mitä on sanottu.

No tuolla skaalalla ja jotakuinkin kaikki merkittävät globaalit netin arvostelusaitit huomioon ottaen, niin uusin Tesla on siinä välttävän rajalla, Ryzen on joo välttävä, Applella menee välttävästi ja voisihan sitä kokeilla sanoa eukollekin että joo oli ihan välttävä suoritus (vaikka henki siinä varmaan menisi).

 

[Taneli-]

No sano sitten se eikä mitään turhaa pyörittelyä.

Nopeasti katsoen 5.8GHz käyttäen 8-ydintä ja 16-säiettä? Mutta minusta on aika turhaa etsiä tuollaisia "miten paljon maksimissaan voi prosessoria ylikellottaa". Tosin jokainen tyylillään.. ..toivottavasti olet onnellinen tiedosta. Itse en tuolla tiedolla mitään tee paitsi ehkä voin todeta että Intelillä ei taida olla kiveä mikä kellottuu yhtä hyvin 8-ytimellä ja 16-säikeellä?

Edit: jos mietit asiaa Coffee Lakea ajatellen (eli 6-ydin/12-säie) niin siinä päästään näköjään 5.9GHz 1600X prosessorilla. Mutta en edelleenkään tiedä mitä nyt tavalliset henkilöt tekevät tiedolla?

Tässä vielä videota tuosta:

Tämän sisällön näkemiseksi tarvitsemme suostumuksesi kolmannen osapuolen evästeiden hyväksymiseen.
Lisätietoja löydät evästesivultamme.

Hyväksy kolmannen osapuolen evästeet

 

[Johan_V]

Noniin, eli siis SMT nopeutti näissä sekä Intelillä että AMDllä. 6:27 on nopeampi kuin 7:30 ja 13:42 on nopeampi kuin 14:38.

Ja onhan tuossa intelillä 16% nopeutus tuosta SMT:stä, ei se ihan olematon nopeutus ole.

AMDn 7% nopeutus toki on melko pieni, mutta edelleen nopeutus. Ei mitään järkeä jättää tätä hyödyntämättä.

Olet kyllä oikeassa. Alkuperäinen pointtini oli kuitenkin se, että on ihmeellistä miten Intel pystyy omalla MKL-paketillaan saavuttamaan noin suuren nopeushyödyn verrattuna muihin, esimerkiksi tuossa OpenBLASiin verrattuna (7m30s vs 11m20s), joka on kuitenkin käännetty täysillä prosessorikohtaisilla optimoinneilla. On sääli ettei AMD:llä ole mitään vastaavaa, kaikki on vain julkaistu open-sourcena ajatuksena ilmeisesti että yhteisö tekee raskaan työn ja AMD vain lisää jonkun patchin silloin tällöin. Kuten tuossa aiemmin totesin, AMD:n open source BLIS kirjasto on lähes käyttökelvoton. Olisi mielenkiintoista nähdä kuinka paljon suorituskykyä AMD pystyisi puristamaan prosessorista irti, mutta nähtävästi AMD:llä ei ole resursseja eikä mielenkiintoa kehittää kunnollisia kirjastoja.

 

[KovaDekki]

Intel on prossujen Apple, ilman kilpailua intel voisi käyttää asemaansa väärin.

AMD tuo lisää kilpailua, joka on erittäin hyvä kuluttajille.

Ostamalla tuotteita, tuette jatkossa kehitystä ja uusia innovatioita.

 

[JiiPee]

AMD:n open source BLIS kirjasto on lähes käyttökelvoton. Olisi mielenkiintoista nähdä kuinka paljon suorituskykyä AMD pystyisi puristamaan prosessorista irti, mutta nähtävästi AMD:llä ei ole resursseja eikä mielenkiintoa kehittää kunnollisia kirjastoja.

Oletkos tähän tutustunut?
BLIS - GPUOpen

AMD pistää aika paljon paukkuja tuonne GPU puolelle kehitykseen, käsittääkseni hiljattain palkkasivat jonkinverran väkeä työskentelemään pelkästään ROCm:n kanssa.

Ilmeisesti AMD visioi että yhä enemmän GPU:lla tullaan laskentaa tekemään ja vegan tuoma HBCC esimerkiksi voisi auttaa nimenomaan sellaisessa tilanteessa missä GPU:n oma muisti ei riitä sille työlle kun saumattomasti voidaan käyttää järjestelmän muistia sen kortin oman muistin jatkeena jolloin se kopiointi josta aiemmin puhuit ei välttämättä enää olekaan ongelma.

Oletkos sitä AMD:tä kokeillut sillä Intelin kääntäjällä ja kirjastoilla? Eikös niiden pitäisi toimia myös AMD:n prossulla?
Tosin historissa Intel on perseillyt ja ne hienoimmat optimoinnit on saanut vain heidän prosessoreillaan käyttöön kun taas AMD:llä on käytetty ihan peruskäskyjä vaikka tukisikin samoja käskyjä kuin Intelin prosessori.
Olivat ihan oikeudessa tuon casen takia.

Sitten tietysti kannattaisi myös clang:lla kokeilla, se pieksee GCC:n aika hyvin tietyissä tilanteissa ja toisissa taas häviää.
GCC vs. LLVM Clang Compiler Performance On AMD's Ryzen - Phoronix

Ja kuten tuosta käy ilmi niin jopa sillä on paljon merkitystä mitä versiota GCC:stä taikka clang:sta käyttää.

 

[Griffin]

Oletkos tähän tutustunut?
BLIS - GPUOpen

AMD pistää aika paljon paukkuja tuonne GPU puolelle kehitykseen, käsittääkseni hiljattain palkkasivat jonkinverran väkeä työskentelemään pelkästään ROCm:n kanssa.

Ilmeisesti AMD visioi että yhä enemmän GPU:lla tullaan laskentaa tekemään ja vegan tuoma HBCC esimerkiksi voisi auttaa nimenomaan sellaisessa tilanteessa missä GPU:n oma muisti ei riitä sille työlle kun saumattomasti voidaan käyttää järjestelmän muistia sen kortin oman muistin jatkeena jolloin se kopiointi josta aiemmin puhuit ei välttämättä enää olekaan ongelma.

Oletkos sitä AMD:tä kokeillut sillä Intelin kääntäjällä ja kirjastoilla? Eikös niiden pitäisi toimia myös AMD:n prossulla?
Tosin historissa Intel on perseillyt ja ne hienoimmat optimoinnit on saanut vain heidän prosessoreillaan käyttöön kun taas AMD:llä on käytetty ihan peruskäskyjä vaikka tukisikin samoja käskyjä kuin Intelin prosessori.
Olivat ihan oikeudessa tuon casen takia.

Sitten tietysti kannattaisi myös clang:lla kokeilla, se pieksee GCC:n aika hyvin tietyissä tilanteissa ja toisissa taas häviää.
GCC vs. LLVM Clang Compiler Performance On AMD's Ryzen - Phoronix

Ja kuten tuosta käy ilmi niin jopa sillä on paljon merkitystä mitä versiota GCC:stä taikka clang:sta käyttää.

Jos käsiteltävät datalohkot ovat yhtään isompia, ja niitä joutuu swappaammaan / hakemaan keskusmuistista, niin PCIe:n hitaus syö hyvin äkkiä sen GPU:n rinnakkaisuuden aikaansaaman hyödyn.
Kun dataa prosessoidaan raskaasti, niin se data ei saa olla minkään hitaan väylän päässä, vaan mahdollisimma äkkiä saatavissa.
Esim valokuvia käsitellessä, kun kuvat veivät yli 64 GT, näyttis (6Gigaa muistilla) oli melkoisen turha kapine, vaikka softa sitä tuki VS 6C12T (IVYB) prossuun ja 32 Gigaan muistia.

Prossussa oleva GPU voi olla tuohon ihan hyvä, paitsi siinä tapauksessa 2 kanavainen DDR4 muistiohjain kyllä tikahtuu alkuunsa, joten saavutettava hyöty jää helposti pieneksi.
-----------------
Heterogenous CPU olisi kova sana, mutta se vaatii tiukkaa yhteistyötä ominaisuuksien käyttöönottamiseksi mm. MS:n kanssa. Pelkkä raudan julkaisu on täysin riittämätön tempaus. Lisäksi jos eri valmistajat tekevät epäyhteensopivat versiot aiheesta, niin ko ominaisuuden käyttöönotto hidastuu erittäin huomattavasti.

 

[JiiPee]

Jos käsiteltävät datalohkot ovat yhtään isompia, ja niitä joutuu swappaammaan / hakemaan keskusmuistista, niin PCIe:n hitaus syö hyvin äkkiä sen GPU:n rinnakkaisuuden aikaansaaman hyödyn.
Kun dataa prosessoidaan raskaasti, niin se data ei saa olla minkään hitaan väylän päässä, vaan mahdollisimma äkkiä saatavissa.
Esim valokuvia käsitellessä, kun kuvat veivät yli 64 GT, näyttis (6Gigaa muistilla) oli melkoisen turha kapine, vaikka softa sitä tuki VS 6C12T (IVYB) prossuun ja 32 Gigaan muistia.

Prossussa oleva GPU voi olla tuohon ihan hyvä, paitsi siinä tapauksessa 2 kanavainen DDR4 muistiohjain kyllä tikahtuu alkuunsa, joten saavutettava hyöty jää helposti pieneksi.

Nyt sinä unohdat kokonaan että HBCC:n kanssa sitä swappaamista ei tarvitse tehdä. GPU:n muistiin ladataan se mitä mahtuu ja loput keskusmuistiin ja sitä dataa voidaan käyttää suoraan sieltä keskusmuistista ilman mitään swappailua. Tämä ei ole graffakorteissa ollut ennen mahdollista käsittääkseni vaan aina on jouduttu swappaamaan jos ei ole mahtunut kortin muistiin.

Tai ilmeisesti HBCC mahdollistaa myös sellaisen toiminnan että se kortin muisti on kakkuna ja sinne taltioidaan dataa joka ottaa hittiä kovin, muu on keskusmuistissa.

Tai sitten jos data vaatii teratavulla muistia, niin sekin onnistuu AMD:llä SSG:n kanssa.

Kokeileppa huviksesi tuota sinun 64GT skenaariota Vegan kanssa ja anna sille Vegalle vaikka +24 Gigaa HBCC:n kanssa muistoa, vähän veikkaan että tulos on hiukan toinen kuin tuolla pelkällä 6GT muistolla varustetulla kortilla.

 

[Griffin]

Nyt sinä unohdat kokonaan että HBCC:n kanssa sitä swappaamista ei tarvitse tehdä. GPU:n muistiin ladataan se mitä mahtuu ja loput keskusmuistiin ja sitä dataa voidaan käyttää suoraan sieltä keskusmuistista ilman mitään swappailua. Tämä ei ole graffakorteissa ollut ennen mahdollista käsittääkseni vaan aina on jouduttu swappaamaan jos ei ole mahtunut kortin muistiin.

Tai ilmeisesti HBCC mahdollistaa myös sellaisen toiminnan että se kortin muisti on kakkuna ja sinne taltioidaan dataa joka ottaa hittiä kovin, muu on keskusmuistissa.

Tai sitten jos data vaatii teratavulla muistia, niin sekin onnistuu AMD:llä SSG:n kanssa.

Kokeileppa huviksesi tuota sinun 64GT skenaariota Vegan kanssa ja anna sille Vegalle vaikka +24 Gigaa HBCC:n kanssa muistoa, vähän veikkaan että tulos on hiukan toinen kuin tuolla pelkällä 6GT muistolla varustetulla kortilla.

HBCC vain lähinnä automatisoi datanvaihdon näyttiksen muistiin.

Sikäli, kun se käsiteltävä datamöhkäle on iso, HBCC:llä ei saavuteta mitään hyötyä, jos se ei maagisesti lisää PCIe:n kaistaa, jota se ei tee. Asian pyörittely taustalla ei auta kertakaikkiseen kaistan puutteeseen. Välimuistia (näyttiksen muistia) pitää olla niin paljon, jotta PCIe siirrot ovat hyvin harvinaisia. Nyt jos kuitenkin rinnakkaistetaan massiivisesti, esim käsitellään aineiston eri osia, niin tuo cache (näyttiksen muisti) jää melko pieneksi ja PCIe laulaa usein, jolloin se tukkeutuu.
Jos tuolla maagisesti ratkaistaisiin näyttiksen paikallismuistin määrän ongelma, niin meillä ei suorituskykyisiisä näyttiksissä olisi läheskään niinpaljon muistia, kuin nyt on, sillä GPU:n kylkeen lyötävä muisti on kallista ja noissa säästetään, aina, kun mahdoollista.

Materiaaleja ei enää ole, eikä ole ohjelmaakaan, ko versio toimi vain rajoitetun ajan. Pitempi käyttö vaatisi hyvin kalliin lisenssin.

No, Vegassa on 16 Gigaa matalalatenssista, nopeaa muistia ja se on paljon uudempi kortti. Vaikka AMD tyrikin vegan kanssa raskaasti, niin en hetkeäkään epäile, etteikö se olisi jonkinverran / paljonkin nopeampi, riippuen, miten tuo muisti riittäisi.

 

[Jage]

Nopeasti katsoen 5.8GHz käyttäen 8-ydintä ja 16-säiettä? Mutta minusta on aika turhaa etsiä tuollaisia "miten paljon maksimissaan voi prosessoria ylikellottaa".

En tiedä ymmärsinkö nyt jotain väärin viestistäsi, mutta itseäni nimenomaan tuossa alkuperäisen kirjoittajan lausahduksessa ärsytti se epämääräisyys. Se kun jättää aika paljon auki ja jos nyt jaksaisin niin alkaisin laskemaan prosentuaalista arvoa tuolle kellotaajuuden nostolle mutta koska olen laiska niin en viitsi.

Nimim. itsehän en ole edes omaa prossuani (R5 1600) kellottanut lainkaan

 

[Taneli-]

En tiedä ymmärsinkö nyt jotain väärin viestistäsi, mutta itseäni nimenomaan tuossa alkuperäisen kirjoittajan lausahduksessa ärsytti se epämääräisyys. Se kun jättää aika paljon auki ja jos nyt jaksaisin niin alkaisin laskemaan prosentuaalista arvoa tuolle kellotaajuuden nostolle mutta koska olen laiska niin en viitsi.

Nimim. itsehän en ole edes omaa prossuani (R5 1600) kellottanut lainkaan

Noh, R5 1600X 3.6GHz (turbo 4) => 5.9GHz ja 1800X 3.6 (turbo 4) => 5.8GHz

jos 3600 = 100% niin 36 = 1%, tästä voidaan laskea että 5800 = 161.1111...% ja 5900 = 163.888...%
Eli maksimissaan 1800X saa kellotettua vakiosta sen rapiat 161% (jos vakio on 100%) ja 1600X prosessoria 163,9% (jos vakio on 100%)

JOS oletetaan että 1600 kellottuisi saman verran kuin 1600X voidaan laskea että 3.2GHz = vakio (3.6 turbolla) joten:
3200 = 100% niin 32 = 1% tästä voidaan laskea että 5800 = 181.25% ja 5900 = 184,375%

Itse voisin siis teoriassa todeta että oma 1700X voi teoreettisesti kellottua 3.4GHz (3.8turbo) samalla kaavalla katsoen pelkästään 1800X saatua ennätystä 34 = 1% joten 170% ja rapiat saisin "hyötyä" maksimaalisesta kellotuksesta.

Käytännön kellotuksesta voin 24/7 kelloistani tehdä seuraavan laskun: 3975 (nykyinen kellotukseni) ~117% kellotus (3.975GHz) ja idlatessaan vain 33.8% kellot (1.15GHz)
Joku voi laskea paljonko jännite-eroa (tai euroja kuukaudessa tms) tulee maksimiin kellotetulla omalla prosessorillani (1.35625V) minimiin verrattuna (0.6025V) jos haluaa, itse en nyt jaksa alkaa moiseen.

 

[Jage]

Noh, R5 1600X 3.6GHz (turbo 4) => 5.9GHz ja 1800X 3.6 (turbo 4) => 5.8GHz

Tämä nyt meni ihan alkuperäisen aiheen ohi jota käyttäjän Melbac viestistä kritisoin mutta ei nyt jatketa suotta tästä aiheesta.

 

[Phat-J]

Nopeasti katsoen 5.8GHz käyttäen 8-ydintä ja 16-säiettä? Mutta minusta on aika turhaa etsiä tuollaisia "miten paljon maksimissaan voi prosessoria ylikellottaa". Tosin jokainen tyylillään.. ..toivottavasti olet onnellinen tiedosta. Itse en tuolla tiedolla mitään tee paitsi ehkä voin todeta että Intelillä ei taida olla kiveä mikä kellottuu yhtä hyvin 8-ytimellä ja 16-säikeellä?

Nimenomaan lähes ketään ei kiinnosta nuo kuivajää/nestetyppi kellotukset - Ei auta Janne PerusJonnea edes Cinepelissä...

Silti pitänee nyt kuitenkin korjata yllä oleva lainaus seuraavalla linkillä:

Cinebench - R15 overclocking records @ HWBOT

 

[vaappu79]

Nimenomaan lähes ketään ei kiinnosta nuo kuivajää/nestetyppi kellotukset - Ei auta Janne PerusJonnea edes Cinepelissä...

Silti pitänee nyt kuitenkin korjata yllä oleva lainaus seuraavalla linkillä:

Cinebench - R15 overclocking records @ HWBOT

Ei näy muuten rytsölää tuolla listalla 5.8MHz kohalla vaan korkein on 5.5MHz.
Että kuinkas on?

 

[Phat-J]

Ei näy muuten rytsölää tuolla listalla 5.8MHz kohalla vaan korkein on 5.5MHz.
Että kuinkas on?

No mitäs maagista se ryzölä saavuttaisi tolla 5,5 -> 5,8GHz kellotaajudella?

Lainaus johon aiemmin vastasin liittyi ainoastaan maksimikellotukseen ja mielestäni linkin useampi 6GHz+ Intel vähän niin kuin kumoaa tämän?!

 

[Taneli-]

Lainaus johon aiemmin vastasin liittyi ainoastaan maksimikellotukseen ja mielestäni linkin useampi 6GHz+ Intel vähän niin kuin kumoaa tämän?!

Jos siellä nyt oli useampikin kellotus tehty "Itse en tuolla tiedolla mitään tee paitsi ehkä voin todeta että Intelillä ei taida olla kiveä mikä kellottuu yhtä hyvin 8-ytimellä ja 16-säikeellä?" vähintään 8-ydin/16-säie prosessorilla siten että kaikki ytimet sekä säikeet olivat käytössä? Koska olihan siinä minun postissani myös "vain" 6-ydin/12-säi 5.9GHz 1600X tulos mihin voi sitten vertailla näitä ns. halpaversioita prosessoreista millä on vähäisempi määrä ytimiä jne. käytössään.

 

[Deleted member 4604]

Koneina Threadripper 1950x Asrock x399 Taichi emolevy ja 96GB (3000 Mhz CL15) muistia
i7-5960x (4Ghz) Asus deluxe x99 emolevy, 64GB muistia
Tulokset:
Intel 8 threads icc+mkl 7m30s
Intel 16 threads icc+mkl 6m27s
Intel 8 threads gcc+OpenBLAS 11m20s [-02 -ffast-math]
Intel 8 threads gcc+OpenBLAS 12m25s [-O3]
Intel 8 threads gcc+mkl 8m12s

AMD 16 threads gcc+OpenBLAS 14m38s
AMD 32 threads gcc+OpenBLAS 13m42s

Affinity asetettu niin että fyysiset ytimet täytetään ensin. Kuten näkyy hyperthreading vaikutus on varsin minimaalinen. Nämä ovat vain yhdestä ajosta, joten erot voivat vielä tasoittua. Kerralla käytössä on 30 säiettä, joten AMD:n ytimet eivät tule aivan täyteen. Tästä näkyy myös että Intelin icc+mkl yhdistelmä on täysin ylivoimainen verrattuna OpenBLASiin. Muistikäyttö AMD:llä oli noin 45GB.

Blokkaako ICC+MKL yhdistelmä muut kuin Intelin prossut, vai miksi TR:n lukemia ei ole sillä?
ICC on monesti huomattavasti GCC:tä nopeampi liukuluvuissa, joten olisi kiva nähdä ero GCC:n ja ICC:n välillä TR:llä.
Omien testien mukaan ICC >=2015 on keskimäärin parhain kääntäjä Zenille (ICC / MSVC / GCC 7.x).

ICC:n tietyillä käännösparametreilla koodiin lisäämä Vendor-blokkaus on helppo poistaa muuttamalla pari käskyä binääreistä.

 

[JiiPee]

Blokkaako ICC+MKL yhdistelmä muut kuin Intelin prossut, vai miksi TR:n lukemia ei ole sillä?
ICC on monesti huomattavasti GCC:tä nopeampi liukuluvuissa, joten olisi kiva nähdä ero GCC:n ja ICC:n välillä TR:llä.
Omien testien mukaan ICC >=2015 on keskimäärin parhain kääntäjä Zenille (ICC / MSVC / GCC 7.x).

ICC:n tietyillä käännösparametreilla koodiin lisäämä Vendor-blokkaus on helppo poistaa muuttamalla pari käskyä binääreistä.

Ainakin joskus on antanu AMD:n prossuilla ainoastaan ihan basic käskyt käyttöön, Intel ollut tän asian takia oikeudessakin. Sittemmin homma ilmeisesti hiukan parantunut, mutta saattahan siellä edelleen olla jotain.

 

[Deleted member 4604]

Ainakin joskus on antanu AMD:n prossuilla ainoastaan ihan basic käskyt käyttöön, Intel ollut tän asian takia oikeudessakin. Sittemmin homma ilmeisesti hiukan parantunut, mutta saattahan siellä edelleen olla jotain.

Puhtaasti Intel-optimoitu moodi (Qx) ei enää edes käynnisty AMD:n prosessoreilla, dispatcher estää sen.
Geneeriset tai lisäpolkuoptiot käyttää kaikkia tuettuja SIMD:ä valmistajasta riippumatta.

 

[JiiPee]

Puhtaasti Intel-optimoitu moodi (Qx) ei enää edes käynnisty AMD:n prosessoreilla, dispatcher estää sen.
Geneeriset tai lisäpolkuoptiot käyttää kaikkia tuettuja SIMD:ä valmistajasta riippumatta.

Sitten tilanne on parentunu. Hyvä niin.

 

[Phat-J]

Jos siellä nyt oli useampikin kellotus tehty "Itse en tuolla tiedolla mitään tee paitsi ehkä voin todeta että Intelillä ei taida olla kiveä mikä kellottuu yhtä hyvin 8-ytimellä ja 16-säikeellä?" vähintään 8-ydin/16-säie prosessorilla siten että kaikki ytimet sekä säikeet olivat käytössä? Koska olihan siinä minun postissani myös "vain" 6-ydin/12-säi 5.9GHz 1600X tulos mihin voi sitten vertailla näitä ns. halpaversioita prosessoreista millä on vähäisempi määrä ytimiä jne. käytössään.

Niin vastaushan oli nimenomaan tuohon lauseeseen "Intelillä ei taida olla...". Kyllä on ja on ollut jo pari vuotta (5960X, joka myös prosentuaalisesti yli 200%). Linkistä voit suodattaa haluamasi ydinmäärät ja tulokset on rankattu Cinebench MT:n mukaan... Eli kaikki ytimet on varmasti käytössä.

Lähinnä itsellä mielessä ettei ajella sillä RyzöläHype-junalla ihan sokkona faktoista välittämättä. Se on oikeasti hyvä, mutta jos ei hintaa huomioida, niin Intel on edelleen se tehokkain vaihtoehto...Kaikissa mahdollisissa skenaarioissa.

 

[JiiPee]

Lähinnä itsellä mielessä ettei ajella sillä RyzöläHype-junalla ihan sokkona faktoista välittämättä. Se on oikeasti hyvä, mutta jos ei hintaa huomioida, niin Intel on edelleen se tehokkain vaihtoehto...Kaikissa mahdollisissa skenaarioissa.

Vaan kun ei ole kaikissa. Ihan turha väittää että se Intel olis kaikessa parempi kun asia ei yksinkertaisesti ole niin.

 

[Phat-J]

Vaan kun ei ole kaikissa. Ihan turha väittää että se Intel olis kaikessa parempi kun asia ei yksinkertaisesti ole niin.

Nyt taas sitä luetun ymmärrystä... Minä ainakin pyrin olemaan tarkka sanoistani, siksi en sanonutkaan Intelia (tai mitään muutakaan) paremmaksi, vaan ainoastaan tehokkaammaksi(nopeammaksi) silloin kun hintaa ei huomioida.

Ihan siis sama millä ydinmäärällä verrataan, jos verrataan maximeja niin Intel vie potin.

Sitten kun otetaan valuutat mukaan kuvioon niin, peli on ihan toinen. Paitsi, että edelleen jos pelit on se raskain taski, niin Intel on se marginaalisesti tehokkaampi vaihtoehto.

 

[JiiPee]

Nyt taas sitä luetun ymmärrystä... Minä ainakin pyrin olemaan tarkka sanoistani, siksi en sanonutkaan Intelia (tai mitään muutakaan) paremmaksi, vaan ainoastaan tehokkaammaksi(nopeammaksi) silloin kun hintaa ei huomioida.

Ihan siis sama millä ydinmäärällä verrataan, jos verrataan maximeja niin Intel vie potin.

Sitten kun otetaan valuutat mukaan kuvioon niin, peli on ihan toinen. Paitsi, että edelleen jos pelit on se raskain taski, niin Intel on se marginaalisesti tehokkaampi vaihtoehto.

Ei tartte ottaa edes valuuttoja mukaan kun Intel saa pahasti käkättimeen.
Sizing Up Servers: Intel's Skylake-SP Xeon versus AMD's EPYC 7000 - The Server CPU Battle of the Decade?

Pointti on se että on erittäin typerää sanoa että Intel oon kaikessa paras taikka tehokkain koska asia ei ole niin kuten esimerkki osoittaa.
Tuohon ei ole edes vielä niitä kolikoita otettu vertailuun jossa se Intel ottaa pahasti käkättimeen myös ja todennäköisesti ottaa pahasti käkättimeen myös perf/W mittarilla tuolla kuormalla.

Eli se riippuu ihan kuormasta kumpi on parempi tehtävään Intel vaiko AMD.

 

[sushukka]

Nyt taas sitä luetun ymmärrystä... Minä ainakin pyrin olemaan tarkka sanoistani, siksi en sanonutkaan Intelia (tai mitään muutakaan) paremmaksi, vaan ainoastaan tehokkaammaksi(nopeammaksi) silloin kun hintaa ei huomioida.

Ihan siis sama millä ydinmäärällä verrataan, jos verrataan maximeja niin Intel vie potin.

Sitten kun otetaan valuutat mukaan kuvioon niin, peli on ihan toinen. Paitsi, että edelleen jos pelit on se raskain taski, niin Intel on se marginaalisesti tehokkaampi vaihtoehto.

Hinnan jättäminen pois kuvioista on kuitenkin niin epärealistista ettei sellaisella spekulaatiolla tee oikein mitään. Tästä on taidettu tässä ketjussa jo länkyttää aikaisemmin esim. IBM:n System Z-prosessorit pesee kaikki x86-prossut mennen tullen, mutta hinnan takia niitä ei paljoa kuluttajilla näy...eikä paljoa edes serveripuolella. Onhan niitä erikois-Ferrareita ja Bugatteja, mutta ne eivät ole Intelin segmenttiä ja sen takia tuo kustannuspuoli tulee pitää mukana kaikissa laskelmissa koska siinä Intelin on pakko myös pärjätä. On aivan minimimargniaalia ne jotka ostavat tyyliin ihan-sama-mitä-maksaa koska kyllä sillekin löytyy aina joku raja. Joku voi olla valmis maksamaan sen 500€, harvempi 2000€ ja vielä harvempi 13k€. Massamarkkinoilla yksikkökustannukset voittaa pitkässä juoksussa ja siellä se iso raha lepää. Sisäänostajalle ei ole vaikea valinta ostaa 1000 x 10% hitaampi prossu, jos hinta on 50% vähemmän per yksikkö.

 

[Griffin]

Hinnan jättäminen pois kuvioista on kuitenkin niin epärealistista ettei sellaisella spekulaatiolla tee oikein mitään. Tästä on taidettu tässä ketjussa jo länkyttää aikaisemmin esim. IBM:n System Z-prosessorit pesee kaikki x86-prossut mennen tullen, mutta hinnan takia niitä ei paljoa kuluttajilla näy...eikä paljoa edes serveripuolella. Onhan niitä erikois-Ferrareita ja Bugatteja, mutta ne eivät ole Intelin segmenttiä ja sen takia tuo kustannuspuoli tulee pitää mukana kaikissa laskelmissa koska siinä Intelin on pakko myös pärjätä. On aivan minimimargniaalia ne jotka ostavat tyyliin ihan-sama-mitä-maksaa koska kyllä sillekin löytyy aina joku raja. Joku voi olla valmis maksamaan sen 500€, harvempi 2000€ ja vielä harvempi 13k€. Massamarkkinoilla yksikkökustannukset voittaa pitkässä juoksussa ja siellä se iso raha lepää. Sisäänostajalle ei ole vaikea valinta ostaa 1000 x 10% hitaampi prossu, jos hinta on 50% vähemmän per yksikkö.

X86 prossujen pesemisellä ei tavankäyttäjälle ole merkitystä, jos prossu ei aja virheettömästi ja nopeasti x86 koodia, vaikka prossu olisi halvempi.

 

[japau]

 

[svk]

Lähteet?

 

[Andy]

PlayerUnknown's Battlegrounds (PUBG) CPU Test

Tuolta löytyy testi. Tässä puolestaan prosessorin käyttö. 1600X ja 8700k molemmat 6-ytimisiä ja silti prosessorin käytössä huomattava ero. Paljon on vielä optimoinnin varaa, eikä nuo max fps lukemat erityisen korkeita ole vielä Intelilläkään.

Spoileri: Kuva