Virallinen: AMD vs Intel keskustelu- ja väittelyketju

[Threadripper]

Suomesta ei kyllä löydy vrk.fi palvelun mukaan yhtään hkultala nimistä henkilöä, niin etu- että sukunimi ei tuota osumia.

Käyttäjä hkultala on monta kertaa sanonut missä on töissä ja siihen kun lisää nimimerkin, ei tarvita kummoistakaan salapoliisityötä.

Vielä helpommalla pääsee googlettamalla nimimerkin

Aika jännä silti, mutta sattuu sitä oudompiakin. Foorumin pääasiallinen Ryzen-tieturi Stilt taitaa kuitenkin olla ja kenties parhaiten perillä Ryzenin toiminnasta.

The Stiltin tietomäärä Ryzenistä on varsin vakuuttava. Silti, oli tietomäärä mitä tahansa, ei se tarkoita henkilön olevan aina oikeassa. Esim. arviot Ryzenin kellotaajuuksista menivät todella pahasti pieleen.

 

[HEDT]

Mutta täällä forumisoturit on jo moneen kertaan tyrmännyt prosessorien eroavaisuudet, eli ei sillä ole mitään väliä koska molemmat prosessorit ajaa koodia yhtä hyvin tai yhtä huonosti.

Eiköhän tuo ole koodattu (AMD: lle) niin lähelle konsoli- versiota kun vain mahdollista.

 

[Deleted member 4604]

Mitä mieltä @JiiPee (sekä muut seuraavasta tilanteesta):

Stockfish 9 shakkimoottorin modernein koodipolku käyttää BMI2 käskykannan PEXT käskyä.
AMD:lla BMI2 tuki tuli Bulldozerin viimeisessä kehitysversiossa (Carrizo) ja Intelillä Haswellissa.

PEXT käskyn käyttäminen parantaa suorituskykyä Inteleillä, mutta vastaavasti hidastaa sitä Ryzenilla.
Tämä johtuu siitä, että AMD:n PEXT implementaatio Ryzenissa on kuusi kertaa (18C vs. 3C) hitaampi kuin Intelillä esim. Skylakessa.

Pitäisikö siis mielestäsi Ryzenia suosia enemmistön kustannuksella (Intel) ja jättää PEXT käskyt käyttämättä, jolloin suorituskyky Ryzenilla paranee ja Intelillä heikkenee?

 

[sushukka]

Pitäisikö siis mielestäsi Ryzenia suosia enemmistön kustannuksella (Intel) ja jättää PEXT käskyt käyttämättä, jolloin suorituskyky Ryzenilla paranee ja Intelillä heikkenee?

Hyvä kysymys. Nyt tilanne kun on juuri se, että jos AMD tuo markkinoille jonkun optimoinnin joka olisi heidän prosessoreillaan nopeampi, mutta taas hidastaisi läpimenoa Intelin puolelle, ei siihen paljoa koskettaisi. Tämän takia AMD ei voi lähteä kehittelemään mitään kovin paljoa Intelistä poikkeavaa vaan sen on jollain tasolla peesattava Inteliä. Kilpailun ja kehityksen kannalta huono tilanne. Jos nyt saisi Zen lisää markkinaosuutta, niin mahdollisuudet reiluun kilpailuun myös tällä tasolla kasvaisivat.

 

[svk]

Paras vaihtoehto olisi, jos sen käskyn sais pois halutessaan. Muuten taitaa mennä enemistön ehdoilla tämä.

 

[Mechanical Man]

Paras vaihtoehto olisi, jos sen käskyn sais pois halutessaan. Muuten taitaa mennä enemistön ehdoilla tämä.

Ei taitaisi poistaminen auttaa suoritusnopeuteen amd:llä.

 

[svk]

Ei taitaisi poistaminen auttaa suoritusnopeuteen amd:llä.

Miksi ei auttaisi, jos se hidastaa, kuten @The Stilt in esimerkissä?

e. Taisin tulkita hieman päin honkia.

 

[Urpola77]

Edit. Hups väärä ketku

 

[svk]

Oon täällä sohvalla viltin alla.
Tulkaa juttelee
Keitäm vaikka kaffet

Ei pääse kun töissä nyt.

 

[jsa]

Mitä mieltä @JiiPee (sekä muut seuraavasta tilanteesta):
PEXT käskyn käyttäminen parantaa suorituskykyä Inteleillä, mutta vastaavasti hidastaa sitä Ryzenilla.
Tämä johtuu siitä, että AMD:n PEXT implementaatio Ryzenissa on kuusi kertaa (18C vs. 3C) hitaampi kuin Intelillä esim. Skylakessa.

Jos ei haluta tehdä kahta erillistä implementaatiota (toinen PEXTillä ja toinen sitten jollain muulla tavalla) niin PEXT sietää pysyä. Jos polkuja voi tehdä useampia niin sitten voisi harkita optimoitua polkua Ryzenille, sikäli mikäli käyttäjäkunnassa moiselle olisi tarvetta.

 

