Virallinen: AMD vs Intel keskustelu- ja väittelyketju

  • Keskustelun aloittaja Keskustelun aloittaja Sampsa
  • Aloitettu Aloitettu
Onhan se, tosin ei johdu niinkään prosessoreista itsestään vaan Radeon Groupin tuottamasta GPUOpen kirjastosta jota peliin on käytetty.
Softaa ei kyllä pitäisi kehittää sillä periaatteella, että heti kun se menee kääntäjästä läpi -> tuotantoon. Ja tuollainen munaus olisi pitänyt näkyä testauksessa jos se olisi tehty kunnolla.
 
AMD:n Ryzen prossut ovat jo monta vuotta olleet varteenotettava vaihtoehto pelitietokoneeseen, joten luulisi vuoden suurimman pelin pystyvän ihan hyvin tukemaan AMD:nkin prossuja. En kyllä tässä tapauksessa mitenkään saa tuota mokaa AMD:n syyksi.

Mokaa?

Kyllä Ryzenit ovatkin ihan ok prosessoreita olleet, varsinkin hintalaatu suhteelta, mutta tähän asiaan liittyen niin onhan niitä lukemattomia muitakin esimerkkejä missä AMD:n yhtätehokkailla prossuilla pelit pyörii huonommin kuin Intelillä. Turha siitä on peliyrityksiä syyttää, jos tietoisesti ostaa prossuvalmistajaa josta tiedetään että se ei kaikissa peleissä toimi niin hyvin kuin kilpailija. Jos kyse olisi yksittäisesti poikkauksesta niin olisin samaa mieltä, mutta näitä pelejä on aika paljon.

Jos taas haluaa että kaikki pelit toimii hyvin (olettaen ettei kyseessä ole huonosti optimoitu peli tai vain liian raskas nykyteknologialle) niin silloin ostaa tehokkaan Intelin. Nämä on valintoja jota jokainen voi tehdä.


Osta AMD:ta tilalle, niin ei tarvitse oman valinnan aiheuttamaa mielipahaa purkaa forumeilla.

Mielipahaa? Ei minulla mitään mielipahaa ole. Puhun asioista suoraan objektiivisesti kylläkin täällä ja se ei kaikkia miellytä, mutta en olekkaan täällä kaikkia miellyttämässä.


Eli Cyberpunkissa oleva selvä bugi on jotenkin AMD:n syy? Hyvin sinäkin vedät

Selvä bugi? Mistä tiedät ettei Cyperpunkin kehittäjät ole tehneet tätä ihan tietoisesti tälläistä teknistä toteutusta?

Jos viittaat siihen rekisteri editori fixiin niin monen hyvin tunnetun ja kunnieitun it-sivuston mukaan siitä ei ole ollut käytännössä hyötyä vaan pikemminkin enemmän haittaa (cyperpunk ketjussa enemmän tästä).

Enkä sanonut että tämä olisi AMD:n syy vaan että kummastelen kuluttajia jotka ostaa AMD:tä ja sitten valittavat kun jokin peli ei toimi niin hyvin kuin Intelillä vaikka tälläinen kaava on lukuisissa peleissä ollut jo vuosia.
 
Mokaa?

Kyllä Ryzenit ovatkin ihan ok prosessoreita olleet, varsinkin hintalaatu suhteelta, mutta tähän asiaan liittyen niin onhan niitä lukemattomia muitakin esimerkkejä missä AMD:n yhtätehokkailla prossuilla pelit pyörii huonommin kuin Intelillä. Turha siitä on peliyrityksiä syyttää, jos tietoisesti ostaa prossuvalmistajaa josta tiedetään että se ei kaikissa peleissä toimi niin hyvin kuin kilpailija. Jos kyse olisi yksittäisesti poikkauksesta niin olisin samaa mieltä, mutta näitä pelejä on aika paljon.

Jos taas haluaa että kaikki pelit toimii hyvin (olettaen ettei kyseessä ole huonosti optimoitu peli tai vain liian raskas nykyteknologialle) niin silloin ostaa tehokkaan Intelin. Nämä on valintoja jota jokainen voi tehdä.
Niin, että maailman ääriin pitäisi ostaa Inteliä, koska joskus on ollut pelejä, joissa Intel toimii paremmin? Kyllä se on pelintekijän moka jos vieläkin onnistutaan peli ryssimään noin. Ei siinä, onhan tuo Cyberpunk muutenkin buginen läjä paskaa, kuten itse ennen julkaisua veikkasinkin.

Onko se mielestäsi prossunvalmistajan vika jos pelinkehittäjät eivät jostain syystä osaa tehdä peliä, joka toimii kaikenmerkkisellä raudalla? Ei se prossunvalmistaja varsinkaan tuolle voi paljoa mitään tehdä jos pelinkehittäjät ovat kädettömiä ja jämähtäneet johonkin mooseksen aikaiseen Intelin rautaan.
 
Melkein voisi ryzeniä laittaa koneeseen, mutta ei kehtaa ajella alle vitosen kelloilla vuonna 2020...

Mahtaakohan vanhat jäähyt toimia alder lakella? Näyttää olevan aika paljon isompi chippi kun aikasemmat
 
Melkein voisi ryzeniä laittaa koneeseen, mutta ei kehtaa ajella alle vitosen kelloilla vuonna 2020...

Mahtaakohan vanhat jäähyt toimia alder lakella? Näyttää olevan aika paljon isompi chippi kun aikasemmat

Ja tässä taas oikein mainio esimerkki siitä kun ei ymmärretä mitään.

Niillä kikaherzeillä ei loppupelissä ole mitään merkitystä, vai ajattelitko vaikka 5v päästä edelleen hyrskytellä sillä 5GHz intelillä vaikka amd:llä olisi tuplasti tehokkaampi prossu ulkona joka ei kellotu kuin 4GHz:n?
 
Niin, että maailman ääriin pitäisi ostaa Inteliä, koska joskus on ollut pelejä, joissa Intel toimii paremmin? Kyllä se on pelintekijän moka jos vieläkin onnistutaan peli ryssimään noin. Ei siinä, onhan tuo Cyberpunk muutenkin buginen läjä paskaa, kuten itse ennen julkaisua veikkasinkin.

Onko se mielestäsi prossunvalmistajan vika jos pelinkehittäjät eivät jostain syystä osaa tehdä peliä, joka toimii kaikenmerkkisellä raudalla? Ei se prossunvalmistaja varsinkaan tuolle voi paljoa mitään tehdä jos pelinkehittäjät ovat kädettömiä ja jämähtäneet johonkin mooseksen aikaiseen Intelin rautaan.
Kyllä se voi olla prossuvalmistajan vika jos se sille pitää kodata ihan erillä tapaa kun toiselle. Tyyliin jotkut ekojen ryzenien järkyttävän hitaat käskyemulaatiot joilla ei tee mitään.

Cyberpunkissa kyse ei ole siitä. 6 ytimiselle ht-intellille käynnistetään 12 threadia ja 6 ytimiselle ht-amdlle 6 threadia. Kyse on vaan typerästä pelintekijöiden bugisesta koodista. Tästä saa ja pitää valittaa.
 
Pakko antaa pientä sivukommenttia tuosta että Intelillä toimii paremmin pelit kuin AMD:llä. Että viimevuonna kun testailin X79 Inteleitä sekä 1000- ja 2000-sarjan Ryzeneita niin nuo Intelin kamat hakkasivat nuo Ryzenit... no kaikissa peleissä.
Mutta mitä nyt testaillut niin esim remastoroidussa Crysiksessa mikä ei edes käytä paljoa säikeitä nuo Ryzenit vievät noita X79 kamoja ihan miten vaan. Eli samassa kohdassa peliä 6c/12t 3930K@4.6GHz ja 6c/12t 4930K@4.7GHz:lla peli pörräsi siinä 60-70fps:ssä ja ihan Ryzen 7 1700@4.0GHz:llä oltiinkin sitten sadassa ja vähän ylikin.
Hauskasti tuossa samassa kohdassa Athlon 200GE@3.95GHz paukutti tupla ytimellä ja neljällä säikeellä samoja fps:iä kuin nuo X79 Intelit. Toki tuolla Athlonilla frame timet olivat... no aika paskaa, mutta hieno suoritus tuolta Athlonilta kumminkin.

