Käyttäjä hkultala on monta kertaa sanonut missä on töissä ja siihen kun lisää nimimerkin, ei tarvita kummoistakaan salapoliisityötä.
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.
Eiköhän tuo ole koodattu (AMD: lle) niin lähelle konsoli- versiota kun vain mahdollista.
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.
Ei taitaisi poistaminen auttaa suoritusnopeuteen amd:llä.
Miksi ei auttaisi, jos se hidastaa, kuten @The Stilt in esimerkissä?
Ei pääse kun töissä nyt.Oon täällä sohvalla viltin alla.
Tulkaa juttelee
Keitäm vaikka kaffet
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.
... ja throughputissa ero on ilmeisesti vielä suurempi, 18-kertainen, skylakessa tuo käsky on liukuhihnoitettu, ryzenissa ilmeisesti ei.
Vastaan tähän, mutta muuten ei oikein ole halua tulla tähän aiheeseen.
GCC:n ollessa kyseessä ohjelma kaatuu, mikäli suorittava prosessori ei tue ohjelman käyttämiä käskykantoja.
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.
Miten niin?
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.
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.
Ja näin, ei ole mitenkään vaikea toteuttaa.
Eli kääntäjän pitäisi jättää käyttämättä käskykantoja jotka prosessorivalmistaja on katsonut tarpeelliseksi tukea?
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ä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ää?
Eli prosessorin tukemia ominaisuuksia pitää manuaalisesti disabloida koodista tai muuten koodi on Intel-optimoitu?
Tämä Ryzen-vastainen PEXT (BMI2) tuki on lisätty Stockfishiin alkuvuodesta 2014.
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ä.
Ryzenin tapauksessa taitaa olla hidastava.
Yhteensopivuus tietysti. On parempi että ohjelma toimii (vaikka sitten hitaasti) kuin ettei ohjelma toimi ollenkaan.
Prosessorin tukemia ominaisuuksia ei tarvitse käyttää mikäli prosessori suorittaa niitä hitaasti.
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.
Tuo on lähes vuoden vanhaa testiä. Nykyinen saattaisi ottaa tuonkin huomioon.
Lihavoitu olennaisena. Missä kohtaa se oletuksena nopeuttaa Ryzenillä ohjelman suoritusta?Ihan näin suurta AMD-fanitusta en kyllä itsekään Ryzenin omistajana jaksa kuunnella kovin montaa sivua
Qx optio vastaa GCC:n "march" optiota Intelin kääntäjässä.
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.
Millos se käännös on tehty?
Ei tuo ole bugi. Se on ihan dokumentoitu feature, että tuo käsky on zenillä hidas.
Miksi nopeuttaa oletuksena? Ominaisuudet jotka lisätään yhteensopivuussyistä eivät useinkaan ole kovin nopealla toteutuksella.
Käskyjen lisäämiseen on kaksi mahdollista syytä:
Katsoisin, että kyseessä ON BUGI, jos erillinen nopeuttamiseen tarkoitettu käsky toimiikin hitaammin, kuin erillisillä käskyillä tehty ohjelma.
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.
AMD on julkaissut uudemman version, mutta eipä se mikään sateentekijä ole.
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ä.
Tuo sentään menee virhemarginaaliin, tai ainakin lähelle.
Noinhan se pitäisikin olla.
Miten päättelit syynä olevan suorittimen?
oliko se "ATOM romu" vielä peräisin lappeen Rannasta?
... paljonkos siinä koneessa oli muistia?
Helposti:
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 mahdollinenKunnon tuhnuhan sieltä tulee
Kyseessä on myös aikasen vaiheen bios ja valmiit biossit tulee muuttamaan asiaan radikaalisti.