[Deleted member 4604]

Jos ei haluta tehdä kahta erillistä implementaatiota (toinen PEXTillä ja toinen sitten jollain muulla tavalla) niin PEXT sietää pysyä. Jos polkuja voi tehdä useampia niin sitten voisi harkita optimoitua polkua Ryzenille, sikäli mikäli käyttäjäkunnassa moiselle olisi tarvetta.

Ohjelma ei tue useampaa polkua samassa binäärissä, eli ainoa tapa on kääntää useampi versio.

Omassa testisuitessa on jokaiselle kuormalle yksi binääri, koska se edustaa parhaiten reaalimaailman tilannetta.

 

[hkultala]

Mitä mieltä @JiiPee (sekä muut seuraavasta tilanteesta):
PEXT käskyn käyttäminen parantaa suorituskykyä Inteleillä, mutta vastaavasti hidastaa sitä Ryzenilla.
Tämä johtuu siitä, että AMD:n PEXT implementaatio Ryzenissa on kuusi kertaa (18C vs. 3C) hitaampi kuin Intelillä esim. Skylakessa.

... ja throughputissa ero on ilmeisesti vielä suurempi, 18-kertainen, skylakessa tuo käsky on liukuhihnoitettu, ryzenissa ilmeisesti ei.

eli siis Skylake pystyy joka kellojakso aloittamaan uuden pext-käskyn suorittamisen, ryzen vasta 18 kellojakson jälkeen, kun edellinen on saatu kokonaan suoritettua.

Tässä luulisi olevan AMDlle helppoa parannettavaa zen2een. (tämän vuoden zen+aan ei liene tulossa).

 

[Stephen Elop]

Ohjelma ei tue useampaa polkua samassa binäärissä, eli ainoa tapa on kääntää useampi versio.

Omassa testisuitessa on jokaiselle kuormalle yksi binääri, koska se edustaa parhaiten reaalimaailman tilannetta.

Vastaan tähän, mutta muuten ei oikein ole halua tulla tähän aiheeseen.

Kyllä se ohjelma varmaan tukee useampaa polkua, vai kaatuko se niillä prossuilla, joissa kyseistä käskyä ei tueta?

ZENin tapauksessa pitäisi käskyn tuen lisäksi olla optimaalinen arkkitehtuurikohtainen polku, jota tuossa ei ilmeisesti ole.

Class factory suunnittelumallia voisi tuossa käyttää. Mutta siitä optimoinnista täytyy myös olla merkittävää hyötyä. Jos hyöty on 5% luokkaa niin tuskin maksaa vaivaa. Itse alkaisin harkitsemaan vasta 20% hyödyllä. Tosin jos silloinkin tälläisiä prosessoreja käyttäisi vain yksi ihminen, niin keskittyisin kyllä muihin juttuihin.

 

[Deleted member 4604]

Vastaan tähän, mutta muuten ei oikein ole halua tulla tähän aiheeseen.

Kyllä se ohjelma varmaan tukee useampaa polkua, vai kaatuko se niillä prossuilla, joissa kyseistä käskyä ei tueta?

ZENin tapauksessa pitäisi käskyn tuen lisäksi olla optimaalinen arkkitehtuurikohtainen polku, jota tuossa ei ilmeisesti ole.

Class factory suunnittelumallia voisi tuossa käyttää. Mutta siitä optimoinnista täytyy myös olla merkittävää hyötyä. Jos hyöty on 5% luokkaa niin tuskin maksaa vaivaa. Itse alkaisin harkitsemaan vasta 20% hyödyllä. Tosin jos silloinkin tälläisiä prosessoreja käyttäisi vain yksi ihminen, niin keskittyisin kyllä muihin juttuihin.

GCC:n ollessa kyseessä ohjelma kaatuu, mikäli suorittava prosessori ei tue ohjelman käyttämiä käskykantoja.

Koodi joka tarkistaisi prosessorin tukemat ominaisuudet ja ottaisi ne valinnaisesti käyttöön täytyisi kirjoittaa käsin.

Intelin kääntäjä osaa tehdä tuon tiettyyn pisteeseen asti automaattisesti ja se on yleisen nopeuden lisäksi sen suurin etu.
Samaa binääriä voidaan käyttää SSE2 - AVX512 tukevalla raudalla, ilman suorituskykypenalttia.

 

[Miro.Simounen]

En tiedä prossuista kumpi vie voiton, mutta saakeli tota tr:n pakettia.18kpl prossuja auki ja iso säkillinen jätettä. Vastaava intelistä ehkä 1kg pahvia.

 

[Stephen Elop]

Intelin kääntäjä osaa tehdä tuon tiettyyn pisteeseen asti automaattisesti ja se on yleisen nopeuden lisäksi sen suurin etu.
Samaa binääriä voidaan käyttää SSE2 - AVX512 tukevalla raudalla, ilman suorituskykypenalttia.

