AMD CPU-spekulaatio (Zen6/Zen7 ...)

Rautalangasta pitää näköjään vääntää.
CCX muutos nimenomaan lisää IPC:tä, sekä ST että MT kuormilla. IPC on ihan kirjaimellisesti "instructions per clock" ja jos peli kulkee kovempaa niin se ajaa enemmän käskyjä samassa ajassa, eli IPC on korkeampi. Tämän lisäksi siellä tehtäneen ytimiin myös muita muutoksia jotka myös vaikuttavat IPC:n kasvuun.
Et voi sanoa että "CCX muutos lisää IPC:tä jo ennen mitään IPC lisää", sillä tossa lauseessa ei ole mitään järkeä.
sano mielummin että "CCX muutos jo itsessään nostaa IPC:tä paljon, puhumattkaan muista potentiaalisista arkkitehtuurimuutoksista."

Oikeastaan per cycle, vaikka clock usein käytetty. Ei siis reaaliajassa (seinäkello) .

"In computer architecture, instructions per cycle (IPC), commonly called instructions per clock is one aspect of a processor's performance: the average number of instructions executed for each clock cycle."

Voi olla, että sitä tarkoitit, mutta rautalanka oli nyt vähän epäselvää.
 
Oikeastaan per cycle, vaikka clock usein käytetty. Ei siis reaaliajassa (seinäkello) .

"In computer architecture, instructions per cycle (IPC), commonly called instructions per clock is one aspect of a processor's performance: the average number of instructions executed for each clock cycle."

Voi olla, että sitä tarkoitit, mutta rautalanka oli nyt vähän epäselvää.
Ovat keskenään synonyymejä. Molempia käytetään.
 
Ja sitten on vielä single ja multicore ipc erillään jotka on aivan todellisia asioita johtuen ydinten kesken jaetuista resursseista.

Se ipc ei ole mikään kauhean hyvä kiveen hakattu vertailunumero muuten kuin samanlaisten työkuormien kesken.

Arkkitehtuuri muutos voi kasvattaa vain multicore ipc:tä esimerkiksi.
 
Ja sitten on vielä single ja multicore ipc erillään jotka on aivan todellisia asioita johtuen ydinten kesken jaetuista resursseista.

Se ipc ei ole mikään kauhean hyvä kiveen hakattu vertailunumero muuten kuin samanlaisten työkuormien kesken.

Arkkitehtuuri muutos voi kasvattaa vain multicore ipc:tä esimerkiksi.
Jep. IPC:n voi määrittää aina vain kuormakohtaisesti. Mitään ”universaalia” IPC:tä ei ole jolla verrata eri prosessoreja.
 
Rautalangasta pitää näköjään vääntää.
CCX muutos nimenomaan lisää IPC:tä, sekä ST että MT kuormilla. IPC on ihan kirjaimellisesti "instructions per clock" ja jos peli kulkee kovempaa niin se ajaa enemmän käskyjä samassa ajassa, eli IPC on korkeampi. Tämän lisäksi siellä tehtäneen ytimiin myös muita muutoksia jotka myös vaikuttavat IPC:n kasvuun.
Et voi sanoa että "CCX muutos lisää IPC:tä jo ennen mitään IPC lisää", sillä tossa lauseessa ei ole mitään järkeä.
sano mielummin että "CCX muutos jo itsessään nostaa IPC:tä paljon, puhumattkaan muista potentiaalisista arkkitehtuurimuutoksista."

Kun pelin lanka on ccx:llä ja se tarvii toisella ccx:llä olevan langan dataa, on se viive suurempi ja vaikuttaa peleissä suorituskykyyn. Ccx-ccx viive on n. tuplat vs. Ccx sisäinen viive.
 
Kun pelin lanka on ccx:llä ja se tarvii toisella ccx:llä olevan langan dataa, on se viive suurempi ja vaikuttaa peleissä suorituskykyyn. Ccx-ccx viive on n. tuplat vs. Ccx sisäinen viive.
Kyllä, ja tuon rakenteen muuttaminen sellaiseksi jossa jopa kahdeksan ydintä muodostaa sen CCX:n kasvattaa IPC:tä peleissä.
 
Kun pelin lanka on ccx:llä ja se tarvii toisella ccx:llä olevan langan dataa, on se viive suurempi ja vaikuttaa peleissä suorituskykyyn. Ccx-ccx viive on n. tuplat vs. Ccx sisäinen viive.

Nyt jos FPS uskovaisten logiikalla lähdettäisiin tuota purkamaan niin Zen 3 olisi 50% nopeampi!!11 ;)
 
Kun pelin lanka on ccx:llä ja se tarvii toisella ccx:llä olevan langan dataa, on se viive suurempi ja vaikuttaa peleissä suorituskykyyn. Ccx-ccx viive on n. tuplat vs. Ccx sisäinen viive.
Kyllä, ja tuon rakenteen muuttaminen sellaiseksi jossa jopa kahdeksan ydintä muodostaa sen CCX:n kasvattaa IPC:tä peleissä.

Niin tässä puhutaan NUMA-latensseista..

Tässä oli ihan hyvin selitetty:
 
Niin tässä puhutaan NUMA-latensseista..

Tässä oli ihan hyvin selitetty:
... joiden laskeminen nostaa IPC:tä, sillä prosessori joutuu odottelemaan tarvittavaa dataa lyhyempiä aikoja. Hyvin suuri osa IPC parannuksista liittyy nimenomaan siihen että prossun laskentaresursseja voidaan käyttää tehokkaammin odotteluaikoja minimoimalla.

Edit: ja taas rautalangasta: IPC voidaan aina määrittää vain sovelluskohtaisesti. Jos pelissä yhden pelimoottorisyklin (framen) käsittelyyn kuluu vaikka miljoona käskyä, niin suoritettujen käskyjen (instruction) määrä sekunnissa skaalautuu lineaarisesti fps:n mukaisesti. Prosessorin IPC voidaan määrittää siten seuraavasti: (fps * käskyä per pelimoottorisykli)/kellontaajuus. Näin saadaan kirjaimellisesti laskettua se käskyä prosessorisyklissä -metriikka (instructions per cycle).
 
