Virallinen: AMD vs Intel keskustelu- ja väittelyketju

[El eks]

Missä huhussa on varmistettu , että AMD lopettaa nyt ja heti 12nm ZEN ytinien valmistamisen
Ja siirtyy CCX moduuleista pelkkiin chipletteihin

 

[JiiPee]

En yleistä yhtään, puhun vain ja ainoastaan omista kokemuksista:
Monta Intelin kokoonpanoa = ei BSODeja since vista.
Yksi (ensinmäinen) AMD kokoonpano = useita BSODeja ja nyt halvaantunut kone.

No ittellä tuo aikaisempi Core 2 E8500 oli vakaa kuin kivi winXP ja Vistalla ja vielä Win 7. Sitten tuli päivitettyä tähän i5 4670K:n ja BSOD paukkuu säännöllisesti niin win 7, win 8, win 8.1 että win 10 aikana. Ja ei tunnu olevan mitään merkitystä onko kelloteltu vaiko täysin vakio.
Eli kyllä nämä Inttelitkin kippailee jos rauta ei ole yhteensopivaa. Koskaan en jaksanut alkaa selvittämään että mikä sitä BSOD:tä lopulta aiheuttaa, ei kuitenkaan päivittäin tapahtunut ei välttämättä edes viikottain.

 

[Griffin]

Vaikuttaa nopealla googletuksella enemmänkin korruptoituneelta Windowsilta (esim. päivityksen yhteydessä) kuin rautatason ongelmalta.

Esim muistien hyvin lievä epävakaus tekee helposti tuollaisen ongelman.
Pistin tänne boardille ohjeen, kuinka päivityksen voi peruuttaa korjauskonsolin kautta, jos jämähtää päivitykseen. Muutaman tenäkoneen olen tuollatavoin saanut toimimaan.

Samallantyyppisellä kikalla voi myös poistaa asennetun päivityksen (ei aina). Päivityksiä voi myös poistaa sen asennustikulta löytyvän, olikohan palaa aikaisempaan versioon tms kohdan kautta, yleensä ei toimi)

Luonnollisesti ensin kannattaa koittaa käynnistyksen korjausta asennustikun kautta ja jos se ei onnistu, niin se antaa logitiedoston paikan ja sieltä voi käydä lukemassa sen tekstitiedoston, siinäkin voi olla vihjeitä.

Monasti tuho johtuu (jos korjaus ei onnistu), sekaisin olevasta rekisteristä. Sieltä voi kanssa katsella korjauskonsolin kautta regeditillä, lataamalla rekisteritiedostoja editoriin, editoimalla ja poistamalla taas muistista, tosin ensin kannattaa ottaa kopio niistä. Lisäksi ko viat ovat milestäni erittäin hankalia, kaikinpuolin.

Sitten jos windows saa ladattua rekisterin system osion sekä polkaistua kernelin ym kriittiset käyntiin, niin bootconfigurationin tms kautta saa boottilogin päälle, joka voi kanssa sisältää vihjeitä, mikä menee pieleen.

SFC:llä voi (sfc /scannow) voi koittaa myös käydä läpi windowksen järjestelmätiedostoja ja jos se ei auta, niin sitten joutuu ensin korjaamaan toisella työkalulla ja sitten sfc:llä..
https://support.microsoft.com/fi-fi...-by-using-the-dism-or-system-update-readiness

Win 10:ssä kannattaa tarkistaa, että systemrestore on päällä ja sille on varattu tilaa jonkinverran. Esim 250 Gigan c asemasta 5% on ok.
-------------
Tietysti jos on esim muistiepävakautta, niin korjailu on melkoturhaa, ennenkuin rauta toimii kunnolla. Tuossa muutama viikko tutustuin aiheeseen (Ihan vanhalla intel kokoonpanolla). Muutama bootti ja win 10 oli uudestaan hajalla. Lopulta täydellisesti (kolmas hajoaminen).

 

[svk]

Missä huhussa on varmistettu , että AMD lopettaa nyt ja heti 12nm ZEN ytinien valmistamisen
Ja siirtyy CCX moduuleista pelkkiin chipletteihin

Ei missään? Justhan AMD julkaisi 3xxx sarjaan APU-kiviä, jotka on valmistettu 12nm-prosessilla AMD Ryzen™ 7 3750H Mobile Processor with Radeon™ RX Vega 10 Graphics | AMD

 

[Threadripper]

Ei missään? Justhan AMD julkaisi 3xxx sarjaan APU-kiviä, jotka on valmistettu 12nm-prosessilla AMD Ryzen™ 7 3750H Mobile Processor with Radeon™ RX Vega 10 Graphics | AMD

Niinpä. Ei ole tuollaista väitettä näkynyt. APU-piireistä chipleteillä ei ole mitään tietoa ja jos historiaa katsoo, tulevat aikaisintaan syksyllä.

 

[ratkakapu]

Missä huhussa on varmistettu , että AMD lopettaa nyt ja heti 12nm ZEN ytinien valmistamisen
Ja siirtyy CCX moduuleista pelkkiin chipletteihin

Historian valossa ollaan menty ainakin dual-core aikakaudesta eteenpäin sitten, että edellisen mallin tuotantoa on supistettu reilusti korvaavan tuotteen julkaisun aikoihin ja 3-9kk tästä tuotanto on lakkautettu kokonaan (jotain poikkeuksia löytyy, esim tiettyjä c2d malleja tehtiin 2012 alkuun asti, viimeiset tilaukset sai asettaa puoli vuotta aiemmin). Tämä on ollut trendi molempien otsakkeen valmistajien kohdalla. Single core aikoina edellinen malli saatettiin jättää matalemman suoritustason malliksi (ehkä uudelleenbrändättynä), mutta tämmöistä uudelleensegmentointia ei olla aikoihin nähty.

Niinpä. Ei ole tuollaista väitettä näkynyt. APU-piireistä chipleteillä ei ole mitään tietoa ja jos historiaa katsoo, tulevat aikaisintaan syksyllä.

Itse pidän todenäköisenä, että menee heittämällä 2020 puolelle.

Keväällä tulee epyc. Se ei aiheuta kuluttajamarkkinoilla laineita, koska se on sillä puolella täysin epärelevantti tuote. Edes sen edistyksellisellä 7nm tekniikalla tai muulla ei juuri pullistella osborne-efektin pelossa.

Kesällä alkaa hurja myllytys 8-ytimisten ryzen 7 3000-sarjan kivien kanssa. Mahdollisesti jopa työpöydän suorituskykykuninkuus, tai ainakin aivan Intelin kannoille ylivertaisella energiatehokkuudella ja paljon edullisemmalla hinnalla. Halvin 8-ytiminen malli brändätään täysin ylivoimaiseksi bang-for-buck huippumalliksi.

Tämän jälkeen loppukesään/alkusyksyyn on tarjolla 6- ja 4-ytimiset midrange-mallit, halvimmat oikeastaan lipeävät budjettipuolelle tarjoten silti huippusuorituskykyä. Varsinkin halvin 6-ytiminen malli tulee tarjoamaan käsittämättömän turpasaunan saman hintaluokan Intelin rojuille. Kellotuspotenttiaali on hurja ja hinta mukava. Pelikäytössä ei kellotettuna häviä yhtään 8-ytimisille.

Sen jälkeen on threadripperin vuoro iskeä joulumarkkinoille. Todellinen JYTKY! Vähintään 32 nopeaa corea. 64 en usko, mutta 40-48 on mahdollisuuksien rajoissa.

Lopulta 2020 alkuvuodesta viimeiset 7nm (=APU) tuotteet saadaan linjastolta pihalle. Kun Intel julkaisee ekat oikeasti saatavilla olevat 10nm mallit, niin AMD voi kehuskella, kuinka heillä on nyt koko mallisto julkaistu edistyneellä teknikalla.

 

[hkultala]

Ei se benchmarkhuijaus ole mikään uskon asia vaan puhdasta faktaa

Taidat viitata tällä tähän tapaukseen:

Faktaa on, että Intel jäi kiinni siitä, että erikseen tarkasti, onko kohdeprosessori intelin prossu, ja jos ei, se jätti generoimatta SSE-koodia(tai siis laittoi ajoon koodipolun, joka ei käytä SSEtä). Tästä alkoi oikeusjuttu alkoi 2005 ja sen seurauksena 2009 tehtiin sopimus, jossa sanottiin seuraavaa:

2.3 TECHNICAL PRACTICES

Intel shall not include any Artificial Performance Impairment in any Intel product or require any Third Party to include an Artificial Performance Impairment in the Third Party's product. As used in this Section 2.3, "Artificial Performance Impairment" means an affirmative engineering or design action by Intel (but not a failure to act) that (i) degrades the performance or operation of a Specified AMD product, (ii) is not a consequence of an Intel Product Benefit and (iii) is made intentionally to degrade the performance or operation of a Specified AMD Product. For purposes of this Section 2.3, "Product Benefit" shall mean any benefit, advantage, or improvement in terms of performance, operation, price, cost, manufacturability, reliability, compatibility, or ability to operate or enhance the operation of another product.

In no circumstances shall this Section 2.3 impose or be construed to impose any obligation on Intel to (i) take any act that would provide a Product Benefit to any AMD or other non-Intel product, either when such AMD or non-Intel product is used alone or in combination with any other product, (ii) optimize any products for Specified AMD Products, or (iii) provide any technical information, documents, or know how to AMD.

Vuodelta 2009 oleva postaus aiheesta:

Agner`s CPU blog - Intel's "cripple AMD" function


Eli siis, faktaa on myös se, että 2009, yli 9 vuotta sitten, tehtiin sopimus, jonka seurauksena intel lopetti tämän "huijaamisensa".



(Vai viittaatko siihen, kun Intel vuonna 1995 julkaisi spec-testituloksensa Pentium Pro:lle, ja sai specINT-testissä paremmat tulokset kuin mikään muu prosessori, mutta myöhemmin ilmeni, että testit oli tehty bugisella kääntäjällä(mutta se käänsi itse specINT-testin kyllä oikein, tuotti rikkinäistä koodia muulla koodilla), ja siinä vaiheessa kun nämä kääntäjän bugit oli korjattu siten että se käänsi muunkin koodin oikein, Pentium Pro ei enää ollutkaan specINT-testissä maailman nopein prosessori.)

 

[Marco Polo]

Ja tämän pienen tapauksen takia Threadripper yleisti että kaikki muutkin benchmarkit ovat oletettavasti huijausta, jos Intel on niissä AMD:tä parempi. Naurettavaa logiikkaa jos minulta kysytään..

 

[TheMeII]

Ja tämän pienen tapauksen takia Threadripper yleisti että kaikki muutkin benchmarkit ovat oletettavasti huijausta, jos Intel on niissä AMD:tä parempi. Naurettavaa logiikkaa jos minulta kysytään..

Testit yleensäkin on vain suuntaa-antavia ja on työtehtävästä riippuvaista mitä ominaisuutta tarvitaan. Testauksessa pitää ottaa joku kulma siihen mitä testataan ja miten sitä arvotetaan. Yksi on parasta mitä rahalla saa, toinen taas mitä samalla rahalla saa. Myös paljonko sitä tehoa saa per m^2 tai paljonko tehoa saa lämpökuormaa kohden.

Ei ole yksiselitteistä oikeaa tapaa testata saati sitten testiohjelmaa.

 

[JiiPee]

Ja tämän pienen tapauksen takia Threadripper yleisti että kaikki muutkin benchmarkit ovat oletettavasti huijausta, jos Intel on niissä AMD:tä parempi. Naurettavaa logiikkaa jos minulta kysytään..

No ei se nyt ihan PIENI tapaus ollut kun sitä ihan oikeudessa puitiin. Benchmarkeissa on aina kusetettu ja tullaan kusettamaan. Tähän on syyllistyny niin Intel, nVidia ja AMD.

 

[Marco Polo]

Testit yleensäkin on vain suuntaa-antavia ja on työtehtävästä riippuvaista mitä ominaisuutta tarvitaan. Testauksessa pitää ottaa joku kulma siihen mitä testataan ja miten sitä arvotetaan. Yksi on parasta mitä rahalla saa, toinen taas mitä samalla rahalla saa. Myös paljonko sitä tehoa saa per m^2 tai paljonko tehoa saa lämpökuormaa kohden.

Ei ole yksiselitteistä oikeaa tapaa testata saati sitten testiohjelmaa.

Mutta jokainenhan voi valita luettavaksi tai katottavaksi ne testit, jotka testaavat sitä asiaa mitä itse arvostaa? Taitaa kuitenkin olla ihan faktaa, että suurin osa testien lukijoista arvostaa pelisuorituskykyä ja sen takia suurin osa testeistä sitä testaakin. Sen jälkeen tulee erilaisten ohjelmien testit suosiossa yms. Aika harvinaiselta omaan korvaan kuulostaa kyllä, että joku pitäisi tärkeimpinä testeinä esimerkiksi paljonko tehoa saa lämpökuormaa kohden.

No ei se nyt ihan PIENI tapaus ollut kun sitä ihan oikeudessa puitiin. Benchmarkeissa on aina kusetettu ja tullaan kusettamaan. Tähän on syyllistyny niin Intel, nVidia ja AMD.

Kyllä se pieni oli siinä mielessä, että sen perusteella yleisti kaikkiin muihinkin benchmarkkeihin saman huijaus oletuksen. Uskallan väittää että muutenkin suurin osa lukijoista lukee tai katsoo ulkopuolisten henkilöiden tekemiä benchmark tuloksia eikä yhtiöiden omia, kun tekee valintoja. Ja uskallan väittää että näistä suurin osa on ihan rehellisesti tehtyjä. Myös tämän päivän ohjelmat ovat hyvin luotettavia. Jos on erimieltä tämän päivän ohjelmien luotettavuudesta niin voi jotain todisteitakin antaa väitteilleen. Senhän se pitää todistaa, joka huijaamista väittää tapahtuvan. Se ei riitä todisteeksi että joskus vuonna kivi on joku huijannut jossakin ohjelmassa. Se on vähän sama kuin väittäisi henkilön X tehneen murhan, koska vuosia sitten henkilö Y teki murhan.

 

[Samat]

Mutta jokainenhan voi valita luettavaksi tai katottavaksi ne testit, jotka testaavat sitä asiaa mitä itse arvostaa? Taitaa kuitenkin olla ihan faktaa, että suurin osa testien lukijoista arvostaa pelisuorituskykyä ja sen takia suurin osa testeistä sitä testaakin. Sen jälkeen tulee erilaisten ohjelmien testit suosiossa yms. Aika harvinaiselta omaan korvaan kuulostaa kyllä, että joku pitäisi tärkeimpinä testeinä esimerkiksi paljonko tehoa saa lämpökuormaa kohden.

Ei koti/toimistokäytössä, tärkeämpää serveripuolella jossa konesalien jäähdytys on merkittävä kustannus.

 

[JiiPee]

skallan väittää että muutenkin suurin osa lukijoista lukee tai katsoo ulkopuolisten henkilöiden tekemiä benchmark tuloksia eikä yhtiöiden omia, kun tekee valintoja.

Huoh! Kaikki ohjelmat jotka oli Intelin kääntäjällä käännetty, automaattisesti kusetti. Ei ollu väliä kuka ne testit teki.

Ja edelleen, aina on huijattu ja jatkossakin tullaan huijaamaan.

 

[Threadripper]

Taidat viitata tällä tähän tapaukseen:

Faktaa on, että Intel jäi kiinni siitä, että erikseen tarkasti, onko kohdeprosessori intelin prossu, ja jos ei, se jätti generoimatta SSE-koodia(tai siis laittoi ajoon koodipolun, joka ei käytä SSEtä). Tästä alkoi oikeusjuttu alkoi 2005 ja sen seurauksena 2009 tehtiin sopimus, jossa sanottiin seuraavaa:

Vuodelta 2009 oleva postaus aiheesta:

Agner`s CPU blog - Intel's "cripple AMD" function


Eli siis, faktaa on myös se, että 2009, yli 9 vuotta sitten, tehtiin sopimus, jonka seurauksena intel lopetti tämän "huijaamisensa".

Jep, valitettavasti tuo koskee vain Inteliä itseään. On käytännössä täysin mahdoton todistaa mikäli esim. Intel maksaa jollekin kolmannelle osapuolelle vastaavan tekemisestä.

Ja tämän pienen tapauksen takia Threadripper yleisti että kaikki muutkin benchmarkit ovat oletettavasti huijausta, jos Intel on niissä AMD:tä parempi. Naurettavaa logiikkaa jos minulta kysytään..