Paitsi ZENin tapauksessa suoritetaan kyseiselle prosessorille ei-optimaalisin vaihtoehto. Mutta joo vaatisi koodata itse ohjelmaan luokkatehtaan, joka lataisi sitten erikseen käännetyn optimoidun dll:n jotta ongelmalta vältyttäisiin.

 

[Deleted member 4604]

Paitsi ZENin tapauksessa suoritetaan kyseiselle prosessorille ei-optimaalisin vaihtoehto.

Miten niin?
Samoja käskykantoja / polkua se käyttää kuin Intelitkin, ellei käytössä ole ollut joku Intel-spesifistinen /Qx optio (ts. /arch tai /Qax).
Uusilla (ainakin >= 2015 versio) binääri ei kyllä edes tuolloin käynnisty muilla kuin Intelin prosessoreilla.

Toki Intelin kääntäjä ei mitään varsinaisia optimointeja AMD:n prosessoreille sisällä (yllätys).

 

[Stephen Elop]

Miten niin?
Samoja käskykantoja / polkua se käyttää kuin Intelitkin, ellei käytössä ole ollut joku Intel-spesifistinen /Qx optio (ts. /arch tai /Qax).
Uusilla (ainakin >= 2015 versio) binääri ei kyllä edes tuolloin käynnisty muilla kuin Intelin prosessoreilla.

Toki Intelin kääntäjä ei mitään varsinaisia optimointeja AMD:n prosessoreille sisällä (yllätys).

No siis jos Intelin kääntäjä vain katsoo mitä käskyjä tuetaan, ja sen mukaan kääntää eli tulee samanlainen koodipolku. ZEN tukee kyseistä BMI (mitä lie käskykantaa), mutta sen toteutus tuolle käskykannalle sen verran haitallinen, että koodi muulla käskykannalla toimisi ZENillä nopeammin. Kääntäjän täytyisi ottaa siis myös käskykantojen toteutuksien erot huomioon.

 

[Threadripper]

Mitä mieltä @JiiPee (sekä muut seuraavasta tilanteesta):

Stockfish 9 shakkimoottorin modernein koodipolku käyttää BMI2 käskykannan PEXT käskyä.
AMD:lla BMI2 tuki tuli Bulldozerin viimeisessä kehitysversiossa (Carrizo) ja Intelillä Haswellissa.

PEXT käskyn käyttäminen parantaa suorituskykyä Inteleillä, mutta vastaavasti hidastaa sitä Ryzenilla.
Tämä johtuu siitä, että AMD:n PEXT implementaatio Ryzenissa on kuusi kertaa (18C vs. 3C) hitaampi kuin Intelillä esim. Skylakessa.

Pitäisikö siis mielestäsi Ryzenia suosia enemmistön kustannuksella (Intel) ja jättää PEXT käskyt käyttämättä, jolloin suorituskyky Ryzenilla paranee ja Intelillä heikkenee?

Toisin sanottuna tässä saatiin esimerkki ohjelmistosta joka on selkeästi ja tarkoituksella Intelille optimoitu. eikä kääntäjä kuulemma pysty asiaa AMD:n osalta korjaamaan.

Miten sen optimoinnin kanssa nyt taas olikaan? Eikös noiden ohjelmistojen pitänyt olla sellaisia ettei niitä ole erikseen Intelille optimoitu?

No siis jos Intelin kääntäjä vain katsoo mitä käskyjä tuetaan, ja sen mukaan kääntää eli tulee samanlainen koodipolku. ZEN tukee kyseistä BMI (mitä lie käskykantaa), mutta sen toteutus tuolle käskykannalle sen verran haitallinen, että koodi muulla käskykannalla toimisi ZENillä nopeammin. Kääntäjän täytyisi ottaa siis myös käskykantojen toteutuksien erot huomioon.

Ja näin, ei ole mitenkään vaikea toteuttaa.

 

[Deleted member 4604]

No siis jos Intelin kääntäjä vain katsoo mitä käskyjä tuetaan, ja sen mukaan kääntää eli tulee samanlainen koodipolku. ZEN tukee kyseistä BMI (mitä lie käskykantaa), mutta sen toteutus tuolle käskykannalle sen verran haitallinen, että koodi muulla käskykannalla toimisi ZENillä nopeammin. Kääntäjän täytyisi ottaa siis myös käskykantojen toteutuksien erot huomioon.

Eli kääntäjän pitäisi jättää käyttämättä käskykantoja jotka prosessorivalmistaja on katsonut tarpeelliseksi tukea?

GCC joka sisältää optimoinnit Zenille ottaa automaattisesti myös BMI2 käskykannan käyttöön (kun käytetään march=znver1 optiota).

 

[Griffin]

Toisin sanottuna tässä saatiin esimerkki ohjelmistosta joka on selkeästi ja tarkoituksella Intelille optimoitu. eikä kääntäjä kuulemma pysty asiaa AMD:n osalta korjaamaan.