Viimeksi muokattu:
... joiden laskeminen nostaa IPC:tä, sillä prosessori joutuu odottelemaan tarvittavaa dataa lyhyempiä aikoja. Hyvin suuri osa IPC parannuksista liittyy nimenomaan siihen että prossun laskentaresursseja voidaan käyttää tehokkaammin odotteluaikoja minimoimalla.

Edit: ja taas rautalangasta: IPC voidaan aina määrittää vain sovelluskohtaisesti. Jos pelissä yhden pelimoottorisyklin (framen) käsittelyyn kuluu vaikka miljoona käskyä, niin suoritettujen käskyjen (instruction) määrä sekunnissa skaalautuu lineaarisesti fps:n mukaisesti. Prosessorin IPC voidaan määrittää siten seuraavasti: (fps * käskyä per pelimoottorisykli)/kellontaajuus. Näin saadaan kirjaimellisesti laskettua se käskyä prosessorisyklissä -metriikka (instructions per cycle).

Se, että otat FPS:n mukaan tuohon IPC:hen, ei ole ihan oikea tapa. Sitten muistinopeudella on merkitystä ja kellotaajuudella (RAM+CPU).. IPC:n pitäisi olla näistä riippumaton.
 
Se, että otat FPS:n mukaan tuohon IPC:hen, ei ole ihan oikea tapa.

Kyllä on. Tuo nimenomaan kertoo montako käskyä suoritettiin kellojaksoa kohden keskimäärin, mikä on IPCn määritelmä.

Sitten muistinopeudella on merkitystä ja kellotaajuudella (RAM+CPU).. IPC:n pitäisi olla näistä riippumaton.

:facepalm:

KAIKELLA on merkitystä IPC:hen.

Ja kaikkein eniten siihen IPChen nykyaikana vaikuttaa se, paljonko kaikkea joudutaan odottelemaan. Ei se, montako laskentayksikköä siellä prosessorilla on.
 
Se, että otat FPS:n mukaan tuohon IPC:hen, ei ole ihan oikea tapa. Sitten muistinopeudella on merkitystä ja kellotaajuudella (RAM+CPU).. IPC:n pitäisi olla näistä riippumaton.
Mutta kun ne eivät ole toisistaan riippumattomia asioita. Myös muistiohjaimien muutokset ovat nostaneet prosessorien IPC:tä aina ja tulevat sitä jatkossakin tekemään. Lisäksi esim. infinity fabric on vahvasti prossun sisäinen elementti ja vaikuttaa IPC:hen esim. erilaisten latenssien muodossa, mutta on kellontaajuutensa osalta sidottu muistien nopeuteen. Sen puolesta voi kyllä väitellä, että pitäisikö testeissä käytetyt muistinopeudet olla aina jedecin speksien mukaiset (tästä hyötyisi lähinnä AMD, sillä ne tukevat jedec 3200 speksiä, siinä missä intel ei muistaakseni edelleenkään speksiensä puolesta tue kuin jedec 2666 nopeutta).
 
Teidän laskelmilla voi ottaa markkinoiden parhaat DDR4-muistit, kellottaa ne maksimeihin, kiristää latenssit minimiin ja se on teidän mukaan riippumaton ja oikea IPC. :facepalm:
Tulosten pitäisi olla toistettavia prosessorilla. Nyt otatte lisämuuttujia, joita ei ole edes määritelty ja se on teidän mielestä ihan ok.

Intel teki tätä perseilyä ainakin Ivy Bridgessä. Eli nosti DDR3-tuen 1333MHz->1600MHz ja laski tuon suoraan IPC:hen. Ei se ole prosessorista riippuva asia ja ne, jotka käyttivät 1333MHz muisteja eivät saaneet luvattua suorituskykyparannusta. Ja ne, joilla oli kellotettavat prosessorit saivat osan lisä-IPC:tä ilmaiseksi ja vielä lisääkin, kun ostivat esim. 1833MHz muisteja.

Tämä näyttää kovin epätieteelliseltä meno täällä nyt. Markkinointi saa selvästi laittaa mitkä luvut vaan, kunhan on koonneet vastaavan koneen siihen ympärille. Laitetaan pari NVME-SSD:tä raidiin ja lasketaan latausajatkin IPC:hen! (kilpailijan laskenta sitten mekaanisella levyllä ja ilman RTX IO:ta).

edit: kun luen omaa viestiäni, niin vakioitua testikokoonpanoahan minä peräänkuulutan ja koko homma lähti siitä, että fps on niin huono mittari IPC:lle (myös normalisoituna). Kai sitä jotain saisi räpellettyä, jos edellisen generaation testaisi samalla setillä ja laskisi gainit prosentuaalisesti. Mutta tässäkin tapauksessa tulisi ylläribonusta siitä, että olisi esimerkin RTX IO ja PCI Express v4 käytössä, niin en kyllä vieläkään laskisi sitä näin. Tulee niin paljon lisämuuttujia ja turhaa kompleksisuutta (mutta toisaalta estää testiohjelmakohtaiset optimoinnit).
 
Viimeksi muokattu:
Teidän laskelmilla voi ottaa markkinoiden parhaat DDR4-muistit, kellottaa ne maksimeihin, kiristää latenssit minimiin ja se on teidän mukaan riippumaton ja oikea IPC. :facepalm:

:facepalm:

Mitä seuraavista kolmesta sanasta et ymmärrä:

"Instructions"

"per"

"Cycle"

?

Tulosten pitäisi olla toistettavia prosessorilla. Nyt otatte lisämuuttujia, joita ei ole edes määritelty ja se on teidän mielestä ihan ok.