Että jokin on muuttunut vuodessa, kenties pelejä optimoidaan nykyään myös Ryzeneille ?
Mutta ei minulla muuta tältä erää ja jatkakaa vaan väittelyitänne :)
 
Nämä suurimmatkaanvänkkääjät ja puolustelijat eivät edes omista sitä huippu prossua, saatikka sitten sellaista näytönohjainta joka ottaisi kaiken irti siitä prossusta kuten rauta saittien testeissä.

Joten onko sillä silloin väliä onko sillä Ryzen/Intel muutaman Fps erolla benchmarkeissa väliä jos ei edes omista niitä huippu nopeita muisteja,huippu näytönohjainta jne..
Muuta kuin pelkän kannatuksen kannalta kun voi vertailla "pituuksia" joita itseltä ei edes löydy.

Kyllä nämä pelit toimii pelattavasti vaikka muutamaia Fps jälkeen toinen valmistaja jäisikin, olkoon sitten kyseessä cyberpunkki tai mikä tahansa peli.
 
Kyllä se voi olla prossuvalmistajan vika jos se sille pitää kodata ihan erillä tapaa kun toiselle.
Tyyliin jotkut ekojen ryzenien järkyttävän hitaat käskyemulaatiot joilla ei tee mitään.

Se, että siellä on jostain äärimmäisen harvoin käytettävästä käskystä mikrokoodilla toteutettu versio ei tee siitä mitään" emulointia" ja niillä nimenomaan tekee hyvin paljon, niillä tekee sen, että niitä käyttävät softat toimii.

Jos yksi sellainen käsky suoritetaan keskimäärin miljoonan kellojakson välein, sillä, että siihen menee parisataa kellojaksoa ei ole kokonaissuorituskyvyn kannalta mitään väliä.

Toki jos joku softa haluaakin käyttää niitä keskimäärin vaikka tuhannen eikä miljoonan kellojakson välein, silloin sillä alkaakin olemaan jo huomattavasti väliä, mutta siltikin edelleen sillä käskyllä tekee hyvin paljon. Sillä tekee silti sen, että se softa toimii.


Erot Intelin prossujen ja Ryzenien välillä optimoinnin suhteen on käytännössä hyvin pieniä. Molemmissa on samankokoiset välimuistilinjat, joka on oleellinen asia mm. sen kannalta, miten data kannattaa sijoitella muistiin, ja miten dataa voi pilkkoa palasiksi jaettavaksi monelle ytimelle ilman että false sharing tulee ongelmaksi. Molemmat on moderneja OoOE-prossuja jotka eivät tarvi tarkkaa käskyskedulointia, vaan osaavat itse skeduloida suorituksensa, kunhan inputissa on vaan jotain järkeä (ja joo, yhdessä todellisessa pelissä vastaan tuli yksi tapaus, jossa inputissa ei ollut järkeä, tästä alempana lisää).

Zen2sta lähtien sekä Intelin että AMDn työpöytäprossuissa on myös ollut sama tilanne SIMD-käskykantojen suhteen, eli että sieltä löytyy 256-bittisellä toteutuksella oleva AVX2. Ja Zen1 jo tuki AVX2sta, tosin puolinopeusimplementaatiolla, mutta eipä siinäkään SSE4:n käyttäminen sen AVX2n sijasta juurikaan hyödyttänyt, joten käytännössä optimointi AVX2lle on ollut järkevää jo vuosien ajan molempien prossuilla.

Suurin ero optimoinnista Zen-sarjan ja intelin prossujen välillä tulee käytännössä Zenin CCX-rakenteesta, että miten asioita kannattaa säikeistää ja säikeiden jakaa dataa keskenään, intelillä on yksi jaettu L3-välimuisti, Zenillä taas useampia erillisiä L3-välimuisteja, ja jos samaa dataa käpistelee eri CCXssä olevat ytimet, tästä voi seurata epäoptimaalisuuksia. Mutta Zen3 muuttaa tätäkin lähemmäksi Inteliä, kun Zen3ssa saman L3-kakun jakavien ytimien määrä noysee kahdeksaan, ja Intelilläkään ei toisaalta seuraavassa sukupolvessa tule enempää kuin kahdeksaa ydintä, 10-ytimiset intelin työpöytäprossut jäi hyvin harvinaisiksi välimalleiksi.

Ja joo, Zen1llä ja Zen2lla oli niitä joitain yksittäisiä hyvin hitaita käskyjä(pdep, pext), mutta ne ei ole mitään sellaisia käskyjä joita tyypillisesti suoritetaan usein. Ja jotkut jonkin verran useammin mutta silti melko harvoin käytetyt käskyt (mm. gather) on myös selvästi (muttei tähtitieteellisesti) hitaampia kuin lake-sarjan prossuilla, mutta näiden nopeus on sellainen että sen tekemiseen mitä niillä tehdään ei ole mitään nopeampaakaan tapaa, niitä haluaa silti käyttää Zen1/zen2llakin.

Tapaus ashes of singularity:
Ja joo, Zenillä oli store-to-load-forwarding ei toimi usean non-temporal storen yli, ja tällaisen jälkeen dataa lataava load hidastui todella paljon. Vanha visual studio 2015 teki koodia, jossa nämä käskyt oli tässä "väärässä järjestyksessä" visual studio 2017 oli jo korjattu siten, että se skeduloi käskyt siten, että se store-to-load-forwarding toimii paljon useammin (eli siis toimii mm. ashes of singularityn tapauksessa).

Tosin se, että kirjoitetaan koodia jossa talletetaan arvo non-temporal storella ja sen jälkeen heti perään ladataan se on muutenkin typerää koodia ja veren kerjäämistä nenästä; Tämän koodin kuuluisikin olla hidasta. Se, että se joillain prossuilla tai kääntäjillä toimii nopeasti on pikemminkin hyvää tuuria.


Lähinnä optimoinnissa AMDn ja Intelin prossujen välillä oleellista eroa tulee siinä vaiheessa kun Intel julkaisee AVX-512sta tukevat työpöytäprossut, että tällöin motivaatio alkaa optimoimaan softia sille kasvaa selvästi. Paitsi että ei ehkä kasvakaan, koska tätä iloa saadaan ehkä nauttia alle vuoden kunnes se ehkä jälleen katoaa Adler Lakessa. Ja tällöin se saattaakin kääntyä toisinpäin, että AMDllä voi Zen4ssa olla AVX-512 mutta Intelillä Adler Lakessa ei.

(IMHO käsittämätöntä tunarointia Inteliltä että edes AVXää ei ole saatu tuotua kaikkiin tuotteisiin (Lakefield) n. 9 vuotta sen ensimmäisen tulemisen jälkeen , ja AVX-512-tuen suhteen tuki on satunnaisissa tuotteissa, eikä ollenkaan työpöytäkoneissa, joita softankehittäjät pääsiassa käyttää; Vaikka sen eka implementaaatio (Skylake-SP/Skylake-X/Cascade Lake) on ollut suorituskyvyn kannalta huonohko, se, että se olisi tuettu edes jossain normaaleissa työpöytämalleissa mahdollistaisi sen, että softankehittäjät voisivat helpolla hankkia edes normaalin työpöytäkoneen, jossa testata sitä, mutta eipä sitten Intel saanut aikaiseksi tuoda edes Skylake-SP-ytimiä työpöytäkannoille, eikä myöskään Cannon Lakesta tai Ice Lakesta tullut mitään malleja työpöytäkannoille)
 
Viimeksi muokattu:
Mikroarkkitehtuuri on yksi asia, mutta toinen missä AMD yllätti Intelin housut kintuissa oli Chiplet-pohjainen prosessoriarkkitehtuuri. Intelin prosessorit ovat edelleen monoliittisia, mikä tekee hyvin hankalaksi valmistaa niitä samoilla ydinmäärillä mitä AMD tekee - ja vaikka se teknisesti onnistuisi, olisi tuollainen saantojen vuoksi kilpailukyvytön AMD:n kanssa.