Miten sen optimoinnin kanssa nyt taas olikaan? Eikös noiden ohjelmistojen pitänyt olla sellaisia ettei niitä ole erikseen Intelille optimoitu?

Ja näin, ei ole mitenkään vaikea toteuttaa.

Jos ohjelma on tehty ennen ryzenin julkaisua, niin se on lähinnä tehty mahdollisimman nopeaksi. Jos on olemassa nopeuttava käskylaajennus, niin toki sitä kannattaa oletuksena käyttää. Jos ei käytettäisi, niin mitään käskykantalaajennuksia ei kannattaisi ikinä tehdä.

 

[Cirrus]

Eli kääntäjän pitäisi jättää käyttämättä käskykantoja jotka prosessorivalmistaja on katsonut tarpeelliseksi tukea?

Tässä ollaan viimeisen päälle asian ytimessä. Kääntäjät vääntää koodia mutä kaikki prosessorit tukee. Amd:n tehtävä on tukea käskykantojaan sillä tavalla että niitä myös voi käyttää. Mitä hemmetin järkeä on laittaa käskykanta ja sitten sitä ei kuitenkaan kääntäjät saisi käyttää?

 

[Deleted member 4604]

Toisin sanottuna tässä saatiin esimerkki ohjelmistosta joka on selkeästi ja tarkoituksella Intelille optimoitu. eikä kääntäjä kuulemma pysty asiaa AMD:n osalta korjaamaan.

Miten sen optimoinnin kanssa nyt taas olikaan? Eikös noiden ohjelmistojen pitänyt olla sellaisia ettei niitä ole erikseen Intelille optimoitu?

Eli prosessorin tukemia ominaisuuksia pitää manuaalisesti disabloida koodista tai muuten koodi on Intel-optimoitu?

Ts. on ohjelmistokehittäjien ja Intelin vika että AMD:n BMI2 implementaatio on helvetin hidas?

Samalla logiikalla esim. X265 enkooderista pitäisi disabloida SSE2 kokonaan kaikilla prosessoreilla, koska AMD:n Bobcat ytimillä SSE2 suorituskyky on huono?

multicoreware / x265 / source / source / common / cpu.cpp — Bitbucket

 

[Deleted member 4604]

Jos ohjelma on tehty ennen ryzenin julkaisua, niin se on lähinnä tehty mahdollisimman nopeaksi. Jos on olemassa nopeuttava käskylaajennus, niin toki sitä kannattaa oletuksena käyttää. Jos ei käytettäisi, niin mitään käskykantalaajennuksia ei kannattaisi ikinä tehdä.

Tämä Ryzen-vastainen PEXT (BMI2) tuki on lisätty Stockfishiin alkuvuodesta 2014.

 

[Threadripper]

Eli kääntäjän pitäisi jättää käyttämättä käskykantoja jotka prosessorivalmistaja on katsonut tarpeelliseksi tukea?

GCC joka sisältää optimoinnit Zenille ottaa automaattisesti myös BMI2 käskykannan käyttöön (kun käytetään march=znver1 optiota).

Totta hitossa pitäisi jättää mikäli ne hidastavat tiettyjä prosessorimalleja. Ei kaikkea antiikkiroskaa tarvitse käyttää vain siksi että sitä prosessori tukee. Se tuki on usein olemassa yhteensopivuussyistä.

Kai kääntäjän pitäisi MMX:a käyttää myös koska nykyiset prosessorit sitä tukevat. En kyllä usko että kovinkaan nopeasti...

Jos ohjelma on tehty ennen ryzenin julkaisua, niin se on lähinnä tehty mahdollisimman nopeaksi. Jos on olemassa nopeuttava käskylaajennus, niin toki sitä kannattaa oletuksena käyttää. Jos ei käytettäisi, niin mitään käskykantalaajennuksia ei kannattaisi ikinä tehdä.

Ryzenin tapauksessa taitaa olla hidastava.

Tässä ollaan viimeisen päälle asian ytimessä. Kääntäjät vääntää koodia mutä kaikki prosessorit tukee. Amd:n tehtävä on tukea käskykantojaan sillä tavalla että niitä myös voi käyttää. Mitä hemmetin järkeä on laittaa käskykanta ja sitten sitä ei kuitenkaan kääntäjät saisi käyttää?

Yhteensopivuus tietysti. On parempi että ohjelma toimii (vaikka sitten hitaasti) kuin ettei ohjelma toimi ollenkaan.

Eli prosessorin tukemia ominaisuuksia pitää manuaalisesti disabloida koodista tai muuten koodi on Intel-optimoitu?

Ts. on ohjelmistokehittäjien ja Intelin vika että AMD:n BMI2 implementaatio on helvetin hidas?

Samalla logiikalla esim. X265 enkooderista pitäisi disabloida SSE2 kokonaan kaikilla prosessoreilla, koska AMD:n Bobcat ytimillä SSE2 suorituskyky on huono?

multicoreware / x265 / source / source / common / cpu.cpp — Bitbucket