:facepalm:

IPC ei ole mikään ytimen paremmuutta mittaava "testitulos" joka on tarkoitettu vertailtavaksi "mulla on suurempi kuin sulla-"lastentarhaväittelyihin.
Vaan se on ihan suoraan mitattava matalan tason luku siitä mitä prosessorin sisällä tapahtuu.

Se on luku joka kertoo ainostaan sen montako käskyä suoritetaan kellojaksossa.

Käytännössä se vaihtelee joka ikinen kellojakso

Sisään luetaan jollain kellojaksolla 3 käskyä, jollain 4, jollain micro-op-cachestä jopa 6, joillain kellojaksolla taas luetut käskyt heitetään menemään kun haarautumisenennustuksessa on tullut huti eikä niitä koskaan suoriteta.

Execute-vaiheessa suoritukseen menee sitten joka kellojakso joku määrä käskyjä, esim. Zen2illä mitä tahansa välilä 0-11.

Retire-vaiheessa sitten valmistuu joka kellojakso joku määrä (0-8) käskyä. Käytännössä siinä vaiheessa kun käsky valmistuu, se voidaan julistaa suoritetuksi.


Käytännössä tyypillisesti kun puhutaan IPCstä tarkoitetaan sitten sitä, montako käskyä keskimäärin valmistuu per kellojakso, ja tämäkin on aina sekä workload-kohtainen että systeemikohtainen


Kuvitelma, että IPC olisi joku prosessoriytimelle ominainen vakio-luku on todella pahasti väärinymmärretty

Mikä tahansa IPC joka prosessorilta mitataan on aina oikea IPC.
Se vaihtelee tilanteen mukaan.

Tämä näyttää kovin epätieteelliseltä meno täällä nyt.

Kyllä, kun täällä yhdellä ihmisillä on aivan totaalisen hukassa mitä "instructions per cycle" tarkoittaa.
 
Viimeksi muokattu:
Teidän laskelmilla voi ottaa markkinoiden parhaat DDR4-muistit, kellottaa ne maksimeihin, kiristää latenssit minimiin ja se on teidän mukaan riippumaton ja oikea IPC. :facepalm:
Tulosten pitäisi olla toistettavia prosessorilla. Nyt otatte lisämuuttujia, joita ei ole edes määritelty ja se on teidän mielestä ihan ok.

Intel teki tätä perseilyä ainakin Ivy Bridgessä. Eli nosti DDR3-tuen 1333MHz->1600MHz ja laski tuon suoraan IPC:hen. Ei se ole prosessorista riippuva asia ja ne, jotka käyttivät 1333MHz muisteja eivät saaneet luvattua suorituskykyparannusta. Ja ne, joilla oli kellotettavat prosessorit saivat osan lisä-IPC:tä ilmaiseksi ja vielä lisääkin, kun ostivat esim. 1833MHz muisteja.

Tämä näyttää kovin epätieteelliseltä meno täällä nyt. Markkinointi saa selvästi laittaa mitkä luvut vaan, kunhan on koonneet vastaavan koneen siihen ympärille. Laitetaan pari NVME-SSD:tä raidiin ja lasketaan latausajatkin IPC:hen! (kilpailijan laskenta sitten mekaanisella levyllä ja ilman RTX IO:ta).

edit: kun luen omaa viestiäni, niin vakioitua testikokoonpanoahan minä peräänkuulutan ja koko homma lähti siitä, että fps on niin huono mittari IPC:lle (myös normalisoituna). Kai sitä jotain saisi räpellettyä, jos edellisen generaation testaisi samalla setillä ja laskisi gainit prosentuaalisesti. Mutta tässäkin tapauksessa tulisi ylläribonusta siitä, että olisi esimerkin RTX IO ja PCI Express v4 käytössä, niin en kyllä vieläkään laskisi sitä näin. Tulee niin paljon lisämuuttujia ja turhaa kompleksisuutta (mutta toisaalta estää testiohjelmakohtaiset optimoinnit).
Kuten kirjoitin jo viestissäni, on ihan validia vaatia että testeissä käytettäisiin mahdollisumman nopeita prosessorin tukemia standardoituja (jedec) muisteja.
Jos prossuvalmistaja on sitä mieltä että sen omat prossut ei tue jotain korkeampaa kellontaajuutta, niin ne on niitä prossun ominaisuuksia ja valmistajan vika jos eivät kykene parempia validoimaan.

IPC on kuitenkin ihan (sovellus ja laitteistokohtaisesti) mitattava suure ja siihen vaikuttaa myös se välimuistin nopeus.
 
:facepalm:

Mitä seuraavista kolmesta sanasta et ymmärrä:

"Instructions"

"per"

"Cycle"

?

@pomk kaavassa oli cpu_cycle, tuossa on muistin cyclet jätetty kokonaan huomiotta.

Tuolta:

1599485434221.png


Sama kaava, eri tulokset, jos vaan vaihtaa muistien kelloja. FPS kun on se mittari.

:facepalm:

IPC ei ole mikään "testitulos" joka on tarkoitettu vertailtavaksi.

Se on luku joka kertoo ainostaan sen montako käskyä suoritetaan kellojaksossa.

Käytännössä se vaihtelee joka ikinen kellojakso

Sisään luetaan jollain kellojaksolla 3 käskyä, jollain 4, jollain kellojaksolla luetut käskyt heitetään menemään kun haarutumisenennustksessa on huti eikä niitä koskaan suoriteta.

Execute-vaiheessa suoritukseen menee sitten joka kellojakso joku määrä käskyujä, esim. Zen2illä mitä tahansa välilä 0-11.

Retire-vaiheessa sitten valmistuu joka kellojhakso joku määrä (0-8) käskyä.


Käytännössä tyypillisesti kun puhutaan IPCstä tarkoitetaan sitten sitä, montako käskyä keskimäärin valmistuu per kellojakso, ja tämäkin on aina sekä worklopad-klohtainen että systeemikohtainen


