• Live: io-techin pikkujoulu- ja hyväntekeväisyysstriimi tänään alkaen klo 19. Pelataan io-techin toimituksen kesken PUBGia ja tavoitteena saada 10000 euroa täyteen Pelastakaa Lapset ry:n joulukeräykseen! Tule mukaan katselemaan ja keskustelemaan! Linkki lähetykseen >>

Virallinen: AMD vs Intel keskustelu- ja väittelyketju

  • Keskustelun aloittaja Keskustelun aloittaja Sampsa
  • Aloitettu Aloitettu
Jees, odottelen kiinnolla tulevaa kk, että näkee The Stiltin testi raportin. Aikaisemmissakin oli selkeän näköiset palkit. :tup:
 
Aiemmin kyselin mitä esim. Zetterin testikokoonpanot ottavat seinästä. Kaivelin sitten hieman esimerkkejä tuolta internetsin ihmeellisestä maailmasta. Ja kuinka vertailukelpoisia ovat, mutta on siinä ainakin jotain suuntaa antavaa näihin.

Xeon X5650 @ 4,37 GHz ja tehonkulutus oli 285 wattia. Linkki: Intel X5650 Overclocking – resulting a 4.37 GHz hexacore – tomrei.com
Ryzen 3 2200G @ vakio ja tehonkulutus 86 wattia. Linkki: Testissä AMD Ryzen 5 2400G & Ryzen 3 2200G (Raven Ridge) - io-tech.fi
Ryzen 5 2400G @ vakio ja tehonkulutus 100 wattia. Linkki: Testissä AMD Ryzen 5 2400G & Ryzen 3 2200G (Raven Ridge) - io-tech.fi
i7 860 @ vakio ja tehonkulutus 180 wattia. Linkki: The Intel Core i7 860 Review

Siinä saa SERriin laitella vähän järeämpää virtalähdettä jos lähtee kelloja hakemaan ja ei taideta ihan parin kympin coolereillakaan pärjätä noiden tehojen suhteen. Mutta jokainen joutuu itse päätöksensä tekemään, itse lähtisin mieluummin 2200G linjalle ja saa uuden alustan, takuunalaisen. Sekä saa niitä nykyajan ominaisuuksia (esim. M.2, USB3, Sata 3) ihan out of box. Vielä kun saisivat noita DDR4 hintoja alaspäin..
 
Dudem sanoi:
Aiemmin kyselin mitä esim. Zetterin testikokoonpanot ottavat seinästä. Kaivelin sitten hieman esimerkkejä tuolta internetsin ihmeellisestä maailmasta. Ja kuinka vertailukelpoisia ovat, mutta on siinä ainakin jotain suuntaa antavaa näihin.

Xeon X5650 @ 4,37 GHz ja tehonkulutus oli 285 wattia. Linkki: Intel X5650 Overclocking – resulting a 4.37 GHz hexacore – tomrei.com
Ryzen 3 2200G @ vakio ja tehonkulutus 86 wattia. Linkki: Testissä AMD Ryzen 5 2400G & Ryzen 3 2200G (Raven Ridge) - io-tech.fi
Ryzen 5 2400G @ vakio ja tehonkulutus 100 wattia. Linkki: Testissä AMD Ryzen 5 2400G & Ryzen 3 2200G (Raven Ridge) - io-tech.fi
i7 860 @ vakio ja tehonkulutus 180 wattia. Linkki: The Intel Core i7 860 Review

Siinä saa SERriin laitella vähän järeämpää virtalähdettä jos lähtee kelloja hakemaan ja ei taideta ihan parin kympin coolereillakaan pärjätä noiden tehojen suhteen. Mutta jokainen joutuu itse päätöksensä tekemään, itse lähtisin mieluummin 2200G linjalle ja saa uuden alustan, takuunalaisen. Sekä saa niitä nykyajan ominaisuuksia (esim. M.2, USB3, Sata 3) ihan out of box. Vielä kun saisivat noita DDR4 hintoja alaspäin..
Napsauta laajentaaksesi...

Tuo X5650 tulos ei voi pitää paikkaansa mitenkään. Noctua NH-D15 oli mulla tuossa jääynä (yhdellä tuulettimella) niin Prime95 kuormalla lämmöt 86C. Peleissä 57-68C eli viileämpi kuin nykyiset Coffee Lake i7:t. Joten tuo watti määrä ei voi olla mahdollista. Tämä siis 4.50GHz kelloilla.

EDIT: Nuo DDR4 muistihinnat tekevät SER-vehkeistä paljon houkuttelevammat. Sitten jos päästään takas sinne n.40€ 8GB hintoihin niin sitten asia on aivan toinen.
 
Viimeksi muokattu:
Zetteri sanoi:
Tuo X5650 tulos ei voi pitää paikkaansa mitenkään. Noctua NH-D15 oli mulla tuossa jääynä (yhdellä tuulettimella) niin Prime95 kuormalla lämmöt 86C. Peleissä 57-68C eli viileämpi kuin nykyiset Coffee Lake i7:t. Joten tuo watti määrä ei voi olla mahdollista. Tämä siis 4.50GHz kelloilla.
Napsauta laajentaaksesi...

Olikos ton ajan intelit juotettuja vielä?
 
svk sanoi:
Olikos ton ajan intelit juotettuja vielä?
Napsauta laajentaaksesi...

Toki olivat. Mutta ei Noctua NH-D15 jaksa 285W lämpökuormaa jaksa hoitaa mitenkään. Joten siksi kerroinkin että tulos ei voi vaan pitää paikkaansa.
Ja ei ollut edes kovin lämmin sitä koskettaessa.
 
Zetteri sanoi:
Laitetaas tähän noitten testejeni Cinebench scoret,video renderöinti ja 3dmark firestrike tulokset. Että ei tarvi valittaa että tulokset eivät ole "oikeita" tai jotain sinne päin.
3dmark tuloksista uupuu se i7 3820:n koska sitä mulla ei enää ollut kun aloin suorittaa näitä 3dmark testejä yleisöpalautteen takia.

Ja video renderöinnistä että näyttäis että tuo ei osaa hyödyntää oikein yli 8 säettä.
E5-2670 jossa 16 säettä niin CPU kuormat vain noin 60% ja 12 säikeisellä X5650:lla n.80%.

3dmark firestrike.png
cinebench.png
video.png
Napsauta laajentaaksesi...

Firestriken testeissä on kyllä jotain hämärää.. Pelkkä ikivanha Xeon ei tuota eroa tee.
Aiemmalla kokoonpanolla sain i7 3820 ja SLI 980:llä 15847 pistettä... 2 x 980GTX:ää on nopeampi Firestrikessä kuin yksi 980Ti.
I scored 15 847 in Fire Strike
 
Zetteri sanoi:
Tuo X5650 tulos ei voi pitää paikkaansa mitenkään. Noctua NH-D15 oli mulla tuossa jääynä (yhdellä tuulettimella) niin Prime95 kuormalla lämmöt 86C. Peleissä 57-68C eli viileämpi kuin nykyiset Coffee Lake i7:t. Joten tuo watti määrä ei voi olla mahdollista. Tämä siis 4.50GHz kelloilla.

EDIT: Nuo DDR4 muistihinnat tekevät SER-vehkeistä paljon houkuttelevammat. Sitten jos päästään takas sinne n.40€ 8GB hintoihin niin sitten asia on aivan toinen.
Napsauta laajentaaksesi...
Eikös sinulla ole kulutusmittaria jolla mitata? Ainakin olit laittanut serveri videoon tehonkulutuksesta juttua. Joten oletan että olit itse mittaillut?

svk sanoi:
TDP guidelines & cooler height Saattaa jaksaa, saattaa että ei. Mitä tuo 165W & OC sitten meinaakaan taulukossa.
Napsauta laajentaaksesi...
The overclocking headroom (OC) is specified as follows:
*** = best overclocking potential
** = medium overclocking potential
* = low overclocking potential
Napsauta laajentaaksesi...
 
Dudem sanoi:
Eikös sinulla ole kulutusmittaria jolla mitata? Ainakin olit laittanut serveri videoon tehonkulutuksesta juttua. Joten oletan että olit itse mittaillut?
Napsauta laajentaaksesi...

No oli semmoinen. Mutta se nyt päätti ottaa ja hajota (Tokmannin joku halppis) eli ei näytä mitään ruudussa. Pitänee varmaan hommata uusi ja katsoa paljon tuo mörkö vie virtaa kun tein siitä X5650@4.5GHz:sta ja GTX980ti:sta nykyisen koneeni edellisen E5-2670 tilalle.

