Virallinen: AMD vs Intel keskustelu- ja väittelyketju

  • Keskustelun aloittaja Keskustelun aloittaja Sampsa
  • Aloitettu Aloitettu
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:
rapukala sanoi:
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:
Napsauta laajentaaksesi...
Jaa samalla powerilla ajeltu myös tämä: rapukala`s CPU Frequency score: 5199.72 mhz with a Xeon X5675 ? Sinä voisit sen mittailla ja kertoa meille. :)
 
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:
 
En ole tarkistanut, mutta jos ovat pitäneet mukana niin voi herra isä :D
 
Kun täällä on nyt ollut puhetta noista optimoinneista ja gcc:stä. Paljonkos sillä on @The Stilt vaikutusta noihin testeihin jos tosiaan käyttää gcc:lle noita flägejä geneeriseen verrattuna? (Olikos se nyt -march=skylake -mtune=skylake intelin jorpakoille ja -march=znver1 -mtune=znver1 amd:n rytsölöille)

Edit: 3dnow! putos kelkasta bulldozerissa.
 
Näkyy Phenomit olleen viimeisiä mitkä sitä tuki.
 
JiiPee sanoi:
Eli nyt myönnät että ne ei olekkaan samanlaisia?
Napsauta laajentaaksesi...


:facepalm:

Minä en puhu paskaa toisin kuin eräät muut täällä.

Jos en ole jostain asiasta 100% varma, en väitä sitä 100% varmana asiana.

Jos väitän jotain asiaa >90% varmuudella, silloin asia oikeasti erittäin suurella varmuudella on niin.

Mikroarkkitehtuureissa on jotain eroja niin aina voi tulla joitain hyvin harvinaisia, kokonaiskuvan kannalta merkityksettömiä tapauksia, joissa tilanteet eroavat.

Ja tällöinen mene puhumaan paskaa 100%sta vaan totean että "yli 90% tapauksista", ollakseni rehellinen.

Sinä taas puhut ihan täyttä paskaa intelille optimoiduista softista ilman mitään todisteita, perusteita tai ymmärrystä väitteidesi tueksi, tietämättä asiasta oikeasti yhtään mitään.

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.
Napsauta laajentaaksesi...

Enkä alkanut. Jälleen postaat olkiukkopaskaa.

Sinä olet tässä ainoa joka on vängännyt, minä olen vain selittänyt miten asiat toimii.

Ilmeisesti se kääntäjä ei pystykkään tekemään kaikkea ja tuossa on esimerkiksi tilanne jossa koodaaja voisi asioihin vaikuttaa.
Napsauta laajentaaksesi...

Kuten jo selitin edellisessä viestissäni, käytännössä MILLÄÄN The Stiltin 29 softasta minkään säikeiden skedulointi huonosti eri CCXlle ei vaikuta MILLÄÄN TAVALLA suorituskykyyn, koska niissä ei ole tilanteita, että ajossa olisi vain muutama säie. Ajossa on joko vain yksi säie, jolloin ei väliä, millä säikeellä se ajautuu, tai ajossa on niin paljon säikeitä että molempien CCXien kaikki virtuaaliytimet on täysin työllistetty, niin ei taaskaan oel väliä, millä CCXllä mikäkin ajautuu.
 
Viimeksi muokattu:
TeroP sanoi:
Nytkö tästä on tullut jo ikäkysymys? Paljonpa luulet näillä herroilla olevan ikää?
Napsauta laajentaaksesi...

Sinäällään kyllä että nuorempi sukupolvi ei tunnu ymmärtävän että nykyinen tapa koodata ei ole se paras tapa. Kustannustehokastahan se toki on kun suht pienellä vaivalla saadaan tehtyä isojakin asioita valmiilla kikkareilla ja yhä useampi pystyy koodaamaan riittävän hyvin. Tämä johtuu puhtaasti siitä että nykyisin koneista löytyy niin paljon tehoa että ei juurikaan haittaa vaikka sitä teho poltettaisiin turhuuksiin.
20v sitten koodaaminen oli hyvin erilaista ja esim. kaverini joka on koodannut jo pitkälti yli 30v ei tykkää tästä nykyisestä suuntauksesta koska se tuottaa "aivottomia" koodaajia.
 
JiiPee sanoi:
Sinäällään kyllä että nuorempi sukupolvi ei tunnu ymmärtävän että nykyinen tapa koodata ei ole se paras tapa. Kustannustehokastahan se toki on kun suht pienellä vaivalla saadaan tehtyä isojakin asioita valmiilla kikkareilla ja yhä useampi pystyy koodaamaan riittävän hyvin. Tämä johtuu puhtaasti siitä että nykyisin koneista löytyy niin paljon tehoa että ei juurikaan haittaa vaikka sitä teho poltettaisiin turhuuksiin.
20v sitten koodaaminen oli hyvin erilaista ja esim. kaverini joka on koodannut jo pitkälti yli 30v ei tykkää tästä nykyisestä suuntauksesta koska se tuottaa "aivottomia" koodaajia.
Napsauta laajentaaksesi...

Et vastannut kysymykseen, vaan lähdit puhumaan filosofiahuttua asiasta josta sinulla ei ole omaa kokemusta, pelkästään "kaverien kertomusten perusteella".

Kerrotko, mitä ne turhuudet omasta mielestäsi ovat?


(joo, olet oikeassa, että niitä "turhuuksia" on, mutta epäilen, että osaatko nimetä niitä. Eikä niistä läheskään kaikki oikeastaan ole turhuuksia, vaan osa on esim. luotettavuusominaisuuksia, ja osa koodarien tuottavuutta parantavia ominaisuuksia).

Ja välillä tilanne on mennyt myös toisinpäin, uudet korkeamman tason ohjelmointikielet ovat mahdollistaneet tehokkaampien tietorakenteiden helpomman käytön, ja samat asiat on (samalla tai pienemmällä vaivalla) välillä voitu tehdä fiksummilla nopeammilla algoritmeilla koska uuden kielen parempi vakiokirjasto on tarjonnut tietorakenteet siihen. So what jos uusi kieli ajautuu kolmasosalla vanhan kielen suoritusnopeudesta, jos jotain looppia tarvii pyöriä miljoonan kierroksen sijasta 20 kierrosta. Toki tämä on jossain määrin harvinainen tilanne.


ps. Olen koodannut työkseni jo yli 20 vuotta sitten, ja ensimmäisestä yksinkertaisesta tietokoneohjelmastani on jo reilusti yli 25 vuotta.
 
Viimeksi muokattu:
hkultala sanoi:
:facepalm:

Minä en puhu paskaa toisin kuin eräät muut täällä.

Jos en ole jostain asiasta 100% varma, en väitä sitä 100% varmana asiana.

Jos väitän jotain asiaa >90% varmuudella, silloin asia oikeasti erittäin suurella varmuudella on niin.
Napsauta laajentaaksesi...

Kukas se nyt niitä maalitolppia siirtelee?

Ensin annat ymmärtää että 90% on samaa ja nyt se sitten muuttuukin että 90% on "must tuntuu" että on samaa. Hiukan eri asia.


hkultala sanoi:
Enkä alkanut. Jälleen postaat olkiukkopaskaa.

Sinä olet tässä ainoa joka on vängännyt, minä olen vain selittänyt miten asiat toimii.
Napsauta laajentaaksesi...

Virallinen: AMD vs Intel keskustelu- ja väittelyketju

Siinä eka viesti jossa aloit tuota kääntäjä sontaa suoltamaan, eli kyllä se olit sinä joka sen tähän soppaan sekoitti.

hkultala sanoi:
(joo, olet oikeassa, että niitä on, mutta epäilen, että osaatko nimetä niitä. Eikä niistä läheskään kaikki oikeastaan ole turhuuksia, vaan osa on esim. luotettavuusominaisuuksia, ja osa koodarien tuottavuutta parantavia ominaisuuksia)
Napsauta laajentaaksesi...

No siihen nyt ei varmaan kovin suurta päättelytaitoa vaadita että pystyy sanomaan etten osaa nimetä niitä koska olen jo kertonut että itse en ehjelmoinnista tiedä juurikaan eikä suuremmin edes kiinnosta.
Mutta kaverin juttuja kun on kuunnellut (ihmisillä on taipumus puhua niistä asioista jotka heitä kiinnostaa) niin onhan sieltä jotain jäänyt mieleen.
 
JiiPee sanoi:
Kukas se nyt niitä maalitolppia siirtelee?

Ensin annat ymmärtää että 90% on samaa ja nyt se sitten muuttuukin että 90% on "must tuntuu" että on samaa. Hiukan eri asia.




Virallinen: AMD vs Intel keskustelu- ja väittelyketju

Siinä eka viesti jossa aloit tuota kääntäjä sontaa suoltamaan, eli kyllä se olit sinä joka sen tähän soppaan sekoitti.



No siihen nyt ei varmaan kovin suurta päättelytaitoa vaadita että pystyy sanomaan etten osaa nimetä niitä koska olen jo kertonut että itse en ehjelmoinnista tiedä juurikaan eikä suuremmin edes kiinnosta.
Mutta kaverin juttuja kun on kuunnellut (ihmisillä on taipumus puhua niistä asioista jotka heitä kiinnostaa) niin onhan sieltä jotain jäänyt mieleen.
Napsauta laajentaaksesi...
Lopeta jo hyvä mies! Yrität puhua aidan seipäästä, kun ammattimiehet on selittänyt jo kymmenisen kertaa mikä se aita on. :tdown:
 
svk sanoi:
En itse koodaamisesta perusta, mutta eikös se olisi käyttöjärjestelmätason juttu se säikeiten jako tietylle CCX:lle?
Napsauta laajentaaksesi...

Helpoin se varmaan siellä olisi toteuttaa ettei tarttis mitään purkkavirityksiä. Mutta kun Zeppelin ei ole NUMA vaikka tavallaan onkin, niin käyttis näkee sen yhtenä tasa-arvoisena prosessorina. Tosin NUMA varmaan olisi hiukan liian raju zeppelin tasolle, tarvittaisiin joku välimuoto.

The Stilt sanoi:
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:
Napsauta laajentaaksesi...

No cinebenchin exe näyttä itsellä 5.12.2016 päivätyksi joten jos foliopipon painaa päähän niin voisi olla mahdollista että AMD olisi MAXTON:n kanssa työskennellyt ennen tuon julkaisua, eikös AMD noihin aikoihin alkanut demoamaan myös kiviä?

Ja sehän tiedetään että AMD työskenteli joittenkin softatalojen kanssa, eikös blender ollut esimerkiksi yksi josta AMD:lla oli demoissaan käytössä vielä julkaisematon versio, vai oliko se joku beta tai alpha versio joka oli juuri tullut julkiseksi?


Mutta voihan se toki olla että kuvittelen vaan ja Ryzen on ainoastaan cinebenchissä lähes tasoissa intelin kanssa ja saa kuokkaan kaikessa muussa ja pahasti.
 
Testasin ihan huumoriarvon puolesta, mitä tapahtuu kun kuormat optimoi tietylle arkkitehtuurille kääntäjän puolesta.
Otin kuormiksi uusimman Stockfish 9 version sekä IFVD CFD:n, koska nuo on molemmat nopea kääntää uudelleen.
Kolme eri versiota eri tuunauksilla (geneerinen, znver1 sekä broadwell).

R7 1700 & 7960X, 3.8GHz kellotaajudella, ST.

IFVD CFD

Ryzen:

Generic: 16.261 IPS
Znver1: 16.301 IPS
Broadwell: 16.094 IPS

Skylake-X:

Generic: 17.199 IPS
Znver1: 17.035 IPS
Broadwell: 17.167 IPS

Stockfish 9

Ryzen:

Generic: 1605k
Znver1: 1631k
Broadwell: 1629k

Skylake-X:

Generic: 2489k
Znver1: 2461k
Broadwell: 2486k

Erot mahtuvat helposti virhemarginaaliin
Paras optimointi esim. IFVD:n tapauksessa on käyttää Intelin kääntäjää Ryzenille GCC:n sijasta.
Nopeushyöty > 18% verrattuna GCC 7.2 version :kahvi:

Toki ylläolevat tulokset eivät tietysti todista mitään, sillä ohjelmien lähdekoodi on alunperin kirjoitettu puolueelliseksi Intelin sekä mahdollisesti myös Kiovan fasistijuntan toimesta.
 
JiiPee sanoi:
Helpoin se varmaan siellä olisi toteuttaa ettei tarttis mitään purkkavirityksiä. Mutta kun Zeppelin ei ole NUMA vaikka tavallaan onkin, niin käyttis näkee sen yhtenä tasa-arvoisena prosessorina. Tosin NUMA varmaan olisi hiukan liian raju zeppelin tasolle, tarvittaisiin joku välimuoto.



No cinebenchin exe näyttä itsellä 5.12.2016 päivätyksi joten jos foliopipon painaa päähän niin voisi olla mahdollista että AMD olisi MAXTON:n kanssa työskennellyt ennen tuon julkaisua, eikös AMD noihin aikoihin alkanut demoamaan myös kiviä?

Ja sehän tiedetään että AMD työskenteli joittenkin softatalojen kanssa, eikös blender ollut esimerkiksi yksi josta AMD:lla oli demoissaan käytössä vielä julkaisematon versio, vai oliko se joku beta tai alpha versio joka oli juuri tullut julkiseksi?


Mutta voihan se toki olla että kuvittelen vaan ja Ryzen on ainoastaan cinebenchissä lähes tasoissa intelin kanssa ja saa kuokkaan kaikessa muussa ja pahasti.
Napsauta laajentaaksesi...

Tietääkseni viimeisin versio Cinebenchistä on huomattavasti vanhempi, vuodelta 2013 tms.

Blender ja Cinebench R15 vaikuttavat soveltuvan Ryzenille erittäin hyvin siksi, että Ryzenin SMT:n hyötysuhde on niissä poikkeuksellisen korkea (< 42% CB R15, 35% Blender) ja ennenkaikkea Inteliä selkeästi korkeampi.
IPC:ssä kuitenkin esim. Skylake-X on Ryzenia 9.6% edellä Cinebench R15:ta ja 8% Blenderissä (2.79a).
 
The Stilt sanoi:
Tietääkseni viimeisin versio Cinebenchistä on huomattavasti vanhempi, vuodelta 2013 tms.
Napsauta laajentaaksesi...

Hakemistossa on myös 26.8.2013 päivättyjä tiedostoja, mutta exe on esimerkiksi allekirjoitettu 5.12.2016 ja copyright ulottuu myös vuoteen 2016 että kyllä se vaikuttaisi 2016 julkaistulta versiolta. (15.0.3.8)
 
Mielenkiintoista että AoTS tekijät on antanu tällaisia kommentteja

“Every processor is different on how you tune it, and Ryzen gave us some new data points on optimization,” Oxide’s Dan Baker told PCWorld. “We’ve invested thousands of hours tuning Intel CPUs to get every last bit of performance out of them, but comparatively little time so far on Ryzen.”

Here's proof that Ryzen can benefit from optimized game code

Että kumpaa sitä sitten uskoisi? Koodaajia jotka on jotain näkyvää saanut aikaiseksi vaiko näitä forumin ammattisotureita jotka sanoo että prosessorit on ihan samanlaisia ja sama koodi toimii molemmissa ihan yhtä hyvin.

Niin toki kaikki on mahdollista kun folipipon oikein syvälle vetää päähän. Onhan se täysin mahdollista että AMD on tuon kommentin antajalle pistänyt näppiin nipun paperia jotta kaveri sanoo ihan mitä AMD haluaa hänen sanovan.
 
JiiPee sanoi:
Sinäällään kyllä että nuorempi sukupolvi ei tunnu ymmärtävän että nykyinen tapa koodata ei ole se paras tapa. Kustannustehokastahan se toki on kun suht pienellä vaivalla saadaan tehtyä isojakin asioita valmiilla kikkareilla ja yhä useampi pystyy koodaamaan riittävän hyvin. Tämä johtuu puhtaasti siitä että nykyisin koneista löytyy niin paljon tehoa että ei juurikaan haittaa vaikka sitä teho poltettaisiin turhuuksiin.
20v sitten koodaaminen oli hyvin erilaista ja esim. kaverini joka on koodannut jo pitkälti yli 30v ei tykkää tästä nykyisestä suuntauksesta koska se tuottaa "aivottomia" koodaajia.
Napsauta laajentaaksesi...
Kysymys varmaan on millä ammattitaidolla Sinä olet täällä, kun Kaveria ei lasketa mukaan?
 
mäsä-79 sanoi:
Kysymys varmaan on millä ammattitaidolla Sinä olet täällä, kun Kaveria ei lasketa mukaan?
Napsauta laajentaaksesi...

Sillä nyt ei varmaan ole mitään merkitystä vaikka olisin juuri valittu venäjän presidentti että miten huonosti porukka nykyisin osaa optimoida koodia.
 
mäsä-79 sanoi:
Eli voidaan unohtaa nämä JiiPeen keskustelut tässä langassa :)
Napsauta laajentaaksesi...

Sitten voidaan unohtaa kaikkien keskustelut, koska tuskin kukaan tulee sinulle kertomaan sen tarkemmin omaa ammattitaitoaan. Kaikenmoisia "ammattilaisia" täällä toki on, mutta se ei ole mikään velvollisuus niistä kertoa.
Oletko esim. miettinyt sellaista että täälläkin saattaa olla keskustelussa sellaisia jotka eivät edes saa huudella omasta ammattitaidostaan mitenkään julkisesti?
 
JiiPee sanoi:
Sitten voidaan unohtaa kaikkien keskustelut, koska tuskin kukaan tulee sinulle kertomaan sen tarkemmin omaa ammattitaitoaan. Kaikenmoisia "ammattilaisia" täällä toki on, mutta se ei ole mikään velvollisuus niistä kertoa.
Oletko esim. miettinyt sellaista että täälläkin saattaa olla keskustelussa sellaisia jotka eivät edes saa huudella omasta ammattitaidostaan mitenkään julkisesti?
Napsauta laajentaaksesi...
Tiedetään ainakin ne ketkä ei huutele turhia MutuMaster(tm) teorioitaan ;)
 
mäsä-79 sanoi:
Tiedetään ainakin ne ketkä ei huutele turhia MutuMaster(tm) teorioitaan ;)
Napsauta laajentaaksesi...

Ilmeisesti täällä ei saisi keskustella yhtään mistään jos ei heti ole jotain lähdettä esittää. Ja johan minä olen lähteenkin antanut jossa pelifirmasta kommentoidaan asiaa joka tukee minun näkemystä.
Mutta eihän sekään teille tietysti riitä kun on sellainen "leikki" peli.

EDIT: Laitetaan vielä uudestaan

“Every processor is different on how you tune it, and Ryzen gave us some new data points on optimization,” Oxide’s Dan Baker told PCWorld. “We’ve invested thousands of hours tuning Intel CPUs to get every last bit of performance out of them, but comparatively little time so far on Ryzen.”
 
JiiPee sanoi:
Ilmeisesti täällä ei saisi keskustella yhtään mistään jos ei heti ole jotain lähdettä esittää. Ja johan minä olen lähteenkin antanut jossa pelifirmasta kommentoidaan asiaa joka tukee minun näkemystä.
Mutta eihän sekään teille tietysti riitä kun on sellainen "leikki" peli.

EDIT: Laitetaan vielä uudestaan

“Every processor is different on how you tune it, and Ryzen gave us some new data points on optimization,” Oxide’s Dan Baker told PCWorld. “We’ve invested thousands of hours tuning Intel CPUs to get every last bit of performance out of them, but comparatively little time so far on Ryzen.”
Napsauta laajentaaksesi...
Onko äijällä ollu omaa tietämystä ollut kun on puhuttu puhtaasti teknisestä toteutuksesta. Kyllä nää Ashes of the Benchmarkin tekijät tiedetään jo.
 
mäsä-79 sanoi:
Onko äijällä ollu omaa tietämystä ollut kun on puhuttu puhtaasti teknisestä toteutuksesta. Kyllä nää Ashes of the Benchmarkin tekijät tiedetään jo.
Napsauta laajentaaksesi...

Aivan, eipä yllättänyt tuo vastaus kyllä yhtään. Ennemmin uskotaan keskustelupalstasotureiden juttuja kuin sellaisten jotka ovat oikeasti jotain näkyvää koodanneet.

Eiköhän tämä sitten ollut tässä. :)
 
Kirjaudu tai rekisteröidy kirjoittaaksesi tänne.

Uutiset

Uutisia lyhyesti

Uusimmat viestit

Statistiikka

Viestiketjuista
295 645
Viestejä
5 047 133
Jäsenet
80 968
Uusin jäsen
hattuk1

Hinta.fi

Back
Ylös Bottom