Kuvitelma, että IPC olisi joku prosessoriytimelle ominainen vakio-luku on todella pahasti väärinymmärretty



Kyllä, kun täällä yhdellä ihmisillä on aivan totalisen hukassa mitä "instructions per cycle" tarkoittaa.

Ylläolevasta kuvasta voi saada samalla kaavalla, samalla testikokoonpanolla, eri asetuksilla - neljä eri tulosta.

Se johtuu nyt siitä, että te että ymmärrä, mistä se FPS tulee ja luulette jotenkin , että pelkkä prosessorin kellotaajuus siihen vaikuttaa, kun pelkkä se on nimittäjässä.

--

..mutta jätän tämän osaltani tähän, kun tämä on tämmöistä jankkausta. Jos sieltä tulee järkevä ehdotus, miten FPS-lukemia voidaan käyttää IPC:n laskemisessa, niin tähän saa jotain järkeä.

Edelleen, IPC-parannus olisi suhteellisen helppo laskea vakioimalla koneen muu sisältö, mutta nyt sekään ei kelpaa..
 
Edelleen, IPC-parannus olisi suhteellisen helppo laskea vakioimalla koneen muu sisältö, mutta nyt sekään ei kelpaa..
IPC on laitteistokohtainen suure joka voidaan määrittää sovelluskohtaisesti. Wikipediassakin on se oikea määritelmä tälle: The number of instructions executed per clock is not a constant for a given processor; it depends on how the particular software being run interacts with the processor, and indeed the entire machine, particularly the memory hierarchy.

Edit: prosessoreille voidaan myös määrittää jotain teoreettisia IPC maksimeja, kuten vaikka GPU markkinoinnissa käytettävät erikokoiset flopsit ja iopsit. Nämä eivät yleensä riipu mistään muusta kuin prossujen ’raa’asta laskentatehosta’, mutta kyseisillä luvuilla ei oikein tee mitään, kun ihan oikeiden hyötyohjelmien ja pelien suorituskyvyt on vähintään yhtä helppo testata.
 
Viimeksi muokattu:
@pomk kaavassa oli cpu_cycle, tuossa on muistin cyclet jätetty kokonaan huomiotta.

Tuolta:

1599485434221.png


Sama kaava, eri tulokset, jos vaan vaihtaa muistien kelloja. FPS kun on se mittari.

Nimenomaan! Kaikki vaikuttaa siihen IPChen.

Tätä sinulle ollaan yritetty toitottaa!

Ylläolevasta kuvasta voi saada samalla kaavalla, samalla testikokoonpanolla, eri asetuksilla - neljä eri tulosta.

Se johtuu nyt siitä, että te että ymmärrä, mistä se FPS tulee ja luulette jotenkin , että pelkkä prosessorin kellotaajuus siihen vaikuttaa, kun pelkkä se on nimittäjässä.

:facepalm:

Voisitko nyt lopettaa muiden syyttämisen omista virheistäsi?

Toisin kuin sinä, me ymmärrämme, että siihen FPSään vaikuttaa kaikki. ja että se on ihan normaalia ja ok.

Edelleen, IPC-parannus olisi suhteellisen helppo laskea vakioimalla koneen muu sisältö, mutta nyt sekään ei kelpaa..

Yleispätevästi ei voi, koska se kaikki muu vaikuttaa siihen IPC:hen ja se parannus pätisi vain niissä olosuhteissa.

Ei ole mitään "yleistä IPC-parannusta" vaan on ainoastaan tilannekohtainen IPC-parannus

Esimerkki:

Oletetaan vaikka joku ydin ja koodi siten että tuolla ytimellä, tuolla koodilla, niin kauan kun se koodi ei käsittele muistia, sitä suoritetaan keskimäärin IPCllä 2.

Muistin viive on sitten 50ns, OoOE pystyy piilottamaan tätä viivettä 80 käskyn verran , ja tässä koodissa on L3-välimuistihuti, DRAM-muistiin asti menevä muistiaccess 1000 käskyn välein.

1 GHz nopeudella 80 käskyä suoritetaan 40 kellojaksossa eli 40 nanosekunnissa, muistin näkyväksi viiveeksi jää 10ns

1000 käskyn suoritukseen kuluu sitten aikaa 510 ns, eli IPC on n. 1.96

4 GHz nopeudella 80 käskyä suoritetaan 40 kellojaksossa eli 10 nanosekunnissa, muistin näkyväksi viiveeksi jää 40ns.

1000 käskyn suoritukseen kuluu sitten aikaa 125ns + 40ns = 165 ns eli IPC on n. 1.52

Samalla mikroarkkitehtuurilla, samalla koodilla siis IPC tässä vaihtelee kellotaajuuden mukaan jopa >25%.



Entäs jos suurennetaankin L3-kakkua siten että saadaan vähemmän L3-huteja? 1/2000 käskyn välein. Paljonko meidän IPC kasvaa?

1 GHz:lla 2000 käskyn suoritukseen kuluu aikaa 1010 ns, eli IPC on n. 1.98. IPC siis lisääntyi n. 1%.

4 GHz:lla 2000 käskyn suoritukseen kuluu aikaa 250ns + 40ns = 290 ns eli IPC on n . 1.72. IPC siis lisääntyi n. 13%.


Sama parannus mikroarkkitehtuuriin paransi IPCtä toisella kellotaajuudella 13%, toisella kellotaajuudella 1%

Ja molemmat ovat ihan yhtä oikein. Vaikka kyse jopa samoista mikroarkkitehtuurista ja samasta koodista.

Sitten kuin verrataan IPCtä eri ohjelmien välillä, muuttujia on vielä paljon enemmän.



Summa summarum: Ei ole mitään "yleispätevää IPCtä" joka on mikroarkkitehtuurin ominaisuus. Vaan kaikki vaikuttaa IPChen. Mikä tahansa IPC joka mikroarkkitehtuurilta on jossain tilanteessa mitattu on ihan yhtä oikein, mutta pitää aina huomioida että se pätee vain siinä tilanteessa.
 