EDIT: Mainittakoon muuten että Bloomfield Core i7:a (ja sen Xeon veljiä) kellottelin yli 4GHz:n niin Noctua ei meinannut saada niitä pysymään mitenkään alle 97C prime95 kuormalla. Ne oli oikeita lämpöpattereita
 
Zetteri sanoi:
EDIT: Nuo DDR4 muistihinnat tekevät SER-vehkeistä paljon houkuttelevammat. Sitten jos päästään takas sinne n.40€ 8GB hintoihin niin sitten asia on aivan toinen.
Napsauta laajentaaksesi...

Muistien hinnat oli itsellä kanssa aika pitkälti syynä miksi en kakkoskonetta alkanut päivittämään. Sitten kun emolevy sanoi sopimuksen irti X5460 kiven alta niin kävin hakemassa toisen, mutta ei suostunut toimimaan LGA771 kiven kanssa mitenkään loogisesti, niin päätin panostaa vasta 2400G settiin. Kalliiksi tuli vs SER, mutta eipähän tarvinnut kikkailla että sai koneen taas käyttöön.
 
The Stilt sanoi:
Kerrotko nyt jotain konkreettisia esimerkkejä (pl. täysin epärelevantti AoTS) ensin ohjelmista, jotka on nimenomaan optimoitu jollekkin tietylle mikroarkkitehtuurille?

Arkkitehtuuri joka vaatii koodin kirjoittamisen käsin suoriutuakseen kunnolla, ei ole hyvä / pitkäikäinen arkkitehtuuri. Tuo on täysin kohtuuton vaatimus.
Napsauta laajentaaksesi...

Miten se AoTS optimointi nyt yht äkkiää muuttuu epärelevantiksi? Ei sovi agendaasi? Kyllähän niitä tuli muitakin suorituskykyä parantavia pätsejä muihin ohjelmiin Ryzenin julkaisun jälkeen, jotkut jopa hyödytti myös Inteliä ei tosin niin paljoa. Eli kyllä sillä softaoptimoinnilla on merkitystä.

Mutta jos sinä väität että Intel ja AMD prosessorit ajaa samaa koodia täysin optimaalisesti tilanteessa kuin tilanteessa täysin samalla koodilla niin onhan se sitten meidän kaikkien uskottava sinun sanaasi ja joku AoTS optimointi on pakko olla jotain illuusiota.

hkultala sanoi:
Koodaan töikseni kääntäjän optimointeja joten väitän tietäväni koodin optimoinnista aika paljon.
Napsauta laajentaaksesi...

Eli sama kysymys: Prosessorikohtaisilla optimoinneilla ei ole merkitystä?

Se että nykyisin ei nysvätä juurikaan optimointeja johtuu ihan siitä että Intel puolella helpot tyhjät on jo vuosia sitten otettu pois ja vaikka tyhjää edelleen olisi, ei niiden pois nysväämisellä enää saavuteta paljoa. AMD:n puolella tilanne on eri,
vaikka molemmat on x86_64 prosessoreita, niin ei ne TOIMI identtisesti, eivätkä muutenkaan ole identtisiä.
 
JiiPee sanoi:
Miten se AoTS optimointi nyt yht äkkiää muuttuu epärelevantiksi? Ei sovi agendaasi? Kyllähän niitä tuli muitakin suorituskykyä parantavia pätsejä muihin ohjelmiin Ryzenin julkaisun jälkeen, jotkut jopa hyödytti myös Inteliä ei tosin niin paljoa. Eli kyllä sillä softaoptimoinnilla on merkitystä.
Napsauta laajentaaksesi...

Nopeutti se ryzen patchi myös inteliä hieman.
 
JiiPee sanoi:
Eli sama kysymys: Prosessorikohtaisilla optimoinneilla ei ole merkitystä?
Napsauta laajentaaksesi...

Ei, vaan niitä löytyy melko harvan softan lähdekoodista.

Prosessorikohtaiset optimoinnit on toteutettu kääntäjiin ja kääntäviin tulkattavien kielten virtuaalikoneisiin, ja sitten kun softa käännetään, kääntäjälle sanotaan mille arkkitehtuurille se optimoi, ja mitä käskykantalaajennuksia saa käyttää, tai kun virtuaalikone kääntää tulkattavaa kieltä natiivikoodiksi, se haistelee, millä prossulla sitä ajetaan, ja tekee sille optimoitua koodia käyttäen käskykantalaajennuksia, jotka siinä on tuettu.

Ja tämä keskustelu lähti niistä The Stiltin testaamista 29 softasta, joista suurimman osan The Stilt oli kääntänyt itse siten että niitä ei oltu käännetty mitkään intel-optiot päällä.

Ja sitten sinä aloit epäilemään että kuitenkin olivat "intel-optimoituja softia". Eivät olleet.


Joissain softissa, pääasiassa peleissä, toki on myös prosessorisoftaisia optimointeja ihan lähdekoodissa, mutta nämä on harvinaisia.

Ja The Stilt ei käsittääkseni ollut testannut AoTSää , mikään niistä 29 softasta ei ollut AoTS, joten sillä ei tämän kanssa ole mitään tekemistä.
 
JiiPee sanoi:
Miten se AoTS optimointi nyt yht äkkiää muuttuu epärelevantiksi? Ei sovi agendaasi?
Napsauta laajentaaksesi...

Optimointi ei ole epärelevantti, vaan tuo "peli" itsessään on täysi vitsi.

Mikä se agenda mahtaa olla?

Kun kerran tiedät tarkkaan miten suorituskykyerot johtuu Intelin suosimisesta, niin voisitko näyttää esimerkkiä tämän koodin optimoimisesta Ryzenille?
Tässä geneerisessä NBodyssa Ryzenin IPC on ~47% Skylaken ja uudempien Intelien vastaavasta.

Koodi: 
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include "timer.h"

#define CACHELINE 64 // size of cache line [bytes]
#define SOFTENING 1e-9f

typedef struct { float *x, *y, *z, *vx, *vy, *vz; } BodySystem;

void randomizeBodies(float *data, int n) {
  for (int i = 0; i < n; i++) {
    data[i] = 2.0f * (rand() / (float)RAND_MAX) - 1.0f;
  }
}


void bodyForce(BodySystem p, float dt, int n, int tileSize) {
  for (int tile = 0; tile < n; tile += tileSize) {
    int to = tile + tileSize;
    if (to > n) to = n;

    for (int i = 0; i < n; i++) {
      float Fx = 0.0f; float Fy = 0.0f; float Fz = 0.0f;

      #pragma vector aligned
      #pragma simd
      for (int j = tile; j < to; j++) {
        float dy = p.y[j] - p.y[i];
        float dz = p.z[j] - p.z[i];
        float dx = p.x[j] - p.x[i];
        float distSqr = dx*dx + dy*dy + dz*dz + SOFTENING;
        float invDist = 1.0f / sqrtf(distSqr);
        float invDist3 = invDist * invDist * invDist;

        Fx += dx * invDist3; Fy += dy * invDist3; Fz += dz * invDist3;     
      }
   
      p.vx[i] += dt*Fx; p.vy[i] += dt*Fy; p.vz[i] += dt*Fz;
    }
  }
}

int main(const int argc, const char** argv) {
 
  int nBodies = 30000;
  if (argc > 1) nBodies = atoi(argv[1]);

  int tileSize = 24400;
  if (tileSize > nBodies) tileSize = nBodies;

  const float dt = 0.01f; // time step
  const int nIters = 10;  // simulation iterations

  if ( tileSize % (CACHELINE/sizeof(float)) ) {
    printf("ERROR: blockSize not multiple of %d vector elements\n", CACHELINE/(int)sizeof(float));
    exit(1);
  }

  int bytes = 6*nBodies*sizeof(float);
  float *buf = (float*)_mm_malloc(bytes, CACHELINE);
  BodySystem p;
  p.x  = buf+0*nBodies; p.y  = buf+1*nBodies; p.z  = buf+2*nBodies;
  p.vx = buf+3*nBodies; p.vy = buf+4*nBodies; p.vz = buf+5*nBodies;

  randomizeBodies(buf, 6*nBodies); // Init pos / vel data

  double totalTime = 0.0;

  for (int iter = 1; iter <= nIters; iter++) {
    StartTimer();

    bodyForce(p, dt, nBodies, tileSize); // compute interbody forces

    for (int i = 0 ; i < nBodies; i++) { // integrate position
      p.x[i] += p.vx[i]*dt;
      p.y[i] += p.vy[i]*dt;
      p.z[i] += p.vz[i]*dt;
    }

    const double tElapsed = GetTimer() / 1000.0;
    if (iter > 1) { // First iter is warm up
      totalTime += tElapsed;
    }
  }
  double avgTime = totalTime / (double)(nIters-1);
  printf("\nBodies: %d", nBodies);
  printf("\nTotal time elapsed: %0.3f seconds", totalTime);
  printf("\nAverage time per iteration: %0.4f seconds", avgTime);
  printf("\nAverage %0.4f BIPS\n", 1e-9 * nBodies * nBodies / avgTime);

  _mm_free(buf);
}
 