Ensimmäisten vuotojen pohjalta Sapphire Rapids on idealtaan pitkälti ensimmäisen sukupolven EPYCin kaltainen: Ei erillistä I/O-sirua vaan kaksi isoa monoliittista sirua pultattu yhteen samoihin prosessorikuoriin. Seuraava sukupolvi Sapphire Rapidsin jälkeen siirtynee täysin AMD:n Rome/Milan-prosessorin malliin - mutta auttamattoman myöhässä.

EPYCin ensimmäisen sukupolven julkaisun jälkeen Intel haukkui AMD:n mallin lyttyyn - ja tuossa vaiheessa osaksi syystäkin - mutta nyt ovat tekemässä AMD:n perässä vaihe vaiheelta aivan samat temput.

Jälleen kerran pitää toistaa sama historiakatsaus, kun puhutaan kritiikitöntä mainoshömppää chipleteistä. "Chipletit" on ainoastaan epäsymmetristä MCM-paketointia, ja se on ikivanha juttu.

Intelillä on ollut epäsymmetrinen MCM vuonna 1995 Pentium Prossa, 15 vuotta ennen AMDn ensimmäistä MCMää ja 24 vuotta ennen AMDn ensimmäistä epäsymmetristä MCää.

Histoire_Pentium_Pro_cpu.jpg


Tämän jälkeen Intelillä on ollut symmetrinen MCM vuonna 2005 Pentium D:ssä (5 vuotta ennen AMDtä) sekä 2008 Core 2 Quad:ssa (2 vuotta ennen AMDtä).

intel_pentium_d_presler.jpg

1387-front.small.jpg


Tämän jälkeen Intelillä on ollut epäsymmetrinen MCM mm. Clarkdalessa/Arrendalessa/Westmeressä 2010 (9 vuotta ennen AMDn ekaa epäsymmetristä MCMää)

Arrandale-die.jpg


Tämän jälkeen Intel on tehnyt vaikka kuinka paljon epäsymmetrisiä MCMiä läppärehin, mutta energiatehokkuuden takia sellaisella ratkaisulla, että muistiohjain ja iGPU on samalla piilastulla kuin CPU-ytimet, ja toisella piilastulla on ollut vain perinteiset eteläsiltapiirin toiminnot:
7th-gen-core-16x9.png.rendition.intel.web.864.486.png


intel_core_8th_gen_mobile_cpu_678_678x452.png


71E9LuH0kKL._AC_SX466_.jpg

images

Tällaisia piirejä on ollut jatkuvasti vuosien ajan yhtämittaisesti markkinoilla Intelillä.

Ja lisäksi tuli MCM jossa samaan pakettin ängettiin vielä AMDn GPU:


images




Ei siis ole olemassa mitään AMDlle eksklusiivista ylivoimaista "chiplet-pohjaista arkkitehtuuria". On vaan MCM-paketteja, joihin laitetaan useampi piilastu samaan pakettiin.

Ja valmistustekniikat pienenee nopeammin kuin mitä CPU-ytimet kasvaa, ja lisäksi valmistustekniikat myös kallistuu pinta-alaansa nähden.


Kun muistiohjaimet integroitiin samalle piirille CPUn kanssa (AMD K8ssa 2003, Intel Nehalemissa 2008), se teki oikein hyvää suorituskyvylle, ja se oli se suunta, mihin Mooren laki on vääjäämättä menossa, koska valmistustekniikan pienenevät nopeammin kuin mitä ytimet kasvavat.

Nyt kun AMD (tietyissä piireissä, ei kaikissa) reversoi tämän ja toi muistiohjaimen pois samalta piilastulta, lisäten samalla muistiviivettä selvästi, AMD-fanipojat on kuorossa huutamassa kuinka tässä on tulevaisuus ja Intel on perässä.

Ei, AMD otti tässä askeleen taaksepäin, koska se sopi senhetkiseen AMDn markkinatilanteeseen.

Ja AMDllä edelleen läppärimallit on yhden piilastun SoC:eja, koska se muistiohjain siellä erillisellä piilastulla olisi vaan turhaa sähkönhaaskasta, lämmöntuottoa ja muistiviivettä.


Intel on päättänyt pitää muistiohjaimen samalla piilastulla ytimien kanssa, koska se mahdollistaa nopeamman muistiviiveen ja paremman energiatehokkuuden.

Ja jos tarvitaan enemmän monen säikeen suorituskykyä, Intelin strategia tähän on, että sitten laitetaan monta sokettia. Intelin palvelinprossut tukee paljon suurempaa määrä soketteja kuin AMDn, jolla maksimi on kaksi. Toki useamman soketin kanssa voi sitten tarvia softassa olla NUMA-optimoinnit, että se muisti ei käännykin hitaammaksi.
 
Viimeksi muokattu:
Meinaatko että saisivat kiinni tämän nykytilanteen vai että saisivat kiinni AMD:n siinä pisteessä kun sekin on päivittänyt tuotteensa ja valmistustekniikkansa (varmaan jo pariin otteeseen siinä välissä)?
Kysymys on hieman tulkinnanvarainen, saako A) arkkitehtuurillisesti kiinni suorituskyvyssä vai B) saako ydinmäärässä/tehonkulutuksessa? A ilmeisesti jo toteutuu ensikuussa, mutta B on taas todellisuudessa saako Intel kiinni TSMC:n prosessin, tuskin ihan heti.
 
Ja jos tarvitaan enemmän monen säikeen suorituskykyä, Intelin strategia tähän on, että sitten laitetaan monta sokettia. Intelin palvelinprossut tukee paljon suurempaa määrä soketteja kuin AMDn, jolla maksimi on kaksi. Toki useamman soketin kanssa voi sitten tarvia softassa olla NUMA-optimoinnit, että se muisti ei käännykin hitaammaksi.

No siis teoriassa mikään ei estäisi AMD:tä tekemästä vaikka neljän socketin EPYC alustaa. Siinä EPYC:ssä on 4kpl PCI-e 16x linkkejä varattu socket to socket seurusteluun, siitä vaan tulisi huomattavasti hitaampi linkki. Ja ne linkithän on ihan PCI-e linkkejä joten sekin olisi varmaan mahdollista että neljän socketin alustassa rohmuttaisiin vaikka 32 linkkiä lisää siihen sockettien väliseen liikenteeseen, jolloin edelleen maksimi ulos olisi se 128.

Onhan joku emo valmistaja julkaisussut jo nyt sellaisenkin dual socket alustan jossa ulkoisia PCI-e väyliä on 128 sijaan 192, eli sockettien väliseen liikenteeseen on jätetty vain 2kpl 16x linkkiä.

Markkinat vain taitaa olla sen verran pienet noille 4-socket, ettei AMD ole nähny tarpeelliseksi moista. Mites muuten tarttiskos AMD:n lisätä jotain noihin EPYC:n noin teknisesti muutakin kuin mikrokoodi tason tuki jotta tollainen 4-socket olisi mahdollinen vai voisiko sen käytännössä halutessaan toteuttaa ihan nykyisilläkin?
 
Ja jos tarvitaan enemmän monen säikeen suorituskykyä, Intelin strategia tähän on, että sitten laitetaan monta sokettia. Intelin palvelinprossut tukee paljon suurempaa määrä soketteja kuin AMDn, jolla maksimi on kaksi.
Saas nähdä että mitä ice lake sp tukee. Whitley platform on nykyisten huhujen mukaan rajattu vaatimattomaan 2s konfiguraatioon.
 
Kuninkuus (esim. peleissä) on sitä, että on paras esim. peleissä, vaikka erot eivät olisikaan jättiläismäisiä. Dominointi taas olisi sitä että veisi kaikessa selvästi.

Ja mitä väliä sillä miten kiuas se prossu on, kun nuo prossuthan pyörivät 30e prossucoolerilla ja kestävät käyttöä 100c asti nykyään? Lämmittää myös taloa talvella hyvin siinä sivussa.


Toinen juttu mitä ihmettelen niin en ymmärrä AMD:n omistajia jotka valittaa kun esim. Cyperpunkissa 2077:ssa valtaosa AMD:n prossuista ei saa hyödynnettyä peliä niin hyvin kuin Intel.