Tuo "pikku juttu" koski aika suurta osaa ohjelmista Lisäksi käytännössä aina se mitä pystytään todistamaan on hyvin pieni osa kaikesta.

Kyllä se pieni oli siinä mielessä, että sen perusteella yleisti kaikkiin muihinkin benchmarkkeihin saman huijaus oletuksen. Uskallan väittää että muutenkin suurin osa lukijoista lukee tai katsoo ulkopuolisten henkilöiden tekemiä benchmark tuloksia eikä yhtiöiden omia, kun tekee valintoja. Ja uskallan väittää että näistä suurin osa on ihan rehellisesti tehtyjä. Myös tämän päivän ohjelmat ovat hyvin luotettavia. Jos on erimieltä tämän päivän ohjelmien luotettavuudesta niin voi jotain todisteitakin antaa väitteilleen. Senhän se pitää todistaa, joka huijaamista väittää tapahtuvan. Se ei riitä todisteeksi että joskus vuonna kivi on joku huijannut jossakin ohjelmassa. Se on vähän sama kuin väittäisi henkilön X tehneen murhan, koska vuosia sitten henkilö Y teki murhan.

Millä hitolla todistat nykypäivän benchmarkkien olevan "luotettavia"? Lähes kaikissa on sama ongelma: testaajalla ei ole mitään tietoa siitä miten tulos on saatu.

Eli näin: ajetaan ohjelma prosessorilla A, ohjelma antaa tulokseksi numeron X. Ajetaan ohjelma prosessorilla B, ohjelma antaa tulokseksi numeron Y.

Miten X ja Y on saatu, on lähes aina mysteeri.

Ei koti/toimistokäytössä, tärkeämpää serveripuolella jossa konesalien jäähdytys on merkittävä kustannus.

Höpö höpö. Ei todellakaan ole yhtään millään tavalla merkittävä kustannus. Jos niin olisi, kukaan ei olisi ostanut esim. Intel Prescottin kaltaisia kiukaita.

 

[Marco Polo]

Huoh! Kaikki ohjelmat jotka oli Intelin kääntäjällä käännetty, automaattisesti kusetti. Ei ollu väliä kuka ne testit teki.

Sopivasti jätit vastaamatta 90% kirjoittamiini kohtiini. Ehkäpä juuri siksi, että tiedät minun olevan oikeassa ja sinun AMD-fanin olevan väärässä.

1)
Tuo "pikku juttu" koski aika suurta osaa ohjelmista Lisäksi käytännössä aina se mitä pystytään todistamaan on hyvin pieni osa kaikesta.


2)
Millä hitolla todistat nykypäivän benchmarkkien olevan "luotettavia"? Lähes kaikissa on sama ongelma: testaajalla ei ole mitään tietoa siitä miten tulos on saatu.

Eli näin: ajetaan ohjelma prosessorilla A, ohjelma antaa tulokseksi numeron X. Ajetaan ohjelma prosessorilla B, ohjelma antaa tulokseksi numeron Y.

Miten X ja Y on saatu, on lähes aina mysteeri.

1) Täysin naurettava väite logiikan näkökulmasta. Väität että aina se mitä pystytään todistamaan on hyvin pieni osa kaikesta. Eli jos et ymmärtänyt niin mistä tiedät, että se mitä pystytään todistamaan on pieni osa kaikesta, jos et pysty sitä todistamaan esimerkiksi benchmarkeissa? Teillä AMD-faneilla tämä logiikan puute perusteluissa on kyllä hyvin yleistä.

2) Asia menee niin päin, että jos sinä väität että ne eivät ole luotettavia niin sinun pitää se todistaa. Niin se menee aina kun kyse on siitä onko jossain huijattu. Teiltä AMD-faneilta näitä huijaus todisteita tämän päivän benchmarkeista on tosin turha pyytää, kun niitä ei koskaan saa. Pelkästään epämääräisiä syytöksiä perustuen siihen, että joskus ikuisuus sitten on pieni tapaus ollut ja sen perusteella luullaan, että tänäpäivänäkin kaikki testit ja benchmarkit huijaa, koska oma rakas amd ottaa niissä turpaan inteliltä ja nvidialta kuin viimeistä päivää.

Sinun ymmärrykselle se voi olla mysteeri miten X ja Y on voitu saada, mutta se ei tarkoita että se olisi sitä kaikille muillekkin.

 

[Threadripper]

1) Täysin naurettava väite logiikan näkökulmasta. Väität että aina se mitä pystytään todistamaan on hyvin pieni osa kaikesta. Eli jos et ymmärtänyt niin mistä tiedät, että se mitä pystytään todistamaan on pieni osa kaikesta, jos et pysty sitä todistamaan esimerkiksi benchmarkeissa? Teillä AMD-faneilla tämä logiikan puute perusteluissa on kyllä hyvin yleistä.

Tämähän on hyvin helppo todistaa:

Otetaan lähes mikä vaan prosessoritesti. Halutaan tietää ovatko kyseisen testin benchmarkit Inteliä suosivia vai ei.

Ensimmäisenä voisi tarkastaa onko ohjelmassa jotain prosessorintunnistusta joka aiheuttaa koodin erilaisen suorittamisen Intelillä. Tämä on helppo testata. Otetaan AMD:n prosessori johon muutetaan valmistajan koodit ja näin AMD:n prosessori esittäytyy Intelinä. Hyvin helppoa ja yksinkertaista paitsi että AMD:lla ei ole julkisessa jakelussa yhtäkään prosessoria jossa niin voisi tehdä.

Seuraavaksi voisi tarkistaa onko ohjelma ajettu tasapuolisilla kääntäjällä ja kääntäjäasetuksilla. Tämäkin on helppoa. Otetaan ohjelman lähdekoodi, tasapuolinen kääntäjä, laitetaan tasapuoliset asetukset, käännetään ohjelma ja ajetaan ohjelma. Hyvin helppoa ja yksinkertaista paitsi että useimpien benchmarkkien lähdekoodit eivät ole julkisia.

Ts. vaikka olisi kuinka selvä tapaus (ohjelma suosii tiettyä valmistajaa), sen todistaminen on useimmissa tapauksissa täysin mahdotonta.

2) Asia menee niin päin, että jos sinä väität että ne eivät ole luotettavia niin sinun pitää se todistaa. Niin se menee aina kun kyse on siitä onko jossain huijattu. Teiltä AMD-faneilta näitä huijaus todisteita tämän päivän benchmarkeista on tosin turha pyytää, kun niitä ei koskaan saa. Pelkästään epämääräisiä syytöksiä perustuen siihen, että joskus ikuisuus sitten on pieni tapaus ollut ja sen perusteella luullaan, että tänäpäivänäkin kaikki testit ja benchmarkit huijaa, koska oma rakas amd ottaa niissä turpaan inteliltä ja nvidialta kuin viimeistä päivää.

Sinun ymmärrykselle se voi olla mysteeri miten X ja Y on voitu saada, mutta se ei tarkoita että se olisi sitä kaikille muillekkin.

Höpö höpö. Tuossa ylempänä jo osoitin pitävästi että suurinta osaa tällaisista asioista on mahdoton todistaa. Tuo PC Mark05 huijaushan on mitä parhain esimerkki. Todella moni sivusto sanoi tulosten perusteella testin suosivan Inteliä. Vaan milläs sen todistat? Eli arvostetutkin sivustot epäilevät ohjelman suosivan Inteliä vaikkeivät sitä voi mitenkään todistaa. Ts. vaatimuksesi todistustaakasta sun muusta ei näissä asioissa päde.

Ilman tarkkaa tietoa ohjelman toiminnasta (lähdekoodi tai suorituksen hyvin tarkka tutkiminen) on lähes pelkästään arvailua miten X ja Y on saatu.

 

[Deleted member 4604]

Ne Intelin kääntäjällä käännetyt ohjelmat voi erittäin helposti pätsätä sen dispatcherin osalta, mikäli sille näkee tarvetta.
Helpoin tapa on vaihtaa "AuthenticAMD" ja "GenuineIntel" tekstit binäärissä päikseen, jossei halua muuttaa yhdeksää CMP käskyä TEST 0 käskyiksi.

Tuon toimivuuden voi helposti testata vaikka sillä ainoalla itselle vastaan tulleella (muinaisella) testiohjelmalla, jossa AMD:n käyttämä koodipolku on rampautettu (Caselab Euler3D Stars).

Nykyisetkin Intelin kääntäjäversiot lisää sen dispatcherin siihen binääriin, vaikka koodi olisi käännetty geneerisillä optioilla (esim. /arch:AVX2).
Vaihtoehtoisen Intelille optimoidun koodipolun lisääminen binääriin (esim. QaxCORE-AVX2 optio) ei myöskään rampauta suorituskykyä AMD:n prosessoreilla.
Jos ohjelma optimoidaan varta vasten Intelin prosessoreille (QxCORE-AVX2 optio), se ei käynnisty muilla kuin Intelin prosessoreilla.

Intelin kääntäjä on keksimääriin nopein tarjolla oleva kääntäjä, myös Ryzenille.
AMD on jo vuosia käyttänyt sitä muun muassa näytönohjainajuriensa sekä tiettyjen matematiikkakirjastojen kääntämiseen.

 

[HEDT]

Intelin kääntäjä on keksimääriin nopein tarjolla oleva kääntäjä, myös Ryzenille.
AMD on jo vuosia käyttänyt sitä muun muassa näytönohjainajuriensa sekä tiettyjen matematiikkakirjastojen kääntämiseen.

Eli AMD: llä on (pitäisi olla) myös oma kääntäjänsä?

Vaatimus vaan tuntuu joillain olevan: Intellin kääntäjä pitäisi optimoida AMD: lle.

 

[Marco Polo]

Nykyisetkin Intelin kääntäjäversiot lisää sen dispatcherin siihen binääriin, vaikka koodi olisi käännetty geneerisillä optioilla (esim. /arch:AVX2).
Vaihtoehtoisen Intelille optimoidun koodipolun lisääminen binääriin (esim. QaxCORE-AVX2 optio) ei myöskään rampauta suorituskykyä AMD:n prosessoreilla.
Jos ohjelma optimoidaan varta vasten Intelin prosessoreille (QxCORE-AVX2 optio), se ei käynnisty muilla kuin Intelin prosessoreilla.

Intelin kääntäjä on keksimääriin nopein tarjolla oleva kääntäjä, myös Ryzenille.
AMD on jo vuosia käyttänyt sitä muun muassa näytönohjainajuriensa sekä tiettyjen matematiikkakirjastojen kääntämiseen.

Juurikin näin. Jopa AMD itse käyttää Intelin kääntäjää, kun tietää sen olevan kenties paras mitä on saatavilla. Olisi aika naurettavaa väittää, että jos Intel kääntäjä tahalleen rampauttaisi konekielelle käännetyn ohjelman AMD:n prosessoreilla niin että AMD vielä itse käyttäisi heidän kääntäjäänsä.

Kaikenmailman järjenvastaisia ja perusteettomia syytöksiä täällä on ollut Intel salaliitoista milloin koskien kääntäjää ja milloin benchmark ohjelmia ja milloin koko tuloksien päästä vääristelyä. Jostain syystä muutama harva käyttäjä ei vain voi myöntää Intelin olevan nopeampi esimerkiksi peliprossujen puolella niin pitää tuoda kaikenmaailman epämääräisiä ja perusteettomia syytöksiä tämän päivän testien vääristelyistä.

 

[Threadripper]

Ne Intelin kääntäjällä käännetyt ohjelmat voi erittäin helposti pätsätä sen dispatcherin osalta, mikäli sille näkee tarvetta.
Helpoin tapa on vaihtaa "AuthenticAMD" ja "GenuineIntel" tekstit binäärissä päikseen, jossei halua muuttaa yhdeksää CMP käskyä TEST 0 käskyiksi.

Tuon toimivuuden voi helposti testata vaikka sillä ainoalla itselle vastaan tulleella (muinaisella) testiohjelmalla, jossa AMD:n käyttämä koodipolku on rampautettu (Caselab Euler3D Stars).

Nykyisetkin Intelin kääntäjäversiot lisää sen dispatcherin siihen binääriin, vaikka koodi olisi käännetty geneerisillä optioilla (esim. /arch:AVX2).
Vaihtoehtoisen Intelille optimoidun koodipolun lisääminen binääriin (esim. QaxCORE-AVX2 optio) ei myöskään rampauta suorituskykyä AMD:n prosessoreilla.
Jos ohjelma optimoidaan varta vasten Intelin prosessoreille (QxCORE-AVX2 optio), se ei käynnisty muilla kuin Intelin prosessoreilla.

Intelin kääntäjä on keksimääriin nopein tarjolla oleva kääntäjä, myös Ryzenille.
AMD on jo vuosia käyttänyt sitä muun muassa näytönohjainajuriensa sekä tiettyjen matematiikkakirjastojen kääntämiseen.

Tuo vaihtotemppu toimii ehkä nykyisin, muttei toiminut aikaisemmin (tai porukka ei osannut).

Vaikka AMD käyttää Intelin kääntäjää, sehän ei millään tavalla tarkoita Intelin kääntäjän olevan AMD:lle lähellekään paras mahdollinen. Vaihtoehdotkin ovat vähissä. Toki AMD voisi kehittää oman kääntäjän (ja taitavat sellaista tehdäkin), mutta rahaa tarvitaan muualla enemmän. Rampauttaa ja tehdä optimaalista koodia ovat loppujen lopuksi täysin eri asioita.

Eli AMD: llä on (pitäisi olla) myös oma kääntäjänsä?

Vaatimus vaan tuntuu joillain olevan: Intellin kääntäjä pitäisi optimoida AMD: lle.

Ei auta paljoakaan vaikka AMD:lla olisi oma kääntäjä joka tekisi nopeampaa koodia kuin Intelin kääntäjä. Ohjelmat pitäisi myös kääntää sillä AMD:n kääntäjällä.

Ihan sidenotena: mitä olen benchmarkkeja katsellut, AMD pärjää keskimäärin paljon paremmin Linux benchmarkeissa kuin Windows benchmarkeissa. Johtuisikohan siitä että useat Linux benchmarkit käännetään AMD:lle sopivilla asetuksilla ja Windows puolella ei...

Juurikin näin. Jopa AMD itse käyttää Intelin kääntäjää, kun tietää sen olevan kenties paras mitä on saatavilla. Olisi aika naurettavaa väittää, että jos Intel kääntäjä tahalleen rampauttaisi konekielelle käännetyn ohjelman AMD:n prosessoreilla niin että AMD vielä itse käyttäisi heidän kääntäjäänsä.

Kaikenmailman järjenvastaisia ja perusteettomia syytöksiä täällä on ollut Intel salaliitoista milloin koskien kääntäjää ja milloin benchmark ohjelmia ja milloin koko tuloksien päästä vääristelyä. Jostain syystä muutama harva käyttäjä ei vain voi myöntää Intelin olevan nopeampi esimerkiksi peliprossujen puolella niin pitää tuoda kaikenmaailman epämääräisiä ja perusteettomia syytöksiä tämän päivän testien vääristelyistä.

Rampauttaminen ja optimaalisen nopean koodin tekeminen ovat eri asioita. Noita x86 kääntäjiä ei paljoa ole, Microsoft taitaa olla Intelin lisäksi sellainen jota iso taho kehittää jatkuvasti. Varmuuden vuoksi: Intel ja Microsoft eivät ole hyviä kavereita keskenään.

Perusteitahan tässä on tuotu aika paljon. Tämä hommahan menee aina seuraavasti: kun väitetään Intelin huijaavan, tietyt ninimerkit selittävät ettei ole todisteita. Kun pitäviä todisteita saadaan, niillä ei ole merkitystä koska ne asiat ovat tapahtuneet vuosia sitten eikä tämän hetken asioista ole todisteita. Kun niitä vuosien päästä saadaan, selitetään kuinka niillä ei ole merkitystä koska vanhoja eikä tämän hetken asioita ole todisteita. Piiri pieni pyörii.

Ihan aluksi voisit vaikka selittää tuon Linux asian. Miksi AMD pärjää keskimäärin selvästi paremmin Linux benchmarkeissa jotka on käännetty AMD:lle sopivilla asetuksilla kuin Windows puolella jossa lähdekoodit hyvin harvoin ovat julkisia ja siten kääntäjät (ja niiden asetukset) voivat olla ihan mitä tahansa?

Lisäksi on täysin turha selittää etteikö monissa peleissä olisi jotain pahasti vialla. Esimerkiksi näin: Rise of the Tomb Raider Gets a Ryzen Performance Update | PC Perspective