Prosessorin tukemia ominaisuuksia ei tarvitse käyttää mikäli prosessori suorittaa niitä hitaasti.

Mitä väliä sillä kenen syy on? Laitetaan ohjelmaan tunnistus joka katsotaan onko Ryzen 2 ja jos on, ei oteta BMI2:ta käyttöön. Hyvin yksinkertaista.

Miksi kaikilla prosessoreilla? Otetaan pois käytöstä Bobcat-sarjan prosessoreilla ja ongelma ratkaistu.

 

[Stephen Elop]

ZENiin käskykantatuki on saatettu pistää vain yhteensopivuuden takia.

Omasta mielestäni kääntäjän kuuluu tehdä niin nopeaa ja muistitehokasta koodia kuin mahdollista. ZENin tapauksessa se nyt ei tee sitä. Tästä sitten päästään siihen, että kannattaako tuota kääntäjää tehdä monimutaisemmaksi sen takia, että ZEN prosessoreilla nopeutta tulisi joku x% lisää? Mahdollisesti AMD voisi itse tehdä kääntäjään laajennoksen tai koko kääntäjän. Tästä voisi päätellä että AMD:kään mielestä moista panostusta ei kannata tehdä.

 

[Deleted member 4604]

AMD:llahan on "oma" AOCC kääntäjä, mutta sen suorituskyky ei juurikaan eroa muista vastaavista kääntäjistä.

https://www.phoronix.com/scan.php?page=article&item=amd-ryzen-aocc&num=1

 

[Jooga]

Tyhjiössä tehtävä pudotustesti molempien leirien kiville alkaa vaikuttamaan ainoalta myös AMD-fanien hyväksymältä testiltä. Siinä ohitettaisiin kaikki kääntämiset ja vääntämiset. Tosin tasapisteisiin päätyvä tulos olisi varmaan mittausepävarmuuksien kautta voitto AMD:lle.

Ihan näin suurta AMD-fanitusta en kyllä itsekään Ryzenin omistajana jaksa kuunnella kovin montaa sivua Tottakai jos shakkibenchmarkin tekijä on huomannut molempien valmistajien tukevan tiettyä käskykantoja mitkä oletuksena nopeuttavat ohjelman suoritusta, niin silloin tuota tulee käyttää. Tässä esimerkissä testi on mielestäni tasapuolinen, AMD:n yksittäinen ratkaisu tässä on vain huonompi jonka syykin on karkeasti tullut jo esille. En tajua miten tuo pitää vängätä AMD:n kannalta edullisemmaksi tulokseksi kuin mitä se oikeasti on.

 

[Stephen Elop]

Eikös muuten tuosta Intelin kääntäjästä saa pakotettua käännöstä jollekin tietylle arkkitehtuurille? Eli sellaiselle vanhemmalle prossulle jossa ei ole BMI2 tukea? Tosin tällöin ongelmana on mahdolllisten muiden oikeasti toimivien optimointien poisjääminen.

Mutt mää jätän tämän nyt. Ei pitänyt tähän lankaan montaa viestiä laittaa. Jatkakaa muut kun en tullut vängäämään vaan toteamaan.

 

[Threadripper]

AMD:llahan on "oma" AOCC kääntäjä, mutta sen suorituskyky ei juurikaan eroa muista vastaavista kääntäjistä.

Benchmarking AMD's New AOCC Compiler For Ryzen - Phoronix

Tuo on lähes vuoden vanhaa testiä. Nykyinen saattaisi ottaa tuonkin huomioon.

Ihan näin suurta AMD-fanitusta en kyllä itsekään Ryzenin omistajana jaksa kuunnella kovin montaa sivua Tottakai jos shakkibenchmarkin tekijä on huomannut molempien valmistajien tukevan tiettyä käskykantoja mitkä oletuksena nopeuttavat ohjelman suoritusta, niin silloin tuota tulee käyttää. Tässä esimerkissä testi on mielestäni tasapuolinen, AMD:n yksittäinen ratkaisu tässä on vain huonompi jonka syykin on karkeasti tullut jo esille. En tajua miten tuo pitää vängätä AMD:n kannalta edullisemmaksi tulokseksi kuin mitä se oikeasti on.

Lihavoitu olennaisena. Missä kohtaa se oletuksena nopeuttaa Ryzenillä ohjelman suoritusta?

 

[Deleted member 4604]

Eikös muuten tuosta Intelin kääntäjästä saa pakotettua käännöstä jollekin tietylle arkkitehtuurille? Eli sellaiselle vanhemmalle prossulle jossa ei ole BMI2 tukea? Tosin tällöin ongelmana on mahdolllisten muiden oikeasti toimivien optimointien poisjääminen.

Mutt mää jätän tämän nyt. Ei pitänyt tähän lankaan montaa viestiä laittaa. Jatkakaa muut kun en tullut vängäämään vaan toteamaan.