Tämähän on ollut iät ja ajat tiedossa jo että lukuisat pelit toimivat paremmin Intelin prossuilla, vaikka olisivatkin tehoissa tasamääräisiä. On tämä asia niin pitkään ollut tiedossa, että ei mielestäni ole oikeutta asiasta valittaa, jos AMD:n prossun on mennyt ostamaan. Kyllä sen on varmasti ostaessa tiennyt ellei sitten ihan maallikko ole näiden asioiden suhteen.

Kummasti sitä vaan dissataan niitä prossuja jotka dominoi,abouttiarallaa kaikessa ja sanotaan että se ois dominointia vasta kun...
Jollain unrealin enginen peleillä je Zen1 tais olla oikeasti merkittävä ero intel ja amd välillä.
Intel on perinteisesti rahamiesten ratkaisu, jos ne pitää kellottaa sinne 5,3+ghz niin lämpökuorman lisäksi myös virrankulutus kasvaa ja viimeksi kun tarkistin niin sähköstäkin pitää maksaa. Kun otetaan huomioon että emot on kalliimpia, prossut on about samassa (no intel taitaa olla parikymppiä halvempi vastaavilta tehoiltaan, jos vastaavia tehoja olisi mistä tarjota).

Siihen kun lasketaan että se 5,3ghz+ kellotettu prossu imaisee 300-400w sähköä niin lämmityksen lisäksi se näkyy kyllä myös sähkölaskussa, tällä tietysti ei ole niin suurta merkitystä jos kämppä lämmitetään suorasähköllä.

Kyllä minä voisin harkita ostavani Intelin prossun jos niiltä tulisi oikeasti joku hyvä tuote jossa olisi perf/watti kohdillaan eikä suotta hehkuttaisi rautaa punaisena, mutta ihmettelen suuresti niitä jotka ovat jämähtäneet johonkin core 2 duo-aikaan niinkuin Kepun äänestäjät, aina ennenkin on tässä talossa kepulaisia äänestetty.

Muistiviiveet on AMD:lla toki suuremmat, mutta minua henk koht kiinnostaisi tietää mihin perustuu se, että se ei näy suorituskyvyssä, vai saataisiinko inteliä vastaavalla muistiviiveellä se 20-30% kaulaa lisää
 
Mokaa?

Kyllä Ryzenit ovatkin ihan ok prosessoreita olleet, varsinkin hintalaatu suhteelta, mutta tähän asiaan liittyen niin onhan niitä lukemattomia muitakin esimerkkejä missä AMD:n yhtätehokkailla prossuilla pelit pyörii huonommin kuin Intelillä. Turha siitä on peliyrityksiä syyttää, jos tietoisesti ostaa prossuvalmistajaa josta tiedetään että se ei kaikissa peleissä toimi niin hyvin kuin kilpailija. Jos kyse olisi yksittäisesti poikkauksesta niin olisin samaa mieltä, mutta näitä pelejä on aika paljon.

Joo vanhemmissa peleissä on intel optimointia toki, kun ei ennen Ryzenia oikeastaan ollut 10 vuoteen oikeasti huipputason AMD peliprossua. Uusissa peleissä on ihan pelinkehittäjän ymmärtämättömyyttä, jos edelleen ignooraa Ryzenit pelinkehityksessä ja optimoi vain intelille. Tuskin tulee olemaan mitenköön yleinen tilanne.

Mielipahaa? Ei minulla mitään mielipahaa ole. Puhun asioista suoraan objektiivisesti kylläkin täällä ja se ei kaikkia miellytä, mutta en olekkaan täällä kaikkia miellyttämässä.

On kyllä objektiivisuus hyvin hyvin kaukana. Tai ainakin se perustuu joihinkin omiin kuvitelmiisi.


Selvä bugi? Mistä tiedät ettei Cyperpunkin kehittäjät ole tehneet tätä ihan tietoisesti tälläistä teknistä toteutusta?

Jos viittaat siihen rekisteri editori fixiin niin monen hyvin tunnetun ja kunnieitun it-sivuston mukaan siitä ei ole ollut käytännössä hyötyä vaan pikemminkin enemmän haittaa (cyperpunk ketjussa enemmän tästä).

Enkä sanonut että tämä olisi AMD:n syy vaan että kummastelen kuluttajia jotka ostaa AMD:tä ja sitten valittavat kun jokin peli ei toimi niin hyvin kuin Intelillä vaikka tälläinen kaava on lukuisissa peleissä ollut jo vuosia.

Mitäköhän hemmettiä mä taas luin... Vai että on oikein tietoinen päätös ollut CDPR:n toimesta...

Kyllä siitä hex edit fixistä on ihan oikeaa hyötyä Ryzeneilla varsinkin noilla 6c12t malleilla. Omalla 3700x:llä siitä oli myös selvää hyötyä paikka paikoin ja toisissa kohdissa perffi oli sama kun ilman tuota hex edittiä. Negatiivisia vaikutuksia on vain noillla 12c ja yli AMD:n prosessoreilla.

Se että on ollut ennen vuotta 2017 semmoinen "kaava", että pelit on intelille pelkästään optimoitu, ei merkkaa mitään peleissä, joiden kehitys on aloitettu esim. 2017 ja sen jälkeen. Aiemminkin aloitetussa projekteissa voidaan lisötä koodiin myös Ryzenille optimointeja, joka olisikin hyvin järkevää, kun ottaa huomioon kuinka suosittuja Ryzenit nykyään on.

En ymmärrä, miten joku voi takertua johonkin menneeseen asiaan niin sokeasti, että ei ymmärrä tai näe nykytilannetta saati tulevaisuutta.

Intel voi olla helposti vielä vuosia köysissä noiden prosessiongelmien vuoksi, ja ero tulee hyvin todennäköisesti vaan kasvamaan AMD:n eduksi.
 
AMD:n tuleva 8-ytiminen läppäriprosessoreiden huippumalli (Ryzen 9 5900HX, 45W) on nopeampi kuin Ryzen 7 3800X ja Intel Core-i7 10700 (molemmat työpöytäprosessoreita).
1608389056910.png

Eipä ole ihme, kun tuossa on uudempi järeämpi arkkitehtuuri, selvästi pienemmät muistiviiveet, ja silti yhtä paljon L3-kakkua yhdelle säikeelle (yhteensä puolet 4-8 ytimelle)

Vertailu 5800X:ään on mielenkiintoisempi, kun sitten arkkitehtuuri on muuten sama, mutta erot on muistiviive vs tuplasti L3-kakkua.
 
No siis teoriassa mikään ei estäisi AMD:tä tekemästä vaikka neljän socketin EPYC alustaa.
Siinä EPYC:ssä on 4kpl PCI-e 16x linkkejä varattu socket to socket seurusteluun, siitä vaan tulisi huomattavasti hitaampi linkki. Ja ne linkithän on ihan PCI-e linkkejä joten sekin olisi varmaan mahdollista että neljän socketin alustassa rohmuttaisiin vaikka 32 linkkiä lisää siihen sockettien väliseen liikenteeseen, jolloin edelleen maksimi ulos olisi se 128.
Onhan joku emo valmistaja julkaisussut jo nyt sellaisenkin dual socket alustan jossa ulkoisia PCI-e väyliä on 128 sijaan 192, eli sockettien väliseen liikenteeseen on jätetty vain 2kpl 16x linkkiä.

Markkinat vain taitaa olla sen verran pienet noille 4-socket, ettei AMD ole nähny tarpeelliseksi moista. Mites muuten tarttiskos AMD:n lisätä jotain noihin EPYC:n noin teknisesti muutakin kuin mikrokoodi tason tuki jotta tollainen 4-socket olisi mahdollinen vai voisiko sen käytännössä halutessaan toteuttaa ihan nykyisilläkin?

