Virallinen: AMD vs Intel keskustelu- ja väittelyketju

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

 

[BOT]

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.

 

[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

 

[BOT]

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.

 

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

 

[hkultala]

Liittyy tänne vääntöön siitä, millaista on hyvin optimoitu vs huonosti optimoitu koodi:

Case-tapaus koodin optimoinnista: WiF-lautapelin ilmataistelun todennäköisyyslaskuri

 

[Fenotype]

Jokos niitä Intelin CPUn uusimpia haavoittuvuuksia on saanut julkaista?
Skylake ja siitä uudemmat
Ei ainakaan uutista ole ollut vielä iotekissä?

 

[TheMeII]

Jokos niitä Intelin CPUn uusimpia haavoittuvuuksia on saanut julkaista?
Skylake ja siitä uudemmat
Ei ainakaan uutista ole ollut vielä iotekissä?

Kukas niitä on nyt löytäny?

 

[Emeron]

Jokos niitä Intelin CPUn uusimpia haavoittuvuuksia on saanut julkaista?
Skylake ja siitä uudemmat
Ei ainakaan uutista ole ollut vielä iotekissä?

Onko jossain muualla ollut tälläisia uutisia?

 

[Marco Polo]

Muuten missä ne hirveät Intelin haavoittovuuksia hyödyntävät virukset yms. on? Aukot ovat olleet jo pienen ikuisuuden tiedossa ja monien eri foorumien punalasisten mukaan Intelin käyttäjien päivät olivat luetut. Kumma kun en ole kuullut vielä yhdestäkään isosta viruksesta, joka hyödyntäisi näitä "hirveitä" aukkoja, vaikka aikaa on kulunut jo vaikka kuinka niiden paljastumisesta.. Luulisi että ainakin yksi tälläinen virus olisi isosti ollut uutisissa, kun valtaosa koneista käyttää Inteliä kuitenkin..

Taisi kuitenkin olla niin, että niiden "valtavien" aukkojen hyödyntäminen käytännössä ei onnistunutkaan ainakaan haittaa aiheuttavasti ja juttu jäi enemmän teoria tasolle kuten itse alun alkaen arvelinkin.

Onko tästä täällä keskusteltu vielä?

 

[svk]

Muuten missä ne hirveät Intelin haavoittovuuksia hyödyntävät virukset yms. on? Aukot ovat olleet jo pienen ikuisuuden tiedossa ja monien eri foorumien punalasisten AMD:n tukijoiden mukaan Intelin käyttäjien päivät olivat luetut. Kumma kun en ole kuullut vielä yhdestäkään isosta viruksesta, joka hyödyntäisi näitä "hirveitä" aukkoja, vaikka aikaa on kulunut jo kuinka niiden paljastumisesta.. Luulisi että ainakin yksi tälläinen virus olisi isosti ollut uutisissa, kun valtaosa koneista käyttää Inteliä kuitenkin..

Taisi kuitenkin olla niin, että niiden "valtavien" aukkojen hyödyntäminen käytännössä ei onnistunutkaan ainakaan haittaa aiheuttavasti ja juttu jäi enemmän teoria tasolle kuten itse alun alkaen arvelinkin.

Onko tästä täällä keskusteltu vielä?

Aika äkäseen noita patchejä on jaettu windows päivitysten kautta, joten ei kovin montaa haavoittuvaa konetta taida olla enää olemassa, poislukien museokoneet joihin ei paikkausta tipu.

 

[Marco Polo]

Aika äkäseen noita patchejä on jaettu windows päivitysten kautta, joten ei kovin montaa haavoittuvaa konetta taida olla enää olemassa, poislukien museokoneet joihin ei paikkausta tipu.

Käsittääkseni kuitenkaan kaikkia haavoittuvuuksia ei ole korjattu. Saa korjata jos olen väärässä. Enkä usko että kaikki käyttäjät ovat päivittäneet koneitaan ja kuten sanoit kaikilla ei ole uusimpia Windowsseja käytössä. Luulisi että joku oli jo näihin koneisiin hyökännyt. Siitä olisi kyllä tullut niin iso juttu, että luulisi että oltaisiin kuultu, mutta mitään ei ole tapahtunut.

 

[svk]

Käsittääkseni kuitenkaan kaikkia haavoittuvuuksia ei ole korjattu. Saa korjata jos olen väärässä.

tarkoitat noita uusia reikiä? Jotain olin lukevinaan et uusia olisi löytynyt...

E. Tutkijat julkistivat seitsemän uutta Spectre- ja Meltdown-sivukanavahyökkäystä olikin jo marraskuussa uutisoitu

 

[Marco Polo]

tarkoitat noita uusia reikiä? Jotain olin lukevinaan et uusia olisi löytynyt...

E. Tutkijat julkistivat seitsemän uutta Spectre- ja Meltdown-sivukanavahyökkäystä olikin jo marraskuussa uutisoitu

Niin ja muistaakseni kaikkiin noita edeltäviinkään ei saatu Windows patchia. Ainakaan kaikkiin variantteihin haavoittuvuudesta, jos muistan nyt oikein ja olen ajantasalla asiasta.

 

[TheMeII]

Niin ja muistaakseni kaikkiin noita edeltäviinkään ei saatu Windows patchia. Ainakaan kaikkiin variantteihin haavoittuvuudesta, jos muistan nyt oikein ja olen ajantasalla asiasta.

Sekä HT että SMT altistaa osalle niistä ja siksi esim turvalliset linux jakelut disabloi ne softatasolla jos ei ole raudalla suljettu.

 

[Jho]

Niin ja muistaakseni kaikkiin noita edeltäviinkään ei saatu Windows patchia. Ainakaan kaikkiin variantteihin haavoittuvuudesta, jos muistan nyt oikein ja olen ajantasalla asiasta.

Mitäköhän ajat takaa tällä vänkäämisellä asiasta? Eiköhän kaikki tajua että ilman näitä patcheja homma olisi paljon vaarallisempi mitä se nyt on. Ei Intel ja muut olisi tehnyt koko patcheja sillä vauhdilla millä tekivät jos niistä ei olisi suurempaa haittaa ollut.

edit: turhaa mutuila ilman lähteitä ei kannata edes alottaa, tietää mitä siitä syntyy täällä.

 

[hkultala]

Sekä HT että SMT altistaa osalle niistä ja siksi esim turvalliset linux jakelut disabloi ne softatasolla jos ei ole raudalla suljettu.

"HT ja SMT".. mitähän ihmettä olet tarkoittavinaan puhuessasi noista erillään?

Intelin core sarjassa "hyperthreading" on vain markkinointinimi SMTlle. Ne ovat täsmälleen sama asia, oikealta nimeltään SMT.

Sen sijaan joissain itaniumeissa ja muinaisissa Atomeissa on täysin erilaisia tekniikoita, joita intel myös harhaanjohtavasti kutsuu samalla markkinointinimellä.

Ja SMT ei millään tavalla altista Spectrelle/Meltdownille ja muille toisen sukupolven sivukanavahyökkäyksille. Pikemminkin se vaan häiritsee niiden toimimista, kun ajoitukset muuttuu satunnaisesti toisen säikeen tehdessä omia juttujaan samalla ytimellä.

SMT voi vaan toimia hyökkäysrajapintana 1. sukupolven sivukanavahyökäyksille, joissa hyökätään sellaista (huonosti koodattua) softaa vastaan, jossa on salatun datan perusteella haarautumisia.

 

[TheMeII]

"HT ja SMT".. mitähän ihmettä olet tarkoittavinaan puhuessasi noista erillään?

Intelin core sarjassa "hyperthreading" on vain markkinointinimi SMTlle. Ne ovat täsmälleen sama asia, oikealta nimeltään SMT.

Käytin niitä markkinointinimillään että kukaan ei luule että vain toisen valmistajan versio on haavoittuvainen.

SMT voi vaan toimia hyökkäysrajapintana 1. sukupolven sivukanavahyökäyksille, joissa hyökätään sellaista (huonosti koodattua) softaa vastaan, jossa on salatun datan perusteella haarautumisia.

Selvä. muistan vain että kun näistä oli juttua joku distro sano että tämä/nämä tietyt versiot ei toimi heillä kun ne käyttää ht:ta ja heän distro disabloi sen joka tapauksessa tms jotain. Sinähän se tässä ammattilainen olet.

 

[hkultala]

Käytin niitä markkinointinimillään että kukaan ei luule että vain toisen valmistajan versio on haavoittuvainen.

Selvä. muistan vain että kun näistä oli juttua joku distro sano että tämä/nämä tietyt versiot ei toimi heillä kun ne käyttää ht:ta ja heän distro disabloi sen joka tapauksessa tms jotain. Sinähän se tässä ammattilainen olet.

Sekoitat "Portsmashiin" joka on vain uusi 1. sukupolven sivukanavahyökkäys. Se perustuu SMThen.

Sillä voi vaan lukea salausavaimen huonosti koodatusta kryptosoftasta, jota ajetaan toisella virtuaaliytimellä. Ja sen hyödyntäminen tosimaailmassa on hyvin vaikeaa.

Kun taas spectrellä ja meltdownilla voi oikeasti "päästä hiekkalaatikosta ulos", ja niiden hyödyntäminen on selvästi helpompaa.

Kyse on aivan eri kaliiberin ja vakavuusasteen hyökkäyksistä, "Portsmashiä" ei pidä sekoittaa Spectreen/Meltdowniin(2. sukupolven sivukanavahyökkäyksiin), vaikka se julkaistiinkin niiden jälkeen.

 

[Griffin]

Tosin mites nopeaa tuo datan luku on noilla sivukanavahyökkäyksillä (tavua / sekunti)? Ja minkä aikaa pitää ensin kalibroida ja rasittaako hyökkäys esim ytimen / ytimiä tappiinsa?
Mites käy, jos kellot hieman heittelee koneessa, meneekö homma pieleen.