hkultala sanoi:
Ja sitten sinä aloit epäilemään että kuitenkin olivat "intel-optimoituja softia". Eivät olleet.


Ja The Stilt ei käsittääkseni ollut testannut AoTSää , mikään niistä 290 softasta ei ollut AoTS, joten sillä ei tämän kanssa ole mitään tekemistä.
Napsauta laajentaaksesi...

En minä ole missään epäillyt että olisi intel-optimoinnit päällä käännetty ne softat, vaan olen koko ajan tarkoittanut sitä että Softan tekijät on menneet Intelin ehdoilla jo vuosia.
@jokumuu myös asiaan otti kantaa ja on hyvin linjassa siihen mitä kaveri on jutellut ja hän työkseen päivittäin koodaa. AMD:lle ei ole järkevää optimoida, kun ei rautaa ole juurikaan missään käytössä, mutta toki tilanne voi muuttua.
Virallinen: AMD vs Intel keskustelu- ja väittelyketju

AoTS on varsin oiva esimerkki juuri siitä että optimoinneilla on merkitystä. Minä sanoin että itse luotan cinebench lukuihin koska se näyttäisi olevan suhteellisen hyvin optimoitu molemmille, jonka sinä halusit ampua alas väittäen että ei ole hyvin optimoitu jolloin keskustelu ohjautui softaoptimointiin ja sen merkitykseen IPC:n.
 
JiiPee sanoi:
Minä sanoin että itse luotan cinebench lukuihin koska se näyttäisi olevan suhteellisen hyvin optimoitu molemmille, jonka sinä halusit ampua alas väittäen että ei ole hyvin optimoitu jolloin keskustelu ohjautui softaoptimointiin ja sen merkitykseen IPC:n.
Napsauta laajentaaksesi...

Cinebench on hyvä yleinen mittari suorituskyvylle, mutta melko koomista että väität sen olevan hyvin optimoitu molemmille kun kaikki Maxonin softat on nimenomaan käännetty Intelin kääntäjillä.
Ja voit olla varma että Intelin kääntäjät eivät sisällä mitään optimointeja nimenomaan AMD:lle.

Syy miksi Cinebench sopii hyvin AMD:lle on siinä että ohjelma käyttää maksimissaan SSE3 käskykantaa (R15).
Siinä vaiheessa kun Cinebench päivittyy tukemaan AVX/AVX2/AVX512/FMA käskyjä niin se voi yllättäen muuttua "huonosti AMD:lle optimoiduksi".

Lisäksi toki Intelin kääntäjä on keskimäärin nopein vaihtoehto, myös AMD:lle.
 
Onhan se päivän selvää että ohjelmaa voidaan hioa suoriutumaan paremmin arkkitehtuurin jos toisen kanssa. Minusta tuntuu että jopa Windowsin käskyttäjää voitaisiin hioa vielä paremmaksi, ellei jopa täysin erikseen uniikiksi AMD:tä kuin Inteliäkin varten, jos tämä on teknisesti mahdollista.

Veikkaan että AMD:n on jopa pitänyt harkita monia saman kaltaisuuksia Intelin kanssa arkkitehtuuria luodessaan, jotta nuo kääntäjät tekisivät myös heille mahdollisimman hyvää jälkeä. Peleissä nähdään sitten nämä räikeimmät esimerkit, millainen rooli optimoinnilla on, mutta saa nähdä auttaisiko Pinnacle Ridgen pienemmät välimuistien latenssit peleissä vai tuleeko eroa ollenkaan, että hyötyvätkö pelit tällaisesta parannuksesta automaattisesti vaiko eivät.

EDIT. Ja AotS on hyvä esimerkki tässä yhteydessä, ainoastaan sillä huomiolla, että näytönohjaimen ajurilla on oma roolinsa välissä. Kannattaa sekin muistaa että jotkin pelit performoivat huomattavasti paremmin kun paritetaan esimerkiksi Ryzen ja Vega verrattuna Ryzen ja Pascal.
 
Viimeksi muokattu:
The Stilt sanoi:
Optimointi ei ole epärelevantti, vaan tuo "peli" itsessään on täysi vitsi.
Napsauta laajentaaksesi...

Onko sillä väliä millainen se "peli" on jos voidaan osoittaa että patchin jälkeen suorituskykyä tuli rutkasti lisää?
Mistä se parannus sinun mielestäsi sitten tuohon kyseiseen "peliin" tuli jos ei optimoinnista?

The Stilt sanoi:
Kun kerran tiedät tarkkaan miten suorituskykyerot johtuu Intelin suosimisesta, niin voisitko näyttää esimerkkiä tämän koodin optimoimisesta Ryzenille?
Napsauta laajentaaksesi...

En minä ole koodaaja joten en todellakaan osaa sanoa että voisiko tuota koodia mitenkään optimoida Ryzenille. Mutta sen olen vuosien varrella oppinut että jokaiselle hevoselle kyllä löytyy kengittäjä. Eli vaikka itse luulee että on tehnyt ihan parhautta, niin joku muu saattaakin tehdä asian paremmin.
 
BOT sanoi:
EDIT. Ja AotS on hyvä esimerkki tässä yhteydessä, ainoastaan sillä huomiolla, että näytönohjaimen ajurilla on oma roolinsa välissä. Kannattaa sekin muistaa että jotkin pelit performoivat huomattavasti paremmin kun paritetaan esimerkiksi Ryzen ja Vega verrattuna Ryzen ja Pascal.
Napsauta laajentaaksesi...

Siinä AoTS testissä oli käytetty mittarina ainoastaan CPU painotettua testiä, eli näyttiksen ajureiden merkitys pitäisi olla lähes nolla.
 
Dudem sanoi:
Aiemmin kyselin mitä esim. Zetterin testikokoonpanot ottavat seinästä. Kaivelin sitten hieman esimerkkejä tuolta internetsin ihmeellisestä maailmasta. Ja kuinka vertailukelpoisia ovat, mutta on siinä ainakin jotain suuntaa antavaa näihin.

Xeon X5650 @ 4,37 GHz ja tehonkulutus oli 285 wattia. Linkki: Intel X5650 Overclocking – resulting a 4.37 GHz hexacore – tomrei.com
Ryzen 3 2200G @ vakio ja tehonkulutus 86 wattia. Linkki: Testissä AMD Ryzen 5 2400G & Ryzen 3 2200G (Raven Ridge) - io-tech.fi
Ryzen 5 2400G @ vakio ja tehonkulutus 100 wattia. Linkki: Testissä AMD Ryzen 5 2400G & Ryzen 3 2200G (Raven Ridge) - io-tech.fi
i7 860 @ vakio ja tehonkulutus 180 wattia. Linkki: The Intel Core i7 860 Review

Siinä saa SERriin laitella vähän järeämpää virtalähdettä jos lähtee kelloja hakemaan ja ei taideta ihan parin kympin coolereillakaan pärjätä noiden tehojen suhteen. Mutta jokainen joutuu itse päätöksensä tekemään, itse lähtisin mieluummin 2200G linjalle ja saa uuden alustan, takuunalaisen. Sekä saa niitä nykyajan ominaisuuksia (esim. M.2, USB3, Sata 3) ihan out of box. Vielä kun saisivat noita DDR4 hintoja alaspäin..
Napsauta laajentaaksesi...

Paljonkohan tämä imutteli sitten virtaa jos tuo linkkaamasi veti jo 285W edestä :think:

image_id_1796131.png


Totuus: 450W rutku poweri ja 780ti:sidea:
 
JiiPee sanoi:
En minä ole missään epäillyt että olisi intel-optimoinnit päällä käännetty ne softat, vaan olen koko ajan tarkoittanut sitä että Softan tekijät on menneet Intelin ehdoilla jo vuosia.
Napsauta laajentaaksesi...

ja tässä olet väärässä vähintään 90% tapauksista.

Suurinta osaa koodista mitä ihmisten koneilla pyörii ole optimoitu edes GENEERISESTI JÄRKEVÄSTI. Niissä olisi saatavissa suuria parannuksia helpolla samalla koodimuutoksella KAIKILLA ALUSTOILLA.

Korkealla tasolla Intelille ja AMDlle toimii aivan samat optimoinnit.

Molemmille toimii ihan samat muistiinsijoittelusäännöt.

Hyvin pitkälle "Intelin ehdoilla meneminen" tuottaa myös AMDlle optimaalisen koodin. Se tuottaa ehkä Itaniumille tai Cortex A-53lle epäoptimaalisen koodin.