Ei niitä soketteja voi vaan lisätä ja piuhoja vetää niiden välille, kun niiden pitää myös osata jutella keskenään ja toimia. Kun systeemi on NUMA jossa muistit on jaettu kaikkien eri sokettien kesken, se tarkoittaa sitä, että siellä pitää olla logiikka, joka osaa mäpätä kaiken eri NUMA-nodeilla olevan muistin johonkin kaikille yhteisiin muistiosoitteisiin ja sitten reitittää sen muistiaccessin oikealle NUMA-nodelle, oikeiden linkkien yli, ja toisaalta reitittää vastaukset takaisin.

Ja jossain tulee rajat vastaan tässä reitityslogiikassa. Toki ekan sukupolven Zen-pohjaisten EPYCien NUMA-topologia oli monimutkaisempi, maksimissaan 8 nodea, joten on mahdollista että myös zen2/zen3ssa voisi sen takia olla tuki käytännössä esim. kahdeksalle NUMA-nodelle eli zen2/zen3 tapauksessa kahdeksalle soketille, mutta hyvin myös mahdollista, että muistiacessien nopeuden optimoimiseksi tätä logiikkaa on yksinkertaistettu zen -> zen2-välillä.


Ja esim. jo ytimen sisäisten välimuistien suunnittelussa pitää ottaa huomioon se, kuinka suurta fyysistä osoiteavaruutta tuetaan, että paljonko tarvitaan bittejä TLBihin(virtuaaliosoitteen muunnos) ja tagibittejä fyysisellä osoitteella tagattujen välimuistien tageihin(kirjanpitoon=. Käytännössä järkevä koko tähän lienee esim systeemin maksimi keskusmuistin määrä * 2 jolloin sinne jää yhtä paljon muistialuetta vapaaksi muistimapattyyn IO:hon kuin itse keskusmuistille.

Eli jos liian purkalla aletaan soketteja lisäämään, käy niin, että sitten raja siinä, paljonko muistia/soketti voidaan käyttää alkaa pudota.


Intelhän on jo Cove-sarjassa laajentanut virtuaaliosoitteet 48 => 57 bittiä, AMDn on Zen3lla vielä 48 bitissä. Se, missä vaiheessa virtuaaliosoitetta laajennetaan antaa hiukan osviittaa siitä, missä mennään myös fyysisen osoitteen suhteen, Intel tähtää Cove-määrällä suurempiin muistimääriin kuin AMD Zen3lla. Toki huomattava syy tässä voi Intelillä olla se, että Intel varautuu xPoint/Optane-muistien käyttöön myös keskusmuistina, se saattaa helposti 2-8-kertaistaa keskusmuistin määrän eli tuoda 1-3 bittiä lisää, AMD luottaa vielä perinteiseen DRAMiin.


Kun systeemi suunnitellaan, sinne päätetään jotkut rajat näille, ja kaikki siellä suunnitellaan niiden rajojen ehdoilla. Ne rajat valitaan sen mukaan, kunka järeisin käyttötarkoituksiin arkkitehtuurin pitää taipua, eikä sinne turhaan sitten laiteta tukea näiden rajojen yli, koska ne lisäbitit on aina lisää pinta-alaa, virrankulutusta, ehkä myös viivettä, myös niillä alempiin markkinasegmentteihin myytävillä piireillä, ja monimutkaisemmat logiikat on näiden lisäksi myös ylimääräistä tuotekehitystyötä ja potentiaalisia paikkoja bugeille.

Toki osa rajoista on sitten purkalla kierrettävissä, ja toisaalta osa piiristä sisältää IPtä joka jaetaan muiden piirien kanssa (jossa rajat voi olla järeämmät) eikä näitä usein aleta pienentämään koska se taas on myös lisää työtä ja potentiaalisia buginpaikkoja.


IMHO esim, tuo Coven 5-tasoinen 57-bittinen virtuaaliosoite on overkill läppärimalleissa, sen olisi aivan hyvin voinut jättää niistä pois ja tuoda vain serverimalleihin, kenen tarvii lähivuosina ajaa ohjelmia jotka mappaavat yli 256 teran verran muistia (tai no, yli 128 teran, jos yksi bitti jätetään käyttikselle)? Mutta toisaalta, nyt voi kehittää käyttiksen kernelin tukea sille 5-tasoiselle sivutuksella serverimallia varten läppärimallilla ja testata, että se 5-tasoinen sivutaulutoteutus toimii. Maailmassa vaan on ehkä n. alle 20 ihmistä jotka niitä käyttiksien ytimien sivutaulutoteutuksia koodaa, joten toisaalta taas vähän turha näitä <20 ihmistä varten myydä kymmeniä miljoonia prossuja, joissa tuo on.

Mutta olennainen syy tässä 5-tasoisen sivutuksen sisällyttämisessä Sunny Coven läppärimalleihinkin varmaan oli se, että ei haluttu tehdä Cove-sarjan ytimistä tämän osalta kahta erilaista mallia, koska se olisi tarkoittanut enemmän tuotekehitystyötä ja testausta kokonaisuudessaan.
 
Jälleen kerran pitää toistaa sama historiakatsaus, kun puhutaan kritiikitöntä mainoshömppää chipleteistä. "Chipletit" on ainoastaan epäsymmetristä MCM-paketointia, ja se on ikivanha juttu.

(paljon kuvia poistettu)

Ei siis ole olemassa mitään AMDlle eksklusiivista ylivoimaista "chiplet-pohjaista arkkitehtuuria". On vaan MCM-paketteja, joihin laitetaan useampi piilastu samaan pakettiin.
Sinulla on kummallinen keskustelutyyli, jossa automaattisesti oletetaan, että toinen osapuoli ei tiedä asiasta yhtään mitään. Noita Pentium Pro-prosessoreilla toimitettuja palvelimia on tullut itsekin joskus asenneltua ja mm. vaihdettua takuuseen joitakin prosessoreita, joissa oli liukulukulaskennan bugi. Ja hyvin tiesin jo tuolloin noiden olevan valmistettu useammasta piipalasta.

Kun muistiohjaimet integroitiin samalle piirille CPUn kanssa (AMD K8ssa 2003, Intel Nehalemissa 2008), se teki oikein hyvää suorituskyvylle, ja se oli se suunta, mihin Mooren laki on vääjäämättä menossa, koska valmistustekniikan pienenevät nopeammin kuin mitä ytimet kasvavat.
Se teki hyvää suorituskyvylle, koska välistä saatiin tiputettua hidas FSB-väylä ja samalla muistiaccessit paremmin synkronoitua ytimen vaatimuksiin - latenssi pieneni merkittävästi.

Nyt kun AMD (tietyissä piireissä, ei kaikissa) reversoi tämän ja toi muistiohjaimen pois samalta piilastulta, lisäten samalla muistiviivettä selvästi, AMD-fanipojat on kuorossa huutamassa kuinka tässä on tulevaisuus ja Intel on perässä.

Ei, AMD otti tässä askeleen taaksepäin, koska se sopi senhetkiseen AMDn markkinatilanteeseen.
Intel julkaisi omassa Architecture Day 2020-tapahtumassaan olevan menossa voimakkaasti chipletteihin. Chipletit ovat palvelinprosessoreissa tulevaisuus, sillä sillä saadaan parannettua saantoja, pienennettyä valmistus- ja suunnittelukustannuksia, lisättyä merkittävästi ytimien määrä ja myös hajautettua piipalojen lämpöä laajemmalle alueelle.

Chipletit eivät ole askel taaksepäin, vaan välttämättömyys, jotta prosessorien tehokehitys voi jatkua vanhaan malliin. Monoliittisistä prossoreista tulee yksinkertaisesti liian kalliita valmistaa ja liian hidasta suunnitella. Tätä Chiplet-maailman suunnittelun nopeutta myös Intel korostaa omissa kalvoissaan:

Ja AMDllä edelleen läppärimallit on yhden piilastun SoC:eja, koska se muistiohjain siellä erillisellä piilastulla olisi vaan turhaa sähkönhaaskasta, lämmöntuottoa ja muistiviivettä.
Tietenkin. Pienillä ydinmäärillä integroitu SOC on kaikilla mittareilla parempi. Suurilla ydinmäärillä tilanne on aivan toinen.

Intel on päättänyt pitää muistiohjaimen samalla piilastulla ytimien kanssa, koska se mahdollistaa nopeamman muistiviiveen ja paremman energiatehokkuuden.
Intel teki virheen tehdessään vuosia sitten linjauksen millainen Ice Lake ja Sapphire Rapids-prosessorien perusarkkitehtuuri on ja katuvat sitä varmasti jo nyt. Sapphire Rapids tulee olemaan jo kahden lastun yhteen liimattu kokonaisuus. Jos heillä olisi kokonaan Chiplet-arkkitehtuurin ehdoilla tehty prosessori, olisi Intelin tämän hetken kilpailukykyongelmat pitkälti ratkaistu. 10nm:n prosessin saannot ovat heikkoja ja pienet chipletit parantaisivat niitä radikaalisti. Nyt heillä ei ole tarjolla mitään yli 28 ytimen maailmaan, kun AMD menee jo 64 coren prosessoreissa.

Ja jos tarvitaan enemmän monen säikeen suorituskykyä, Intelin strategia tähän on, että sitten laitetaan monta sokettia. Intelin palvelinprossut tukee paljon suurempaa määrä soketteja kuin AMDn, jolla maksimi on kaksi. Toki useamman soketin kanssa voi sitten tarvia softassa olla NUMA-optimoinnit, että se muisti ei käännykin hitaammaksi.
Yli kahden socketin palvelimet ovat käytännön elämässä todellinen harvinaisuus. Ne ovat kaikilla mittareilla merkittävästi kalliimpia per tehoyksikkö verrattuna kahden socketin palvelimiin ja kukaan ei käytä niitä ellei ole pakottavaa tarvetta. Myös sovellusarkkitehtuurit ovat edistyneet siten, ettei yhden palvelimen skaalausta ylöspäin enää tarvita samaan malliin kuin aikaisemmin. Esimerkiksi kannat (SQL Server, Oracle jne) skaalautuvat nykyään loistavasti vertikaalisesti. Käytännössä järeät SAP HANA-palvelimet ovat lähes tulkoon ainoa mieleen tulevat käytännön sovellus, jossa niitä vielä tarvitaan.

Ja miksi ostaa Intelin todella kallista neljän socketin palvelinta, kun saat AMD:ltä kahden socketin palvelimena saman tai paremman tehon?

Intel teki vuosia sitten virhevalinnan arkkitehtuurivalinnassaan, jota nyt yritetään pikaisesti korjata. Prosessorin pilkkominen Chipleteiksi vain on monen vuoden suunnitteluprojekti ja siinä ei auta, vaikka jo Pentium Pro vuonna miekka ja kirves oli tehty useammasta piilastusta.
 
Saas nähdä että mitä ice lake sp tukee. Whitley platform on nykyisten huhujen mukaan rajattu vaatimattomaan 2s konfiguraatioon.

Joo, ja tässä Intel kyllä IMHO hiukan markkinasegmentoi itseään suohon, toimi aiemmin rahastukseen erinomaisesti mutta nyt kilpailutilanteen kiristittyä käy huonommaksi.

Niiden >2 sokettia käyttävien systeemien kysyntä on kuitenkin ollut perinteisesti melko pientä, joten Intel on laittanut niille omat erikoismallinsa joissa oikein kunnon rahastushintalappu (mikä entisestään on vähentänyt niiden myyntiä). Aiemmin ne oli aivan samoja piirejä, mutta siten että niissä oli vain bitti poikittain että "suostun toimimana yli 2 soketin systeemeissä."

Mutta ilmeisesti sitten Intel aikoo näissä 4S-8S-systeemeissä hypätä Ice Lake-sukupolven yli, ja Ice Lake SP:ssä on tuki vain kahdelle soketille, ja Cooper Laken 4S/8S-mallit julkaistiin juuri viime kesänä, ja uudet 4S/8S-mallit tulee sitten vasta sapphire rapids-sukupolvessa

Tästä kuitenkin seuraa se, että ensi vuonna palvelinpuolella on käytännössä vastakkain eri suorituskykyluokissa suurinpiirtein:

Ice Lake-SP (36 ydintä, 8 muistikanavaa)Milan (32 ydintä, 8 muistikanavaa) (joko 4 CCD-piirin malli, tai puolet ytimistä pois päältä)
Milan (64 ydintä, 8 muistikanavaa)
Ice Lake-SP * 2 (72 ydintä, 16 muistikanavaa)Milan * 2 (64 ydintä, 16 muistikavava) (joko 4 CCD-piirin malli, tai puolet ytimistä pois päältä)
Cooper Lake * 4 (112 ydintä, 24 muistikanavaa, "14nm", huono energiatehokkuus)Milan * 2 (128 ydintä , 16 muistikanavaa)
Cooper Lake * 8 (224 ydintä, 48 muistikanavaa, "14nm" huono energiatehokkuus)

Eli heti kun mennään 72 ytimen yli, Intel käy selvästi huonommaksi energiatehokkuudeltaan. AMDllä on selvä energiaetu tuossa 128 ytimen luokassa, jota zen2/zen3 vielä tukee, ja AMD voi myös hinnoitella piirinsä siten, että muuttaa markkinatilannetta siinä, että tuo aiemmin harvinainen 128 ytimen luokkaa (jota intel vähän ylenkatsoi tässä tulevassa sukupolvessa) nouseekin nyt merkittäväksi luokaksi.



Eli ylläoleva taulukko on vain suorituskykyluokkien, ei hintaluokkien vertailuy keskenään. Hintaluokittain vertailu menisi eri tavalla, käytännössä AMD hinnoittelee piirinsä selvästi alemmas kuin Intel, ylläoleva on vaan suorituskykyluokka, ei se , mitkä piirit on vastakkain samalla hinnalla. Ja syyt on

1) Intelillä on kalliimmat valmistuskustannukset, koska
1a) Intelin "10nm" prosessilla on huonommat saannot kuin TSMCn "7nm" prosessilla
1b) AMD ei valmista DRAM-PHYitä yms. huonosti skaalatuvaa kamaa pinta-alaansa nähden kalliilla uudella prosessilla vaan vanhalla halvalla ja luotettavalla prosessilla
1c) AMDllä on paljon pienempiä piilastuja, tämän vaiktus saantoihin. Tämän vaikutus saantoihin ei kuitenkaan moniydinpiireillä ole niin suuri kuin se joskus oli, koska valmistusvika ei riko koko piiriä ellei se osu johonkin sellaiseen osana piiriä, jota ei voi kytkeä pois päältä.
1d) Intelin "10nm" prosessi saattaa ehkä vaatia vielä hiukan monimutkaisempaa multipatternointia kuin TSMCn "7nm" prosessi, mikä suoraan hidastaa sitä kuinka monta piikiekkoa muuten vastaavalla määrällä laitteistoa saisi valmistettua aikayksikössä.
2) Markkinatalous. Intel nyt vaan hinnoittelee tuotteensa korkeammalle. Koska voi, koska markkinajohtajan asema ja vanhat asiakkaat jotka ostaa. Ei se ole tyhmä, joka pyytää, vaan se, joka maksaa.
 