Viimeksi muokattu:
Nimenomaan! Kaikki vaikuttaa siihen IPChen.

Tätä sinulle ollaan yritetty toitottaa!

Mutta jos puhutaan ja yritetään määrittää PROSESSORIN IPC:tä ei saisi vaikuttaa.

Esimerkki:
- Sandy Bridge 2600K julkaistaan ja testataan, FPS pelissä X kyseisen vuoden parhaalla näytönohjaimella on vaikka 100
- Samaa (2600K) prosessoria testataan 10 vuotta myöhemmin ja nyt muuttujana on eri näytönohjain jolloin FPS onkin 500.

Voidaanko siis sanoa että pelkästään käyttämällä 2600K prosessoria sen IPC on yllättäen 10 vuodessa kasvanut julkaisun numerosta 1 myöhemmin saatavaan 5?

Eli lähes jokainen prosessori, sen IPC tulee kasvamaan ja nopeutumaan lähes takuuvarmasti kunhan uusia & nopeampia näytönohjaimia vain julkaistaan.

Täten voimme todeta että minkä tahansa prosessorin IPC ei ole koskaan vakio vaan täysin muuttuva suure minkä muuttuvuuteen vaikuttaa jokainen myyty yksilö (käyttäjä) ja mitä pidempään yksilö käyttää tätä samaa prosessoria mutta muistaa päivittää ympäröivää rautaa (sekä softaa) parempaan prosessorin IPC tulee luultavasti jatkuvasti nousemaan portaittain mihin vaikuttaa eniten päivityksiin käytetty raha sekä prosessorin julkaisusta kulunut aika?

Edit:
Tämä myös teoriassa tarkoittaa sitä että jos ensin on saanut vaikka tuloksen 1FPS testatessa SB 2600K prosessoria käyttäen ainoastaan sen integroitua näytönohjainta ja hankkii myöhemmin julkaistavan GTX 3090 näytönohjaimen ja saa esim. 1000FPS samasta testistä prosessorin IPC on räjähdyksenomaisesti noussut 1000 kertaisesti ostohetkestä? Minusta tuota ei voi eikä pidä testata ihan noin...
 
Viimeksi muokattu:
Esimerkki:
- Sandy Bridge 2600K julkaistaan ja testataan, FPS pelissä X kyseisen vuoden parhaalla näytönohjaimella on vaikka 100
- Samaa (2600K) prosessoria testataan 10 vuotta myöhemmin ja nyt muuttujana on eri näytönohjain jolloin FPS onkin 500.

Voidaanko siis sanoa että pelkästään käyttämällä 2600K prosessoria sen IPC on yllättäen 10 vuodessa kasvanut julkaisun numerosta 1 myöhemmin saatavaan 5?
Teknisesti kyllä, sillä aikaisemmin laitteistossa on ollut raju pullonkaula jossain muualla, tästä syystä johtuen monesti prossuja testataan peleissä matalilla resoluutioilla. Lisäksi kuvailet lähinnä näytönohjaintestiä tuossa, sillä prossuja testatessa pyritään luonnollisesti kontrolloimaan mahdollisimman hyvin kaikki muut komponentit johonkin ideologiaan perustuen, ja sitä laitteistojen välistä IPC eroa verrataan lähinnä prosessoria vaihtamalla.

Täten voimme todeta että minkä tahansa prosessorin IPC ei ole koskaan vakio vaan täysin muuttuva suure minkä muuttuvuuteen vaikuttaa jokainen myyty yksilö (käyttäjä) ja mitä pidempään yksilö käyttää tätä samaa prosessoria mutta muistaa päivittää ympäröivää rautaa (sekä softaa) parempaan prosessorin IPC tulee luultavasti jatkuvasti nousemaan portaittain mihin vaikuttaa eniten päivityksiin käytetty raha sekä prosessorin julkaisusta kulunut aika?
Ajalla tossa ei ole mitään merkitystä, muuten olet kyllä ihan oikeassa. Lisäksi IPC vertailuissa softa on vakioitu testialustojen välillä, sillä muuten tuloksilla ei tee mitään. Eli kun laitteiston pullonkauloja poistetaan, niin sen IPC kasvaa. Päivittäminenhän olisi ihan hullun hommaa jos suorituskyky ei sillä kasvaisi.

Edit:
Tämä myös teoriassa tarkoittaa sitä että jos ensin on saanut vaikka tuloksen 1FPS testatessa SB 2600K prosessoria käyttäen ainoastaan sen integroitua näytönohjainta ja hankkii myöhemmin julkaistavan GTX 3090 näytönohjaimen ja saa esim. 1000FPS samasta testistä prosessorin IPC on räjähdyksenomaisesti noussut 1000 kertaisesti ostohetkestä? Minusta tuota ei voi eikä pidä testata ihan noin...
Kyllä tossa on nimenomaan laitteiston IPC kasvanut kyseisessä sovelluksessa räjähdyksenomaisesti, tai ainakin minusta tuhatkertaista suorituskykyä voi kuvailla moisella sanalla.

edit:
Mutta jos puhutaan ja yritetään määrittää PROSESSORIN IPC:tä ei saisi vaikuttaa.
Haluaisin kyllä nähdä sen testijärjestelmän jonka avulla pelkkä PROSESSORIN IPC lasketaan.

edit2: hkultalalla oli kyllä ihan hyvä huomio siitä että mitä se prossu sit tekee odotellessaan näytönohjainta, eli ei ehkä voi niin yksinkertaisesti noin voimakkaasti gpu pullonkaulaisen softan ajossa sitä IPC:tä laskea.
 
Viimeksi muokattu:
Mutta jos puhutaan ja yritetään määrittää PROSESSORIN IPC:tä ei saisi vaikuttaa.