Pikkupatsi peliin ja 17% lisää nopeutta Ryzenille (2% Intelille). Se vastaa karkeasti vaihtoa Sandy Bidgestä Broadwelliin (olettaen samat kellotaajuudet)

 

[L2K2]

Tuo vaihtotemppu toimii ehkä nykyisin, muttei toiminut aikaisemmin (tai porukka ei osannut).

Vaikka AMD käyttää Intelin kääntäjää, sehän ei millään tavalla tarkoita Intelin kääntäjän olevan AMD:lle lähellekään paras mahdollinen. Vaihtoehdotkin ovat vähissä. Toki AMD voisi kehittää oman kääntäjän (ja taitavat sellaista tehdäkin), mutta rahaa tarvitaan muualla enemmän. Rampauttaa ja tehdä optimaalista koodia ovat loppujen lopuksi täysin eri asioita.

Ei auta paljoakaan vaikka AMD:lla olisi oma kääntäjä joka tekisi nopeampaa koodia kuin Intelin kääntäjä. Ohjelmat pitäisi myös kääntää sillä AMD:n kääntäjällä.

Ihan sidenotena: mitä olen benchmarkkeja katsellut, AMD pärjää keskimäärin paljon paremmin Linux benchmarkeissa kuin Windows benchmarkeissa. Johtuisikohan siitä että useat Linux benchmarkit käännetään AMD:lle sopivilla asetuksilla ja Windows puolella ei...



Rampauttaminen ja optimaalisen nopean koodin tekeminen ovat eri asioita. Noita x86 kääntäjiä ei paljoa ole, Microsoft taitaa olla Intelin lisäksi sellainen jota iso taho kehittää jatkuvasti. Varmuuden vuoksi: Intel ja Microsoft eivät ole hyviä kavereita keskenään.

Perusteitahan tässä on tuotu aika paljon. Tämä hommahan menee aina seuraavasti: kun väitetään Intelin huijaavan, tietyt ninimerkit selittävät ettei ole todisteita. Kun pitäviä todisteita saadaan, niillä ei ole merkitystä koska ne asiat ovat tapahtuneet vuosia sitten eikä tämän hetken asioista ole todisteita. Kun niitä vuosien päästä saadaan, selitetään kuinka niillä ei ole merkitystä koska vanhoja eikä tämän hetken asioita ole todisteita. Piiri pieni pyörii.

Ihan aluksi voisit vaikka selittää tuon Linux asian. Miksi AMD pärjää keskimäärin selvästi paremmin Linux benchmarkeissa jotka on käännetty AMD:lle sopivilla asetuksilla kuin Windows puolella jossa lähdekoodit hyvin harvoin ovat julkisia ja siten kääntäjät (ja niiden asetukset) voivat olla ihan mitä tahansa?

Lisäksi on täysin turha selittää etteikö monissa peleissä olisi jotain pahasti vialla. Esimerkiksi näin: Rise of the Tomb Raider Gets a Ryzen Performance Update | PC Perspective

Pikkupatsi peliin ja 17% lisää nopeutta Ryzenille (2% Intelille). Se vastaa karkeasti vaihtoa Sandy Bidgestä Broadwelliin (olettaen samat kellotaajuudet)

Ei Intelin kääntäjä ole (aina) edes Intelin prosessoreille paras mahdollinen. Ainakin Linux-puolella olen saanut joissain tapauksissa gcc:llä aikaan hieman nopeampaa koodia. Toki Intelin kääntäjä tuntuu olevan keskimäärin älyttömän hyvä ja joissain tapauksissa ihan tolkuttoman paljon parempi kuin kilpailijansa (kaikki käännöt tasan kyseiselle prosessoriarkkitehtuurille, ja koodia, jossa AVX2 käskykantalaajennokset pääsevät vauhtiin). Toki Intelin kääntäjä taitaa olla tällä hetkellä se keskimäärin nopein kääntäjä kummankin valmistajan prosessoreille. Joten, jos kummallekin prosessorille käytetään sille optimaalista kääntäjää, niin kääntäjävalinta on ”icc”. Pulinat pois, jos ei ole parempaa, niin sitten vertailu on ihan reilu: koska niiden nopeustestien lisäksi myös se oikean maailman koodi käännetään noilla samoilla kääntäjillä.

Jos AMD:llä olisi selvästi parempi kääntäjä, niin kyllä sitä koodia alettaisiin hiljalleen ehkä sillä kääntää.. ainakin niissä kohdin jossa tuo oikeasti vaikuttaisi suorituskykyyn (ja jos kääntäjä olisi vieläpä edes lähes plug-and-play -yhteensopiva). Jos taas erot kääntäjien välillä on enemmän ns. akateemisia, niin käy kuten Googlen Chromen kanssa (joka käännetään nykyään myös Windows-puolella clang:illa vaikka clang on yleensä edelleen selvästi hitaampi kuin kilpailijansa).

Ainakin HEDT-alustoilla Linux-puolella AMD pärjännee paremmin koska se käyttöjärjerjestelmän ydin sattuu olemaan oleellisesti parempi tietyntyyppisessä monen ytimen kuorman jakamisessa (NUMA..). Tähän lienee syynä ihan se, että raskaasta laskennasta aika iso osa nyt sattuu olemaan Linux-puolella, joten myös ne optimoinnit on sinne puolelle.

Nuo päivitys peliin ja paljon nopeutta AMD:llä kertovat vaan enemmän siitä, että Ryzen on tietyntyyppisessä kuormassa hidas... esim. ne muistilatenssit... Intelin prosessorit nyt sattuvat olemaan vaan tasaisen nopeita, ja kun Ryzen on vielä verrattain tuore ja pienellä markkinaosuudella, niin... Tuossa päivityksessä siis tasattiin työjakoa säikeiden välillä (mikä siis auttoi pääosin vain AMD alustalla, Intelin prosessorit olivat nopeita jopa sillä hieman epätasaisemmalla kuorman jaollakin – irvileuka sanoisi: eli parempia prosessoreita ;-).

 

[Threadripper]

Samaa mieltä kokonaiskuvasta @Threadripper kanssa. Onneksi nyt Ryzenin valtakaudella tullemme näkemään miten pelien ja ohjelmien toimintaa tehostetaan Ryzen edellä. Tämä on vain hyväksi kaikille, sillä sehän tarkoittaa ohjelmien säikeistämistä mitä tarvitaan tulevaisuudessa yhä enemmän. Oma mielipide on että Intelin suunta ohjelmoinnin saralla on paljon hitaampi suunta kehityksessä ja jarruttaa siksi sitä, että voitaisiin lypsää hitaasti vähällä vaivalla asiakkailta rahaa. Toisaalta onhan Intel parannellut virrankulutusta jo pitkään, mutten ymmärrä mitä järkeä on erityisesti tukea tällaista etanan vauhdilla etenemistä.

Parasta on että saadaan maailmalle sitä laskentatehoa reilusti enemmän, mikä tulee luonnollisesti lukuisten suoritinytimien muodossa, jotta voidaan sairauksia ja muita peitota, joiden voittamisessa tarvitaan välillisesti myös tehokkaita suorittimia. Pohtiessa miten moni asia palvelimista alkaen on tänä päivänä suorittimesta riippuvainen ja etenkin suoritinmarkkinasta, on todettava Intelin kehityksen olleen varsin kielteistä jo vuosien ajan. Voi tosin todeta että AMD ei ole ollut tarpeeksi pätevä tarjotakseen asianmukaista kilpailua, mutta me tiedämme menneestä miten pahasti Intel on häirinnyt kilpailijansa toimintaa laittomalla ja paheksuttavalla toiminnalla.

On meidän kaikkien ja laajemmin koko maailman onni että Intelin pitää nyt aidosti kehittää kunnollista tuotetta ja ei missään tapauksessa niin että kampitetaan kilpailijaa. Näin vertauskuvana, esittääkseen yleisölle mahdollisimman näyttävän ja ihailtavan urheilusuorituksen, ei urheilijan tule kampittaa vastustajaa vaan kilpailla rehdisti. Paras voittakoon, ei voitto pelkän voiton tähden ole voitto ollenkaan. Omassa päässänsä tämän sortin urheilija voi olla voittaja, muttei koskaan yleisön silmissä. Onneksi jokainen saa useimmiten uuden mahdollisuuden ja niin toivon myös Intelin aloittavan todellisen ahkeroinnin ja panostavan parhaaseen mahdolliseen tuotteeseen, jonka asiakas todella haluaa omistaa.

Osasyy Intelin hitaaseen kehitykseen on sama miksi Ryzen muistuttaa kovasti Intelin prosessoreita: jos Intel vaihtaa arkkitehtuuria radikaalisti, se kohtaa saman ongelman kuin Pentium 4:n kanssa ja jonka AMD kohtasi Bulldozerissa: ohjelmistopuoli laahaa yleisellä tasolla karkeasti vuosikymmenen jäljessä rautaa ja kestää todella kauan jotta uudesta parannuksesta arkkitehtuuriin, sinänsä järkevästä, saadaan kunnolla hyötyä ohjelmissa. Kun tehdään vain pieniä viilauksia arkkitehtuuriin, vältytään ongelmalta jossa ohjelmien pitäisi olla radikaalisti erilaisia.

Joten en usko Inteliltä enkä myöskään AMD:lta ihan heti tulevan kovinkaan radikaalia uudistusta nykyprosessoreihin.

Ei Intelin kääntäjä ole (aina) edes Intelin prosessoreille paras mahdollinen. Ainakin Linux-puolella olen saanut joissain tapauksissa gcc:llä aikaan hieman nopeampaa koodia. Toki Intelin kääntäjä tuntuu olevan keskimäärin älyttömän hyvä ja joissain tapauksissa ihan tolkuttoman paljon parempi kuin kilpailijansa (kaikki käännöt tasan kyseiselle prosessoriarkkitehtuurille, ja koodia, jossa AVX2 käskykantalaajennokset pääsevät vauhtiin). Toki Intelin kääntäjä taitaa olla tällä hetkellä se keskimäärin nopein kääntäjä kummankin valmistajan prosessoreille. Joten, jos kummallekin prosessorille käytetään sille optimaalista kääntäjää, niin kääntäjävalinta on ”icc”. Pulinat pois, jos ei ole parempaa, niin sitten vertailu on ihan reilu: koska niiden nopeustestien lisäksi myös se oikean maailman koodi käännetään noilla samoilla kääntäjillä.

Jos AMD:llä olisi selvästi parempi kääntäjä, niin kyllä sitä koodia alettaisiin hiljalleen ehkä sillä kääntää.. ainakin niissä kohdin jossa tuo oikeasti vaikuttaisi suorituskykyyn (ja jos kääntäjä olisi vieläpä edes lähes plug-and-play -yhteensopiva). Jos taas erot kääntäjien välillä on enemmän ns. akateemisia, niin käy kuten Googlen Chromen kanssa (joka käännetään nykyään myös Windows-puolella clang:illa vaikka clang on yleensä edelleen selvästi hitaampi kuin kilpailijansa).

Määrittele parempi. Jos AMD:lla olisi kääntäjä joka tekee AMD:n prosessoreille selvästi nopeampaa koodia, miksi pitäisi käyttää Intelin kääntäjää? Jotta Intel pärjäisi mahdollisimman hyvin?

Aivan, se ei ole reilu tilanne jos yhden prosessorivalmistajan kääntäjää käytetään toisen prosessorivalmistajan prosessorien kanssa.

Ainakin HEDT-alustoilla Linux-puolella AMD pärjännee paremmin koska se käyttöjärjerjestelmän ydin sattuu olemaan oleellisesti parempi tietyntyyppisessä monen ytimen kuorman jakamisessa (NUMA..). Tähän lienee syynä ihan se, että raskaasta laskennasta aika iso osa nyt sattuu olemaan Linux-puolella, joten myös ne optimoinnit on sinne puolelle.

Nuo päivitys peliin ja paljon nopeutta AMD:llä kertovat vaan enemmän siitä, että Ryzen on tietyntyyppisessä kuormassa hidas... esim. ne muistilatenssit... Intelin prosessorit nyt sattuvat olemaan vaan tasaisen nopeita, ja kun Ryzen on vielä verrattain tuore ja pienellä markkinaosuudella, niin... Tuossa päivityksessä siis tasattiin työjakoa säikeiden välillä (mikä siis auttoi pääosin vain AMD alustalla, Intelin prosessorit olivat nopeita jopa sillä hieman epätasaisemmalla kuorman jaollakin – irvileuka sanoisi: eli parempia prosessoreita ;-).

Tuo Linux-homma pätee myös Ryzeneihin ja FX-prosessoreihin jolloin NUMA ei yksinään kelpaa selityksestä.

Miksi kaikissa peleissä ei ole samaa ongelmaa? Ettei vaan olisi peliin tehty työnjako (ehkä ohittaen Windowsin schedulerin?) joka sopi vain tietynlaisille prosessoreille hyvin ja muunlaisilla toimi surkeasti? Myös Intel sai nopeutta lisää samoiilla muutoksilla joten eipä Intelkään täydellinen ollut.

 

[vemkki]

Anandtech oli saanut käsiinsä läppärin, jossa on tämä myyttinen Intelin 10 nm Cannon Lake -prosessori i3-8121U:
Intel's 10nm Cannon Lake and Core i3-8121U Deep Dive Review
Käytännössä AVX-512-suorituskyky on hyvä, ja samalla kellotaajuudella tuo on suorituskyvyltään samaa luokkaa i3-8130U:n kanssa, mutta i3-8130U turboaa paljon korkeammalle ja tietysti i3-8121U tarvitsee ulkoisen näytönohjaimen. Anandtech arveleekin, että prosessori on julkaistu vain ja ainoastaan siksi, että voidaan sijoittajille väittää 10 nm prosessorien olevan myynnissä, kun itse tuotteessa ei ole mitään järkeä.

Tuo juttu on muutenkin mielenkiintoinen. Siinä kerrotaan myös 14 nm prosessin alkuvaiheiden ongelmista.

Toivottavasti Ice Lake saadaan markkinoille suunnitellulla aikataululla.

 

[Marco Polo]

Perusteitahan tässä on tuotu aika paljon. Tämä hommahan menee aina seuraavasti: kun väitetään Intelin huijaavan, tietyt ninimerkit selittävät ettei ole todisteita. Kun pitäviä todisteita saadaan, niillä ei ole merkitystä koska ne asiat ovat tapahtuneet vuosia sitten eikä tämän hetken asioista ole todisteita. Kun niitä vuosien päästä saadaan, selitetään kuinka niillä ei ole merkitystä koska vanhoja eikä tämän hetken asioita ole todisteita. Piiri pieni pyörii.


Ihan aluksi voisit vaikka selittää tuon Linux asian. Miksi AMD pärjää keskimäärin selvästi paremmin Linux benchmarkeissa jotka on käännetty AMD:lle sopivilla asetuksilla kuin Windows puolella jossa lähdekoodit hyvin harvoin ovat julkisia ja siten kääntäjät (ja niiden asetukset) voivat olla ihan mitä tahansa?

Lisäksi on täysin turha selittää etteikö monissa peleissä olisi jotain pahasti vialla. Esimerkiksi näin: Rise of the Tomb Raider Gets a Ryzen Performance Update | PC Perspective

Ensinnäkään mistään sinun väittämästä "Intelin nykyisestä huijauksesta" ei ole mitään todisteita. Ja tuo jälkimmäinen on myös täyttä spekulaatioita, että "joskus tultaisiin saamaan todisteita nykyisestä huijauksesta". Pysytään nyt faktoissa hei jooko?

Linux benchmarkit on ihan turhia ainakin pelipuolen keskusteluissa. Täysin turhaa spekuloida tuota tässä keskustelussa. Pelimaailma nyt kuitenkin kun on 99%:sti Windows puolella.

Ja yhden pelin performance update ei todista sitä, että muissakin peleissä olisi jotain pahasti vialla. Logiikan näkökulmasta järjetön väite.

Samaa mieltä kokonaiskuvasta @Threadripper kanssa. Onneksi nyt Ryzenin valtakaudella tullemme näkemään miten pelien ja ohjelmien toimintaa tehostetaan Ryzen edellä.

En jaksa edes kaikkiin kohtiisi lisätä vastausta, mutta otetaanpa tämä räikein esiin. Millä ihmeen Ryzenin valtakaudella? Intel edelleen dominoi AMD:tä vastaan esimerkiksi peliprossujen määrässä sekä Intelin paras markkinoilla oleva peliprossu on selvästi AMD:n paras peliprossua parempi. Ei kuulosta kovin kummoiselta Ryzenin "valtakaudelta" ainakaan minusta!

