Virallinen: AMD vs Intel keskustelu- ja väittelyketju

[japau]

Mukavaa luettavaa ollut aamukahvilla nämä viimepäivät. AMD:n miehet ne vaan odottelee maagisia 'optimointeja' vielä vuosi julkaisun jälkeen, että maailma kääntyisi päälaelleen.

 

[HEDT]

Erot mahtuvat helposti virhemarginaaliin
Paras optimointi esim. IFVD:n tapauksessa on käyttää Intelin kääntäjää Ryzenille GCC:n sijasta.
Nopeushyöty > 18% verrattuna GCC 7.2 version

Toki ylläolevat tulokset eivät tietysti todista mitään, sillä ohjelmien lähdekoodi on alunperin kirjoitettu puolueelliseksi Intelin sekä mahdollisesti myös Kiovan fasistijuntan toimesta.

Täällä on väittely nousut ihan uudelle tasolle.

Mielenkiintoista että AoTS tekijät on antanu tällaisia kommentteja

“Every processor is different on how you tune it, and Ryzen gave us some new data points on optimization,” Oxide’s Dan Baker told PCWorld. “We’ve invested thousands of hours tuning Intel CPUs to get every last bit of performance out of them, but comparatively little time so far on Ryzen.”

Here's proof that Ryzen can benefit from optimized game code

Että kumpaa sitä sitten uskoisi? Koodaajia jotka on jotain näkyvää saanut aikaiseksi vaiko näitä forumin ammattisotureita jotka sanoo että prosessorit on ihan samanlaisia ja sama koodi toimii molemmissa ihan yhtä hyvin.

Niin toki kaikki on mahdollista kun folipipon oikein syvälle vetää päähän. Onhan se täysin mahdollista että AMD on tuon kommentin antajalle pistänyt näppiin nipun paperia jotta kaveri sanoo ihan mitä AMD haluaa hänen sanovan.

Tuo peli on tehty täysin AMD: n ehdoilla alkujaankin: Tyyliin: "Tällä me sitten demotaan meidän prossuja" (ovat niin tehneetkin).

Kuten The Stilt tuossa jo mainitsikin, sieltä on voitu korjata selviä bugejakin. IMO: jopa ihan tietoisia, että saadaan näyttämään "optimointi" hyvältä.....

Varmaa on se että tuo on AMD: n peli!

Korjaus: typo

 

[MrFoxZet]

Aivan, eipä yllättänyt tuo vastaus kyllä yhtään. Ennemmin uskotaan keskustelupalstasotureiden juttuja kuin sellaisten jotka ovat oikeasti jotain näkyvää koodanneet.

Eiköhän tämä sitten ollut tässä.

Koska esimerkiksi Silthän ei ole koodannut kuin RTC:n ja pari muuta "pikkusoftaa"

Luulis sen nyt jotain sanovan jos käyttäjänimimerkki löytyy sekunnissa Googlaamalla muualtakin kuin foorumilta mutta jos on tiedoton niin on tiedoton.

 

[hkultala]

[offtopic]

Aivan, eipä yllättänyt tuo vastaus kyllä yhtään. Ennemmin uskotaan keskustelupalstasotureiden juttuja kuin sellaisten jotka ovat oikeasti jotain näkyvää koodanneet.

Eiköhän tämä sitten ollut tässä.

Olen viimeiset n. 12.5 vuotta työkseni koodannut pääosin kääntäjää, välillä vähän muutakin. Tänä aikana olen julkaissut aika monta tieteellistä paperia liittyen optimointeihin, joita olen kääntäjään koodannut, ja ollut kakkoskirjoittajana mukana työkaverien papereissa kun olen heitä auttanut heidän tutkimushommissaan.

Googlen haku tieteellisistä papereista löytää aika hyvin

Google Scholar

(tulee myös pari jotka ei minun papereitani, mutta ne erottaa aika hyvin aihealueen perusteella)

Tuorein paperini taitaa tuolta vielä puuttua.


Että aika hyvin on kyllä näkyvää esillä siitä, mitä olen tehnyt.

[/offtopic]

 

[Cirrus]