"PROSESSORIN IPC" joka ei muutu ajettavan softan ja muun systeemin mukana on yhtä järkevä asia yrittää määrittää kuin yrittää määritellä vaikka Helsingin vakiolämpötila ja Helsingin vakiotuulennopeus jotka pitävät aina paikkaansa mutta eivät muutu säätilan mukana tunnista toiseen, päivästä toiseen, vuodesta toiseen.

Sille, että jotkut asiat muuttuu, ei vaan voi mitään. Se, että yritetään määritellä niille joku "vakioarvo" on vaan typeryyttä.

Esimerkki:
- Sandy Bridge 2600K julkaistaan ja testataan, FPS pelissä X kyseisen vuoden parhaalla näytönohjaimella on vaikka 100
- Samaa (2600K) prosessoria testataan 10 vuotta myöhemmin ja nyt muuttujana on eri näytönohjain jolloin FPS onkin 500.

Voidaanko siis sanoa että pelkästään käyttämällä 2600K prosessoria sen IPC on yllättäen 10 vuodessa kasvanut julkaisun numerosta 1 myöhemmin saatavaan 5?

Ei.

Noissa suoritetaan eri määrä käskyjä eri ajassa TAI aika, minkä prosessori laskee, pysyy edelleen käytännössä samana:

Kun prosessori odottelee näytönohjainta, se joko
1) odottelee spinloopissa, suorittaa ylimääräisiä käskyjä.
2) nukkuu tai suorittaa jonkun ihan muun ohjelman koodia. Eli siis se prosessorin käyttämä kellojaksomäärä on pienempi (yhteen frameen sama kuin sen nopeamman näyttiksen kanssa)

Spinloopissa odottelun IPC voi sitten olla joko pienempi TAI suurempi kuin itse pelin muun koodin keskimäärinen IPC eli se saattaa vaikuttaa joko sitä nostavasti tai laskevasti. Itse pelin hyödyllisen laskennan IPC pysyy kuitenkin tällöin käytännössä samana.

Asiat, mitkä tässä näyttiksen vaihdoksessa oikeasti muuttaa sitä IPCtä on esim.
1) Näyttiksillä on erilaiset ajurit ja toisen ajurien koodin IPC on eri kuin toisen
2) Toisen näyttiksen ajurit käsittelee suurempaa datamäärää ja tätä dataa tulee välimuisteihin ja tämä vaikuttaa myös itse pelin koodin välimuistin osumatarkkuuteen ja sen kautta IPChen
3) Toisella näyttiksellä on vähemmän muistia ja sinne latailllan tavaraa keskusmuistista jonka takia muistiväylällä on välillä ruuhkaa, ja jotkut muistiaccessit kestää eri ajan

Eli lähes jokainen prosessori, sen IPC tulee kasvamaan ja nopeutumaan lähes takuuvarmasti kunhan uusia & nopeampia näytönohjaimia vain julkaistaan.

Ei.

Täten voimme todeta että minkä tahansa prosessorin IPC ei ole koskaan vakio vaan täysin muuttuva suure minkä muuttuvuuteen vaikuttaa jokainen myyty yksilö (käyttäjä) ja mitä pidempään yksilö käyttää tätä samaa prosessoria mutta muistaa päivittää ympäröivää rautaa (sekä softaa) parempaan prosessorin IPC tulee luultavasti jatkuvasti nousemaan portaittain mihin vaikuttaa eniten päivityksiin käytetty raha sekä prosessorin julkaisusta kulunut aika?

Oikeilla jäljillä, mutta oikeasti tässä mennään uusien softien myötä ehkä enemmän toiseen suuntaan: Se keskimääräinen IPC pikemminkin LASKEE koska uudemmat softat käyttää keskimäärin esim. suurempaa määrää muistia ja välimuistien osumatarkkuudet huononee, eli käytetään enemmän aikaa muistien odotteluun.

Lisäksi uusien SIMD-käskykantojen käyttöönotto tarkoittaa sitä, että vaikka suorituskyky kasvaa, se kasvaa nimenomaan sen kautta, että suoritettujen käskyjen määrä vähenee, joten IPC saattaa vähentyä samalla kun kellotaajuuskohtainen suorituskyky paranee.
 
Viimeksi muokattu:
Tämän sekamelskan vuoksihan tehdään vakioituja testejä joissa esim ajetaan 5 sukupolvea prossuja kiinteillä, samoilla kelloilla samalla muistinopeudella. Ja vielä semmoisia että näytönohjain ei tulokseen vaikuta. Cinebench on hyvä esimerkki testistä kuten myös esim chromiumin kääntäminen.
 
Tämän sekamelskan vuoksihan tehdään vakioituja testejä joissa esim ajetaan 5 sukupolvea prossuja kiinteillä, samoilla kelloilla samalla muistinopeudella.
Eli muistitekniikoiden yli ei voida verrata IPC:tä?
Muistiohjain on keskeinen osa prosessoria ja sen kehityksen huomiotta jättäminen antaa vanhoille prossuille etulyöntiaseman. Jokaisen prossun spekseissä eksplisiittisesti lukee että mitä muistinopeuksia kyseisen prossun muistiohjaimen on luvattu tukevan ja on ihan loogista valita niiden tietojen mukaiset kammat prossun kaveriksi.
 
Eli muistitekniikoiden yli ei voida verrata IPC:tä?
Muistiohjain on keskeinen osa prosessoria ja sen kehityksen huomiotta jättäminen antaa vanhoille prossuille etulyöntiaseman. Jokaisen prossun spekseissä eksplisiittisesti lukee että mitä muistinopeuksia kyseisen prossun muistiohjaimen on luvattu tukevan ja on ihan loogista valita niiden tietojen mukaiset kammat prossun kaveriksi.
Meinaat että i9-9900k:lle hyvät muistit olisi DDR4-2666 ja i7-7700k joutuisi tyytymään hurjasti huonompaan DDR4-2400 muistiin. Mites latenssit?