Ja turha toivoa että pelejä ja ohjelmistoja alettaisiin erikseen tehostaan Ryzen edellä. Ei niin ole tehty Intelinkään kohdalla, vaikka Intel on dominoinut jo pidemmän aikaa pelipuolella.

 

[Threadripper]

Ensinnäkään mistään sinun väittämästä "Intelin nykyisestä huijauksesta" ei ole mitään todisteita. Ja tuo jälkimmäinen on myös täyttä spekulaatioita, että "joskus tultaisiin saamaan todisteita nykyisestä huijauksesta". Pysytään nyt faktoissa hei jooko?

Linux benchmarkit on ihan turhia ainakin pelipuolen keskusteluissa. Täysin turhaa spekuloida tuota tässä keskustelussa. Pelimaailma nyt kuitenkin kun on 99%:sti Windows puolella.

Ja yhden pelin performance update ei todista sitä, että muissakin peleissä olisi jotain pahasti vialla. Logiikan näkökulmasta järjetön väite.

Tuossahan kerroin miten asia menee. Katsotaan muutaman vuoden päästä miten se asia oli. Silloin tiedetään faktat, ehkä. Nyt ei taatusti tiedetä.

Entäs pelimaailman ulkopuolelta? Kyllä sielläkin tehoa tarvitaan.

Yksi peli paikattiin ja siitä tuli todella iso suorituskykylisä. Monet muut pelit eivät ole saaneet vastaavaa päivitystä koska? 1. Peleissä ei ole mitään vikaa vai 2. Julkaisija "ei viitsi" tehdä päivitystä?

Pelimaailman tuntien vaihtoehto 2 on satavarmasti oikea.

En jaksa edes kaikkiin kohtiisi lisätä vastausta, mutta otetaanpa tämä räikein esiin. Millä ihmeen Ryzenin valtakaudella? Intel edelleen dominoi AMD:tä vastaan esimerkiksi peliprossujen määrässä sekä Intelin paras markkinoilla oleva peliprossu on selvästi AMD:n paras peliprossua parempi. Ei kuulosta kovin kummoiselta Ryzenin "valtakaudelta" ainakaan minusta!

Ja turha toivoa että pelejä ja ohjelmistoja alettaisiin erikseen tehostaan Ryzen edellä. Ei niin ole tehty Intelinkään kohdalla, vaikka Intel on dominoinut jo pidemmän aikaa pelipuolella.

Intelin peliprossu ei ole AMD:n peliprossua parempi, se vaan pyörittää paremmin nykyisiä pelejä joka on täysin eri asia.

Monet ns. suositut pelit, kuten PUBG, on Intelille optimoitu.

 

[L2K2]

Tuossahan kerroin miten asia menee. Katsotaan muutaman vuoden päästä miten se asia oli. Silloin tiedetään faktat, ehkä. Nyt ei taatusti tiedetä.

Entäs pelimaailman ulkopuolelta? Kyllä sielläkin tehoa tarvitaan.

Yksi peli paikattiin ja siitä tuli todella iso suorituskykylisä. Monet muut pelit eivät ole saaneet vastaavaa päivitystä koska? 1. Peleissä ei ole mitään vikaa vai 2. Julkaisija "ei viitsi" tehdä päivitystä?

Pelimaailman tuntien vaihtoehto 2 on satavarmasti oikea.



Intelin peliprossu ei ole AMD:n peliprossua parempi, se vaan pyörittää paremmin nykyisiä pelejä joka on täysin eri asia.

Monet ns. suositut pelit, kuten PUBG, on Intelille optimoitu.

”satavarmasti” :-D

Jos siellä olisi joku helposti korjattava suorituskyvyn rampauttava bugi, niin luultavasti se korjattaisiin. Jos ja kun taas vikana on se, että Ryzen on nirso sille kuorman tyypille (tai, siis, nirsompi kuin Intelin nykyprosessorit), niin sitten se korjaus ei välttämättä ole kovin helppo.

Pyörittää nykyisiä pelejä paremmin = on parempi peliprosessori vuonna 2019! Vai mitä vielä pitäisi vaatia?

Pelit optimoidaan yleensä sellaiselle raudalle, jota suurin osa käyttäjistä käyttää. (Ja lisäksi kuten tuon päivityksen kohdalla nähtiin, kyseessä ei niinkään ollut pelin optimointi Intel-alustalle, vaan Intel-alustan kyky sietää paremmin sitä ei-optimaalisen tasaista työjakoa eri säikeiden välillä. Parempi työjako nopeutti myös Intelin prosessorilla, joten voisi ennemmin sanoa, että tuota ei ollut loppuun asti optimoitu (koska Intelin parempi* prosessori ei sitä tarvinnut).)

* Lienee selvää, että jos toinen prosessori pärjää toista paremmin tyypillisessä, siis ei aina aivan ideaalisessa, kuormassa, niin se on parempi. Hinta-laatusuhde on sitten taas aivan eri asia. Siihen on ihan syynsä miksi ne Ryzenit on halvempia per ydin...

 

[Threadripper]

”satavarmasti” :-D

Jos siellä olisi joku helposti korjattava suorituskyvyn rampauttava bugi, niin luultavasti se korjattaisiin. Jos ja kun taas vikana on se, että Ryzen on nirso sille kuorman tyypille (tai, siis, nirsompi kuin Intelin nykyprosessorit), niin sitten se korjaus ei välttämättä ole kovin helppo.

Jaa että peleistä luultavasti korjataan helposti korjattavat bugit

Esimerkkinä vaikka ison budjetin peli Far Cry 2. Pelin kakkospatsin jälkeen toisen pelialueen kaikki nauhat tuottivat saman tarinan vaikka joka nauhasta pitäisi löytyä eri sisältö. Ongelmaa ei ollut ykköspatsissa. Jos tuo ei ole helppo korjata niin mikä sitten on? Korjattiinko? Ei ainakaan vielä ole korjattu...

Pyörittää nykyisiä pelejä paremmin = on parempi peliprosessori vuonna 2019! Vai mitä vielä pitäisi vaatia?

Parempi peliprosessori ja parempi peliprosessori vuonna 2019 ovat eri asioita. Vertaa vaikka joku i3 vs FX-8350 nyt ja 5 vuotta sitten.

Pelit optimoidaan yleensä sellaiselle raudalle, jota suurin osa käyttäjistä käyttää. (Ja lisäksi kuten tuon päivityksen kohdalla nähtiin, kyseessä ei niinkään ollut pelin optimointi Intel-alustalle, vaan Intel-alustan kyky sietää paremmin sitä ei-optimaalisen tasaista työjakoa eri säikeiden välillä. Parempi työjako nopeutti myös Intelin prosessorilla, joten voisi ennemmin sanoa, että tuota ei ollut loppuun asti optimoitu (koska Intelin parempi* prosessori ei sitä tarvinnut).)

* Lienee selvää, että jos toinen prosessori pärjää toista paremmin tyypillisessä, siis ei aina aivan ideaalisessa, kuormassa, niin se on parempi. Hinta-laatusuhde on sitten taas aivan eri asia. Siihen on ihan syynsä miksi ne Ryzenit on halvempia per ydin...

Intel optimoinnistahan siinä oli kyse koska työnjako oli tehty sopivaksi vain Intelin prosessorille. Monissa peleissä kuormanjakoa ei erityisesti tehdä millekään prosessorille (tai annetaan Windowsin hoitaa se) jolloin Ryzen ei erityisemmin kärsi. Ei tässäkään mitään epäselvää ole.

 

[SatanTwister]

Eipä tuossa enempää todisteita tarvita. Ei ole mitään syytä tarkistaa vendorID:tä jos prosessori ilmoittaa tukevansa käskykantaa. Tämä on sitä paitsi ikivanha juttu jo.
Agner`s CPU blog - Intel's "cripple AMD" function

Unfortunately, software compiled with the Intel compiler or the Intel function libraries has inferior performance on AMD and VIA processors. The reason is that the compiler or library can make multiple versions of a piece of code, each optimized for a certain processor and instruction set, for example SSE2, SSE3, etc. The system includes a function that detects which type of CPU it is running on and chooses the optimal code path for that CPU. This is called a CPU dispatcher. However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string. If the vendor string says "GenuineIntel" then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version.

 

[hkultala]

Eipä tuossa enempää todisteita tarvita. Ei ole mitään syytä tarkistaa vendorID:tä jos prosessori ilmoittaa tukevansa käskykantaa. Tämä on sitä paitsi ikivanha juttu jo.
Agner`s CPU blog - Intel's "cripple AMD" function

Niin, tämä oli tilanne yli 9 vuotta sitten.

Tästä seuranneen oikeusjutun seurauksena intel joutui poistamaan tämän jo kauan, kauan sitten

 

[SatanTwister]

Niin, tämä oli tilanne yli 9 vuotta sitten.

Tästä seuranneen oikeusjutun seurauksena intel joutui poistamaan tämän jo kauan, kauan sitten

Intel tuomittu rikollinen.

 

[hkultala]

Intel optimoinnistahan siinä oli kyse koska työnjako oli tehty sopivaksi vain Intelin prosessorille. Monissa peleissä kuormanjakoa ei erityisesti tehdä millekään prosessorille (tai annetaan Windowsin hoitaa se) jolloin Ryzen ei erityisemmin kärsi. Ei tässäkään mitään epäselvää ole.

Voi huoh minkä tason tuubaa taas tulee.

Tasainen kuormanjako säikeiden välillä olisi nopeampi myös intelillä. Sitä ei ole optimoitu siten, että siitä saataisiin maksimaalinen suorituskyky intelillä.

Sen optimointiin vaan ei ole jaksettu nähdä sitä älytöntä määrää vaivaa (ja tuotekehitysresursseja, rahaa, aikaa) mikä siihen tarvittaisiin.

Pelit halutaan myyntiin, että ne alkavat tuottaa rahaa niitä tekeville firmoille. Ennen kun peli on myynnissä, se ei tuota yhtään mitään, ja pelin kehittämisen viivästyttäminen tai pelin julkaiseminen bugisena vain sen takia, että siitä se pyörisi hiukan nopeammin olisi yleensä todella typerää.

Suosittelen muuten tutustumaan peliprojektiin nimeltä "duke nukem forever", joka oli hyvin nimensä veroinen tuotekehitysajaltaan.

 

[Marco Polo]

Tuossahan kerroin miten asia menee. Katsotaan muutaman vuoden päästä miten se asia oli. Silloin tiedetään faktat, ehkä. Nyt ei taatusti tiedetä.


Yksi peli paikattiin ja siitä tuli todella iso suorituskykylisä. Monet muut pelit eivät ole saaneet vastaavaa päivitystä koska? 1. Peleissä ei ole mitään vikaa vai 2. Julkaisija "ei viitsi" tehdä päivitystä?

Pelimaailman tuntien vaihtoehto 2 on satavarmasti oikea.



Intelin peliprossu ei ole AMD:n peliprossua parempi, se vaan pyörittää paremmin nykyisiä pelejä joka on täysin eri asia.

Kuten jo moni muukin sinulle sanoi niin melkoista tuubaa nyt vaihteeksi kirjoitit. Kirjoitat sinun kuvitelmia faktoina.

 

[sushukka]

”satavarmasti” :-D

Jos siellä olisi joku helposti korjattava suorituskyvyn rampauttava bugi, niin luultavasti se korjattaisiin. Jos ja kun taas vikana on se, että Ryzen on nirso sille kuorman tyypille (tai, siis, nirsompi kuin Intelin nykyprosessorit), niin sitten se korjaus ei välttämättä ole kovin helppo.

Pyörittää nykyisiä pelejä paremmin = on parempi peliprosessori vuonna 2019! Vai mitä vielä pitäisi vaatia?

Pelit optimoidaan yleensä sellaiselle raudalle, jota suurin osa käyttäjistä käyttää. (Ja lisäksi kuten tuon päivityksen kohdalla nähtiin, kyseessä ei niinkään ollut pelin optimointi Intel-alustalle, vaan Intel-alustan kyky sietää paremmin sitä ei-optimaalisen tasaista työjakoa eri säikeiden välillä. Parempi työjako nopeutti myös Intelin prosessorilla, joten voisi ennemmin sanoa, että tuota ei ollut loppuun asti optimoitu (koska Intelin parempi* prosessori ei sitä tarvinnut).)

* Lienee selvää, että jos toinen prosessori pärjää toista paremmin tyypillisessä, siis ei aina aivan ideaalisessa, kuormassa, niin se on parempi. Hinta-laatusuhde on sitten taas aivan eri asia. Siihen on ihan syynsä miksi ne Ryzenit on halvempia per ydin...

No eiköhän nämä samat latenssiongelmat, chipletit yms. ala pian olla myös Intelin prossujen ongelmia. Kellotaajuudessa ollaan saavuttamassa jonkunlaista kattoa joten laskentatehon lisääminen täytyy tehdä horisontaalisesti ytimiä lisäämällä. Kaikkien ytimien tunkeminen samalle piilastulle taas tulee kalliiksi ja Intel todennäköisesti painii juurikin monoliittisen arkkitehtuurinsa kanssa parasta aikaa. Jotain huhuja on jo ollut että sininen lähtisi myös tuohon chiplet-tyyppiseen malliin.

IPC:n parantamisessa kellotaajuuden nosto alkaa siis olla pian käytetty. Käsky/haarautumisennustuksissa taas noi spectret yms. ovat nyt iskeneet omalta osaltaan näpeille. @hkultala varmaan osaa kertoa tarkemmin mitä merkittäviä nopeutuskikkoja on vielä nähtävissä (AVX tms), mutta tuo ydinten määrän lisääminen lienee kumminkin se varmin asia mitä tullaan näkemään lähitulevaisuudessa. Toki sovelluspuolella niiden ydinten hyödyntäminen onkin sitten usein aika perhananmoinen haaste, eikä aina ole edes (järkevällä työmäärällä) mahdollista.

ARM-puolella on suht.normaalia että samassa paketissa on eri nopeuksisia ytimiä esim. 4x2,5GHz ja 4x1,6GHz. Virransäästö varmaan tärkeimpänä, mutta kysymys kuuluukin että olisiko tämä mitenkään realistinen tai järkevä skenaario työpöytäpuolelle? Tyyliin pari aina jokseenkin varmasti 5GHz-kellotaajuudella pyörivää ydintä ja kasa hitaampia kaverina lämpökuorman sallimissa puitteissa. Tavallaanhan nuo turbot, AVX:t yms. mahdollistavat jo nyt tällaisen vaihtelevan jaon, mutta silti se maksimikellotaajuus koko piirillä tippuu kun lämpöä alkaa tulla. Miten siis peleissä jossa ns. pääsäie ja vaikka viisi kevyempää, olisiko tällaisessa hyötyä että olisi tavallaan taattu nopea ydin jossain? Ja jos asian laajentaa AMD:n chipletteihin, niin olisiko ideaa että olisi yhdessä chipletissä muutama nopea ydin ja sitten useampi hitaampi erillisessä? Entäs jos nämä eriytettäisiin kokonaan? Paremmin jäähdytetty nopea socketti ja heikommin jäähdytetty suurta rinnakkaisuutta tarjoava? Tässä spekuloinnissa on joo reikiä monessa kohtaa, mutta kunhan nyt maalaisjärjellä ideoin.

 

[Threadripper]