Olen viimeiset n. 12.5 olen työkseni koodannut pääosin kääntäjää, välillä vähän muutakin. Tänä aikana olen julkaissut aika monta tieteellistä paperia liittyen optimointeihin, joita olen kääntäjään koodannut, ja ollut kakkoskirjoittajana mukan työkaverien papereissa kun olen heitä autanut heidän tutkimushommissaan.

Googlen haku tieteellisistä papereista löytää aika hyvin

Google Scholar

(tulee myös pari jotka ei minun papereitani, mutta ne erottaa aika hyvin aihealueen perusteella)

Tuorein paperini taitaa tuolta vielä puuttua.


Että aika hyvin on kyllä näkyvää esillä siitä, mitä olen tehnyt.

Epäilen vahvasti, että jiipee ei pysty ymmärtämään, että jollakin on nimimerkkinä oma nimi.

 

[svk]

Uskooko hän, jos sanon olevani slovakia?

 

[Jooga]

Enemmän uskon luulen että tuo JiiPeen "intel-optimointi" on näkynyt pelien kehityksessä päälinjauksena, jossa perusoletuksena on ollut suhteellisen pieni threadien määrä ja korkea yhden ytimen suorituskyky. Tuolloin pelit on voitu suunnitella toimimaan riittävän hyvin 4/8 threadin kivellä jossa yksi ydin pystyy puskemaan kovia määriä dataa ulos, eikä ole ollut tarvetta käyttää työtunteja multithreadauksen viilaamiseen, kun peruskäyttäjillä ei ole ollut prosessoreja tuohon. Nyt Ryzeneillä yhden ytimen huippusuorituskyky on laskenut jonkin verran, mutta samalla ydinten määrä on tuplaantunut, jolloin välttämättä se perusoletuksena 4 nopealle threadille suunniteltu peli ei niin hyvin toimikaan enää 12 threadilla, jossa kuormittunein ydin ei yllä Intelin vastaavien nopeuksiin. Samalla varmasti jotain pieniä eroja muistien nopeuksissa ja prosessorin sisäisessä toiminnassakin on, mutta en edes yritä päteä noilla mutuarvauksilla. Jätän nuo mieluusti hkultalan ja The Stiltin kommentoitaviksi.

Toivottavasti Ryzenin tulo "optimoi" pelejä siihen suuntaan että threadeja otetaan käyttöön n-kappaletta ja siten, että ne jakaantuvat mahdollisimman tasaisesti. Tuo tuskin on enää kovin helppoa toteuttaa ihan vaan sillä oletuksella, että monissa peleissä on se yksi pääthreadi jonka suorituskyvystä riippuu lähes koko FPS.

edit: ei sekoteta uskoa tieteen avulla tuotettuun teknologiaan.

 

[Hessu]

Enemmän uskon että tuo JiiPeen "intel-optimointi" on näkynyt pelien kehityksessä päälinjauksena, jossa perusoletuksena on ollut suhteellisen pieni threadien määrä ja korkea yhden ytimen suorituskyky. Tuolloin pelit on voitu suunnitella toimimaan riittävän hyvin 4/8 threadin kivellä jossa yksi ydin pystyy puskemaan kovia määriä dataa ulos, eikä ole ollut tarvetta käyttää työtunteja multithreadauksen viilaamiseen, kun peruskäyttäjillä ei ole ollut prosessoreja tuohon. Nyt Ryzeneillä yhden ytimen huippusuorituskyky on laskenut jonkin verran, mutta samalla ydinten määrä on tuplaantunut, jolloin välttämättä se perusoletuksena 4 nopealle threadille suunniteltu peli ei niin hyvin toimikaan enää 12 threadilla, jossa kuormittunein ydin ei yllä Intelin vastaavien nopeuksiin. Samalla varmasti jotain pieniä eroja muistien nopeuksissa ja prosessorin sisäisessä toiminnassakin on, mutta en edes yritä päteä noilla mutuarvauksilla. Jätän nuo mieluusti hkultalan ja The Stiltin kommentoitaviksi.