Qx optio vastaa GCC:n "march" optiota Intelin kääntäjässä.
Tuolloin binäärit käynnistyvät vain Intelin prosessoreilla ja silloin jos kaikki Qx option sisältämät käskykannat on tuettu raudan puolelta.
2017 versiosta lähtien on myös saatavilla "tune" optio joka vastaa toiminnallisuudeltaan GCC:n vastaavaa.

 

[Jooga]

Lihavoitu olennaisena. Missä kohtaa se oletuksena nopeuttaa Ryzenillä ohjelman suoritusta?

Varmasti siinä kohtaa kun tuon Stockfish 9:n kehittäjä on päättänyt ottaa käskykannan käyttöön? En tiedä ko. sovelluksesta tai käskykannoista käytännössä mitään, mutta harva insinööri ottaa asioita käyttöön ilman odotuksia paremmasta suorituskyvystä. Ehkä tuota tehdessä ei ollut tiedossa että AMD:n toteutus on noin huono, kun lähtötietoina on voitu katsoa että molemmat Intel ja AMD tukevat noita The Stiltin mainitsemia käskykantoja. Toinen vaihtoehtohan olisi ollut se, että Intelillä nopeuttavia käskykantoja käytetään ja AMD:llä ei, tuolloin olisi vain tapeltu siitä että miksi AMD:n testissä optio ei ole käytössä vaikka AMD sitä tukeekin.

 

[Threadripper]

Varmasti siinä kohtaa kun tuon Stockfish 9:n kehittäjä on päättänyt ottaa käskykannan käyttöön? En tiedä ko. sovelluksesta tai käskykannoista käytännössä mitään, mutta harva insinööri ottaa asioita käyttöön ilman odotuksia paremmasta suorituskyvystä. Ehkä tuota tehdessä ei ollut tiedossa että AMD:n toteutus on noin huono, kun lähtötietoina on voitu katsoa että molemmat Intel ja AMD tukevat noita The Stiltin mainitsemia käskykantoja. Toinen vaihtoehtohan olisi ollut se, että Intelillä nopeuttavia käskykantoja käytetään ja AMD:llä ei, tuolloin olisi vain tapeltu siitä että miksi AMD:n testissä optio ei ole käytössä vaikka AMD sitä tukeekin.

Lähtötietoina tuskin katsottiin AMD:n tukevan koska mikään AMD:n prosessori ei tukenut sitä 2014.

Jälkimmäisessä tapauksessa AMD:lla oltaisiin vain tyytyväisiä kun yhteensopivuussyistä mukaan laitettua ominaisuutta ei väkisin käytetä.

 

[Griffin]

Tuo on lähes vuoden vanhaa testiä. Nykyinen saattaisi ottaa tuonkin huomioon.



Lihavoitu olennaisena. Missä kohtaa se oletuksena nopeuttaa Ryzenillä ohjelman suoritusta?

Millos se käännös on tehty?
Jos ennen ryzenin markkinoilletuloa, niin tietenkin tuollainen oletuksena nopeuttaa.
Ja ryzeninkin kanssa?!
Nopeuttaako se vai hidastaako se KOKONAISUUTTA minkäverran vai eiko ole käytännön merkitystä?
Jos Intelillä tulee ohjelman kokonaissuorituskykyyn tuon seurauksena vaikka 9% suorituskykyä lisää ja ryzenillä suorituskyky tippuu esim 3%, niin tuo kannattaa ehdottomasti pistää päälle ja toivoa, että AMD korjaa selkeän bugin ryzenissä.

 

[hkultala]

niin tuo kannattaa ehdottomasti pistää päälle ja toivoa, että AMD korjaa selkeän bugin ryzenissä.

Ei tuo ole bugi. Se on ihan dokumentoitu feature, että tuo käsky on zenillä hidas.

JOS prosessorin spekseissä sanottaisiin, että käsky suoritettaisiin vaikka 3ssa kellojaksossa, mutta siinä silti menisi 18, silloin se olisi bugi.

 

[Threadripper]

Millos se käännös on tehty?
Jos ennen ryzenin markkinoilletuloa, niin tietenkin tuollainen oletuksena nopeuttaa.
Ja ryzeninkin kanssa?!
Nopeuttaako se vai hidastaako se KOKONAISUUTTA minkäverran vai eiko ole käytännön merkitystä?
Jos Intelillä tulee ohjelman kokonaissuorituskykyyn tuon seurauksena vaikka 9% suorituskykyä lisää ja ryzenillä suorituskyky tippuu esim 3%, niin tuo kannattaa ehdottomasti pistää päälle ja toivoa, että AMD korjaa selkeän bugin ryzenissä.

Miksi nopeuttaa oletuksena? Ominaisuudet jotka lisätään yhteensopivuussyistä eivät useinkaan ole kovin nopealla toteutuksella.

Se voidaan pistää päälle Intelin prosessoreissa ja olla laittamatta päälle AMD:n prosessoreissa. Yksinkertaista.