Eipä tuossa enempää todisteita tarvita. Ei ole mitään syytä tarkistaa vendorID:tä jos prosessori ilmoittaa tukevansa käskykantaa. Tämä on sitä paitsi ikivanha juttu jo.
Agner`s CPU blog - Intel's "cripple AMD" function

Ei siihen olekaan mitään järkevää syytä ja silti sitä tehtiin

Niin, tämä oli tilanne yli 9 vuotta sitten.

Tästä seuranneen oikeusjutun seurauksena intel joutui poistamaan tämän jo kauan, kauan sitten

Niin onkin ja TUON Intel joutui poistamaan kauan sitten. Mitä muuta siellä on, voidaan toistaiseksi lähinnä arvailla.

Voi huoh minkä tason tuubaa taas tulee.

Tasainen kuormanjako säikeiden välillä olisi nopeampi myös intelillä. Sitä ei ole optimoitu siten, että siitä saataisiin maksimaalinen suorituskyky intelillä.

Sen optimointiin vaan ei ole jaksettu nähdä sitä älytöntä määrää vaivaa (ja tuotekehitysresursseja, rahaa, aikaa) mikä siihen tarvittaisiin.

Pelit halutaan myyntiin, että ne alkavat tuottaa rahaa niitä tekeville firmoille. Ennen kun peli on myynnissä, se ei tuota yhtään mitään, ja pelin kehittämisen viivästyttäminen tai pelin julkaiseminen bugisena vain sen takia, että siitä se pyörisi hiukan nopeammin olisi yleensä todella typerää.

Suosittelen muuten tutustumaan peliprojektiin nimeltä "duke nukem forever", joka oli hyvin nimensä veroinen tuotekehitysajaltaan.

Melko epäloogista. Jos tuo surkea kuormanjako on sellainen jolla päästään mahdollisimman helpolla (=halvalla), samanlaisen tai vastaavan luulisi löytyvän aika monestakin pelistä. Benchmarkkeja katsellessa tuskin niin asia on. Eli toisin sanottuna, jos tuo ei ole se kaikkein helpoin/halvin tapa, miksi se tehdään tarkoituksella ellei tavoitteena ole tehdä hyvin Intelille sopiva peli

Duke Nukem Forever on hyvinkin tuttu tapaus kyllä.

Kuten jo moni muukin sinulle sanoi niin melkoista tuubaa nyt kirjoitit. Kirjoitat sinun kuvitelmia faktoina.

Niin missä kohtaa muka?

 

[svk]

kysymys kuuluukin että olisiko tämä mitenkään realistinen tai järkevä skenaario työpöytäpuolelle? Tyyliin pari aina jokseenkin varmasti 5GHz-kellotaajuudella pyörivää ydintä ja kasa hitaampia kaverina lämpökuorman sallimissa puitteissa.

Coffee lake+gemini lake ytimiä yhteen lastuun kuulostaisi ainakin äkkiseltään vähävirtaisen, mutta tarvittaessa tehokkaan työläppärin sydämeltä, vaikkakin en osaa yhtään sanoa, mitä windows taipuisi moiseen.

 

[L2K2]

Jaa että peleistä luultavasti korjataan helposti korjattavat bugit

Esimerkkinä vaikka ison budjetin peli Far Cry 2. Pelin kakkospatsin jälkeen toisen pelialueen kaikki nauhat tuottivat saman tarinan vaikka joka nauhasta pitäisi löytyä eri sisältö. Ongelmaa ei ollut ykköspatsissa. Jos tuo ei ole helppo korjata niin mikä sitten on? Korjattiinko? Ei ainakaan vielä ole korjattu...

Mistä tiedät onko tuo nimenomainen bugi helposti korjattavissa vai ei?

Parempi peliprosessori ja parempi peliprosessori vuonna 2019 ovat eri asioita. Vertaa vaikka joku i3 vs FX-8350 nyt ja 5 vuotta sitten.

Eivät ole. Jos haluan tehokkaan pelikoneen nykyhetkessä, ja jos toinen alusta ei siihen sovellu yhtä hyvin vuonna 2019, niin se että se alusta pärjää hieman vähemmän surkeasti viisi vuotta myöhemmin ei muuta tätä suorituskykyeroa vuonna 2019.

Intel optimoinnistahan siinä oli kyse koska työnjako oli tehty sopivaksi vain Intelin prosessorille. Monissa peleissä kuormanjakoa ei erityisesti tehdä millekään prosessorille (tai annetaan Windowsin hoitaa se) jolloin Ryzen ei erityisemmin kärsi. Ei tässäkään mitään epäselvää ole.

Voinen toteuttaa vaikka esimerkkikoodin, jossa jätän kaiken käyttöjärjestelmän tasattavaksi, mutta Intel on kokolailla tasan kertoimen 2 nopeampi (samoilla kelloilla kunhan molemmilla puolilla annetaan riittävä määrä ytimiä). Melko triviaalistikin.

Jekku: teen tahallaan epätasaisen työnjaon, jossa yksi säie on muita selvästi raskaampi (mutta Intel-alustalla nopeampi ajaa). Riittävällä ydinmäärällä kumpikin selviää muusta kuormasta nätisti ja nopeasti, jolloin pullonkaulana on yhden säikeen suorituskyky.

Tämä on ihan relevantti ongelma, jos vaikka pelissä on se muutama asia, joita ei voi sisäisesti helposti säikeistää. Nyt siellä on sitä yhden säikeen maksimaalista suorituskykyä vaativa komponentti. Toki yleensä ero on selvästi pienempi kuin tässä tahallaan heitetty kerroin kaksi, jonka tein pahana ihmisenä triviaalisti kirjoittamalla (Intel-alustalla) AVX2 koodia siihen raskaaseen säikeeseen, ja vaikka laittaisin mukaan sen käsinoptimoidun Ryzen-koodipolun ilman AVX2, niin tuo kääntäjän automaattisesti oksentama AVX2-versio veisi silti kertoimella 2..

No eiköhän nämä samat latenssiongelmat, chipletit yms. ala pian olla myös Intelin prossujen ongelmia. Kellotaajuudessa ollaan saavuttamassa jonkunlaista kattoa joten laskentatehon lisääminen täytyy tehdä horisontaalisesti ytimiä lisäämällä. Kaikkien ytimien tunkeminen samalle piilastulle taas tulee kalliiksi ja Intel todennäköisesti painii juurikin monoliittisen arkkitehtuurinsa kanssa parasta aikaa. Jotain huhuja on jo ollut että sininen lähtisi myös tuohon chiplet-tyyppiseen malliin.

IPC:n parantamisessa kellotaajuuden nosto alkaa siis olla pian käytetty. Käsky/haarautumisennustuksissa taas noi spectret yms. ovat nyt iskeneet omalta osaltaan näpeille. @hkultala varmaan osaa kertoa tarkemmin mitä merkittäviä nopeutuskikkoja on vielä nähtävissä (AVX tms), mutta tuo ydinten määrän lisääminen lienee kumminkin se varmin asia mitä tullaan näkemään lähitulevaisuudessa. Toki sovelluspuolella niiden ydinten hyödyntäminen onkin sitten usein aika perhananmoinen haaste, eikä aina ole edes (järkevällä työmäärällä) mahdollista.

ARM-puolella on suht.normaalia että samassa paketissa on eri nopeuksisia ytimiä esim. 4x2,5GHz ja 4x1,6GHz. Virransäästö varmaan tärkeimpänä, mutta kysymys kuuluukin että olisiko tämä mitenkään realistinen tai järkevä skenaario työpöytäpuolelle? Tyyliin pari aina jokseenkin varmasti 5GHz-kellotaajuudella pyörivää ydintä ja kasa hitaampia kaverina lämpökuorman sallimissa puitteissa. Tavallaanhan nuo turbot, AVX:t yms. mahdollistavat jo nyt tällaisen vaihtelevan jaon, mutta silti se maksimikellotaajuus koko piirillä tippuu kun lämpöä alkaa tulla. Miten siis peleissä jossa ns. pääsäie ja vaikka viisi kevyempää, olisiko tällaisessa hyötyä että olisi tavallaan taattu nopea ydin jossain. Ja jos asian laajentaa AMD:n chipletteihin, niin olisiko ideaa että olisi yhdessä chipletissä muutama nopea ydin ja sitten useampi hitaampi erillisessä? Entäs jos nämä eriytettäisiin kokonaan? Paremmin jäähdytetty nopea socketti ja heikommin jäähdytetty suurta rinnakkaisuutta tarjoava? Tässä spekuloinnissa on joo reikiä monessa kohtaa, mutta kunhan nyt maalaisjärjellä ideoin.

Toki, joo. Mutta kahdeksen ytimen kohdalla ei näköjään vielä (tai edes 28, jos katsoo tuota HCC sirua). Toki Intel ei ole vielä saanut sitä ”10 nm” prosessiaan toimintaan. Mutta chiplet-rakennetta ei sieltä vielä nähdä pariin vuoteen, vaan voivat hyvinkin yrittää (ja onnistua) saamaan tuon monoliittisen laitoksen vielä kertaalleen kutistettua.

AVX on Intel-puolella saamassa AVX512-laajennoksen myös ei HEDT-alustalle tuossa 10 nm kohdalla. Tämä tuplaa (vektoroituvan) liukulukulaskennan nopeuden. (Viimeksi tosiaan tuplaus tuli Haswellin myötä kuluttajaprosessoreihin, ja sopivassa – joku voisi sanoa erittäin synteettisessä, mutta laski ihan oikeaa hyötylaskua – kuormassa tosiaan silloinen 2-ydin Haswell-läppärini pärjäsi sukupolvea vanhemmalle 4-ydin kuluttaja-Xeon työasemalleni.)

Läppäreihin tuo sen sijaan voi tulla. Ideana ei välttämättä olisi tuo kellotaajuusero, vaan päinvastainen: saada verrattain korkeakulkuinen mutta silti vähäruokainen ydin kuormalle joka ei hyödy monimutkaisessa kuormassa korkean IPC ytimestä. (Osaako @hkultala sanoa suoraan mikä muuten on esim. Core M -sarjan ytimien ero noihin normaaliruokaisiin kannettaviin? Näissä kun näyttäisi olevan kaikki mausteet mukana, mutta silti tehoa menee tosi vähän?)

 

[JiiPee]

Jotain huhuja on jo ollut että sininen lähtisi myös tuohon chiplet-tyyppiseen malliin.

Huhuja tosiaan on että tänävuonna Intel tekisi AMD:t jaa liimailisi myös työpöydälle pari nykyistä 14nm lastua yhteen, serveri puolellehan on jo ilmoitettu se 48-coren liimailtu prossu.

 

[Threadripper]

Mistä tiedät onko tuo nimenomainen bugi helposti korjattavissa vai ei?

Mietitäämpä. Bugia ei ollut patsaamattomassa versiossa eikä patseissa 1 tai 2. Se tuli vasta patsin 3 myötä. Onko vaikea korjata asia jota ei ole julkaisuversiossa mutta joka tulee viimeisen patsin myötä ja joka ei liity mihinkään muuhun kuin siihen mikä äänitiedosto toistetaan?

Vastaus: korjaus olisi naurettavan helppo. Todennäköisesti yksi merkki jossain lipsahtanut väärin. Mutta kun ei kiinnosta niin ei kiinnosta. Pelihän jäi muutenkin viimeistelemättä.

Eivät ole. Jos haluan tehokkaan pelikoneen nykyhetkessä, ja jos toinen alusta ei siihen sovellu yhtä hyvin vuonna 2019, niin se että se alusta pärjää hieman vähemmän surkeasti viisi vuotta myöhemmin ei muuta tätä suorituskykyeroa vuonna 2019.

Ei muutakaan mutta myöhemmin se ero on erilainen. Kyllä moni pelaa vielä Intelin vuoden 2011 prosessorilla. Ja vanhemmillakin.

Voinen toteuttaa vaikka esimerkkikoodin, jossa jätän kaiken käyttöjärjestelmän tasattavaksi, mutta Intel on kokolailla tasan kertoimen 2 nopeampi (samoilla kelloilla kunhan molemmilla puolilla annetaan riittävä määrä ytimiä). Melko triviaalistikin.

Jekku: teen tahallaan epätasaisen työnjaon, jossa yksi säie on muita selvästi raskaampi (mutta Intel-alustalla nopeampi ajaa). Riittävällä ydinmäärällä kumpikin selviää muusta kuormasta nätisti ja nopeasti, jolloin pullonkaulana on yhden säikeen suorituskyky.

Tämä on ihan relevantti ongelma, jos vaikka pelissä on se muutama asia, joita ei voi sisäisesti helposti säikeistää. Nyt siellä on sitä yhden säikeen maksimaalista suorituskykyä vaativa komponentti. Toki yleensä ero on selvästi pienempi kuin tässä tahallaan heitetty kerroin kaksi, jonka tein pahana ihmisenä triviaalisti kirjoittamalla (Intel-alustalla) AVX2 koodia siihen raskaaseen säikeeseen, ja vaikka laittaisin mukaan sen käsinoptimoidun Ryzen-koodipolun ilman AVX2, niin tuo kääntäjän automaattisesti oksentama AVX2-versio veisi silti kertoimella 2..

Juuri noin, eihän tuossa ole mitään kovin vaikeaa. Tässä kohtaa olennainen kysymys kuuluukin: jos tuo ROTT:n alkuperäinen toteutus ei ollut helpoin tehdä, miksi se tehtiin noin? Eli jos ei haluta suosia mitään tahoa, miksi käyttää ylimääräistä vaivaa toteutukseen jossa yksi taho kärsii selvästi enemmän?

Tuossa esimerkissäsi tehdään tavallaan juuri niin. Nähdään ylimääräistä vaivaa jotta Ryzen on selvästi hitaampi. Mikäli et haluaisi nähdä ylimääräistä vaivaa, tekisitkö noin?

Läppäreihin tuo sen sijaan voi tulla. Ideana ei välttämättä olisi tuo kellotaajuusero, vaan päinvastainen: saada verrattain korkeakulkuinen mutta silti vähäruokainen ydin kuormalle joka ei hyödy monimutkaisessa kuormassa korkean IPC ytimestä. (Osaako @hkultala sanoa suoraan mikä muuten on esim. Core M -sarjan ytimien ero noihin normaaliruokaisiin kannettaviin? Näissä kun näyttäisi olevan kaikki mausteet mukana, mutta silti tehoa menee tosi vähän?)

Peruskellotaajuus alle gigahertsi ja turbot 2 GHz tai vähän päälle (alle 3 GHz kuitenkin). Ei sen kummempaa magiaa tarvita.

 

[L2K2]

Mietitäämpä. Bugia ei ollut patsaamattomassa versiossa eikä patseissa 1 tai 2. Se tuli vasta patsin 3 myötä. Onko vaikea korjata asia jota ei ole julkaisuversiossa mutta joka tulee viimeisen patsin myötä ja joka ei liity mihinkään muuhun kuin siihen mikä äänitiedosto toistetaan?

Vastaus: korjaus olisi naurettavan helppo. Todennäköisesti yksi merkki jossain lipsahtanut väärin. Mutta kun ei kiinnosta niin ei kiinnosta. Pelihän jäi muutenkin viimeistelemättä.

Selvästi näin on oltava kun näin sanot... ;-)

Ei muutakaan mutta myöhemmin se ero on erilainen. Kyllä moni pelaa vielä Intelin vuoden 2011 prosessorilla. Ja vanhemmillakin.

Myöhemmin ero voi olla erilainen. Mutta menneen perusteella tulevan ennustaminen on vaikeaa.

Ajatusleikki: AMD korjaa muistilatenssiongelmansa kesän julkaisussaan, ja kukaan ei enää parin vuoden päästä vaivaudu erikseen optimoimaan pelejä pyörimään myös niillä vanhoilla ”viallisilla” prosessoreilla, joissa on hirveät latenssit. Kumpikohan prosessori alkuvuodelta 2019 kesti paremmin aikaa tässä leikissä?

Juuri noin, eihän tuossa ole mitään kovin vaikeaa. Tässä kohtaa olennainen kysymys kuuluukin: jos tuo ROTT:n alkuperäinen toteutus ei ollut helpoin tehdä, miksi se tehtiin noin? Eli jos ei haluta suosia mitään tahoa, miksi käyttää ylimääräistä vaivaa toteutukseen jossa yksi taho kärsii selvästi enemmän?

Tuossa esimerkissäsi tehdään tavallaan juuri niin. Nähdään ylimääräistä vaivaa jotta Ryzen on selvästi hitaampi. Mikäli et haluaisi nähdä ylimääräistä vaivaa, tekisitkö noin?

”eihän tuossa ole mitään vaikeaa vaikeaa” :-D

Et selvästikään ole koskaan ohjelmoinut mitään säikeistyvää kuormaa? On helppo tehdä hieman epätasainen jako, mutta erittäin vaikeaa tehdä tasainen jako.

Ongelma on, että siinä vaihessa kun tiedät miten raskas kustakin osasta tulee, niin on hieman myöhäistä vaan ”sopia uusiksi miten jaetaan asiat säikeisiin”. Tai sitten joku asia ei tosiaan ole jaettavissa pienempiin rinnakkaisiin osiin, ja se jää siksi homman hitaimmaiksi säikeeksi.

Peruskellotaajuus alle gigahertsi ja turbot 2 GHz tai vähän päälle (alle 3 GHz kuitenkin). Ei sen kummempaa magiaa tarvita.

Ai niin kuin Core i7-7Y75 (1,3 GHz peruskellotaajuus ja turbo 3,6 GHz)? Saattaahan tuo silti olla vain rankka ”alivoltitus” ja ”alikellotus”, mutta onko tuossa myös joku rakenne-ero...

Intel® Core™ i7-7Y75 Processor (4M Cache, up to 3.60 GHz) Product Specifications

 

[Threadripper]

Selvästi näin on oltava kun näin sanot... ;-)

Homma on periaatteeltaan näin vaikea: ota sijainnista X ääninauha 1, soita äänitiedosto 1. Ota sijainnista Y ääninauha 2, soita äänitiedosto 2. Jne. Kolmospatsin jälkeen riippumatta siitä minkä ääninauhan ottaa, soitetaan äänitiedosto 1.

Voit toki täysin vapaasti olla sitä mieltä että tuollaisen bugin korjaus on vaikeaa

Myöhemmin ero voi olla erilainen. Mutta menneen perusteella tulevan ennustaminen on vaikeaa.

Ajatusleikki: AMD korjaa muistilatenssiongelmansa kesän julkaisussaan, ja kukaan ei enää parin vuoden päästä vaivaudu erikseen optimoimaan pelejä pyörimään myös niillä vanhoilla ”viallisilla” prosessoreilla, joissa on hirveät latenssit. Kumpikohan prosessori alkuvuodelta 2019 kesti paremmin aikaa tässä leikissä?

Eipä tuon ennustaminen kummoisiakaan ennustajanlahjoja vaatinut. Jo noihin aikoihin tiedettiin PS4:n ja X-Box tiesmihin tulevan 8-ytimisen prosessorin jossa mopotason ytimet.

Mikä muistilatenssiongelma nykyisissä Ryzeneissä on verrattuna tulevaan 3000-sarjaan

”eihän tuossa ole mitään vaikeaa vaikeaa” :-D

Et selvästikään ole koskaan ohjelmoinut mitään säikeistyvää kuormaa? On helppo tehdä hieman epätasainen jako, mutta erittäin vaikeaa tehdä tasainen jako.

Ongelma on, että siinä vaihessa kun tiedät miten raskas kustakin osasta tulee, niin on hieman myöhäistä vaan ”sopia uusiksi miten jaetaan asiat säikeisiin”. Tai sitten joku asia ei tosiaan ole jaettavissa pienempiin rinnakkaisiin osiin, ja se jää siksi homman hitaimmaiksi säikeeksi.

Täysin tasainen jako on totta kai vaikea tehdä. Tässä tapauksessa oli kyse jaosta joka oli ns. päin mäntyä ja se korjattiin tasolle "hieman epätasainen".

Samat kysymykset edelleen voimassa siitä mitä tuolla päin mäntyä jaolla säästettiin (aikaa/rahaa) ja jos ei kumpaakaan, miksi se tehtiin. Ja miksi about kaikissa peleissä ei ole yhtä lailla päin mäntyä.

Siellä oli myös jotain muuta pakosti tehty päin mäntyä koska Ryzenin ja 7700K:n erot single thread nopeudessa eivät todellakaan ole mitään 50% luokkaa.

Ja tarkemmin katsottuna tuo koko benchmarkki on puhdasta roskaa. i5-7500 on nopeampi kuin i7-7700K. Selityksenä voisi tarjota Hyper Threadingia mutta että i5-7500 voittaa myös i5-7600K:n on jo ihan järjetöntä. Että joo, eipä tuosta kannata paljoa johtopäätöksiä vetää

Ai niin kuin Core i7-7Y75 (1,3 GHz peruskellotaajuus ja turbo 3,6 GHz)? Saattaahan tuo silti olla vain rankka ”alivoltitus” ja ”alikellotus”, mutta onko tuossa myös joku rakenne-ero...

Intel® Core™ i7-7Y75 Processor (4M Cache, up to 3.60 GHz) Product Specifications[/QUOTE]

Vähemmän PCIe linjoja ja tulee vain DDR3-L:a. Ei noissa näytä rakenteellista eroa olevan. Tietenkin all core turbot sun muut ovat hyvin alhaiset.

 

[sushukka]

Ohessa jo mainittiin että AMD:n lukuisat ytimet ovat halpoja syystä, vihjaten huonompaan laatuun verrattuna Inteliin. On tiettyjä valikoituja laskentakuormia toki missä Intel on parempi, mutta kokonaisuudessaan AMD myy laadukkaampaa ja viileämpää ydintä ja voittaa valtaosassa kuormia. Jos Intel laittaa yhtä monta ydintä samaan pakettiin niin hommat ei enää pelitä virrankulutuksen tähden. Tätä seikkaa ei voi vain sivuuttaa, sillä käytännössä Intel ei pysty kasaamaan yhtä antoisaa pakettia yhtä hyvin toimivana.

Me tiedämme jo varmana ja kiistattomana tietona että Intelin tapa kilpailla menneisyydessä, on ollut toisen kampittaminen ja tehokkuuden hidastaminen eri keinoin, myös markkinaosuuden enentämistä on estetty likaisin keinoin. Intel on näin ollen hidastanut jo pitkään kehitystä ryhtymättä aitoon nopeuskilpailuun, vaan koittaa kikkailla omat tuotteensa vaikuttamaan paremmilta. Tälläkin hetkellä tilanne on sama, tulevaisuudesta on vaikea sanoa.

On sääli mitä kaikkea meiltä on jäänyt näkemättä kun jarrutetaan jopa paremman kilpailevan tuotteen leviämistä, niin me emme tiedä mitä kaikkea hienoa ohjelmointi voisi peleissä ja sovelluksissa meille tarjota, jos käytössä olisi aina se paras vaihtoehto kuormaan ja tehostus sille, kuten nyt paras vaihtoehto on kuluttaja- ja palvelinpuolella Ryzen. Minulle on käsittämätöntä tukea hidasta kehitystä vain siksi että itse saisi missä lie pelissä pari FPS lisää nyt, sen sijaan että ostettaisiin parempaa ja laadukkaampaa tuotetta ja saataisin ennen pitkää rutkasti parempaa jälkeä.

Sitä voi vain haaveilla jos AMD:n aikeet säikeistämisestä olisivat lyöneet hyvin läpi jo aikaisemmin niin meillä olisi nyt melkoista laskentatehon hyödyntämistä joka saralla ja näkisimme kaikenlaista uutta ja hyödyllistä. Ei ole kylläkään uutta että kaikki uusi ja kehitys ylipäätään pelottaa, mutta minun näkemykseni on, mitä jo toistan uudelleen, että Intel on hidastanut kehitystä ja jarrut on päällä tälläkin hetkellä. Valoisana puolena voi todeta sentään että hiljaa hyvää tulee ja Intel tosiaan on nöyrtymässä AMD:n osoittamaan parempaan suuntaan, eli säikeistykseen ja lukuisiin ytimiin.

AMD ei ole mikään enkeliyhtiö, mutta minä tuen sitä yhtiötä joka on lähinnä periaatteitani. AMD:n suunta niin näytönohjaimissa kuin suorittimissa on järkevä ja aidosti suuria harppauksia kehityksessä tarjoava suunta, mikä kiehtoo minua ja minä haluan nähdä tämän kehityksen tapahtuvan pian. Elämä on lyhyt ja tekniikka kun kiinnostaa, niin olisi kiva nähdä mahdollisimman paljon.

Tässä loppuun neuvo pelaajalle: Ryzen 2600 tai 2600X vaiko i5-9400? Osta aina Ryzen, ellet saa Inteliä reilusti halvemmalla otettuna huomioon myös emolevyn tarjoama hintalaatusuhde.

Se nyt on ollut selvää että kehitys on ollut heikkoa viimeisen kymmenen vuotta, mutta vasta tuon vanhan koneen päivityksessä silmät itselläni aukesivat todella. Kymmenen vuotta vanhaan emolevyyn vaihdoin @Zetteri opastuksella i7 920 (4c/8t) tilalle Xeon X5675:n (6c/12t) Ebaysta 40€. Tästä olen meuhkannut täällä jo aikaisemminkin, mutta silti: kahdeksan vuotta vanha prossu kellotettuna kamppailee jokseenkin tasapäisesti uusien kaupassa olevien kanssa. Toki 4,5GHz vakaa kellotus vaatii kunnon siilin, mutta tuon lämpenemisen voi melkeinpä kuittaa pelkästään 32nm prosessin piikkiin. Tietenkin on ollut aikansa tykki palvelinprossu, on tullut parempaa AVX:ää, arkkitehtuuria viilailtu jnejne, mutta pointti on että jo vuonna 2011 oli Intelillä prossuja joiden tekniikka pärjää nykypäivänkin tarpeissa/kilpailussa. Lisäksi noita lisäytimiä (enemmän kuin neljä) alkoi näkyä kuluttajille 9v jälkeen vasta kun AMD toi Zenin markkinoille. Sitä ennen ei muka ollut tarvetta. :s

Vaikkei ihan suoraan voikaan verrata, mutta kumminkin: Miten huippu-GPU vuodelta 2011 (esim. GTX 480) pärjäisikään nykypäivänä?

 

[hkultala]

No eiköhän nämä samat latenssiongelmat, chipletit yms. ala pian olla myös Intelin prossujen ongelmia. Kellotaajuudessa ollaan saavuttamassa jonkunlaista kattoa joten laskentatehon lisääminen täytyy tehdä horisontaalisesti ytimiä lisäämällä. Kaikkien ytimien tunkeminen samalle piilastulle taas tulee kalliiksi ja Intel todennäköisesti painii juurikin monoliittisen arkkitehtuurinsa kanssa parasta aikaa. Jotain huhuja on jo ollut että sininen lähtisi myös tuohon chiplet-tyyppiseen malliin.

Suuri pii-pinta-ala tulee AINA kalliiksi, eikä monen piilastun tekeminen yhden sijasta ole merkittävästi halvempaa , mikäli piiristä suurin osa on redundanttia kamaa (kuten moniytimisessä piirissä on, kun yksittäisiä rikkinäisiä ytimiä voidaan kytkeä pois päältä).

Kehitys on tähän asti kulkenut jatkuvasti siihen suuntaan, että yhdelle piilastulle ängetään yhä enemmän erilaista toiminnalliisuutta, ja ytimien osuus piilastusta on yhä pienempi, koska ytimet ovat jatkuvasti pienentyneet. Tämä on juuri päinvastainen kehityssuunta.

386ssa prosessoripiirillä ei ollut välimuistia eikä liukulukuyksikköä, välimuistia saattoi olla emolevyllä(oli emolevykohtaista, oliko ollenkaan). Kaikissa 486ssa prosessoripiirille tuli L1-välimuisti ja 486DXssä liukulukuyksikkö.

K6-3ssa, ja Mendocino-Celeronissa prosessoripiirin kanssa integroitiin samalle piirille L2-välimuisti. K8ssa ja Nehalemissa DRAM-ohjain, Phenomissa ja Nehalemissa myös L3-välimuisti.

Sandy bridgessä ja Llanossa samalle piirille tuli vielä näyttiskin.


Ja suuressa määrässä normaaleita CPU-ytimiä vaan ei ole kovin paljoa järkeä, paitsi palvelinkäytössä. Ei ole paljoa sellaisia (yhden käyttäjän) workloadeja, joiden rinnakkaistamiseen tällainen arkkitehtuuri on tehokasta.

Softissa on tyypillisesti luonnollisesti A) melko pieni määrä rinnakkaisia taskeja, jotka rinnakkaistuvat pienelle määrällä säikeitä, ja B) Tietyissä kohdissa hyvin suuri määrä datatason rinnakkaisuutta, sama koodi ajetaan hyvin isolle taulukolle.

Sen massiivisen datatason hyödyntäminen monella säikeellä CPUlla on toimiva, mutta epätehokas tapa sen hyödyntämiseen. Sen CPUn SIMD-leveyden lisääminen on jo heti paljon parempi tapa sen hyödyntämiseen kuin ytimien lisääminen (ja Intel on nyt siirtymässä AVX-512een).
Tehokkainta on sen siirtäminen kokonaan näyttikselle laskettavaksi (onnistuu melko helposti, mikäli näyttis käyttää samaa muistia välimuistikoherentisti, vaikeampaa ja epätehokkaampaa erillisnäyttiksellä PCIE-väylän takana; Datansiirto-overhead voi usein tehdä käytännössä kannattamattomaksi). Eli sen sijaan, että on järkeä tehdä 16- ja 32-ytimisiä työpöytä-CPUita, kannattaa tehdä piirejä, joissa vaikka 8 CPU-ydintä ja 32 GPU-ydintä.
Tai sen sijaan, että ydinmäärä tuplataan, tuplataan vaan SIMD-leveys. Tosin SIMDin leventämisessä on se huono puoli, että softat pitää kääntää (ja joskus jopa osittain kirjoittaa) uudestaan sen SIMDin hyödyntämiseksi, siinä missä joku OpenMP rinnakkaistaa yksinkertaisen loopin ihan yhtä lailla kahdelle kuin 128 ytimelle, eikä sitä tarvi kääntää uudestaan että se tukee vaikka 128 ydintä.

Toki softankehitystyökalut ja rajapinnat ovat selvästi laahanneet perässä sen suhteen, että miten kamaa laitetaan sinne GPUlle ajettavaksi, kun joskus 6 vuotta sitten jostain HSAsta hypetettiin eikä mitään konkreettista silloin tullut ulos, mutta nyt se silloin luvattu hype alkaa vihdoin pikkuhiljaa materialisoituaan, kun koko HSA alkaaa unohtua. Esimerkiksi OpenMP:n nelosversiossa voi yhdellä pragma-rivillä saada kamaa GPUlle ajoon geneerisessä C/C++-ohjelmassa. (OpenMP Accelerator Support for GPUs - OpenMP)

Toki välillä tulee vastaan koodia, jossa niitä luonnollisia taskeja on paljon enemmän, tai niiden rinnakkaisten looppien sisällä on niin hankalaa musitiaccessia ja haarautumista, että niitä ei ole tehokasta suorittaa SIMDillä tai näyttiksellä, mutta nämä on kuitenkin harvinaisempia tilanteita.



CPU-ydinten jakaminen monelle "chipletille" työpöytäprossussa ei vaan olisi järkevää, ellei sillä vähennettäisi tarvittavien erilaisten piilastujen määrää. Jos montaa "chiplettiä" tarvittaisiin, piiri olisi joka tapauksessa jo liian iso ja kallis työpöydälle ihan suuren pinta-alansa takia muutenkin, eikä työpöytäsoftat kuitenkaan niistä ytimistä hirveästi hyötyisi.

AMDllä ei ole resursseja kehittää nopeasti montaa erillistä prosessoripiilastua, niin tekemällä yhden 8-ytimisen chiletin se voi palvella kaikkia markkinasegmenttejä suunnittelemalla yhden "7nm" piilastun.

Intel voi aivan hyvin tehdä isompia eri kokoisia piilastuja.


Se, että muistiohjain ja muu pitkän matkan IO siirretään omalle vanhemmalla valmsitustekniikalla tehdylle piilastulle on sitten täysin eri asia. Siinä on ihan eri tavalla järkeä, koska ne PHYiden IO-transistorit eivät hyödy mitään niistä uudemmista valmistusprosesseista.

Optimaalinen chiplet-malli on kuitenkin työpöydällä pikemminkuin yksi pienellä valmistustekniikalla tehty ydin-chiplet + yksi pohjoissilta-chiplet, tai sitten yksi cpu-ydin-chiplet + yksi gpu-chiplet + pohjoissilta-chiplet. Ei montaa ydin-chiplettiä.

AMDltä kahden CPU-chipletin ryzen on toki todennäköisesti joskus tulossa, mutta tässä pointtina on paljon enemmän tuotekehityksen nopeuttaminen, ja sen kustannuksissa säästäminen kuin valmistuskustannuksissa säästäminen. Toki AMD varmasti tulee hypettämään jotain valmistuskustannussäästöä, koska se kuulostaa paljon paremmalta kuin sanoa "teimme tämän, koska resurssimme eivät riittäneet muuhun, ja lisäksi tällä säästimme tuotekehityskustannuksissa".

IPC:n parantamisessa kellotaajuuden nosto alkaa siis olla pian käytetty.

Kellotaajuuden nosto huonontaa IPCtä, koska muistiviiveet kasvaa kellotaajuutta kasvattaessa. Samoin mitkään käskykantalaajennokset eivät tyypillisesti auta IPChen, vaan huonontavat sitä; Jos vaikka 16 yhdessä kellojaksossa ajettavaa käskyä korvataan yhdellä, joka ajautuu vaikka parissa kellojaksossa, IPC laskee.

Tarkoittanet "säiekohtaista suorituskykyä".

Käsky/haarautumisennustuksissa taas noi spectret yms. ovat nyt iskeneet omalta osaltaan näpeille.

Juu, tosin parempien haarautumisennustusten kehittäminen ei millään tavalla tee prosessoreita yhtään nykyistä enemmän haavoittuvaisia spectrelle. Jos halutaan specrelle immuuneita prossuja, pitää koko spekulatiivinen suoritus kieltää ja hidastua yli kaksinkertaisesti.

Mutta, niissä haarautumisenennustuksissakaan ei yksinkertaisesti ole kovin paljoa sitä varaa parantaa. Osa haarautumisista vaan on mahdottomia ennustaa, ja niissäkin, jotka voi ennustaa, vaadittavan kirjanpidon määrä alkaa räjähtää käsille, jos sitä yritetään vielä parantaa. Zenissä haarautumisennustusyksikkö on jo isompi kuin ytimen kaikki kokonaislukulaskentayksiköt yhteensä.

Haarautumisenennustuksen parannuksista tullaan saamaan sellaista muutaman prosentin parannusta vuosittain. Osa algoritmiparannuksista, osa siitä, että niiden tietorakenteiden kokoa kasvatetaan.

@hkultala varmaan osaa kertoa tarkemmin mitä merkittäviä nopeutuskikkoja on vielä nähtävissä (AVX tms), mutta tuo ydinten määrän lisääminen lienee kumminkin se varmin asia mitä tullaan näkemään lähitulevaisuudessa. Toki sovelluspuolella niiden ydinten hyödyntäminen onkin sitten usein aika perhananmoinen haaste, eikä aina ole edes (järkevällä työmäärällä) mahdollista.

Se, mitä tullaan näkemään on entistä enemmän ihan tiettyyn käyttöön tulevia erikoiskäskyjä. Viime aikoina on tainnut tulla bitcount ja leading/trailing zero count-käskyjä. Zenin CLZERO oli myös näppärä optimointi muistinvaraukseen.

Sunny coveen luvataan datanpakkausta ja enkryptausta nopeuttavia erikoiskäskyjä.

Mutta nämäkin on juttuja, että jokainen uusi erikoiskäsky nopeuttaa hyvin pientä osaa ohjelmista, ja niitäkin vasta, kun ohjelma on käännetty käyttämään uutta käskyä (ja joskus kääntäminen ei riitä, vaan pitää erikseen käyttää jotain intrinsicciä sen käyttämiseen). Tai no, zenin CLZERO menee kirjastoissa olevien muistinhallintarutiinien sisälle, joten kaikki softat kyllä nopeutuu, kun vaan kirjastot käännetään uusiksi ja päivitetään.

Muistaakseni ARMiin taisi tulla jo joitain käskyjä, joiden idea on nopeuttaa javascriptin JIT-kääntämistä sille, koska nykyään melkein kaikki "appit" on vain javascriptiä sisältäviä html-sivuja. Sama javascript-kiihdytys varmaan tulossa x86-puolellekin jossain vaiheessa.

Mutta tosiaan sunny covessa intel on myös lisäämässä toista tallennusyksikköä, mikä on hiukan yllättävää. Eli vielä tehdään rautaa joka pystyy hyödyntämään lisää IPCtä, se lisä-IPC pitäisi kuitenkin joteinkin myös ajettavasta softasta löytää (toisaalta, ne jatkuvat haarautumisennustuksen parannukset kyllä auttaa löytämään sitä hiukan)

ARM-puolella on suht.normaalia että samassa paketissa on eri nopeuksisia ytimiä esim. 4x2,5GHz ja 4x1,6GHz. Virransäästö varmaan tärkeimpänä, mutta kysymys kuuluukin että olisiko tämä mitenkään realistinen tai järkevä skenaario työpöytäpuolelle? Tyyliin pari aina jokseenkin varmasti 5GHz-kellotaajuudella pyörivää ydintä ja kasa hitaampia kaverina lämpökuorman sallimissa puitteissa. Tavallaanhan nuo turbot, AVX:t yms. mahdollistavat jo nyt tällaisen vaihtelevan jaon, mutta silti se maksimikellotaajuus koko piirillä tippuu kun lämpöä alkaa tulla. Miten siis peleissä jossa ns. pääsäie ja vaikka viisi kevyempää, olisiko tällaisessa hyötyä että olisi tavallaan taattu nopea ydin jossain? Ja jos asian laajentaa AMD:n chipletteihin, niin olisiko ideaa että olisi yhdessä chipletissä muutama nopea ydin ja sitten useampi hitaampi erillisessä? Entäs jos nämä eriytettäisiin kokonaan? Paremmin jäähdytetty nopea socketti ja heikommin jäähdytetty suurta rinnakkaisuutta tarjoava? Tässä spekuloinnissa on joo reikiä monessa kohtaa, mutta kunhan nyt maalaisjärjellä ideoin.

Ei todellakaan haluta ajaa saman softan eri säkeitä eri soketeissa. Kommunikaatioviiveet olisi hirveät, ja joku muistin (vähiten pessimaali) jakaminen eri sokettien välillä olisi aivan hirveä suo. (threadripperin erilliset game modet jne on esimerkkiä tästä suosta). AMD on hyvin onnellinen kun zen2-sukupolvessa pääsee tuosta eroon.

ARMin big.LITTLEn idea ei ole se, että saman (raskaan) softan eri määrän aikaa tarvitsevia säikeitä jaetaan eri ytimille, vaan se, että niille hitaille ytimille laitetaan ne taustaprosessit, joita siellä kuitenkin on koko ajan ajossa. Ja että silloin, in tehoa ei tarvita paljon, voidaan käyttää niitä heikompia ytimiä myös edustalla oleville kevyille prosesseille.

Ja Intel on jo myös kertonut olevansa menossa tähän suuntaan, on sanonut että tulee tekemään piirejä joissa on sekä isoja että pieniä ytimiä.

Mutta tämä ei tosiaankaan ole keino saada lisää suorituskykyä, vaan keino vähentää sähkönkulutusta.

Ja ne "pienet" ytimet on joka tapauksessa niin pieniä, että niitä mahtuu iso kasa vaikka mihin, olisi hirveää tuhlausta tehdä niille omaa "chiplettiä", ainakin ellei niitä sitten optimoitaisi toimimaan myös datarinnakkaisen koodin erikoisytimiä (intelillähän on ollut noita tämän tyyppisiä xeon phi-ytimiä...)



Ja AVXllä ei tämän kanssa ole oikeastaan mitään tekemistä. Jos toiset ytimet tukisi jotain käskykantalaajennosta, toiset ei, sitten meillä ei olisi enää homogeeninen moniprosessorijärjestelmä jolle koodi käännetään yhdellä kääntäjällä ja ajetaan millä tahansa ytimellä ja kaikilla on kivaa, vaan tämä vaatisi paljon monimutkaisemman ajoympäristön, jossa pitäisi olla eriksen koodi molemmille tai sitten pitäisi tietää, mitkä koodia saa ajaa pikkuytimillä, ja mitä ei, ja herätellä niitä isoja ytimiä turhaan kun kevyt taustasofta käyttääkin hyvin pienessä memcpy:ssään AVX-512sta. Sitten on jo melko sama laittaa sinne täysin eri käskykannan ytimiä (GPU-ytimiä)

(ARMin SVE on tämän suhteen nerokas, kun se on SIMD-käskykanta, joka ei ota kantaa vektorien pituuteen; Sama koodi toimii sellaisenaan vaikka 2 tai 16 elementin vektoreilla, pienemmät vektorit sisältävä ydin vaan looppaa loppia useamman kierroksen. Toki tässäkin context switchien kanssa tulee pientä säätöä)

 

[sushukka]

Suuri pii-pinta-ala tulee AINA kalliiksi, eikä monen piilastun tekeminen yhden sijasta ole merkittävästi halvempaa , mikäli piiristä suurin osa on redundanttia kamaa (kuten moniytimisessä piirissä on, kun yksittäisiä rikkinäisiä ytimiä voidaan kytkeä pois päältä).

Kehitys on tähän asti kulkenut jatkuvasti siihen suuntaan, että yhdelle piilastulle ängetään yhä enemmän erilaista toiminnalliisuutta, ja ytimien osuus piilastusta on yhä pienempi, koska ytimet ovat jatkuvasti pienentyneet. Tämä on juuri päinvastainen kehityssuunta.

386ssa prosessoripiirillä ei ollut välimuistia eikä liukulukuyksikköä, välimuistia saattoi olla emolevyllä(oli emolevykohtaista, oliko ollenkaan). Kaikissa 486ssa prosessoripiirille tuli L1-välimuisti ja 486DXssä liukulukuyksikkö.

K6-3ssa, ja Mendocino-Celeronissa prosessoripiirin kanssa integroitiin samalle piirille L2-välimuisti. K8ssa ja Nehalemissa DRAM-ohjain, Phenomissa ja Nehalemissa myös L3-välimuisti.

Sandy bridgessä ja Llanossa samalle piirille tuli vielä näyttiskin.


Ja suuressa määrässä normaaleita CPU-ytimiä vaan ei ole kovin paljoa järkeä, paitsi palvelinkäytössä. Ei ole paljoa sellaisia (yhden käyttäjän) workloadeja, joiden rinnakkaistamiseen tällainen arkkitehtuuri on tehokasta.

Softissa on tyypillisesti luonnollisesti A) melko pieni määrä rinnakkaisia taskeja, jotka rinnakkaistuvat pienelle määrällä säikeitä, ja B) Tietyissä kohdissa hyvin suuri määrä datatason rinnakkaisuutta, sama koodi ajetaan hyvin isolle taulukolle.

Sen massiivisen datatason hyödyntäminen monella säikeellä CPUlla on toimiva, mutta epätehokas tapa sen hyödyntämiseen. Sen CPUn SIMD-leveyden lisääminen on jo heti paljon parempi tapa sen hyödyntämiseen kuin ytimien lisääminen (ja Intel on nyt siirtymässä AVX-512een).
Tehokkainta on sen siirtäminen kokonaan näyttikselle laskettavaksi (onnistuu melko helposti, mikäli näyttis käyttää samaa muistia välimuistikoherentisti, vaikeampaa ja epätehokkaampaa erillisnäyttiksellä PCIE-väylän takana; Datansiirto-overhead voi usein tehdä käytännössä kannattamattomaksi). Eli sen sijaan, että on järkeä tehdä 16- ja 32-ytimisiä työpöytä-CPUita, kannattaa tehdä piirejä, joissa vaikka 8 CPU-ydintä ja 32 GPU-ydintä.
Tai sen sijaan, että ydinmäärä tuplataan, tuplataan vaan SIMD-leveys. Tosin SIMDin leventämisessä on se huono puoli, että softat pitää kääntää (ja joskus jopa osittain kirjoittaa) uudestaan sen SIMDin hyödyntämiseksi, siinä missä joku OpenMP rinnakkaistaa yksinkertaisen loopin ihan yhtä lailla kahdelle kuin 128 ytimelle, eikä sitä tarvi kääntää uudestaan että se tukee vaikka 128 ydintä.

Toki softankehitystyökalut ja rajapinnat ovat selvästi laahanneet perässä sen suhteen, että miten kamaa laitetaan sinne GPUlle ajettavaksi, kun joskus 6 vuotta sitten jostain HSAsta hypetettiin eikä mitään konkreettista silloin tullut ulos, mutta nyt se silloin luvattu hype alkaa vihdoin pikkuhiljaa materialisoituam, kun koko HSA alkaaa unohtua. Esimerkiksi OpenMP:n 4nelosversiossa voi yhdellä pragma-rivillä saada kamaa GPUlle ajoon geneerisessä C/C++-ohjelmassa. (OpenMP Accelerator Support for GPUs - OpenMP)

Toki välillä tulee vastaan koodia, jossa niitä luonnollisia taskeja on paljon enemmän, tai niiden rinnakkaisten looppien sisällä on niin hankalaa musitiaccessia ja haarautumista, että niitä ei ole tehokasta suorittaa SIMDillä tai näyttiksellä, mutta nämä on kuitenkin harvinaisempia tilanteita.



CPU-ydinten jakaminen monelle "chipletille" työpöytäprossussa ei vaan olisi järkevää, ellei sillä vähennettäisi tarvittavien erillisten piirien määrää. Jos montaa "chiplettiä" tarvittaisiin, piiri olisi joka tapauksessa jo liian iso ja kallis työpöydälle ihan suuren pinta-alansa takia muutenkin, eikä työpöytäsoftat kuitenkaan niistä ytimistä hirveästi hyötyisi.

AMDllä ei ole resursseja kehittää nopeasti montaa erillistä prosessoripiilastua, niin tekemällä yhden 8-ytimisen chiletin se voi palvella kaikkia markkinasegmenttejä suunnittelemalla yhden "7nm" piilastun.

Intel voi aivan hyvin tehdä isompia eri kokoisia piilastuja.


Se, että muistiohjain ja muu pitkän matkan IO siirretään omalle vanhemmalla valmsitustekniikalla tehdylle piilastulle on sitten täysin eri asia. Siinä on ihan eri tavalla järkeä, koska ne PHYiden IO-transistorit eivät hyödy mitään niistä uudemmista valmistusprosesseista.

Optimaalinen chiplet-malli on kuitenkin työpöydällä pikemminkuin yksi pienellä valmistustekniikalla tehty ydin-chiplet + yksi pohjoissilta-chiplet, tai sitten yksi cpu-ydin-chiplet + yksi gpu-chiplet + pohjoissilta-chiplet. Ei montaa ydin-chiplettiä.

AMDltä kahden CPU-chipletin ryzen on toki todennäköisesti joskus tulossa, mutta tässä pointtina on paljon enemmän tuotekehityksen nopeuttaminen, ja sen kustannuksissa säästäminen kuin valmistuskustannuksissa säästäminen. Toki AMD varmasti tulee hypettämään jotain valmistuskustannussäästöä, koska se kuulostaa paljon paremmalta kuin sanoa "teimme tämän, koska resurssimme eivät riittäneet muuhun, ja lisäksi tällä säästimme tuotekehityskustannuksissa".



Kellotaajuuden nosto huonontaa IPCtä, koska muistiviiveet kasvaa kellotaajuutta kasvattaessa. Samoin mitkään käskykantalaajennokset eivät tyypillisesti auta IPChen, vaan huonontavat sitä; Jos vaikka 16 yhdessä kellojaksossa ajettavaa käskyä korvataan yhdellä, joka ajautuu vaikka parissa kellojaksossa, IPC laskee.

Tarkoittanet "säiekohtaista suorituskykyä".



Juu, tosin parempien haarautumisennustusten kehittäminen ei millään tavalla tee prosessoreita yhtään nykyistä enemmän haavoittuvaisia spectrelle. Jos halutaan specrelle immuuneita prossuja, pitää koko spekulatiivinen suoritus kieltää ja hidastua yli kaksinkertaisesti.

Mutta, niissä haarautumisenennustuksissakaan ei yksinkertaisesti ole kovin paljoa sitä varaa parantaa. Osa haarautumisista vaan on mahdottomia ennustaa, ja niissäkin, jotka voi ennustaa, vaadittavan kirjanpidon määrä alkaa räjähtää käsille, jos sitä yritetään vielä parantaa. Zenissä haarautumisennustusyksikkö on jo isompi kuin ytimen kaikki kokonaislukulaskentayksiköt yhteensä.

Haarautumisenennustuksen parannuksista tullaan saamaan sellaista muutaman prosentin parannusta vuosittain. Osa algoritmiparannuksista, osa siitä, että niiden tietorakenteiden kokoa kasvatetaan.

@hkultala varmaan osaa kertoa tarkemmin mitä merkittäviä nopeutuskikkoja on vielä nähtävissä (AVX tms), mutta tuo ydinten määrän lisääminen lienee kumminkin se varmin asia mitä tullaan näkemään lähitulevaisuudessa. Toki sovelluspuolella niiden ydinten hyödyntäminen onkin sitten usein aika perhananmoinen haaste, eikä aina ole edes (järkevällä työmäärällä) mahdollista.

Se, mitä tullaan näkemään on entistä enemmän ihan tiettyyn käyttöön tulevia erikoiskäskyjä. Viime aikoina on tainnut tulla bitcount ja leading/trailing zero count-käskyjä. Zenin CLZERO oli myös näppärä optimointi muistinvaraukseen.

Sunny coveen luvataan datanpakkausta ja enkryptausta nopeuttavia erikoiskäskyjä.

Mutta nämäkin on juttuja, että jokainen uusi erikoiskäsky nopeuttaa hyvin pientä osaa ohjelmista, ja niitäkin vasta, kun ohjelma on käännetty käyttämään uutta käskyä (ja joskus kääntäminen ei riitä, vaan pitää erikseen käyttää jotain intrinsicciä sen käyttämiseen). Tai no, zenin CLZERO menee kirjastoissa olevien muistinhallintarutiinien sisälle, joten kaikki softat kyllä nopeutuu, kun vaan kirjastot käännetään uusiksi ja päivitetään.

Muistaakseni ARMiin taisi tulla jo joitain käskyjä, joiden idea on nopeuttaa javascriptin JIT-kääntämistä sille, koska nykyään melkein kaikki "appit" on vain javascriptiä sisältäviä html-sivuja. Sama javascript-kiihdytys varmaan tulossa x86-puolellekin jossain vaiheessa.



Ei todellakaan haluta ajaa saman softan eri säkeitä eri soketeissa. Kommunikaatioviiveet olisi hirveät, ja joku muistin (vähiten pessimaali) jakaminen eri sokettien välillä olisi aivan hirveä suo. (threadripperin erilliset game modet jne on esimerkkiä tästä suosta). AMD on hyvin onnellinen kun zen2-sukupolvessa pääsee tuosta eroon.

ARMin big.LITTLEn idea ei ole se, että saman (raskaan) softan eri määrän aikaa tarvitsevia säikeitä jaetaan eri ytimille, vaan se, että niille hitaille ytimille laitetaan ne taustaprosessit, joita siellä kuitenkin on koko ajan ajossa. Ja että silloin, in tehoa ei tarvita paljon, voidaan käyttää niitä heikompia ytimiä myös edustalla oleville kevyille prosesseille.

Ja Intel on jo myös kertonut olevansa menossa tähän suuntaan, on sanonut että tulee tekemään piirejä joissa on sekä isoja että pieniä ytimiä.

Mutta tämä ei tosiaankaan ole keino saada lisää suorituskykyä, vaan keino vähentää sähkönkulutusta.

Ja ne "pienet" ytimet on joka tapauksessa niin pieniä, että niitä mahtuu iso kasa vaikka mihin, olisi hirveää tuhlausta tehdä niille omaa "chiplettiä", ainakin ellei niitä sitten optimoitaisi toimimaan myös datarinnakkaisen koodin erikoisytimiä (intelillähän on ollut noita tämän tyyppisiä xeon phi-ytimiä...)



Ja AVXllä ei tämän kanssa ole oikeastaan mitään tekemistä. Jos toiset ytimet tukisi jotain käskykantalaajennosta, toiset ei, sitten meillä ei olisi enää homogeeninen moniprosessorijärjestelmä jolle koodi käännetään yhdellä kääntäjällä ja ajetaan millä tahansa ytimellä ja kaikilla on kivaa, vaan tämä vaatisi paljon monimutkaisemman ajoympäristön, jossa pitäisi olla eriksen koodi molemmille tai sitten pitäisi tietää, mitkä koodia saa ajaa pikkuytimillä, ja mitä ei, ja herätellä niitä isoja ytimiä turhaan kun kevyt taustasofta käyttääkin hyvin pienessä memcpy:ssään AVX-512sta. Sitten on jo melko sama laittaa sinne täysin eri käskykannan ytimiä (GPU-ytimiä)

(ARMin SVE on tämän suhteen nerokas, kun se on SIMD-käskykanta, joka ei ota kantaa vektorien pituuteen; Sama koodi toimii sellaisenaan vaikka 2 tai 16 elementin vektoreilla, pienemmät vektorit sisältävä ydin vaan looppaa loppia useamman kierroksen. Toki tässäkin context switchien kanssa tulee pientä säätöä)

Tulipas hyvä vastaus, kiitokset. Tarkoitin juurikin "säiekohtaista suorituskykyä" ja tuo AVX:n rinnastus noihin erinopeuksisiin ytimiin oli oma yritykseni tunkea mahdollisimman paljon asiaa pieneen tilaan. Käytännössä siis ajattelin asiaa juurikin noina erikoiskäsittely-yksiköinä eli AVX:llä voi suorittaa tietyn kuorman huomattavasti nopeammin kuin traditionaalisilla tavoilla. Samoin nuo mainitsemasi pakkauskiihdytykset menevät samaan kategoriaan. IBM:n Z-prossuissa on tähän suuntaan menty jo jonkun aikaa eli siellä on joko rautatason kiihdytinyksiköitä tai omia konekäskyjään ainakin Javalle, pakkaukselle ja salaukselle. Noissa isoissa möhköfanteissa on myös jo pitkään käytetty AMD:n nyt tuomaa "erillinen IO-piiri"-tyyppistä toteutusta. Käytännössä L4-välimuisti (672MB) ja IO-ohjain on eriytetty erilliseen piiriin, joka jaetaan kuuden prossun kesken. Jokaisessa prosessorissa on 10 ydintä, jotka taas jakavat oman 128MB L3-kakun. Jokaisella corella taas on oma 2/4MB L2 ja 128KB/128KB L1 sekä uutena nyt ydinkohtainen salauskiihdytinyksikkö (ennen oli vain yksi kryptoyksikkö per prossu). Power9-puolella IBM (IBM:ää nyt sen takia kun ei näitä vaihtoehtoja paljoa ole) taas myyvät kokonaisuutta hyvin vahvasti tekoälylaskentaan ja nimenomaan Nvidian Volta-GPU:iden kanssa eli näyttäisi tuo "aluekohtainen kiihdytys" ja räätälöinti lisääntyvän.

Toki rautatason kiihdytysten lisääminen on vaarallista, koska standardin muuttuessa on piirisuunnittelussa paljon hitaampaa pysyä perässä ja erehdykset voivat käydä kalliiksi. Esimerkiksi noi IBM Z:n Java-kiihdytykset saivat hieman uutta mietintää kun Oracle vastikään muutti Java-kehityspakettinsa maksulliseksi. Toki OpenJDK jne, mutta kyllä tuo vaikuttaa Java-ekosysteemin suosioon. Js/jit on suht turvallinen ARM:lle, mutta on se silti isompi riski kuin tunkea joku yleispätevä H.264-kiihdytys piirille. Kun saisi js:ään monisäietuen...mutta se nyt on enemmänkin kielen ja toimiympäristön(web) rajoite.

Mutta siis jos nyt tulkistin oikein: 1) Jos halutaan lisätä normiytimiä paljon, niin jossain kohti loppuu yhdestä piiristä pinta-ala ja alkaa latenssitaiteilu useiden piirien välillä joka näyttäisi tarkoittavan ainakin isompia ja useamman tason välimuisteja koska valon nopeus asettaa väylille rajat. Prossuytimien määrä tai enemmänkin nopeus/watti-suhde mahdollisimman pienessä tilassa = jatkuva tarve yhä enemmän virtualisoiduissa konesaleissa. 2) Kotikäyttäjälle taas ytimien mahdoton lisääminen ei järkevää ja tullaan tod.näk näkemään enemmänkin tietyn alueen kiihdytyskäskylaajennoksia ja/tai niitä nopeuttavia sisäisiä laskentayksiköitä. 3) Läppäripuolella taas energiapihistely voi tuoda mielenkiintoisia ratkaisuja pöytään esim. näitä eri nopeuksisia piirejä. Applellahan taitaa olla jo läppäreitä joissa kevyelle kuormalle ARM ja sitten raskaampaan x86.

 

[Warfe]

Se nyt on ollut selvää että kehitys on ollut heikkoa viimeisen kymmenen vuotta, mutta vasta tuon vanhan koneen päivityksessä silmät itselläni aukesivat todella. Kymmenen vuotta vanhaan emolevyyn vaihdoin @Zetteri opastuksella i7 920 (4c/8t) tilalle Xeon X5675:n (6c/12t) Ebaysta 40€. Tästä olen meuhkannut täällä jo aikaisemminkin, mutta silti: kahdeksan vuotta vanha prossu kellotettuna kamppailee jokseenkin tasapäisesti uusien kaupassa olevien kanssa. Toki 4,5GHz vakaa kellotus vaatii kunnon siilin, mutta tuon lämpenemisen voi melkeinpä kuittaa pelkästään 32nm prosessin piikkiin. Tietenkin on ollut aikansa tykki palvelinprossu, on tullut parempaa AVX:ää, arkkitehtuuria viilailtu jnejne, mutta pointti on että jo vuonna 2011 oli Intelillä prossuja joiden tekniikka pärjää nykypäivänkin tarpeissa/kilpailussa. Lisäksi noita lisäytimiä (enemmän kuin neljä) alkoi näkyä kuluttajille 9v jälkeen vasta kun AMD toi Zenin markkinoille. Sitä ennen ei muka ollut tarvetta. :s

Vaikkei ihan suoraan voikaan verrata, mutta kumminkin: Miten huippu-GPU vuodelta 2011 (esim. GTX 480) pärjäisikään nykypäivänä?

https://gpu.userbenchmark.com/Compare/Nvidia-RTX-2080-vs-Nvidia-GTX-480/4026vs3157 oisko tuos suuntaa antava?

 

[vemkki]

Wccftechissä oli EPYCin ja Intelin serveriprosessorien vertailua AWS-pilvipalvelussa. Intel löylyttää AMD:tä testeissä pahemmin kerran myös hinta/suorituskyky-suhteessa. Testitulokset ovat Inteliltä peräisin, ja AMD:ltä mukana on tietysti ensimmäisen sukupolven EPYC. Veikkaan, että tästä seuraa lähiviikoiksi mielenkiintoinen kuhina erinäisillä tekniikkasaiteilla.
First Look: Intel vs AMD EPYC AWS Cloud (IaaS) Benchmarks

 

[svk]

Wccftechissä oli EPYCin ja Intelin serveriprosessorien vertailua AWS-pilvipalvelussa. Intel löylyttää AMD:tä testeissä pahemmin kerran myös hinta/suorituskyky-suhteessa. Testitulokset ovat Inteliltä peräisin, ja AMD:ltä mukana on tietysti ensimmäisen sukupolven EPYC. Veikkaan, että tästä seuraa lähiviikoiksi mielenkiintoinen kuhina erinäisillä tekniikkasaiteilla.
First Look: Intel vs AMD EPYC AWS Cloud (IaaS) Benchmarks

Kaikki testit oletettavasti osaa hyödyntää AVX-512 käskykantaa, mitä yksikään epyc ei tue. Zen 2 epyceissä ero luultavasti tasoittuu

 

[hkultala]

Kaikki testit oletettavasti osaa hyödyntää AVX-512 käskykantaa, mitä yksikään epyc ei tue. Zen 2 epyceissä ero luultavasti tasoittuu

Ei kaikki vaan n. puolet.

* specINT rate - int, ei käytä AVX-512stä ainakaan merkittävissä määrin, ei käytännön vaikutusta tulokseen
* specFP rate - hyötyy selvästi AVX-512sta. muutama osatesti ei välttämättä hyödy.
* specINT rate 1 copy estimated - tällaisten lukuejen esittäminen ylipäätään on hyvin kyseenalaista. Spec-testissä on ne perustulokset (ei rate) joiden pitäisi kertoa se yhden säikeen suorituskyky, en tajua että mitä näillä luvulla haetaan.

* STREAM OMP Triad- Todennäköisesti käyttää AVX-512sta ja hyötyy siitä suuresti

* Server side Java JVM - ei (juuri) hyötyne AVX-512sta
* Wordpress PHP/HHVM - ei (juuri) hyötyne AVX-512sta
* Hammer and postgresql - ei (juuri) hyötyne AVX-512sta
* MongoDB - ei (juuri) hyötyne AVX-512sta

* LAMMPS - todennäköisesti käyttää AVX-512sta ja hyötyy siitä suuresti
* High Perf Linpack - todennäköisesti käyttää AVX-512sta ja hyötyy siitä suuresti


Eli siis, testeissä missä AVX-512sta ei ole (juurikaan) iloa, intel oli keskimäärin sen n. 30% edellä. Testeissä, joissa AVX-512sta voidaan hyödyntää kunnolla, intel oli keskimäärin hiukan yli tuplasti nopeampi.



Siitä, tukeeko zen2 AVX-512sta ei ole varmuutta. Ja vaikka tukisi, sen AVX-512-toteutus olisi silti throughput-nopeudeltaan n. puolet skylake-SP-XCC:n AVX-512-throughput-nopeudesta (koska siinä on vain 256-bittinen SIMD-datapolku, intelillä 512-bittinen; jos zen2 tukee AVX-512sta, se joutuu pilkkomaan 512-bittiset vektorit kahteen palaan). Mutta zen2n myötä ero tosiaan kapenee selvästi (vaikka ei tukisi AVX-512sta, ihan sillä, että 256-bittisitä AVXää suorittaa nopeammin), muttei katoa.

 

[TheMeII]

Mutta zen2n yötä ero tosiaan kapenee selvästi (vaikka ei tukisi AVX-512sta, ihan sillä, että 256-bittisitä AVXää suorittaa nopeammin), muttei katoa.

Miksi AMD ottaa noita käyttöön pala kerrallaan ja koko ajan inteliä jäljessä? Onko niissä jotain lisenssimaksuja jolloin ne otttaa niitä vasta kun niiden puuttuminen tekee liian ison loven suorituyskykyyn vai onko ne vaan hankala / kallis implementoida joten niitä tehdään taso kerrallaan eteenpäin ja menisi liikaa aikaa saada kaikki toimimaan niin lisätään niitä rauhallisesti.

 

[hkultala]

Miksi AMD ottaa noita käyttöön pala kerrallaan ja koko ajan inteliä jäljessä? Onko niissä jotain lisenssimaksuja jolloin ne otttaa niitä vasta kun niiden puuttuminen tekee liian ison loven suorituyskykyyn vai onko ne vaan hankala / kallis implementoida joten niitä tehdään taso kerrallaan eteenpäin ja menisi liikaa aikaa saada kaikki toimimaan niin lisätään niitä rauhallisesti.

Ei ole mitään lisenssimaksuja, AMDllä ja intelillä on ristiinlisensointisopimus.

ja ihan samalla tavalla intel ottaa käskykantalaajennoksia käyttöön "pala kerrallaan".

ja AMD on kyllä joissain käskykantalaajennoksissa ollut Inteliä edellä, esim. Bulldozerissa oli FMA-käskyt selvästi ennen Inteliä, jolla ne tuli vasta Haswellissa. (Toki vasta piledriverissa tuli intelin kanssa yhteensopiva FMA3, mutta se oli silti n. vuoden haswelia aiemmin ulkona). Ja nyt ryzenissä on CLZERO jota intel ei vielä tue missään prosessorissaan.

Oleellinen asia on tuotekehitysaika, AMD teki todella hyvää työtä tuodessaan zenin ulos niin hyvänä ja niin nopeasti kuin se tuli, ei siltä enempää olisi oikein voinut vaatia. Leveämpi SIMD-datapolku päätettiin jättää seuraavaan versioon, zen2een.

Leveät SIMD-yksiköt ja niihin liittyvät rekisterit ja datapolut eivät myöskään ole ilmaisia, ja zen olisi myös ollut isompi ja kalliimpi ydin 256-bittisellä SIMD-datapolulla. Ja 256-bittisten AVX-käskyjen suorittaminen 128-bittisellä datapolulla sujuu vielä melko mukavasti pienellä hidastuksella pilkkoen ne kahteen osaan, mutta AVX-512-käskyt olisi tarvinnut pilkkoa neljään osaan niiden suorittamiseksi 128-bittisellä datapolulla.

Lisäksi AVX-512 on muutenkin selvästi monimutkaisempi käskykanta, ja se vaatii monimutkaisempaa kontrollia kuin AVX/AVX2. Tämä taas tuntuu nimenomaan siinä tuotekehityksen määrässä/ajassa.

Ja AMDllä on myös strategia, että AMD pyrkii saamaan datarinnakkaisen koodin ajettavaksi GPUlla, siinä missä Intelin strategia on enemmän suorittaa kaikki CPUlla. Tämä motivoi inteliä leventämään SIMDiä aggressiivisemmin, kun taas AMD haluaa enemmän pitää CPU-ytimet pienenä ja mielummin laittaa niitä GPU-ytimiä sinne samalle piirille.

 

[Zetteri]

Vaikkei ihan suoraan voikaan verrata, mutta kumminkin: Miten huippu-GPU vuodelta 2011 (esim. GTX 480) pärjäisikään nykypäivänä?

https://gpu.userbenchmark.com/Compare/Nvidia-RTX-2080-vs-Nvidia-GTX-480/4026vs3157 oisko tuos suuntaa antava?

Tässä oma vastaukseni tuohon kysymykseen
Niin että GTX 480:n on vieläkin kova ja hakkaa uudet low end kortit vieläkin kaikkien näitten vuosien jälkeen.

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