Toivottavasti Ryzenin tulo "optimoi" pelejä siihen suuntaan että threadeja otetaan käyttöön n-kappaletta ja siten, että ne jakaantuvat mahdollisimman tasaisesti. Tuo tuskin on enää kovin helppoa toteuttaa ihan vaan sillä oletuksella, että monissa peleissä on se yksi pääthreadi jonka suorituskyvystä riippuu lähes koko FPS.

Toiset miettii näitä faktapohjalta, mutta voithan toki pitää uskonasianakin, mikäli se enemmän mieltä lämmittää.

 

[Jage]

Toiset miettii näitä faktapohjalta, mutta voithan toki pitää uskonasianakin, mikäli se enemmän mieltä lämmittää.

Ehkäpä näin mutta luulisi loogisesti ytimien käytön optimointi tai sen puuttumisen olevan pitkälti Intelin tuotteista johtuvaa. Ja tämähän ei ole Intelin vika lainkaan (toim.huom.)

Kun ytimiä tuodaan enemmän käyttöön työpöytätasolle, niin monisäikeistys tulee varmastikin parantumaan. IPC-etu on tietenkin Intelin puolella, sitä ei käy kiistäminen kenelläkään.

 

[Jooga]

Toiset miettii näitä faktapohjalta, mutta voithan toki pitää uskonasianakin, mikäli se enemmän mieltä lämmittää.

En nyt oikein ymmärtänyt tätä kommenttia? Siis logiikkani oli tuossa jotenkin täysin typerää vai? Vai oliko tuo 'uskon'-sana se joka sinut triggeroi? Voin myös muuttaa sen muotoon 'luulen', mutta koska en tuota tiedä, niin en myöskään sitä väitä.

 

[HEDT]

vaan viedä huomio siltä seikalta, että Ryzenit ovat kokonaisuutena aivan erinomaisia prosessoreita.

Ei tuota ole kukaan väittänyt/ kieltänyt.
IPC- eroja Intellin hyväksi vaan ei katsottu "hyvällä ja tasapuolisella" pelillä saavutetuiksi, esitetystä peräti 29 testikuorman keskiarvoista huolimatta.

 

[MrFoxZet]

Ei tuota ole kukaan väittänyt/ kieltänyt.
IPC- eroja Intellin hyväksi vaan ei katsottu "hyvällä ja tasapuolisella" pelillä saavutetuiksi, esitetystä peräti 29 testikuorman keskiarvoista huolimatta.

Eiköhän noissa epäluotettavuutta herättänyt keskinkertainen dokumentointi, CPU-mittauksiin melko vaatimaton näytönohjain ja tulosten epäsäännöllisyys, ei niinkään erot Intelin ja AMD:n testiprossujen välillä...

 

[hkultala]

Ehkäpä näin mutta luulisi loogisesti ytimien käytön optimointi tai sen puuttumisen olevan pitkälti Intelin tuotteista johtuvaa. Ja tämähän ei ole Intelin vika lainkaan (toim.huom.)

Kun ytimiä tuodaan enemmän käyttöön työpöytätasolle, niin monisäikeistys tulee varmastikin parantumaan. IPC-etu on tietenkin Intelin puolella, sitä ei käy kiistäminen kenelläkään.

Intel oli ensimmäinen joka toi kuluttajamarkkinoille 8aa ja 12aa säiettä yhtä aikaa ajavat prosessorit, 8 säiettä tuli jo 10 vuotta sitten, AMDllä vasta kolmisen vuotta myöhemmin. 12 säiettä ajava kuluttaprosessori AMDltä tuli 7 vuotta intelin jälkeen, tosin samalla AMD hyppäsi sitten 16 säikeeseen asti.

Että kyllä se intelistä täyden tehon irtisaaminen vaatii ihan yhtä lailla sitä monisäikeistämistä.

 

[sushukka]

Eiköhän tämä matalan tason AMD- vs. Intel-optimointi ole nähty. Nykyisellään ei etua paljoa saada. Eri kysymys on se, että kuinka paljon AMD joutuu ratkaisuissaan apinoimaan Inteliä, jotta nykyiset softat toimii optimaalisesti myös heidän kivillään. Toki sovelluskehittäjille helpompi kun käytännössä yksi pääpolku tallustaa, mutta silti väitän että jos markkinaosuudet olisivat 50/50 AMD/Intel, niin nähtäisiin enemmän eroavaisuuksia prosessoreissa ja optimoinneilla olisi enemmän merkitystä.