Onnksi AMD:llä saa ajaa up to 3200MHz
 
Meinaat että i9-9900k:lle hyvät muistit olisi DDR4-2666 ja i7-7700k joutuisi tyytymään hurjasti huonompaan DDR4-2400 muistiin. Mites latenssit?

Onnksi AMD:llä saa ajaa up to 3200MHz
Latenssit luonnollisesti jedec speksien mukaisesti, kaikki muu on ylikellottamista. Tuolta löytyy lista kaikista mahdollisista jedec kammoista: DDR4 SDRAM - Wikipedia

Jos ne prossut kulkee kovempaa, niin valmistajat varmaan osaa validoida ne kovemmille kellontaajuuksille. Nythän esim. intel katkaisee tuotteen takuun jos saa tietää että muisteja on ajettu edes XMP päällä.
 
Latenssit luonnollisesti jedec speksien mukaisesti, kaikki muu on ylikellottamista. Tuolta löytyy lista kaikista mahdollisista jedec kammoista: DDR4 SDRAM - Wikipedia

Jos ne prossut kulkee kovempaa, niin valmistajat varmaan osaa validoida ne kovemmille kellontaajuuksille. Nythän esim. intel katkaisee tuotteen takuun jos saa tietää että muisteja on ajettu edes XMP päällä.
Jaa että 3200 MHz pitäisi ajaa 20-20-20 tai suuremmilla latenseilla
Mitä virkaa koko jedecin taajuuksilla ja latenseilla on, kun ne eivät ole tästä maailmasta.
 
Jaa että 3200 MHz pitäisi ajaa 20-20-20 tai suuremmilla latenseilla
Mitä virkaa koko jedecin taajuuksilla ja latenseilla on, kun ne eivät ole tästä maailmasta.
Ne on standardoitu ja prosessorit on määritetty toimimaan niiden mukaisesti, sitä virkaa niillä on. Tavallaan yhtä reilua olisi ylikellottaa kaikkien prossujen muistit tappiin asti, mutta silloin me nimenomaan lisätään sitä ”prosessorin IPC:n” määrittämisen vaikeutta, sillä kaikki prossut ja muistit kulkee yksilöllisesti ja kyseessä ei olisi enää millään tapaa standardoitu testiasetelma. Siinä ei ole mitään tasavertaista, että eri prossujen muistiohjaimia ylikellotetaan johonkin näennäisen satunnaisesti valittuun yhtenäiseen nopeuteen, jos siis on tarkoitus yrittää etsiä nimenomaan prosessorien IPC eroja (ja muistutuksena vielä, että muistiohjain on osa prosessoria). Joko ei kelloteta ollenkaan, tai sit kellotetaan tappiin, kaikki muu on sen prosessorin kykyjen näkökulmasta epäreilua.

Edelleen, jos intel/amd olisivat sitä mieltä että niiden muistiohjaimet toimivat luotettavasti kovemmilla kelloilla, niin niillä olisi jotain qvl listoja prossujen ja muistien yhteensopivuuksista. Vai onko sulla mitään selitystä sille miksi intel leikkaa takuut jos tunnustat ajaneesi prossusi kanssa muisteja yli 2666MHz nopeudella?
 
Kannattaisiko suosiolla jättää tuo ymmärtämättömyyteen perustuvilla olkiukoilla leikkiminen, kun saat sillä aikaiseksi vain erikoisia väittämiä, jotka menevät joka suunnasta ohi.

Ilmeisesti herralle ei oikein avautunut. Monille FPS tuntuu olevan sellainen jumalainen mittari jolla voidaan tarkoin määritellä että esim. millä CPU:lla voidaan pelata pumpum pelejä ja millä ei jos toinen saavuttaa vaikka 240FPS, toisen jäädessä 210FPS. Sehän on vain yksi monesta kokonaisuuteen vaikuttavasta asiasta aivan samoin kuin joku cache latenssi.

Muutenkin viesti oli tarkoitettu lähinnä kevennyksenä. Mutta ymmärrän toki että täällä porukka on niin huumorintajutonta että kommenttihan oli suorastaan mauton.

Tämän sekamelskan vuoksihan tehdään vakioituja testejä joissa esim ajetaan 5 sukupolvea prossuja kiinteillä, samoilla kelloilla samalla muistinopeudella. Ja vielä semmoisia että näytönohjain ei tulokseen vaikuta. Cinebench on hyvä esimerkki testistä kuten myös esim chromiumin kääntäminen.

chromiumin kääntäminen IPC mittariksi ei välttämättä ole kovin hyvä työväline ellei sitä ajella sitten esim. ramdiskiltä mutta monella ei varmaan ole niin paljon muistia että sorsat ja itse buildi mahtuisi ramdiskille, ellei käytä sitten pakkausta siinä ramdiskillä joka taas johtaa siihen että testataanko kääntämisen ipc:tä vaiko jotain muuta kuten pakkaamista/purkamista.
Chromium touhuaa levyllä aika paljon ja muutenkin koodin kääntäminen mielestäni soveltuu IPC testinä ainoastaan yhdellä säikeellä tehtynä koska riippuen koodista se saattaa viettää paljonkin aikaa pelkästään yhdellä säikeellä. Josta sitten päästään siihen että chromium on varsin aikaa vievä testi yhdellä säikeellä tehtynä. Ja jos levyltä kääntää niin sitten on taas muuttujina levyn luku/kirjoitusnopeudet.
Tollanen cinepeli on huomattavasti parempi siihen CPU:n ipc testaamiseen, siihen kun ei vaikuta levyt eikä GPU:t.
 