Kuten jo sanottiin, kyseessä ei ole mikään bugi.

 

[hkultala]

Miksi nopeuttaa oletuksena?

Käskyjen lisäämiseen on kaksi mahdollista syytä:

1) Joko ne lisäävät uusia ominaisuuksia, jotka mahdollistavat tietokonelaitteiston käytön uusiin asioihin tai uudella tavalla. Esimerkiksi moniajo, siihen liittyvä muistinsuojaus, virtualisointi jne.

2) Ne nopeuttavat sellaisten hommien tekemistä, joita sillä on jo ennestäänkin pystynyt tekemään (kunhan koodi uudelleenkäännetään käytämään näitä käskyjä).

Kaikki tällaiset bitinnysväyskäskyt kuuluu kategoriaan kaksi. Kaiken mitä niillä voi tehdä, voisi aina tehdä loopilla joka shiftailee ja maskailee bittejä, mutta hitaasti.

 

[Griffin]

Miksi nopeuttaa oletuksena? Ominaisuudet jotka lisätään yhteensopivuussyistä eivät useinkaan ole kovin nopealla toteutuksella.

Se voidaan pistää päälle Intelin prosessoreissa ja olla laittamatta päälle AMD:n prosessoreissa. Yksinkertaista.

Kuten jo sanottiin, kyseessä ei ole mikään bugi.

Katsoisin, että kyseessä ON BUGI, jos erillinen nopeuttamiseen tarkoitettu käsky toimiikin hitaammin, kuin erillisillä käskyillä tehty ohjelma.
Jos se taas toimii vain yhtänopeasti tai nopeammin, kuin erillisillä käskyillä, niin silloin sitä kannattaa käyttää.

 

[hkultala]

Katsoisin, että kyseessä ON BUGI, jos erillinen nopeuttamiseen tarkoitettu käsky toimiikin hitaammin, kuin erillisillä käskyillä tehty ohjelma.
Jos se taas toimii vain yhtänopeasti tai nopeammin, kuin erillisillä käskyillä, niin silloin sitä kannattaa käyttää.

Bugi tarkoittaa sitä, että järjestelmä toimii speksiensä vastaisesti. Tämä toimii täysin speksiensä mukaan. Tämä ei ole mikään bugi, tämä on vain huono toteutus.

 

[Deleted member 4604]

BMI2 ei ole ainoa Ryzenissa (ja Carrizossa) mikä toimii hitaasti.
Myös AVX2 disablointi parantaa suorituskykyä esim. X265:ssä pari prosenttia.

 

[JiiPee]

AMD:llahan on "oma" AOCC kääntäjä, mutta sen suorituskyky ei juurikaan eroa muista vastaavista kääntäjistä.

Benchmarking AMD's New AOCC Compiler For Ryzen - Phoronix

AMD on julkaissut uudemman version, mutta eipä se mikään sateentekijä ole.

AMD AOCC 1.1 Shows Compiler Improvements vs. GCC vs. Clang - Phoronix

Ja mitä itse kysymykseen tulee niin olisihan se hienoa että kääntäjä hoitaisi homman niin että ryzenilla ei käytettäisi mutta skylakella käytettäisiin.
Jos ei kääntäjä siihen kykene, niin sitten käsin tekemään. Tätähän se optimointi on.

Toki hienointa olisi että AMD tulevaisuudessa lisäisi oikean tuen eikä vain yhteensopivuustukea jos ominaisuus on kerta hieno ja laajalti käytössä.

 

[Threadripper]

Käskyjen lisäämiseen on kaksi mahdollista syytä:

1) Joko ne lisäävät uusia ominaisuuksia, jotka mahdollistavat tietokonelaitteiston käytön uusiin asioihin tai uudella tavalla. Esimerkiksi moniajo, siihen liittyvä muistinsuojaus, virtualisointi jne.

2) Ne nopeuttavat sellaisten hommien tekemistä, joita sillä on jo ennestäänkin pystynyt tekemään (kunhan koodi uudelleenkäännetään käytämään näitä käskyjä).

Kaikki tällaiset bitinnysväyskäskyt kuuluu kategoriaan kaksi. Kaiken mitä niillä voi tehdä, voisi aina tehdä loopilla joka shiftailee ja maskailee bittejä, mutta hitaasti.

Kakkoskohtaan voisi lisätä tapaukset joissa käsky lisätään pikapikaa vain jotta saadaan käskylle parempaa tukea ja vasta tulevaisuudessa siitä aletaan oikeasti saamaan nopeushyötyä. Menee vähän samaan kategoriaan kuin AVX/AVX2. AMD kyllä sitä tukee muttei halua panostaa siihen samaan tapaan kuin Intel, ymmärrettävistä syistä.

BMI2 ei ole ainoa Ryzenissa (ja Carrizossa) mikä toimii hitaasti.
Myös AVX2 disablointi parantaa suorituskykyä esim. X265:ssä pari prosenttia.