Intel oli ensimmäinen joka toi kuluttajamarkkinoille 8aa ja 12aa säiettä yhtä aikaa ajavat prosessorit, 8 säiettä tuli jo 10 vuotta sitten, AMDllä vasta kolmisen vuotta myöhemmin. 12 säiettä ajava kuluttaprosessori AMDltä tuli 7 vuotta intelin jälkeen, tosin samalla AMD hyppäsi sitten 16 säikeeseen asti.

Että kyllä se intelistä täyden tehon irtisaaminen vaatii ihan yhtä lailla sitä monisäikeistämistä.

Toki vaatii, mutta kuluttajapuoli on tosiaan ollut 2-8 säiettä. HEDT-prossuja en vielä laske ison massamarkkinan kuluttajatuotteiksi. Keskiarvo on siten varmaankin lähempänä neljää kun otetaan kaikki hilavitkuttimet huomioon. Ja vaikka rinnakkaisuus tehdään säikeille, niin se että käytännössä on ollut max. neljä oikeaa ydintä käytettävissä on varmasti myös vaikuttanut rinnakkaisuuden houkuttelevuuteen saavutettavan tehoedun vs. lisätyön näkökulmasta. Ilman AMD:tä Intel olisi tuonut alkuperäisen roadmappinsa mukaan vasta tänä vuonna 6c-prossut myyntiin ja nyt kun säikeiden keskimääräinen taso kasvaa kuluttajamarkkinoilla isommin, niin siihen aletaan kiinnittämään myös huomiota. Siten optimointia on edessä, mutta tässäkin siihen vetävä taho on Intel. AMD:n kannalta hyvä, koska se sopii erityisesti heidän Zen-malliinsa. Intel olisi hyvin voinut tuoda coreja- ja säikeitä lisää Xeon-puolelta milloin vain olisivat halunneet, jolloin AMD:lla olisi ollut paljon surkeammat mahdollisuudet päästä peliin taas mukaan, mutta eivätpä kovassa rahan tarpeessaan tehneet.

 

[Jooga]

Eiköhän noissa epäluotettavuutta herättänyt keskinkertainen dokumentointi, CPU-mittauksiin melko vaatimaton näytönohjain ja tulosten epäsäännöllisyys, ei niinkään erot Intelin ja AMD:n testiprossujen välillä...

Nyt sekoitat the Stiltin CPU-testit ja Zetterin pelitestit.

 

[MrFoxZet]

Nyt sekoitat the Stiltin CPU-testit ja Zetterin pelitestit.

tarkoitin "noilla" nimenomaan noita viimeiset ~4 sivua tuottaneita testejä, luulin että kävis selväksi mainituista epäkohdista mutta tulipahan nyt tarkennettua

 

[Jooga]

tarkoitin "noilla" nimenomaan noita viimeiset ~4 sivua tuottaneita testejä, luulin että kävis selväksi mainituista epäkohdista mutta tulipahan nyt tarkennettua

Spoileri

Kuten sanoin, kyseessä on 29 kuorman keskiarvot. 24 noista kuormista on avointa lähdekoodia.

Testikuormat:

- 3DPM V2.0b1
- 7-Zip 18.02
- Blackscholes (Generic)
- Blender 2.79a
- Bullet 2.85
- Cinebench R10
- Cinebench R11.5
- Cinebench R15
- C-Ray
- Embree 3.0.0
- Eigen 3.3.90 (Dense Solvers)
- Euler3D CFD (Rodinia)
- GCC 7.2
- GMPBench (libGMP 6.1.99 "Fat")
- Image Processing; Crop, DS, PNG (AV 7.12.100 & Scale 5.0.102)
- IFVD CFD
- K-means (Rodinia)
- Linpack 2018.1.009
- Monte Carlo Ray Tracer 1.0
- NAMD 2.12 (APOA1)
- NBody (Generic)
- NQueen (Generic)
- OpenSSL 1.1.0g
- Opus 1.3b
- Stockfish 9
- Vampire Numbers (Generic)
- WinRAR 5.50
- X264 0.156.2905
- X265 2.7+2