Ja ylivoimaisesti suurinta osaa softia ei optimoida (lähdekoodissa) niin pitkälle että mitään eroa tulisi.


Selvä ero voisi sitten tulla esim. siinä, miten vektorikäskykantoja käytetään.

Tosin käytännössä tässäkin tilanne on tyypillisesti se, että melko harvoissa softissa on kuitenkaan mitään vektori-intrinsiccejä alettu kirjoittelemaan käsin. Suurimmassa osassa softia kääntäjä autovektoroi muutaman loopin, mutta paljon jää vektoroimatta, kun koodari ei ole edes vaivautunut kirjoittamaan looppia sillä tavalla, että autovektoroija saisi sen vektoroida. (tai koska koodin tyyliopas käskee kirjoittamaan koodin sellaisella tavalla, että autovektoroija ei siihen pure)

jokumuu myös asiaan otti kantaa ja on hyvin linjassa siihen mitä kaveri on jutellut ja hän työkseen päivittäin koodaa. AMD:lle ei ole järkevää optimoida, kun ei rautaa ole juurikaan missään käytössä, mutta toki tilanne voi muuttua.
Virallinen: AMD vs Intel keskustelu- ja väittelyketju
Napsauta laajentaaksesi...

Heillä koodataan ilmeisesti jotain suorituskykykriittistä palvelinkoodia.

Ja hänen mainitsemansa TSX ei toimi myöskään Intelin i5-prosessoreilla, ja AMDn vastine TSX:lle, ASF, ei ole tuettu yhdessäkään prosessorissa.

TSXn tukeminen ei kuitenkaan millään tavalla ole AMDltä pois.

Ja mikään the Stiltin käyttämistä 29 softasta ei ollut jokumuun firman koodaama.

AoTS on varsin oiva esimerkki juuri siitä että optimoinneilla on merkitystä. Minä sanoin että itse luotan cinebench lukuihin koska se näyttäisi olevan suhteellisen hyvin optimoitu molemmille, jonka sinä halusit ampua alas väittäen että ei ole hyvin optimoitu jolloin keskustelu ohjautui softaoptimointiin ja sen merkitykseen IPC:n.
Napsauta laajentaaksesi...

AoTS on täysin erilainen tilanne kuin se, että geneerisesti optimoitua koodia käännetään geneerisillä kääntäjäoptioilla. Mistä tämä keskustelu lähti.

AoTS:ssä oli yritetty alkaa optimoimaan matalalla tasolla ja tehtykin pessimointeja ja mokattu homma sillä . Ylivoimaisesti suurinta osaa softista ei edes yritetä optimoida tällä tasolla.



Että nyt kaivat nuo The Stiltin koodit käyttämien softien lähdekoodit esille ja näytät sieltä ne Intel-spesifiset optimoinnit tai lopetat tuon höpöttämisen siitä kuinka ne muka on "intelille optimoituja".


ps. Softien listalta löytyy esim. C-ray joka on aivan järkyttävän kamalan huonosti kirjoitettua koodia jonka kamaluudesta kärsii intel vielä paljon enemmän kuin AMD, silmäilin joskus tuon lähdekoodin läpi.

Imgur
 
Viimeksi muokattu:
JiiPee sanoi:
Mistä se parannus sinun mielestäsi sitten tuohon kyseiseen "peliin" tuli jos ei optimoinnista?
Napsauta laajentaaksesi...

Todennäköisesti enemmän tuossa on korjattu joku ongelma, kuin varsinaisesti optimoitu.
Veikkaisin että ovat pakottaneet tietyt tehtävät kiinteästi tietyille ytimille saman CCX:n sisällä (~25ns), jolloin vältytään CCX2CCX (120-160ns) penaltilta.
 
hkultala sanoi:
Että nyt kaivat nuo The Stiltin koodit käyttämien softien lähdekoodit esille ja näytät sieltä ne Intel-spesifiset optimoinnit tai lopetat tuon höpöttämisen siitä kuinka ne muka on "intelille optimoituja".
Napsauta laajentaaksesi...

Okei. Koska sinä käsket minun lopettaa ja sinä yhdessä stiltin kanssa olette todennäköisesti planeetan ellei jopa koko universumin parhaita koodaaji joilla on aikaa räksyttää eri forumeilla kuinka hommat tulisi tehdä, niin onhan se uskottava!

Uskottava on myös se fakta että Intelin ja AMD:n prosessorit on täysin samanlaisia ja ihan sama miten niille koodia kirjoittaa niin ne toimii täysin opti maalisesti kunhan koodi on mennyt kääntäjästä läpi.

Ihan turha oli varmaan myös se AMD:n julkaisema KPTI pätsi linux kerneliin tuossa taannoin.

Eli lopulta pitää myös tunnustaa se fakta että Intel on vain yksinkertaisesti paljon parempi prosessori koska sillä kaikki pyörii niin paljon paremmin. Eiköhän tuo IPC ero ens kuussa ole jo 50% luokkaa Intelin hyväksi.

Jatkakaa.
 
hkultala sanoi:
Heillä koodataan ilmeisesti jotain suorituskykykriittistä palvelinkoodia.
Napsauta laajentaaksesi...
Kyllä. Mm. mainitsemani cache coherency liittyy moniprosessorijärjestelmiin ja fence-käskyjen käyttöön, joissa AMD ei kyllä tuo itsestään parhaimpia puolia esiin. Fencet on AMD:llä monessa paikassa korvattu ihan vain syncillä, kun suorituskykyetu on ollut negatiivinen tai sitä ei ole ollut.

Cache coherency protocol liittyy ccNUMA arkkitehtuuriin ja niiden välisten cachejen synkronointiin. Protokolla pitää huolen, että CPU-cachet ovat synkassa, mutta se ei pidä huolta, että sisältö on järjestyksessä. Kun tehdään context switchejä, on mahdollista, että mennään datassa sekaisin, kun oletetussa positiossa olevat tavarat eivät olekaan siellä.

En valitsisi AMD:n prosessoria mihinkään tarkoitukseen, jossa suorituskykykriittisen prosessin säikeet jaetaan kahdelle eri CPU:lle. Riski huonoon suorituskykyyn - tai vakausongelmiin - on liian iso. En tosin ole testannut EPYCillä, mutta riskit on olemassa, etenkin kun arkkitehtuuri on vähän liimatun oloinen.

Ja hänen mainitsemansa TSX ei toimi myöskään Intelin i5-prosessoreilla, ja AMDn vastine TSX:lle, ASF, ei ole tuettu yhdessäkään prosessorissa.

TSXn tukeminen ei kuitenkaan millään tavalla ole AMDltä pois.
Napsauta laajentaaksesi...

Kummatkin, sekä Intel i5-tuen puute, sekä AMD:n täysi välinpitämättömyys ovat todella outoja päätöksiä. TSX on yksi merkittävimmistä kehityksistä transaktiohallinnassa pitkään aikaan. TSX:stä hyötyy massiivisesti oikeastaan mikä tahansa useampaan säikeeseen skaalautuva sovellus, jonka pitää ottaa lukkoja.
Näkisin, että esim. monet pelit varmasti hyötyisivät tästä merkittävästi, mutta kun alustatuki on vajavainen, niin eipä sitä kannata tehdä, työmäärä kun käytännössä tuplaantuu (uusi ja vanha erikseen).
 
JiiPee sanoi:
Okei. Koska sinä käsket minun lopettaa ja sinä yhdessä stiltin kanssa olette todennäköisesti planeetan ellei jopa koko universumin parhaita koodaaji joilla on aikaa räksyttää eri forumeilla kuinka hommat tulisi tehdä, niin onhan se uskottava!

Uskottava on myös se fakta että Intelin ja AMD:n prosessorit on täysin samanlaisia ja ihan sama miten niille koodia kirjoittaa niin ne toimii täysin opti maalisesti kunhan koodi on mennyt kääntäjästä läpi.
Napsauta laajentaaksesi...
Valitettavasti se, että hkultala ja the stilt näyttäisivät tietävän asiat paljon paremmin kuin moni muu tällä foorumilla ja vielä perustellusti, ei tee heistä räksyttäjiä. Jos sitä räksyttäjää pitää etsiä, niin kannattaisikohan ehkä katsoa peiliin, varsinkin kun argumenttien loppuessa mentiin henkilökohtaisuuksiin. The Stilt esitti testituloksia, joita sinä rupesit kyseenalaistamaan vaikka minkälaisilla mutuiluilla.
 