Ne on standardoitu ja prosessorit on määritetty toimimaan niiden mukaisesti, sitä virkaa niillä on. Tavallaan yhtä reilua olisi ylikellottaa kaikkien prossujen muistit tappiin asti, mutta silloin me nimenomaan lisätään sitä ”prosessorin IPC:n” määrittämisen vaikeutta, sillä kaikki prossut ja muistit kulkee yksilöllisesti ja kyseessä ei olisi enää millään tapaa standardoitu testiasetelma. Siinä ei ole mitään tasavertaista, että eri prossujen muistiohjaimia ylikellotetaan johonkin näennäisen satunnaisesti valittuun yhtenäiseen nopeuteen, jos siis on tarkoitus yrittää etsiä nimenomaan prosessorien IPC eroja (ja muistutuksena vielä, että muistiohjain on osa prosessoria). Joko ei kelloteta ollenkaan, tai sit kellotetaan tappiin, kaikki muu on sen prosessorin kykyjen näkökulmasta epäreilua.

Edelleen, jos intel/amd olisivat sitä mieltä että niiden muistiohjaimet toimivat luotettavasti kovemmilla kelloilla, niin niillä olisi jotain qvl listoja prossujen ja muistien yhteensopivuuksista. Vai onko sulla mitään selitystä sille miksi intel leikkaa takuut jos tunnustat ajaneesi prossusi kanssa muisteja yli 2666MHz nopeudella?
On muuten jännä että mun muisteissa ei oo spd taulussa yhtään noista jedecin nopeus/latenssi comboista
 
Vai onko sulla mitään selitystä sille miksi intel leikkaa takuut jos tunnustat ajaneesi prossusi kanssa muisteja yli 2666MHz nopeudella?
Laiskuus/resussien priorisointi.
Ei ole jaksettu validioida niitä korkeampia kellotaajuuksia. Ja jos luvataan joku nopeus silloin kaikki pitää toimia sillä nopeudella eikä ole jaksettu testata mitkä kammat kykenee siihen nopeuteen ja latenseihin. Lisäksi muistikampojen lämpötila vaikuttaa myös siihen millaisiin kellotaajuus ja latensiyhdistelmiin päästään.

Xmp evää takuun vain paperilla. Gamers Nexus testasi asian.
 
On muuten jännä että mun muisteissa ei oo spd taulussa yhtään noista jedecin nopeus/latenssi comboista
Jännittävää. Mitkä muistit on kyseessä ja mitä sieltä taulusta löytyy? Lisäksi olis kiva tietää mitkä ajotukset se iskee päälle jos resettaat biosin.
 
Jännittävää. Mitkä muistit on kyseessä ja mitä sieltä taulusta löytyy? Lisäksi olis kiva tietää mitkä ajotukset se iskee päälle jos resettaat biosin.
itseasiassa kun luki thaiphoon burnerilla kaikki nopeudet niin alapäässä oli noita specsin mukasiaki pari kappaletta. jostain syystä suurin osa on tämmösiä huonommalla CL:llä olevia. Muistit on jotku crucialin 3000c15 kammat


1067(2133) MHz20151535
 
itseasiassa kun luki thaiphoon burnerilla kaikki nopeudet niin alapäässä oli noita specsin mukasiaki pari kappaletta. jostain syystä suurin osa on tämmösiä huonommalla CL:llä olevia. Muistit on jotku crucialin 3000c15 kammat


1067(2133) MHz20151535
Hyvä että löytyi, muuten sulla ei olisi ollu koneessa teknisesti ottaen DDR4 muistit.
 
1usmusilta tullut liuta paljastuksia Zen 3:sta. Kuten aina, suolasirotin kannattaa pitää käden ulottuvilla.





 
Todennäköisesti ihan faktaa kun perustuu BIOSin nuuskimiseen. Tietysti sillä varauksella että asiat jotka on teknisesti toteutettu eivät välttämättä aina päädy myyntiin asti koska markkinointi päättää toisin, tai koska tulee teknisiä ongelmia ja uusi hieno feature pitää kytkeä pois niin että tuote voidaan shipata.
 
Onko tässä joku "catch" mitä en vaan ymmärrä - uuteen koneeseen katsellut 3700X:ää ja 3900X:ää - molempia saa mindfactorystä satkun halvemmalla mitä jimssiltä? Intelin prossuissa hinta-ero on vaan joitain kymppejä. AMD Ryzen 7 3700X 8x 3.60GHz So.AM4 BOX - Sockel AM4 | Mindfactory.de
Saksan alvit laski 16%:iin. Jimmsillä toki silti melko kallista.

Myöskään tuo ei toimita suoraan Suomeen, pitää käyttää kuriiria, joka maksaa 15-20€, ja tämä syö hyötyjä, jos tilaat vain vähän.
 
Zen 3 tulossa ilmeisesti 8. lokakuuta? En tiedä juuri mitään twitteristä, mutta vaikuttaisi viralliselta:



Jos twiitti ei näy, niin tässä vielä se:

A new era of leadership performance across computing and graphics is coming. The journey begins on October 8.
navi-zen.jpg


EDIT: Nyt löytyy foorumin uutisistakin, eli vaikuttaa varmalta: AMD julkaisee Zen 3 -arkkitehtuurin Ryzen-prosessorit lokakuun alkupuolella
 
Viimeksi muokattu:
Se huomistwiitti kuulostaa kovasti varmemmin olevan esim niitä APUja kuluttajamarkkinoille tai muuta pikkusta ja täydentävää
 
Näinköhän sieltä tulee myös X670 piirisarjaa pihalle samalla? Onko tästä ollut mitään huhuja?
 
Näinköhän sieltä tulee myös X670 piirisarjaa pihalle samalla? Onko tästä ollut mitään huhuja?
Mitä hyötyä siitä vois olla? Mitä uuden piirisarjan vaativia ominaisuuksia nyt on mitä 550 ja 570 ei tue?
 

Statistiikka

Viestiketjuista
258 125
Viestejä
4 487 393
Jäsenet
74 158
Uusin jäsen
kharim

Hinta.fi

Back
Ylös Bottom