Cinebenchejä, Linpackia sekä WinRAR:a lukuunottamatta kaikki kuormat on avointa lähdekoodia.
11:ta itse käännetyssä kuormassa kääntäjänä on GCC (6.3 tai 7.2), kahdeksassa ICL 2017 tai 2018 jonka tuottamat binäärit on pätsätty valmistajariippuvaisen polunohjauksen poistamiseksi.

Spoileri

Ööö minäpä kerron mitä kaikkea sisältyy testeihini kun selvästi et tiedä.

Eli:
Cinebech R15
PowerDirector 15:stä 6min video projektin rendeöinti
3dmark FireStrike
3dmark TimeSpy

Peleihin yritin saada mahdollisimman laajan kirjon eri tyyppisiä pelejä:

8-bit Armies
Arma 3
Battlefield 3
Crysis 3
CS:GO
Doom (2016)
GTA V
Overwatch
Project Cars
Redout
Rise of the Triad (2013)
Sublevel Zero Redux

Siksi vastasin kun itselle ei suoraan selvinnyt kumpia testejä tarkoitit. 29 testiä oli Stiltin osuudessa, mutta siinä ei käsittääkseni taas GPU:ta ole. Ja mielestäni suurempi keskustelu on viimeisissä postauksissa liittynyt nimenomaan tuohon Stiltin raportoimaan IPC-eroon, eikä Zetterin pelitesteihin liittyen. Ei ollut tarkoitus olla vain näsäviisas pilkunnussija.

 

[MrFoxZet]

Siksi vastasin kun itselle ei suoraan selvinnyt kumpia testejä tarkoitit. 29 testiä oli Stiltin osuudessa, mutta siinä ei käsittääkseni taas GPU:ta ole. Ja mielestäni suurempi keskustelu on viimeisissä postauksissa liittynyt nimenomaan tuohon Stiltin raportoimaan IPC-eroon, eikä Zetterin pelitesteihin liittyen. Ei ollut tarkoitus olla vain näsäviisas pilkunnussija.

Joo ehkä hieman sekavasti asiani ilmaisin, ihan asiallisesti toit epäkohdan esiin, ei mitään

 

[JiiPee]

Tuo peli on tehty täysin AMD: n ehdoilla alkujaankin: Tyyliin: "Tällä me sitten demotaan meidän prossuja" (ovat niin tehneetkin).

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.

Kuten The Stilt tuossa jo mainitsikin, sieltä on voitu korjata selviä bugejakin. IMO: jopa ihan tietoisia, että saadaan näyttämään "optimointi" hyvältä.....

No toki kun folipipon laittaa päähän niin tottakai se on mahdollista että ihan tahallaan on rampautettu.

Luulis sen nyt jotain sanovan jos käyttäjänimimerkki löytyy sekunnissa Googlaamalla muualtakin kuin foorumilta mutta jos on tiedoton niin on tiedoton.

Eipä ole ollut tarvetta kyseistä nimimerkkiä googletella. Kerrotko mikä olisi sellainen syy että minulle tulisi pakottava tarve googlettaa vaikka sinun nimimerkkisi?

Olen viimeiset n. 12.5 vuotta työkseni koodannut pääosin kääntäjää, välillä vähän muutakin. Tänä aikana olen julkaissut aika monta tieteellistä paperia liittyen optimointeihin, joita olen kääntäjään koodannut, ja ollut kakkoskirjoittajana mukana työkaverien papereissa kun olen heitä auttanut heidän tutkimushommissaan.

Eli sinä kun keskityt kääntäjän optimointiin niin silloin lähdekoodin optimointi mielestäsi on täysin turhaa eikä sillä saavuteta mitään?

Epäilen vahvasti, että jiipee ei pysty ymmärtämään, että jollakin on nimimerkkinä oma nimi.

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