Tuota Ryzen 3 3200G:n hintaa hieman ihmettelen?
Onko vanhemmista integroidulla grafiikalla varustetuista prosessoreista oikeasti noin kova pula?
o_O
;)
 
Siirretty muualta jossa se on 100% offtopiccia.

Eikö logiikkabugin määritelmä ole, että toimii, mutta ei halutulla tavalla eli tässä tapauksessa sallii sivukanavahyökkäykset?

Ei.

Logiikka on täysin oikea, toimii kuten speksi sanoo. Ei ole mitän logiikkabugia.

Speksi vaan ei ota huomioon sivukanavahyökkäyksiä.
 
Ei.

Logiikka on täysin oikea, toimii kuten speksi sanoo. Ei ole mitän logiikkabugia.

Speksi vaan ei ota huomioon sivukanvaahyökkäyksiä.
Ei se speksi ole mikään kaikkivaltias asia. X86 arkkitehtuuri käskyineen on sekin speksattu ja varmasti tarkasti, mutta sen toteutuksesta on silti olemassa vaikka kuinka monenlaista versiota kuten Intelin ja AMD:n eri prosessorisukupolvet todistavat. Osa niistä toimii paremmin, osa huonommin, mutta ne kaikki ovat silti speksin mukaisia. Osassa niistä vaan se toteutus ontuu ja siitä ei voi syyttää speksiä tai piiloutua sen taakse
 