Tuo sentään menee virhemarginaaliin, tai ainakin lähelle.

AMD on julkaissut uudemman version, mutta eipä se mikään sateentekijä ole.

AMD AOCC 1.1 Shows Compiler Improvements vs. GCC vs. Clang - Phoronix

Ja mitä itse kysymykseen tulee niin olisihan se hienoa että kääntäjä hoitaisi homman niin että ryzenilla ei käytettäisi mutta skylakella käytettäisiin.
Jos ei kääntäjä siihen kykene, niin sitten käsin tekemään. Tätähän se optimointi on.

Toki hienointa olisi että AMD tulevaisuudessa lisäisi oikean tuen eikä vain yhteensopivuustukea jos ominaisuus on kerta hieno ja laajalti käytössä.

Noinhan se pitäisikin olla.

Taitaa olla aika vähän käytössä tuo ja ehkä juuri siksi ei ollut prioriteeteissa kovinkaan korkealla. En löytänyt tietoa kuinka hidas se on Excavatorissa, veikkaan että yhtä hidas. AMD aika varmasti laittoi Zeniin osia Excavatorista koska sillä säästi aikaa eikä Excavatoriin ollut aikaa kummoista tukea kehittää. Zen 2:ssa tuokin asia lienee paremmin toteutettu.

 

[hkultala]

siiirretty toisesta säikeestä tänne vastaus

Virallinen: NVIDIA vs AMD keskustelu- ja väittelyketju

Ompa tässä käsittelyn alla taas yksi läppäri.. Kävi tuntumaan jotenkin, että homma ei vain edisty ja syynä tuntui olevan suoritin..

Miten päättelit syynä olevan suorittimen?

Mitäs sieltä paljastuikaan.. Celeron N2940, eli ATOM romu.

oliko se "ATOM romu" vielä peräisin lappeen Rannasta?

Kyllä nuo ovat edelleenkin yksinkeraisesti hitaita romuja, joihin ei pitäisi kenenkään koskea pitkällä tikullakaan..

... paljonkos siinä koneessa oli muistia?

ja mitä siinä oli massamuistina? pyörivä levy tai eMMC ?

 

[Griffin]

siiirretty toisesta säikeestä tänne vastaus

Virallinen: NVIDIA vs AMD keskustelu- ja väittelyketju



Miten päättelit syynä olevan suorittimen?



oliko se "ATOM romu" vielä peräisin lappeen Rannasta?



... paljonkos siinä koneessa oli muistia?

ja mitä siinä oli massamuistina? pyörivä levy tai eMMC ?

Helposti:
Päivitysprosessissa pyörii tietyssä vaiheessa 1 tai 2 threadia, kun koneella ei tee mitään muuta ja viruskillerikin on poistettu käytöstä (koska hidastaa päivitysprosessia selkeästi kaikilla koneilla). On tuota taskmanageria tullut katsottua kymmenillä ja kymmenillä koneilla.
Jos on oikein suorituskykyinen prossu, niin perinteinen kiintolevy huutaa yleensä hoosiannaa vähänväliä ja tietty päivitys asentuu käynnistysvaiheeseen n puolessa tunnissa. Tässä kuitenkin tuo sama tuttu homma kesti kuten muutamassa muussakin vastaavassa romussa yli 2 tuntia.

Ei ole lappeen Rannasta päin kone. Ja miten se liittyy koneen nopeuteen mitenkään? Onko mielestäsi siis paikkakunnalla, josta kone on peräisin vaikutusta sen nopeuteen.. Melko hämäriä kuvitelmia nyt kyllä..

Muistia on 8 gigaa, joten se riittää kyllä Windows 10:n päivitysten suorittamiseen viruskilleri disabloituna ihan varmasti. Käytössä on alle 2G:aa 8:sasta.

Tämä on ihan tyypillinen ATOM kone. Toimii senverran hitaasti, että sen vain huomaa ja ihmettelee asiaa väkisin jossain vaiheessa, kun on tottunut I3:een ja nopeampiin prossuihin. Ero on nyt vain kertakaikkisesti on erittäin selkeä.

 

[Jahve3]

Kunnon tuhnuhan sieltä tulee

 

[Rentner]

1.5V 4.3GHz

No nyt on massiivista kehitystä havaittavissa

#EiMunZen+

 

[Rentner]

EDIT: Vääräkettuli

 

[svk]

Ei kai se jännite oikeasti ole vakiona noin korkea?

 

[khyldi]

Kunnon tuhnuhan sieltä tulee

No jos katsot videon ajatuksella niin huomaat kyllä ettei tekijä oikein tiedä mitä on tekemässä. Pienellä hienosäädöllä 4,7GHz ja 1,35V ihan mahdollinen Kyseessä on myös aikasen vaiheen bios ja valmiit biossit tulee muuttamaan asiaan radikaalisti.

 

[svk]

Ainakin muistit saatu ilmeisesti 3600 taajuuksille. Nouseekohan tuo vielä biosia rukkaamalla?