Ehkäpä näin mutta luulisi loogisesti ytimien käytön optimointi tai sen puuttumisen olevan pitkälti Intelin tuotteista johtuvaa. Ja tämähän ei ole Intelin vika lainkaan (toim.huom.)

Nimenomaan. Tuntuu vain olevan joillekin niin vaikeata ymmärtää että vuosikausia kun koodia väännetään yhden valmistajan ehdoilla niin siitä tulee ikäänkuin automaattisesti se stantardi jossa nyt eletään ja ei pystytä näkemään nyt sitä että toiselle valmistajalle asiat voitaisiin ehkä tehdä hieman toisin tai sitten ei yksinkertaisesti osata tai ei edes haluta oppia.

Intel oli ensimmäinen joka toi kuluttajamarkkinoille 8aa ja 12aa säiettä yhtä aikaa ajavat prosessorit

Intelin HEDT prossuja on kyllä hyvin vaikea laskea kuluttajamarkkinoille suunnatuiksi tuotteiksi.

 

[MrFoxZet]

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.




No toki kun folipipon laittaa päähän niin tottakai se on mahdollista että ihan tahallaan on rampautettu.



Eipä ole ollut tarvetta kyseistä nimimerkkiä googletella. Kerrotko mikä olisi sellainen syy että minulle tulisi pakottava tarve googlettaa vaikka sinun nimimerkkisi?



Eli sinä kun keskityt kääntäjän optimointiin niin silloin lähdekoodin optimointi mielestäsi on täysin turhaa eikä sillä saavuteta mitään?



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



Nimenomaan. Tuntuu vain olevan joillekin niin vaikeata ymmärtää että vuosikausia kun koodia väännetään yhden valmistajan ehdoilla niin siitä tulee ikäänkuin automaattisesti se stantardi jossa nyt eletään ja ei pystytä näkemään nyt sitä että toiselle valmistajalle asiat voitaisiin ehkä tehdä hieman toisin tai sitten ei yksinkertaisesti osata tai ei edes haluta oppia.



Intelin HEDT prossuja on kyllä hyvin vaikea laskea kuluttajamarkkinoille suunnatuiksi tuotteiksi.

Onhan se ihan järkevä ottaa vähän selvää kenen kanssa on keskustelemassa, niin välttyy monelta harmilta. Olis myös näkynyt sitä "jotain näkyvää" koodauksen tulosta (RTC jne).

Tosin pidän hieman erikoisena ettei io-techissä pyörivä/muuten ATK-uutisia seuraava olisi edes jossain kuullut Stiltistä

 

[JiiPee]

Tosin pidän hieman erikoisena ettei io-techissä pyörivä/muuten ATK-uutisia seuraava olisi edes jossain kuullut Stiltistä

Näin vain on että kyseinen herra on täysin tuntematon itselleni. Tosin oli tuossa melkein 10v tauko ettei koko touhua tullut juurikaan seurattua koska ei ollut mitään mielenkiintoista seurattavaa. Esim. muroa josta ilmeisesti suurin osa tänne on tullut(?) en ole koskaan seurannut taikka siellä keskustellut.
Vasta pari vuotta sitten alkoi taas alan seuraaminen kiinnostaa kun alkoi huhuja kuulumaan että voisi tulevaisuudessa olla mielenkiintoiset ajat taas edessä ja onhan tämä ihan mielenkiintoista Ryzenin julkaisun jälkeen ollutkin.

 

[MrFoxZet]

Näin vain on että kyseinen herra on täysin tuntematon itselleni. Tosin oli tuossa melkein 10v tauko ettei koko touhua tullut juurikaan seurattua koska ei ollut mitään mielenkiintoista seurattavaa. Esim. muroa josta ilmeisesti suurin osa tänne on tullut(?) en ole koskaan seurannut taikka siellä keskustellut.
Vasta pari vuotta sitten alkoi taas alan seuraaminen kiinnostaa kun alkoi huhuja kuulumaan että voisi tulevaisuudessa olla mielenkiintoiset ajat taas edessä ja onhan tämä ihan mielenkiintoista Ryzenin julkaisun jälkeen ollutkin.

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

 

[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.