JiiPee sanoi:
Okei. Koska sinä käsket minun lopettaa ja sinä yhdessä stiltin kanssa olette todennäköisesti planeetan ellei jopa koko universumin parhaita koodaaji joilla on aikaa räksyttää eri forumeilla kuinka hommat tulisi tehdä, niin onhan se uskottava!

Uskottava on myös se fakta että Intelin ja AMD:n prosessorit on täysin samanlaisia ja ihan sama miten niille koodia kirjoittaa niin ne toimii täysin opti maalisesti kunhan koodi on mennyt kääntäjästä läpi.

Ihan turha oli varmaan myös se AMD:n julkaisema KPTI pätsi linux kerneliin tuossa taannoin.

Eli lopulta pitää myös tunnustaa se fakta että Intel on vain yksinkertaisesti paljon parempi prosessori koska sillä kaikki pyörii niin paljon paremmin. Eiköhän tuo IPC ero ens kuussa ole jo 50% luokkaa Intelin hyväksi.

Jatkakaa.
Napsauta laajentaaksesi...

Noniin, sen sijaan, että olisit kaivanut ne mainittujen softien lähdekoodit esille ja alkanut näyttää niistä niitä intel-optimoituja paikkoja esille, aloit uhriutua ja vetää aivan naurettavia olkiukkoja esille.
 
TeroP sanoi:
The Stilt esitti testituloksia, joita sinä rupesit kyseenalaistamaan vaikka minkälaisilla mutuiluilla.
Napsauta laajentaaksesi...

Mikä on mutuilua? Onko se todellakin niin vaikeaa ymmärtää että optimoinneilla on väliä? Se että Intel on hallinnut viimeiset lähes 10v cpu markkinoita on opettanut lähes KAIKKI (Varsinkin nuoremmat, ne jotka imi vielä tissiä silloin kun AMD:n ja Intelin välinen sota oli kuumimmillaan) jo koulusta lähtien koodaamaan täysin Intelin ehdoilla. Tää tuntuu olevan hyvin vaikeaa ymmärtää monelle.
Edelleen, tässä ei sinäänsä ole mitään väärää. Tottakai kannattaa tehdä asiat niin mille on kysyntää.

TeroP sanoi:
Jos sitä räksyttäjää pitää etsiä, niin kannattaisikohan ehkä katsoa peiliin, varsinkin kun argumenttien loppuessa mentiin henkilökohtaisuuksiin.
Napsauta laajentaaksesi...

Argumentit ei lopu, en vaan yksinkertaisesti JAKSA vängätä asiasta kun se on ihan sama vaikka menisi tuonne ulos puupölkyille juttelemaan. En yksinkertaisesti osaa ilmaista asioita niin että näille neropateille se menisi jakeluun.
Ilmeisesti herroilla on vain liikaa vielä tuota nuoruuden intoa ja kun ovat mielestään niin hyvin perillä kaikesta niin on käynyt samalla vähän sellainen efekti että kusi noussu päähän ja ollaan hyvin herkästi heti kyykyttämässä niitä jotka eivät asioita niin tarkkaan tiedä.
 
hkultala sanoi:
Noniin, sen sijaan, että olisit kaivanut ne mainittujen softien lähdekoodit esille ja alkanut näyttää niistä niitä intel-optimoituja paikkoja esille, aloit uhriutua ja vetää aivan naurettavia olkiukkoja esille.
Napsauta laajentaaksesi...

Kirjoitinko epäselvästi? En ole koodaaja. Ihan harrastepohjalta on hiukan tullut tcl ja php:tä joskus "koodattua", perl jonkin verran osaan tulkita mutten ole koskaan sillä mitään "koodannut". Joku C on hyvin pitkälti hepreaa.
Eihän siellä tartte olla mitään ns. "Intel optimoituja paikkoja" kun kokoa alalla on menty 10v Intelin ehdoilla.

Stilt toi esiin tuossa AoTS:ssä esiin tuon CCX <-> CCX asian joka on yksi esimerkki siitä että se "geneerinen" koodi ei välttämättä ole Ryzenille optimaalista. Jos kyse tuossa tapauksessa oli tuosta CCX <-> CCX kommunikoinnista.
Joko kääntäjät esim. osaa tuon CCX:n ottaa huomioon?

Ja mitä täältä on aiemmin tullut lueskeltua niin tuntuisi silläkin olevan merkitystä kuinka cacheja käytetään. Se mikä sattuu yhdelle, ei välttämättä olekkaan optimaalinen toiselle. Tätähän on nähty ihan Intelin sisälläkin.
 
hkultala sanoi:
Noniin, sen sijaan, että olisit kaivanut ne mainittujen softien lähdekoodit esille ja alkanut näyttää niistä niitä intel-optimoituja paikkoja esille, aloit uhriutua ja vetää aivan naurettavia olkiukkoja esille.
Napsauta laajentaaksesi...
JiiPee sanoi:
Okei. Koska sinä käsket minun lopettaa ja sinä yhdessä stiltin kanssa olette todennäköisesti planeetan ellei jopa koko universumin parhaita koodaaji joilla on aikaa räksyttää eri forumeilla kuinka hommat tulisi tehdä, niin onhan se uskottava!

Uskottava on myös se fakta että Intelin ja AMD:n prosessorit on täysin samanlaisia ja ihan sama miten niille koodia kirjoittaa niin ne toimii täysin opti maalisesti kunhan koodi on mennyt kääntäjästä läpi.

Ihan turha oli varmaan myös se AMD:n julkaisema KPTI pätsi linux kerneliin tuossa taannoin.

Eli lopulta pitää myös tunnustaa se fakta että Intel on vain yksinkertaisesti paljon parempi prosessori koska sillä kaikki pyörii niin paljon paremmin. Eiköhän tuo IPC ero ens kuussa ole jo 50% luokkaa Intelin hyväksi.

Jatkakaa.
Napsauta laajentaaksesi...
Hauskahan näitä oli lukea. Pidetään vauhti päällä niin saadaan pian sadan sivun raja rikki! :)

Optimointi on käsitteenä niin laaja että helposti puhutaan periaatteesta samoista asioista mutta eri tasoilla. Järkevintä optimointia lienee juuri @hkultala mainitsema maalaisjärkioptimointi koodia kirjoitettaessa eli rikotaan looppeja tilakoneiksi, käytetään staattisia ja tarpeisiin riittäviä muuttujia jos mahdollista, vältetään turhia metodikutsuja, vältetään muistin roskaamista vaikka onkin roskienkerääjiä jne. Nykyään kielet kuitenkin alkavat enemmän ja enemmän olla valmiita paketteja, joissa vain poimitaan funktioita ja yhdistellään niistä kaikkea kivaa. Usein ne ovat tarkoitukseensa hyvin optimoituja vaikka joku Javan linkkilista, mutta kun kutsut alkavat olla piste.piste....pistejotain, niin aika metsään voi koneen resurssien näkökulmasta mennä. Toki näin sen kuuluukin olla; ei kenellään ole aikaa alkaa hinkkaa jollain prosessorien välimuistitasolla minne mikin alkio milloinkin halutaan laittaa, vaan isoja juttuja pitää saada aikaiseksi nopeasti. Toki kuten @jokumuu sanoi, niin eri asia on spesifit käyttökohteet, jossa pieni osa koodista kuluttaa merkittävän osan resursseista. Tällöin nysväämiselle voi löytyä perusteita. Peleissä näitä varmaan myös löytynee, mutta tällöinkin se normitilanne on antaa pelimoottorin hoitaa se, joka taas on käännetty jollain kääntäjällä, joka kuitenkin lähes kaikissa tapauksissa nykypäivän sovelluskehityksessä on se joka rautatason optimoinnin tekee sitten miten tekee. @hkultala ja @The Stilt tietänevät tästä jonkun verran ja uskon kyllä mitä sanovat, että tilanne nykypäivän x86/x64-arkkitehtuurissa on punaisen ja sinisen leirissä aika lähellä toisiaan ja mitään merkittäviä eroja ei näillä optimoinneilla saada. Intelillä nyt lähinnä AVX512 selkeä etu.

Kuitenkin itse näen että Intel-optimonteja on tämä maailma täynnä. Kääntäjissä ei tarvitse olla mitään erillistä Intel-flagia vaan se nyt vain on niin että Intel ohjaa x86-puolta ja se mitä he tuovat markkinoille, on softakehittäjien pyrittävä ottamaan siitä kaikki irti. AMD:lla ei ole varaa lähteä sooloilemaan paljoa tämän ulkopuolelle. Tässä mielessä @JiiPee on mielestäni ihan oikeassa: eroja voisi olla enemmänkin ja paljon järkevämpiäkin ratkaisuja kuin ne joita olemme nyt vain tottuneet käyttämään kun Intel ne on meille syöttänyt. Esimerkiksi AMD:n nykyinen CCX-rakenne on mielestäni oikea ja järkevä suunta, sillä tulevaisuus on hajautetun laskennan niin fysiikan lakien kuin valmistuskustannusten valossa ja tähän joutuu Intelkin taipumaan ennemmin tai myöhemmin. Tämä vaatii kuitenkin optimointeja/älyä myös korkeammalla (os/hypervisori/skeduleri) tasolla kuin kääntäjäpuolella, koska siellä on parempi tietämys koneen kokonaiskuorman profiilista. Ei helppoa mutta kun on pakko.