Ei se speksi ole mikään kaikkivaltias asia. X86 arkkitehtuuri käskyineen on sekin speksattu ja varmasti tarkasti, mutta sen toteutuksesta on silti olemassa vaikka kuinka monenlaista versiota kuten Intelin ja AMD:n eri prosessorisukupolvet todistavat. Osa niistä toimii paremmin, osa huonommin, mutta ne kaikki ovat silti speksin mukaisia. Osassa niistä vaan se toteutus ontuu ja siitä ei voi syyttää speksiä tai piiloutua sen taakse

Käskykannan speksi speksaa sen toiminnallisuuden, ei käytännön toteutusta. Sen, mitä mikäkin käsky tekee. Ei sitä, miten se suoritetaan.

Ja lisäksi se käskykannan speksi tyypillisesti speksaa vain osan käskyenkoodausavaruudesta ja antaa luvan myöhemmille laajennuksille.

Sen käskyn saa toteuttaa vaikka siten, että kolmen miljoonaa kiinalaista jokainen yhden ottaa logiikkaportin roolin, ja käskyn suorittamiseen saa kulua vaikka kokonainen päivä aikaa.

Mikäli prosessori tuottaa kaikilla käskyllä saman laskutoimituksen tuloksen kuin mitä speksi sanoo, ja tuottaa eri käskyjen tulokset oikeassa järjestyksessä, ja nostaa kaikki speksin vaatimat poikkeukset oikein virhetilanteissa, se on speksin mukainen. Mikäli se tuottaa eri tuloksen, tuottaa käskyjen tulokset väärässä järjestyksessä, tai jättää poikkeuksen heittämättä, se on buginen. Tämä on hyvin selvä asia.

Ei ole mitään "ontuvia toteutuksia". On joko speksin mukainen toteutus, tai bugaava toteutus.



Intelin Meltdown-alttiit prosessorit nostavat aivan speksin mukaisesti oikein page fault-poikkeuksen kaikista laittomista muistiaccesseista eivätkä koskaan anna laittomasti ladatun arvon päätyä arkkitehtuurillisesti näkyvään rekisteriin.

Ongelma vaan on se, että sivukanavahyökkäysaikakaudella tämä ei käytännössä riitä. Speksi ei ota sivukanavia huomioon. Speksiä pitäisi muuttaa (tai siis on jo muutettu uusille prosessoreille) siten, että siinä uudessa speksissä otetaan spekulatiivinen suoritus huomion ja sanotaan, että mikäli tehdään spekulatiivista suoritusta, kielletään laittomasta muistiosoitteesta tehdyn latauksen päätyminen millekään seuraavalle käskylle edes spekulatiivisesti.

Alkuperäinen speksi ei ota edes millään tavalla kantaa koko spekulatiiviseen suoritukseen, niin kauan kuin tulos ei muutu arkkitehtuurillisesti näkyväksi, spekulatiivinen suoritus on ennen saanut tehdä aivan mitä tahansa (koska ainoat keinot päästä käsiksi ei-arkkitehtuurilliseen tilaan on ne sivukanavat)



Prosessori joka toimii tasan kuin speksi sanoo ei ole buginen. Se voi olla ongelmallinen prosessori joka toteuttaa puutteellisen speksin, mutta ei buginen.
 
Viimeksi muokattu:
:facepalm:

Voisitko nyt edes yrittää ymmärtää mitä sana "speksi" tarkoittaa.

Käskykannan speksi speksaa sen toiminnallisuuden, ei käytännön toteutusta. Sen, mitä mikäkin käsky tekee. Ei sitä, miten se suoritetaan.


Ja lisäksi se käskykannan speksi tyypilliesti speksaa vain osan käskyenkoodausavaruudesta ja antaa luvan myöhemmille laajennuksille.


Sen käskyn saa totetutta vaikka siten, että kolmen miljoonaa kiinalaista jokainen yhden ottaa logiikkaportin roolin, ja käskyn suorittamiseen saa kulua vaikka kokonainen päivä aikaa.

Mikäli prosessori tuottaa kaikilla käskyllä saman laskutoimituksen tuloksen kuin mitä speksi sanoo, ja nostaa kaikki speksin vaatimat poikkeukset oikein virhetilanteissa, se on speksin mukainen. Mikäli se tuottaa eri tuloksen tai jättää pokkeuksen heittämättä, se on buginen. Tämä on hyvin selvä asia.

Intelin Meltdown-alttiit prosessorit nostavat aivan speksin mukaisesti oikein page fault-poikkeuksen kaikista laittomista muistiaccesseista eivätkä koskaan anna laittomasti ladatun arvon päätyä arkkitehtuurillisesti näkyvään rekisteriin.

Ongelma vaan on se, että sivukavahyökkäysaikakaudella tämä ei käytännössä riitä. Speksi ei ota sivukanavia huomioon. Speksiä pitäisi muuttaa (tai siis on jo muutettu) siten, että siinä uudessa speksissä otetaan spekulatiivinen suoritus huomion ja sanotaan, että mikäli tehdään spekulatiivista suoritusta, kielletään laittomasta muistiosoitteesta tehdyn latauksen päätyminen millekään seuraavalle käskylle edes spekulatiivisesti.

Alkuperäinen speksi ei ota edes millään tavalla kantaa koko spekulatiiviseen suoritukseen, niin kauan kuin tulos ei muutu arkkitehtuurillisesti näkyväksi, spekulatiivinen suoritus on ennen saanut tehdä aivan mitä tahansa (koska ainoat keinot päästä käsiksi ei-arkkitehtuurilliseen tilaan on ne sivukanavat)
Minä olen koko ajan puhunut siitä toiminnallisuudesta ja sen bugisuudesta ja sinä olet piiloutunut sen speksin taakse. Se toiminnallisuus voi bugisenakin olla sen speksin mukainen.
 
Minä olen koko ajan puhunut siitä toiminnallisuudesta ja sen bugisuudesta ja sinä olet piiloutunut sen speksin taakse. Se toiminnallisuus voi bugisenakin olla sen speksin mukainen.
No voi nyt ehmetti, se speksi määrittelee mikä on oikeaa ja mikä virheellistä toimintaa. Sivukanavahyökkäykset mahdollistava toiminta on oikeaa toimintaa, ei virheellistä.
 
No voi nyt ehmetti, se speksi määrittelee mikä on oikeaa ja mikä virheellistä toimintaa. Sivukanavahyökkäykset mahdollistava toiminta on oikeaa toimintaa, ei virheellistä.
Speksin mukaan se voi olla, mutta jos siihen pääsee iskemään sivukanavalla, niin sisäisesti se ei toimi oikein.

Tässä kannattaa huomata, että AMD näkemys asiasta ei useimmissa tapauksissa mahdollista noita hyökkäyksia, joten ei voida väittää, että speksi määrittelisi ne tavalla joka pakottaisi mahdollistamaan sen sivukanavahyökkäyksen.
 
Speksin mukaan se voi olla, mutta jos siihen pääsee iskemään sivukanavalla, niin sisäisesti se ei toimi oikein.
Sitten mikään asia maailmassa ei voi "toimia oikein", ihan kaikessa on virheitä jos asettaa sopivat maalitolpat.
Se että speksin suunnittelussa ei otettu huomioon tietynlaisten sivukanavahyökkäysten mahdollisuutta ei tarkoita että se olisi bugi.
 
Sitten mikään asia maailmassa ei voi "toimia oikein", ihan kaikessa on virheitä jos asettaa sopivat maalitolpat.
Se että speksin suunnittelussa ei otettu huomioon tietynlaisten sivukanavahyökkäysten mahdollisuutta ei tarkoita että se olisi bugi.
Lainaus edellisestä viestistä ja sen osa jonka lisäsin ilmeisesti sen jälkeen kun olit jo kirjoittanut omasi:

Tässä kannattaa huomata, että AMD näkemys asiasta ei useimmissa tapauksissa mahdollista noita hyökkäyksia, joten ei voida väittää, että speksi määrittelisi ne tavalla joka pakottaisi mahdollistamaan sen sivukanavahyökkäyksen.

Täten sanoisin, että Intelin tapa tehdä se on buginen
 
Lainaus edellisestä viestistä ja sen osa jonka lisäsin ilmeisesti sen jälkeen kun olit jo kirjoittanut omasi:

Tässä kannattaa huomata, että AMD näkemys asiasta ei useimmissa tapauksissa mahdollista noita hyökkäyksia, joten ei voida väittää, että speksi määrittelisi ne tavalla joka pakottaisi mahdollistamaan sen sivukanavahyökkäyksen.

Täten sanoisin, että Intelin tapa tehdä se on buginen
Ei ole. x86 tai sen laajennokset eivät ota millään tapaa kantaa toteutuksen tapaan. AMDlla ja Intelillä on ihan omat speksinsä joka arkkitehtuurilleen. Tässä tapauksessa AMDn speksit ottivat valmiiksi huomioon osan mainituista hyökkäyksistä, Intelin ei, mutta kumpikin toimii ihan yhtä oikein.
 
Ei ole. x86 tai sen laajennokset eivät ota millään tapaa kantaa toteutuksen tapaan. AMDlla ja Intelillä on ihan omat speksinsä joka arkkitehtuurilleen. Tässä tapauksessa AMDn speksit ottivat valmiiksi huomioon osan mainituista hyökkäyksistä, Intelin ei, mutta kumpikin toimii ihan yhtä oikein.
Siinä tapauksessa sekä Intelin speksi, että toteutus ovat bugisia. Molemmat valmistajat kun pelaavat kuitenkin samoilla spekseillä ylätasolla, että prosessorit ovat yhteensopivia kaikkien ohjelmien kanssa.
 
Siinä tapauksessa sekä Intelin speksi, että toteutus ovat bugisia. Molemmat valmistajat kun pelaavat kuitenkin samoilla spekseillä ylätasolla, että prosessorit ovat yhteensopivia kaikkien ohjelmien kanssa.
Eivät ole, koska edelleenkään ne x86n tai laajennosten speksit eivät ota mitään kantaa koko asiaan millään tapaa.
 
Lainaus edellisestä viestistä ja sen osa jonka lisäsin ilmeisesti sen jälkeen kun olit jo kirjoittanut omasi:

Tässä kannattaa huomata, että AMD näkemys asiasta ei useimmissa tapauksissa mahdollista noita hyökkäyksia, joten ei voida väittää, että speksi määrittelisi ne tavalla joka pakottaisi mahdollistamaan sen sivukanavahyökkäyksen.

Täten sanoisin, että Intelin tapa tehdä se on buginen

Jos yhden fillarinrenkaan pinnojen väliin saa työnnettyä kepin, ja toisessa on levykiekko, niin onko ensinmainittu rengas viallinen, vai olisiko se vain suunniteltu huomioimatta mahdollisuutta, että joku saattaisi työntää kepin pinnojen väliin?
 
Jos yhden fillarinrenkaan pinnojen väliin saa työnnettyä kepin, ja toisessa on levykiekko, niin onko ensinmainittu rengas viallinen, vai olisiko se vain suunniteltu huomioimatta mahdollisuutta, että joku saattaisi työntää kepin pinnojen väliin?
Toisaalta jos tuuppaat sitä levykiekkoa sillä kepillä se koko fillari varsin luultavasti kaatuu, mikä ei sekään ole toivottavaa ainakaan jos se on liikkeessä. Eli onko se levykiekko viallinen sekin?

Mutta joo tämä menee jo aika pahasti aiheesta ohi.

Alla lienee Divvyn speksin mukainen pyörä:
c317f52a-c3c9-3e88-8069-83ba9b18caf3.jpg
 
Toisaalta jos tuuppaat sitä levykiekkoa sillä kepillä se koko fillari varsin luultavasti kaatuu, mikä ei sekään ole toivottavaa ainakaan jos se on liikkeessä. Eli onko se levykiekko viallinen sekin?

Josta päästään siihen, että kaikki on viallista koska kaiken voi jotenkin saada rikki tai toimimaan väärin/huonosti. AMD:llä vialliset prossut kun ne ei toimi vasaroinnin jälkeen. Talossa vialliset ikkunat kun niistä pääsee kivellä läpi.
 

Lisää rakettijärvien ES versioita
Onhan tuo aika iso parannus Skylakesta, jopa pistää hieman skeptiseksi. Hyvää kannattaa odottaa.
 
Pelit ei ole aikoihin vaatinut CPU:lta juurikaan mitään.

Jotkut uudet pelit kyllä vaatii CPUltakin suorituskykyä:

xxJ2hsYaDZZbTTAeNpR33o.png

Jos tuossa haluaa päästä edes 60 FPSään 99-persentiilissä niin pitää olla jo kohtalaisen uusi ja kallis CPU.

Ja esim. omalla Ryzen 1700lla oltaisiin jossain vähän päälle 30ssä.
 
Jotkut uudet pelit kyllä vaatii CPUltakin suorituskykyä:

xxJ2hsYaDZZbTTAeNpR33o.png

Jos tuossa haluaa päästä edes 60 FPSään 99-persentiilissä niin pitää olla jo kohtalaisen uusi ja kallis CPU.

Ja esim. omalla Ryzen 1700lla oltaisiin jossain vähän päälle 30ssä.
Mikähän ihme tuossa pelissä on, kun Comet Lake-S on niin paljon nopeampi, kuin Coffee Lake-R? Kolmella eri sivulla nähnyt samanlaiset tulokset, joissa 10700K voittaa 9900K suurella marginaalilla. Tuon THG:n lisäksi GN ja Computerbase sai vastaavat tulokset.
 
Mikähän ihme tuossa pelissä on, kun Comet Lake-S on niin paljon nopeampi, kuin Coffee Lake-R? Kolmella eri sivulla nähnyt samanlaiset tulokset, joissa 10700K voittaa 9900K suurella marginaalilla. Tuon THG:n lisäksi GN ja Computerbase sai vastaavat tulokset.
Mahtaakohan Spectre-pätsit hidastaa kahvijärveä?
 
Mikähän ihme tuossa pelissä on, kun Comet Lake-S on niin paljon nopeampi, kuin Coffee Lake-R? Kolmella eri sivulla nähnyt samanlaiset tulokset, joissa 10700K voittaa 9900K suurella marginaalilla. Tuon THG:n lisäksi GN ja Computerbase sai vastaavat tulokset.

TDP.

Tuo on peli, joka oikeasti kuormittaa kahdeksaa ydintä melko hyvin, 125 watilla ne 8 ydintä voi toimia aika paljon suuremmilla kelloilla kuin 95 watilla.

Mahtaakohan Spectre-pätsit hidastaa kahvijärveä?

Ei, ne hidastaa lähinnä käyttiskutsuja, ei juuri tunnu peleissä.
 
TDP.

Tuo on peli, joka oikeasti kuormittaa kahdeksaa ydintä melko hyvin, 125 watilla ne 8 ydintä voi toimia aika paljon suuremmilla kelloilla kuin 95 watilla.
Unohtui, että joku saattaisi ajaa noita prossuja TDP rajat kytkettynä päälle. :facepalm:

TDP rajat taitaa olla vakiona suurimmalla osalla lankuista kytketty pois päältä, esim. omassa Z490 Tomahawk oli power limit vaatimattomasti 4096W UEFI vakioasetuksilla ja Prime 95 hörppäsi 190W+. Tämä siis ilman, että käyttäjä koski mihinkään UEFI vakioasetuksiin.

Kuitenkaan tuo Cyberpunk ei tunnu vievän pelatessa omalla 10700K kuin 60-70W (jos noihin softien antamiin lukemiin on mitään luottamista), kun koneessa RTX3080 ja asetuksina 1440p RT Ultra + DLSS Balanced.
 

Statistiikka

Viestiketjuista
259 307
Viestejä
4 508 767
Jäsenet
74 351
Uusin jäsen
Hopis

Hinta.fi

Back
Ylös Bottom