Toki optimointeja tehdään toiseenkin suuntaan esim. videoalgoritmien kiihdytykset ja Javan virtuaalikoneen toimintaa nopeuttavat ratkaisut vaikka joissain IBM:n prossuissa. Ymmärrettävästi suunta useimmiten toisin päin, koska maailma muuttuu ja raudan tukemat tekniikat voivat lakata olemasta käytössä plus piipalan rajoitettu tila, kehityskulut jadajada.

Intelin valtakausi on kyllä aikaansaanut sen, että monisäikeistyksen optimointiin on tarvinnut kiinnittää turhan vähän huomiota. 4c/8t on ollut kuluttajapuolen maksimi sen pian kymmenen vuotta ennen Ryzenin tuloa markkinoille. Toki pelit voisivat käyttää enemmänkin, mutta mitä järkeä laittaa paukkuja kehitykseen kun käytännössä 99% markkinoista ei olisi yli kahdeksaa säiettä pystynyt käyttämään, hyvä kun edes neljää. Sen takia uusien Rysien tehosta jää nykyään pelikäytössä harmittavan iso osa käyttämättä. Varmasti suuri yhden säikeen IPC on aina kova juttu, mutta se ero AMD vs. Intel kapenee koko ajan ja lisävauhti on pakko hakea rinnakaistamalla vaikka sitten päällä seisomalla. Vulkan ainakin omalla Doom/Wolfenstein/R1700-kokemuksella osasi jo vallan mainiosti pompotella kaikkia ytimiä suhteellisen tasaisesti verrattuna muihin peleihin eli ei sekään pitkän juoksun takana ole.
 
Viimeksi muokattu:
JiiPee sanoi:
Niin oli 29 ja voi hyvinkin olla että kaikki 29 on pelkästään intelille optimoituja. En ymmärrä miksi tämä on niin vaikeaa monen hyväksyä taikka käsittää että optimoinneilla on väliä eikä se ole mitään takertumista johonkin.
Enkä kritisoi sitä etteikö kaveri osaisi, kritisoin sitä että jätetään oleellisia asioita mainitsematta.
Napsauta laajentaaksesi...
:tdown::rolleyes: Itsekään en koodaa. Mutta hyvin lähellä nuo arkkitehtuurit ovat toisiaan säikeen suorituksen kannalta katsottuna, eikä AMD saa mistään mitään mystistä boostia.
 
Viimeksi muokattu:
Onhan toi SERrin virrankulutus aivan absurdi, jos vertaa nykypäivän laitteisiin. Oma prossun keskikulutus on päivän aikana siinä 60W ja 80W paikkeilla, käyntilämpöjen liikkuessa 40 ja 60 välillä.
 
MrFoxZet sanoi:
Onhan toi SERrin virrankulutus aivan absurdi, jos vertaa nykypäivän laitteisiin. Oma prossun keskikulutus on päivän aikana siinä 60W ja 80W paikkeilla, käyntilämpöjen liikkuessa 40 ja 60 välillä.
Napsauta laajentaaksesi...

Niin no tuossa katselin io-techin i7-8700K testejä ja siitähän löyty tuo mielenkiintoinen taulukko:

cfl-bench-teho2.png



Niin tämä 4.5GHz kellotettu 6C/12T Xeon X5650 nuo luvut ovat Prime95:lla 140W.
IDLE:ssä 15W.

EDIT: Niin ja IDLE lämmöt 30-36C riippuen ytimestä
 
Zetteri sanoi:
Niin no tuossa katselin io-techin i7-8700K testejä ja siitähän löyty tuo mielenkiintoinen taulukko:

cfl-bench-teho2.png



Niin tämä 4.5GHz kellotettu 6C/12T Xeon X5650 nuo luvut ovat Prime95:lla 140W.
IDLE:ssä 15W.

EDIT: Niin ja IDLE lämmöt 30-36C riippuen ytimestä
Napsauta laajentaaksesi...
Onko tuo se Eng sample vai lopullinen versio?
Ja mikä on noiden prossujen prime suorituskyky? Periaatteessahan joku prossu voisi viedä esim 5 kertaa enemmän tehoa, kun jotain tapahtuu, mutta jos asia tuleekin tehtyä 10x nopeammin, niin se on silti puolet parempi. (Energiaa kuluu vain puolet).
Mitä käskykantoja tuo prime muuten käyttikään?
 
Griffin sanoi:
Onko tuo se Eng sample vai lopullinen versio?
Ja mikä on noiden prossujen prime suorituskyky? Periaatteessahan joku prossu voisi viedä esim 5 kertaa enemmän tehoa, kun jotain tapahtuu, mutta jos asia tuleekin tehtyä 10x nopeammin, niin se on silti puolet parempi. (Energiaa kuluu vain puolet).
Mitä käskykantoja tuo prime muuten käyttikään?
Napsauta laajentaaksesi...
Prime käyttää kaikkia mitä haluat sen käyttävän. Säätökysymys.
 
Griffin sanoi:
Onko tuo se Eng sample vai lopullinen versio?
Ja mikä on noiden prossujen prime suorituskyky? Periaatteessahan joku prossu voisi viedä esim 5 kertaa enemmän tehoa, kun jotain tapahtuu, mutta jos asia tuleekin tehtyä 10x nopeammin, niin se on silti puolet parempi. (Energiaa kuluu vain puolet).
Mitä käskykantoja tuo prime muuten käyttikään?
Napsauta laajentaaksesi...

Tässä prime95 benchmark tulokset. Onko noi sitten huonot vai hyvät niin ei hajuakaan. Ja tää on ainakin ihan loppullinen tuotanto versio vai mitä prossua sillä tarkoitit edes ?

Ai niin Prime95 näyttää kellot väärin kuten moni muukin ongelma. Ne eivät tajua että käytetään turbon kertoimia. Eli oikeasti tuo pörrää sillä 4.5Ghz:llä.

[Tue Mar 20 09:20:28 2018]
Compare your results to other computers at http://www.mersenne.org/report_benchmarks
Intel(R) Xeon(R) CPU X5650 @ 2.67GHz
CPU speed: 4095.01 MHz, 6 hyperthreaded cores
CPU features: Prefetch, SSE, SSE2, SSE4
L1 cache size: 32 KB
L2 cache size: 256 KB, L3 cache size: 12 MB
L1 cache line size: 64 bytes
L2 cache line size: 64 bytes
TLBS: 64
Prime95 64-bit version 27.9, RdtscTiming=1
Best time for 768K FFT length: 7.578 ms., avg: 8.017 ms.
Best time for 896K FFT length: 8.534 ms., avg: 8.776 ms.
Best time for 1024K FFT length: 9.400 ms., avg: 9.684 ms.
Best time for 1280K FFT length: 12.032 ms., avg: 12.229 ms.
Best time for 1536K FFT length: 14.992 ms., avg: 15.371 ms.
Best time for 1792K FFT length: 18.360 ms., avg: 18.540 ms.
Best time for 2048K FFT length: 20.879 ms., avg: 21.484 ms.
Best time for 2560K FFT length: 26.104 ms., avg: 26.305 ms.
Best time for 3072K FFT length: 32.752 ms., avg: 33.127 ms.
Best time for 3584K FFT length: 38.627 ms., avg: 38.884 ms.
Best time for 4096K FFT length: 43.799 ms., avg: 44.044 ms.
Best time for 5120K FFT length: 56.266 ms., avg: 57.498 ms.
Best time for 6144K FFT length: 72.557 ms., avg: 73.227 ms.
Best time for 7168K FFT length: 88.274 ms., avg: 88.454 ms.
Best time for 8192K FFT length: 99.832 ms., avg: 100.553 ms.
Timing FFTs using 2 threads on 1 physical CPUs.
Best time for 768K FFT length: 8.174 ms., avg: 8.214 ms.
Best time for 896K FFT length: 8.829 ms., avg: 8.999 ms.
Best time for 1024K FFT length: 11.295 ms., avg: 11.366 ms.
Best time for 1280K FFT length: 14.165 ms., avg: 14.257 ms.
Best time for 1536K FFT length: 17.894 ms., avg: 18.037 ms.
Best time for 1792K FFT length: 20.116 ms., avg: 20.360 ms.
Best time for 2048K FFT length: 23.771 ms., avg: 24.029 ms.
Best time for 2560K FFT length: 31.103 ms., avg: 31.253 ms.
Best time for 3072K FFT length: 37.621 ms., avg: 37.755 ms.
Best time for 3584K FFT length: 44.273 ms., avg: 44.457 ms.
Best time for 4096K FFT length: 51.637 ms., avg: 51.862 ms.
Best time for 5120K FFT length: 66.388 ms., avg: 66.619 ms.
Best time for 6144K FFT length: 79.172 ms., avg: 79.610 ms.
Best time for 7168K FFT length: 90.921 ms., avg: 91.217 ms.
Best time for 8192K FFT length: 106.235 ms., avg: 106.718 ms.
Timing FFTs using 4 threads on 2 physical CPUs.
Best time for 768K FFT length: 4.177 ms., avg: 4.213 ms.
Best time for 896K FFT length: 4.771 ms., avg: 4.900 ms.
Best time for 1024K FFT length: 5.822 ms., avg: 5.931 ms.
Best time for 1280K FFT length: 7.223 ms., avg: 7.261 ms.
Best time for 1536K FFT length: 9.234 ms., avg: 9.461 ms.
Best time for 1792K FFT length: 10.722 ms., avg: 10.850 ms.
Best time for 2048K FFT length: 13.167 ms., avg: 13.438 ms.
Best time for 2560K FFT length: 16.503 ms., avg: 16.649 ms.
Best time for 3072K FFT length: 20.739 ms., avg: 20.843 ms.
Best time for 3584K FFT length: 23.680 ms., avg: 23.898 ms.
Best time for 4096K FFT length: 28.567 ms., avg: 28.704 ms.
Best time for 5120K FFT length: 37.101 ms., avg: 37.288 ms.
Best time for 6144K FFT length: 45.894 ms., avg: 46.193 ms.
Best time for 7168K FFT length: 52.858 ms., avg: 53.398 ms.
Best time for 8192K FFT length: 60.918 ms., avg: 61.270 ms.
Timing FFTs using 6 threads on 3 physical CPUs.
Best time for 768K FFT length: 2.865 ms., avg: 3.019 ms.
Best time for 896K FFT length: 3.532 ms., avg: 3.597 ms.
Best time for 1024K FFT length: 4.158 ms., avg: 4.254 ms.
Best time for 1280K FFT length: 4.963 ms., avg: 5.043 ms.
Best time for 1536K FFT length: 6.624 ms., avg: 6.957 ms.
Best time for 1792K FFT length: 8.102 ms., avg: 8.249 ms.
Best time for 2048K FFT length: 10.205 ms., avg: 10.566 ms.
Best time for 2560K FFT length: 12.552 ms., avg: 12.726 ms.
Best time for 3072K FFT length: 16.147 ms., avg: 16.328 ms.
Best time for 3584K FFT length: 18.509 ms., avg: 18.629 ms.
Best time for 4096K FFT length: 22.918 ms., avg: 23.088 ms.
Best time for 5120K FFT length: 30.268 ms., avg: 30.573 ms.
Best time for 6144K FFT length: 37.382 ms., avg: 37.656 ms.
Best time for 7168K FFT length: 42.687 ms., avg: 42.835 ms.
Best time for 8192K FFT length: 50.303 ms., avg: 50.603 ms.
Timing FFTs using 8 threads on 4 physical CPUs.
Best time for 768K FFT length: 2.260 ms., avg: 2.283 ms.
Best time for 896K FFT length: 2.944 ms., avg: 2.994 ms.
Best time for 1024K FFT length: 3.413 ms., avg: 3.454 ms.
Best time for 1280K FFT length: 3.894 ms., avg: 3.987 ms.
Best time for 1536K FFT length: 5.502 ms., avg: 5.652 ms.
Best time for 1792K FFT length: 7.068 ms., avg: 7.133 ms.
Best time for 2048K FFT length: 9.158 ms., avg: 9.568 ms.
Best time for 2560K FFT length: 11.105 ms., avg: 11.258 ms.
Best time for 3072K FFT length: 14.557 ms., avg: 14.724 ms.
Best time for 3584K FFT length: 16.883 ms., avg: 17.114 ms.
Best time for 4096K FFT length: 21.206 ms., avg: 21.407 ms.
Best time for 5120K FFT length: 28.313 ms., avg: 28.649 ms.
Best time for 6144K FFT length: 35.148 ms., avg: 35.416 ms.
Best time for 7168K FFT length: 39.819 ms., avg: 39.994 ms.
Best time for 8192K FFT length: 47.313 ms., avg: 47.663 ms.
Timing FFTs using 10 threads on 5 physical CPUs.
Best time for 768K FFT length: 1.960 ms., avg: 2.108 ms.
Best time for 896K FFT length: 2.787 ms., avg: 2.945 ms.
Best time for 1024K FFT length: 3.156 ms., avg: 3.261 ms.
Best time for 1280K FFT length: 3.338 ms., avg: 4.313 ms.
Best time for 1536K FFT length: 5.021 ms., avg: 5.115 ms.
Best time for 1792K FFT length: 6.535 ms., avg: 6.631 ms.
Best time for 2048K FFT length: 8.505 ms., avg: 8.887 ms.
Best time for 2560K FFT length: 10.644 ms., avg: 11.053 ms.
Best time for 3072K FFT length: 13.914 ms., avg: 14.018 ms.
Best time for 3584K FFT length: 16.389 ms., avg: 17.098 ms.
Best time for 4096K FFT length: 20.767 ms., avg: 20.906 ms.
Best time for 5120K FFT length: 28.196 ms., avg: 29.152 ms.
Best time for 6144K FFT length: 34.914 ms., avg: 35.481 ms.
Best time for 7168K FFT length: 39.407 ms., avg: 40.291 ms.
Best time for 8192K FFT length: 47.150 ms., avg: 48.086 ms.
Timing FFTs using 12 threads on 6 physical CPUs.
Best time for 768K FFT length: 1.789 ms., avg: 1.873 ms.
Best time for 896K FFT length: 2.766 ms., avg: 2.801 ms.
Best time for 1024K FFT length: 3.130 ms., avg: 3.694 ms.
Best time for 1280K FFT length: 3.162 ms., avg: 3.522 ms.
Best time for 1536K FFT length: 4.930 ms., avg: 4.985 ms.
Best time for 1792K FFT length: 6.351 ms., avg: 6.780 ms.
Best time for 2048K FFT length: 8.535 ms., avg: 9.692 ms.
Best time for 2560K FFT length: 10.732 ms., avg: 10.817 ms.
Best time for 3072K FFT length: 13.646 ms., avg: 14.113 ms.
Best time for 3584K FFT length: 16.956 ms., avg: 19.333 ms.
Best time for 4096K FFT length: 23.367 ms., avg: 35.040 ms.
Best time for 5120K FFT length: 29.565 ms., avg: 39.420 ms.
Best time for 6144K FFT length: 39.100 ms., avg: 48.353 ms.
Best time for 7168K FFT length: 42.427 ms., avg: 119.423 ms.
Best time for 8192K FFT length: 48.812 ms., avg: 49.403 ms.
Best time for 61 bit trial factors: 1.972 ms.
Best time for 62 bit trial factors: 2.071 ms.
Best time for 63 bit trial factors: 2.422 ms.
Best time for 64 bit trial factors: 2.991 ms.
Best time for 65 bit trial factors: 3.367 ms.
Best time for 66 bit trial factors: 3.734 ms.
Best time for 67 bit trial factors: 3.548 ms.
Best time for 75 bit trial factors: 3.399 ms.
Best time for 76 bit trial factors: 3.349 ms.
Best time for 77 bit trial factors: 3.260 ms.
 
Muistelen, jotta IO-techillä olisi ollut jokun eng sample versio prossusta ensin testissä.?
--------------------------------------
Tukeeko Prime 95 siis mitä kaikkia käskylaajennuksia?
 
JiiPee sanoi:
Kirjoitinko epäselvästi? En ole koodaaja. Ihan harrastepohjalta on hiukan tullut tcl ja php:tä joskus "koodattua", perl jonkin verran osaan tulkita mutten ole koskaan sillä mitään "koodannut". Joku C on hyvin pitkälti hepreaa.
Eihän siellä tartte olla mitään ns. "Intel optimoituja paikkoja" kun kokoa alalla on menty 10v Intelin ehdoilla.
Napsauta laajentaaksesi...

Ne "intelin ehdot" on >90%sti ihan yhtä lailla "AMDn ehdot". Olen tätä jo moneen kertaan yrittänyt selittää.

Stilt toi esiin tuossa AoTS:ssä esiin tuon CCX <-> CCX asian joka on yksi esimerkki siitä että se "geneerinen" koodi ei välttämättä ole Ryzenille optimaalista. Jos kyse tuossa tapauksessa oli tuosta CCX <-> CCX kommunikoinnista.
Joko kääntäjät esim. osaa tuon CCX:n ottaa huomioon?
Napsauta laajentaaksesi...

Koko ajan siirtelet maalitolppaasi siinä, onko tuo "ongelma" mielestäsi alunperin softan lähdekoodissa vai kääntäjässä.


Miten kääntäjä VOISI ottaa CCXn jotenkin huomioon?

Ei ole kääntäjän tehtävä jakaa softaa säiikeisiin (paitsi jos käytetty OpenMPtä) eikä skeduloida niitä ytimille.
Ja silloin kun sitä OpenMPtä käytetään, koodi on sellaista että se rinnakkaistuu käytännössä mille määrälle ytimiä tahansa ja MOLEMPIEN VALMISTAJIEN CPUilla kannattaa laukoa niin monta säiettä kun (virtuaali)ytimiä on ja tällöin CCX-rakenteella ei taas ole mitään merkitystä sen koodin optimoinnille.

CCXllä on väliä koodin optimoinnille silloin kun meillä on pieni määrä rinnakkaisia taskeja jotka säikeistetään taskitason rinnakkaisuutena.
Tässä tilanteessa rinnakkaistus ei vaan koskaan ole millään tavalla kääntäjän vastuulla.

Se on softan koodaajan(säikeiden luonti) ja käyttiksen(säikeiden skedulointi) vastuulla.


Ja olen melko varma, että MIKÄÄN noista the stiltin 29 softasta ei sisällä "muutaman" säikeen verran taskitason rinnakkaisuutta(kuten monet pelit). Nuo softat joko rinnakkaistuu kunnolla vaikka kuinka monelle säikeelle tai ei ollenkaan.

Ja mitä täältä on aiemmin tullut lueskeltua niin tuntuisi silläkin olevan merkitystä kuinka cacheja käytetään. Se mikä sattuu yhdelle, ei välttämättä olekaan optimaalinen toiselle. Tätähän on nähty ihan Intelin sisälläkin.
Napsauta laajentaaksesi...

Välimuistilinjan koko on sama (64 tavua) kaikilla Intelin ja AMDn nykyprossuilla. Tämä on se oleellisin asia sillle välimuistille optimoinnissa. Molemmissa on myös todella kehittyneet hardware-prefetcherit joiden ansiosta kummankaan prosessoreille ei tarvi juuri prefetch-käskyjä käyttää.

Bulldozerin välimuistirakenteessa oli joitain typeryyksiä L1-kakuissa(liian iso L1I suhteessa assosiatiivisuuteen johti aliasoitumiseen, ja läpikirjoittava L1D floodasi pahasti L2-kakkua) joiden takia se oli vähän nirso ja hidasteli tietyissä tilanteissa, mutta Zenistä molemmat nämä Bulldozer-johdannaisten typeryydet on korjattu.


Zenillä on jäljellä tuo non-temporal storejen käsittelyn ongelma, johon AoTS tormäsi. Hyvin harvinainen tilanne. Tämä ei millään tavalla selitä mitään noista The Stiltin 29 softan suorituskyvystä, olen melko varma, että korkeintaan yksi niistä käyttää non-temporal storeja yhtään mihinkään, todennäköisesti ei yksikään.
 
Viimeksi muokattu:
JiiPee sanoi:
Mikä on mutuilua? Onko se todellakin niin vaikeaa ymmärtää että optimoinneilla on väliä? Se että Intel on hallinnut viimeiset lähes 10v cpu markkinoita on opettanut lähes KAIKKI (Varsinkin nuoremmat, ne jotka imi vielä tissiä silloin kun AMD:n ja Intelin välinen sota oli kuumimmillaan) jo koulusta lähtien koodaamaan täysin Intelin ehdoilla. Tää tuntuu olevan hyvin vaikeaa ymmärtää monelle.
Edelleen, tässä ei sinäänsä ole mitään väärää. Tottakai kannattaa tehdä asiat niin mille on kysyntää.



Argumentit ei lopu, en vaan yksinkertaisesti JAKSA vängätä asiasta kun se on ihan sama vaikka menisi tuonne ulos puupölkyille juttelemaan. En yksinkertaisesti osaa ilmaista asioita niin että näille neropateille se menisi jakeluun.
Ilmeisesti herroilla on vain liikaa vielä tuota nuoruuden intoa ja kun ovat mielestään niin hyvin perillä kaikesta niin on käynyt samalla vähän sellainen efekti että kusi noussu päähän ja ollaan hyvin herkästi heti kyykyttämässä niitä jotka eivät asioita niin tarkkaan tiedä.
Napsauta laajentaaksesi...
Nytkö tästä on tullut jo ikäkysymys? Paljonpa luulet näillä herroilla olevan ikää?

Kukaan ei ole muuten väittänyt, etteikö optimoinnilla olisi jotain väliä. Jos sinulla on tietoa siitä, että optimoimalla koodia juuri AMD:lle on merkittävää hyötyä, ole hyvä ja esitä todisteet asiasta, silloinhan siitä ei jää mitään epäselvää (sikäli kun todisteet ovat paikkansa pitäviä). Todistustaakka on sinulla silloin, kun käyt esittämään asioita faktana.
 
Jos nyt yritetään miettiä potentiaalisia ihan ryzen-spesifisiä optimointeja, niin yksi sellainen olleellinen on (vain) zenistä löytyvä CLZERO-käsky, jolla voi nollata 64 tavun verran dataa kerralla, ja säästäen muistikaistaa(clzeron kanssa välimuistilinjaa ei tarvi ollenkaan ladata muistista ennen sitä kirjoitusta)

Kutsua tähän käskyyn ei kuitenkaan kuulu sijoittaa mihinkään normaalin ohjelman lähdekoodiin, vaan se kuuluu laittaa käyttöjärjestelmän ja kääntäjän muistinhallintarutiineihin. Että kun kääntäjä tekee koodin jolla se nollaa isoja muistialueita, se tekeekin pienen määrän näitä käskyjä sen sijaan että tekisi suuremman määrän normaaleita 0-vektorin kirjoituksia muistiin.

Tai että kun käyttöjärjestelmä nollaa ison alueen muistia, se tekee sen CLZERO-käskyllä.

En tiedä, mikä on kääntäjien tilanne tämän käskyn tukemisessa. Pitäisi ehkä testata että osaako esim. LLVMn uusin versio käyttää clzeroa memsetin toteuttamiseen silloin kun sillä kirjoitetaan nollaa.
 
Iso määrä 64 tavun cacheline rajalle osuvaa dataa, ihan yleiskäyttöinen tuo CLZERO ei ole.

Edit: LLVM:ssä ainakin intrinsicci olisi tuolle joten miksei sitä voisi bzero() jo tukea.
 
Viimeksi muokattu:
hkultala sanoi:
Ne "intelin ehdot" on >90%sti ihan yhtä lailla "AMDn ehdot". Olen tätä jo moneen kertaan yrittänyt selittää.
Napsauta laajentaaksesi...

Eli nyt myönnät että ne ei olekkaan samanlaisia?

hkultala sanoi:
Miten kääntäjä VOISI ottaa CCXn jotenkin huomioon?
Napsauta laajentaaksesi...

No sinähän se aloit siitä kääntäjästä vänkäämään että se tekee KAIKEN ja koodaajan ei tarvi tehä MITÄÄN. Ilmeisesti se kääntäjä ei pystykkään tekemään kaikkea ja tuossa on esimerkiksi tilanne jossa koodaaja voisi asioihin vaikuttaa.
 
En itse koodaamisesta perusta, mutta eikös se olisi käyttöjärjestelmätason juttu se säikeiten jako tietylle CCX:lle?
 
  • Tykkää
Reactions: BOT
Oliko @JiiPee:llä tiedossa joku puhdas prosessorikuorma, joka ei olisi nimenomaan optimoitu Intelille ja tämän takia AMD:n suorituskyky olisi siinä juuri sen ansiosta sitä mitä pitääkin?

Vai onko tosiaan niin että kaikki viimeisen 10 vuoden aikana kirjoitettu koodi suosii automaattisesti Intelin arkkitehtuureja :confused:
 
Kirjaudu tai rekisteröidy kirjoittaaksesi tänne.

Uutiset

Uutisia lyhyesti

Uusimmat viestit

Statistiikka

Viestiketjuista
262 449
Viestejä
4 556 975
Jäsenet
74 966
Uusin jäsen
Hautamagi

Hinta.fi

Back
Ylös Bottom