AMD otti kantaa Ryzenin suorituskykyyn liittyviin spekulaatioihin

[Kaotik]

AMD julkaisi uuteen Zen-arkkitehtuuriin perustuvat Ryzen-prosessorit kuluvan kuun 2. päivä eli vajaat kaksi viikkoa sitten. Lukuisten erilaisten testien jälkeen netti on täyttynyt spekulaatioista, jotka pyrkii selittämään prosessoreiden suorituskyvyn heittelyt eri testiohjelmissa. Suosituimpia teorioita on ollut muun muassa Windows 10:n säieskedulerin (thread scheduler) vaikeudet uuden arkkitehtuurin kanssa. AMD:n Robert Hallock on julkaissut yhtiön sivuilla blogipostauksen, jossa hän selvittää AMD:n kantaa lukuisiin Ryzeniin liittyviin spekulaatioihin.

AMD:n omien tutkimusten mukaan Windows 10:n säieskeduler toimii Ryzen-prosessoreiden kanssa juuri niin kuin sen pitäisikin ja se osaa käsitellä prosessorin loogisia ytimiä oikein. Monen tahon raportoimat oudot tiedot Sysinternalsin Coreinfo -työkalulla selittyvät puolestaan vanhentuneella versiolla. Coreinfon tuorein 3.31 -versio antaa Ryzenin ytimistä ja välimuisteista oikeat tiedot aiempien versioiden virheellisten sijasta.

AMD:n mukaan erot Windows 7:n ja 10:n suorituskyvyssä selittyvät yksinkertaisesti käyttöjärjestelmien välisillä yleisillä eroilla eikä esimerkiksi ehdotetuilla skedulerin eroilla ole asian kanssa mitään tekemistä. Yhtiö kuitenkin tiedostaa, että vaikka monet ohjelmat osaavat jo nyt hyödyntää Ryzenin arkkitehtuuria tehokkaasti, voisivat lukuisat muut ohjelmat saada optimoinneilla selkeitä suorituskykyparannuksia.

Yksi kysymyksiä herättänyt seikka eri Ryzen-mallien välillä on prosessorin T Control- eli tCTL-anturin raportoimat lämpötilat. Anturi mittaa prosessorin lämpötilaa piisirun ja lämmönlevittäjän yhtymäkohdasta. Eri ohjelmat raportoivat tCTL:n mittauksiin perustuen tällä hetkellä merkittävästi pienempiä lämpötiloja Ryzen 7 1700 -mallille verrattuna 1700X- ja 1800X -malleihin.

AMD:n mukaan syy tälle on halu saada kaikkien Ryzen-prosessoreiden tuuletinprofiilit toimimaan yhtenevällä kaavalla. 95 watin TDP-arvolla varustetut X-prosessorit vaativat luonnollisesti enemmän jäähdytystä kuin 65 watin TDP-arvolla varustetut ei-X-mallit, joten AMD lisää X-prosessoreiden tCTL:n raportoimaan lämpötilaan 20 °C varmistamaan tuulettimen toiminnan riittävällä nopeudella. AMD uskoo lämpötiloja seuraavien ohjelmien päivittyvän tulevaisuudessa ymmärtämään X-prosessoreiden todellisen lämpötilan, mutta sitä odotellessa käyttäjät voivat yksinkertaisesti vähentää 20 °C tCTL-anturin raportoimasta lämpötilasta.

AMD toistaa jälleen suosituksensa käyttää Ryzenin kanssa Windows 10:n Paras suoritusteho -virranhallintaprofiilia (High Performance). Paras suoritusteho -profiili varmistaa, ettei Windowsin virranhallinta sammuta käyttämättömiä ytimiä, mikä hidastaa niiden käyttöönottoa rasituksen kasvaessa. Lisäksi Windowsin virranhallinnan Tasapainotettu-profiili (Balanced) saattaa hidastaa Ryzenin kellotaajuuden ja jännitteen muutoksia verrattuna Paras suoritusteho -profiiliin.

Viimeinen seikka, johon Hallock pureutuu blogissa on Simultaneous Multi-threading eli SMT-ominaisuus. Vaikka lukuisat testit ovat raportoineet useiden pelien suorituskyvyn kärsivän SMT:n ollessa käytössä, pitäisi AMD:n mukaan suorituskykyerojen olla joko olemattomia tai jopa positiivisia. Myös jotkut arvosteluista ovat todenneet samaa huolimatta lukuisista poikkeavista tuloksista.

Io-techin testeissä SMT paransi suorituskykyä parhaimmillaan reilut 8 prosenttia ARMA 3 -pelissä, kun pahimmillaan se heikensi suorituskykyä yli 11 prosenttia Total War: Warhammerissa.

Hallockin blogipostaus antaa vastauksen lukuisiin eri väittelyihin koskien Ryzen-prosessoreita. Se jättää kuitenkin edelleen avoimiksi useita kysymyksiä, kuten suorituskykyerot kun kaikki ohjelman käyttämät säikeet ovat samassa CCX-CPU-kompleksissa verrattuna saman ohjelman suorituskykyyn säikeiden jakautuessa molempiin CCX:iin.



Esimerkiksi NVIDIAn MeshInstancing-demo käyttää kahta säiettä. Roy Botnikin YouTubessa julkaisema testi osoittaa, että kyseisessä ohjelmassa suorituskyvyssä on merkittäviä eroja sen mukaan ovatko suoritettavat säikeet samassa CCX:ssä vai ei. Kun säikeet ovat jakautuneet kahteen CCX:ään, pyörii ruudunpäivitysnopeus Ryzen 7 1800X -prosessorilla ja Radeon R9 200 -sarjan näytönohjaimella noin 14 – 14,5 FPS:n välimaastossa. Kun suoritettavat säikeet ovat samassa CCX:ssä, nousee suorituskyky 16,5 – 17 FPS:n paikkeille. Windows arpoo säikeitä suorittavat loogiset ytimet ohjelman joka käynnistyksellä uudelleen ja eroa voi siis syntyä reilusti yli 15 %.

Myös Hardware.fr-sivusto on testannut hieman vastaavaa tilannetta rajoittamalla Ryzenin neljään ytimeen kahdessa eri konfiguraatiossa. Toisessa konfiguraatiossa on yksi CCX käytössä kokonaisuudessaan ja toinen poistettu käytöstä kokonaan, kun toisessa kummastakin CCX:stä on käytössä kaksi ydintä. 7-Zip-testissä 2+2-ytimen konfiguraatio suoriutui jopa nopeammin kuin 4+0-ydintä, mutta muissa testeissä eroa ei joko ollut käytännössä lainkaan tai 4+0-ydintä suoriutui testistä paremmin. Suurimmillaan ero oli Battlefield 1:ssä, jossa 2+2-ytimen konfiguraatio hävisi 4+0-ytimen konfiguraatiolle liki 20 %:n erolla.

Huom! Foorumiviestistä saattaa puuttua kuvagalleria tai upotettu video.

Linkki alkuperäiseen uutiseen (io-tech.fi)

 

[Sampsa]

Netissä on liikkunut viimeisen parin viikon aikana paljon huhuja, spekulointia ja virheellistä tietoa liittyen Ryzeniin ja sen toimivuuteen Windowsissa. Emme lähteneet io-techin uutisissa hötkyilemään raporttien kanssa, vaan tässä kunnon faktat aiheesta missä mennään tällä hetkellä.

@hkultala

 

[Fileguru]

Oikein mielenkiintoinen ja hyvä päivitys tämän hetkiseen tilanteeseen. Eli teoriassa tilaa olisi optimoinneille esim. peleissä vielä CCX:ien toimivuuteen liittyen (?).

 

[Lagittaja]

@Kaotik @Sampsa PCPerkin perkasi tätä asiaa

Kirjoitettu versio
AMD Ryzen and the Windows 10 Scheduler - No Silver Bullet | PC Perspective

Minusta mielenkiintoisimmat slaidit mittasi pingiä säikeiden välillä

custom written C++ application with a very simple premise: ping threads between cores

En viitsi koko selitystä lainata tähän mutta Intel kuvan kohdalla:

Intel 5960X - What we are looking at above is how long it takes a one-way ping to travel from one logical core to the next. The line riding around 76 ns indicates how long these pings take when they have to travel to another physical core. Pings that stay within the same physical core take a much shorter 14 ns to complete.

Samalla tuolla testillä varmistettiin se että Intel ja AMD loogiset ytimet on numeroitu samalla tavalla ja "oikeat" vs SMT ytimet samoin päin.
0 ja 1 sama fyysinen, 2 ja 3 sama fyysinen jne. Ja kuten Intelillä parilliset "niitä parempia" kuin parittomat, Wintoosan pitäisi tietää että kahdeksan raskasta laskusäiettä on fiksumpi sijoittaa ytimille 0, 2, 4 jne kuin 1, 3, 5 jne.​

Tuosta Ryzen kuvasta näkyy hienosti ne 2xCCX ja miten se vaikuttaa ytimien väliseen jutteluun. Omasta mielestä tämä koko CCX hässäkkä on hieno idea, näkyyhän se tuosta kuinka paljon pienempi se viive loogisten ytimien 0-7 tai 8-15 välillä vs Intelillä (lähes puolet), huono puoli tietenkin on jos loogisen ytimen 0 pitää kysyä loogiselta ytimeltä 8 jotain niin aikaa siihen kuluu reippaasti yli kolme kertaa kauemman kuin saman CCX ytimien välillä (ja lähemmäs 2x kauemman vs minkä tahansa Intel ytimen välillä).

 

[Nerkoon]

Ottaen huomioon Win7 ja Win10 vauhtierot olen edelleen sitä mieltä, että jotain jäi sanomatta. Veikkaan,että jossain vaiheessa vain ilmestyy Windows patchi tai pari jotka kuitataan optimointeina, mutta lisäävät kummasti Ryzenin menohaluja. MS on markkinoinut Win10 parhaana tähän asti ja väite siitä, että se on vaan kehnompi kuin Win7 ei ole hyvää PR:ää heille.

 

[_j03_]

Ottaen huomioon Win7 ja Win10 vauhtierot olen edelleen sitä mieltä, että jotain jäi sanomatta. Veikkaan,että jossain vaiheessa vain ilmestyy Windows patchi tai pari jotka kuitataan optimointeina, mutta lisäävät kummasti Ryzenin menohaluja. MS on markkinoinut Win10 parhaana tähän asti ja väite siitä, että se on vaan kehnompi kuin Win7 ei ole hyvää PR:ää heille.

No todennäköisesti, mutta miksipä AMD ampuisi itseään jalkaan puhumalla paskaa firmoista jotka voi asiaa korjata tai lupailemalla jotain mikä ei ole heidän käsissään.

 

[miiksu]

Ottaen huomioon Win7 ja Win10 vauhtierot olen edelleen sitä mieltä, että jotain jäi sanomatta. Veikkaan,että jossain vaiheessa vain ilmestyy Windows patchi tai pari jotka kuitataan optimointeina, mutta lisäävät kummasti Ryzenin menohaluja. MS on markkinoinut Win10 parhaana tähän asti ja väite siitä, että se on vaan kehnompi kuin Win7 ei ole hyvää PR:ää heille.

Niinpä. Mutta onko ongelma AMD:n mukaan niin pieni että "ongelmaa" ei ole. Eli koittavat hissutella että myyntiluvut säilyy korkeana ja kukaan ei pettyisi vaan suorituskykyyn että kun tulikin vain 2% teholisäys. Vai koittavatko saada työrauhaa vaan. Musta tullu kauheen epäileväinen kaikkeen vuosien varrella että mitään ei kannata 100% uskoa. Katsotaan nyt miten tässä lähikuukausina käy niin sit katsellaan uudestaan

 

[Sampsa]

Niinpä. Mutta onko ongelma AMD:n mukaan niin pieni että "ongelmaa" ei ole. Eli koittavat hissutella että myyntiluvut säilyy korkeana ja kukaan ei pettyisi vaan suorituskykyyn että kun tulikin vain 2% teholisäys. Vai koittavatko saada työrauhaa vaan. Musta tullu kauheen epäileväinen kaikkeen vuosien varrella että mitään ei kannata 100% uskoa. Katsotaan nyt miten tässä lähikuukausina käy niin sit katsellaan uudestaan

Suorituskyky on ok tasolla ja softa/ajurit/peli/kääntäjä/käyttis-optimoinneilla on väkisinkin lisää luvassa, ainakin yksittäisissä sovelluksissa ja peleissä ajan myötä. Siitäkös paskamyrsky olisi syntynyt, jos olisivat heittäneet "ongelmat" Microsoftin harteille, kun itse ovat arkkitehtuurin ja teknisen toteutuksen suunnitelleet ja tehneet..

Mutta kuten sanoit, niin lähikuukausien aikana ollaa viisaampia

 

[Mechanical Man]

Niin. "scheduler works fine" ei poista parantamisen mahdollisuuksia. Esim. siten, että win10 ottaisi huomioon tuon 2*CCX rakenteen jollakin tapaa.

 

[Kaotik]

@Kaotik @Sampsa PCPerkin perkasi tätä asiaa
Kirjoitettu versio
AMD Ryzen and the Windows 10 Scheduler - No Silver Bullet | PC Perspective

Minusta mielenkiintoisimmat slaidit mittasi pingiä säikeiden välillä


En viitsi koko selitystä lainata tähän mutta Intel kuvan kohdalla:

Samalla tuolla testillä varmistettiin se että Intel ja AMD loogiset ytimet on numeroitu samalla tavalla ja "oikeat" vs SMT ytimet samoin päin.
0 ja 1 sama fyysinen, 2 ja 3 sama fyysinen jne. Ja kuten Intelillä parilliset "niitä parempia" kuin parittomat, Wintoosan pitäisi tietää että kahdeksan raskasta laskusäiettä on fiksumpi sijoittaa ytimille 0, 2, 4 jne kuin 1, 3, 5 jne.​

Tuosta Ryzen kuvasta näkyy hienosti ne 2xCCX ja miten se vaikuttaa ytimien väliseen jutteluun. Omasta mielestä tämä koko CCX hässäkkä on hieno idea, näkyyhän se tuosta kuinka paljon pienempi se viive loogisten ytimien 0-7 tai 8-15 välillä vs Intelillä (lähes puolet), huono puoli tietenkin on jos loogisen ytimen 0 pitää kysyä loogiselta ytimeltä 8 jotain niin aikaa siihen kuluu reippaasti yli kolme kertaa kauemman kuin saman CCX ytimien välillä (ja lähemmäs 2x kauemman vs minkä tahansa Intel ytimen välillä).

Mutta kuten tuo NVIDIA MeshInstancing -testi osoittaa, Windows ei laita joka kerta niitä säikeitä samalle CCX:lle, eikä edes aina niille "oikeille ytimille"

PCPerin kaveri toteaa myös tuon kommenteissa näin tehtyään pyynnöstä lisätestin mitä ei päivitetty itse juttuun:

Windows would treat each CCX as a NUMA node if the CPUID coding segmented it accordingly, but that doesn't appear to be the case currently.

ja

It depends. If the scheduler was made aware of the CCX / cache segmentation, it could prioritize one CCX over another, but you might still have workloads that would have behaved better otherwise (i.e. performs slower with 8 threads on only 4 physical cores vs. spread across 8). Point being there is no one size fits all fix here.

 

[Meteorismus]

Tykkään io-techin linjasta olla hätäilemättä ja olla julkaisematta "uutisia" puutteellisten tietojen pohjalta. Mutupaketissa tämä oli jo heitetty ilmoille Microsoftin paikallistamana bugina, eikä sitä virheellistä uutista todennäköisesti korjata. Hienoa on sekin, että mikäli io-techissä tehdään virhe, niin näitä uutisia ja artikkeleita muokataan sitä mukaa jos faktat muuttuvat. Vähän menee nyt ehkä ohi aiheen tämä viesti, mutta halusin silti kehua toimintaanne tämän(kin) uutisen kohdalla ja pyydänkin teitä jatkamaan samalla linjalla.

 

[FlyingAntero]

Täytyy kompata ylempää sen verran, että tällainen juttu konsepti toimii todella hyvin . Antaa sellaisen kuvan, että asioita on oikeasti mietitty ja tutkittu, eikä vain tuupattu uutta höttöuutista pihalle toisen perään. Lähes kuka tahansa voi kääntää huhu-uutisia saitilta toiselle (välillä enemmän tai vähemmän onnistuneesti ) mutta tämä osoittaa osaamista. Kiitos .

 

[Juha Kokkonen]

Tykkään io-techin linjasta olla hätäilemättä ja olla julkaisematta "uutisia" puutteellisten tietojen pohjalta. Mutupaketissa tämä oli jo heitetty ilmoille Microsoftin paikallistamana bugina, eikä sitä virheellistä uutista todennäköisesti korjata. Hienoa on sekin, että mikäli io-techissä tehdään virhe, niin näitä uutisia ja artikkeleita muokataan sitä mukaa jos faktat muuttuvat. Vähän menee nyt ehkä ohi aiheen tämä viesti, mutta halusin silti kehua toimintaanne tämän(kin) uutisen kohdalla ja pyydänkin teitä jatkamaan samalla linjalla.

Tarkoituksena ei tosiaan ole aina olla ensimmäinen uutisoimassa jostain asiasta, vaan ennemminkin uutisoida vain mahdollisimman varmoista asioista ja koittaa tuoda mahdollisuuksien mukaan lisäarvoa ja -sisältöä aiheen kylkeen.

 

[jive]

Tarkoituksena ei tosiaan ole aina olla ensimmäinen uutisoimassa jostain asiasta, vaan ennemminkin uutisoida vain mahdollisimman varmoista asioista ja koittaa tuoda mahdollisuuksien mukaan lisäarvoa ja -sisältöä aiheen kylkeen.

Vähän niin kuin Suomen Anandtech tai siis sellainen Anandtech kuin mitä se oli vielä silloin kun Anandtech oli vielä Anandtech.

 

[Dygaza]

Tarkoituksena ei tosiaan ole aina olla ensimmäinen uutisoimassa jostain asiasta, vaan ennemminkin uutisoida vain mahdollisimman varmoista asioista ja koittaa tuoda mahdollisuuksien mukaan lisäarvoa ja -sisältöä aiheen kylkeen.

Juu on kaksi eri asiaa kommentoida ja spekuloida asiaa foorumilla ja tehdä siitä ihan erillinen tarina. Jotenkin kun teet asiasta virallisen lööpin ni se tarkoittaa että se on sitten "fakta".

 

[Dygaza]

Suorituskyky on ok tasolla ja softa/ajurit/peli/kääntäjä/käyttis-optimoinneilla on väkisinkin lisää luvassa, ainakin yksittäisissä sovelluksissa ja peleissä ajan myötä.

Millaisiahan optimointeja siellä oikeasti voidaan tehdä. Dan Bakerhan sano silloin siinä AMD pressi tilaisuudessa että päivitykset eivät ehtineet peliin Ryzenin julkaisuun, mutta voisiko joku vähän avata mitä siellä oikeasti voidaan optimoida? Selvästikin tuo kahden CCX:n välinen kommunikointi hidastaa ainakin tietyillä säikeillä. Voiko pelinkehittäjät esim tehdä säikeistä "pidempiä" jolloin säikeiden välinen yhteinen kommunikointi vähänee, jolloin saadaan paremmin piilotettua noita CCX moduulien latensseja?

 

[Anatoli]

Eli iotechin kellottamien Ryzenien lämpötilat todellisuudessa Handbrake-kuormituksessa :

1700@4GHz, 1,425V, 75°C
1700X@3,95GHz, 1,425, 66°C
1800X@4GHz, 1,4V, 60°C

Vaikuttaa vähän järkevimmiltä lukemilta kuin alkuperäiset, mutta silti aika väkevä ero 1700X:n ja 1700:n välillä.

 

[hsalonen]

Vähän niin kuin Suomen Anandtech tai siis sellainen Anandtech kuin mitä se oli vielä silloin kun Anandtech oli vielä Anandtech.

Sano vaan suoraan: ennenkuin Anand lähti Applelle.

Silloin oli Sampsakin jäljessä, kun noi melkein suvereenisti keksivät, että IOPS on järkevämpi mittari SSD-nopeudelle ja todistivat, että JMicron on täyttä roskaa.. Nyt ei ole niin suurta eroa, mitä foorumia seuraa, kun Suomessakin on näin hyviä vaihtoehtoja..

 

[mRkukov]

Eli iotechin kellottamien Ryzenien lämpötilat todellisuudessa Handbrake-kuormituksessa :

1700@4GHz, 1,425V, 75°C
1700X@3,95GHz, 1,425, 66°C
1800X@4GHz, 1,4V, 60°C

Vaikuttaa vähän järkevimmiltä lukemilta kuin alkuperäiset, mutta silti aika väkevä ero 1700X:n ja 1700:n välillä.

Vai onko? Nuo erothan on siis vaihdellut bios versioiden välillä, otitko nyt sen huomioon? Ymmärtääkseni niitä on säädetty edes taas.

Edit: vai olitko siis katsonut bios versiota ja verrannut lämpöjä sitten?

 

[Sivari]

Tykkään io-techin linjasta olla hätäilemättä ja olla julkaisematta "uutisia" puutteellisten tietojen pohjalta. Mutupaketissa tämä oli jo heitetty ilmoille Microsoftin paikallistamana bugina, eikä sitä virheellistä uutista todennäköisesti korjata. Hienoa on sekin, että mikäli io-techissä tehdään virhe, niin näitä uutisia ja artikkeleita muokataan sitä mukaa jos faktat muuttuvat. Vähän menee nyt ehkä ohi aiheen tämä viesti, mutta halusin silti kehua toimintaanne tämän(kin) uutisen kohdalla ja pyydänkin teitä jatkamaan samalla linjalla.

Fakta ei muutu, koskaan. Ja tämä on faktaa.

 

[Alghazanth]

Näihin isoihin arkkitehtuurien muutoksiin ois hyvä palata 6-12kk jälkeen julkaisusta, ja mielellään pelitestit uusilla peleillä niin sais vähän realistisempaa kuvaa missä todellinen taso menee. Jo julkaistuja alelaarin pelejä tuskin kukaan enää vaivautuu optimoimaan uudelle raudalle.

 

[Anatoli]

Nuo erothan on siis vaihdellut bios versioiden välillä, otitko nyt sen huomioon? Ymmärtääkseni niitä on säädetty edes taas.

Katsoin lämmöt ihan vaan suoraan ao. artikkeleista, mistään biosten aiheuttamista eroista en tiedä mitään. Prossujen ilmoittamat lämmöt nyt joka tapauksessa on vähän sinnepäin, eikä biossit ainakaan tuohon perus offsettiin ole vaikuttanut? Tossa on kuitenkin aika monta asiaa, mitkä pääsee vaikuttamaan siihen lämpötilaan, niin ei nuo lukemat nyt erityisen vertailtavia ylipäätänsä ole, mutta ainakaan niissä ei enää ole mitään huomattavia eroja väärään suuntaan.

 

[FireFly Renaissance]

Eli iotechin kellottamien Ryzenien lämpötilat todellisuudessa Handbrake-kuormituksessa :

1700@4GHz, 1,425V, 75°C
1700X@3,95GHz, 1,425, 66°C
1800X@4GHz, 1,4V, 60°C

Vaikuttaa vähän järkevimmiltä lukemilta kuin alkuperäiset, mutta silti aika väkevä ero 1700X:n ja 1700:n välillä.

Oliko tuuletin pwm-ohjattuna? Tuo AMD:n 20 asteen lisäys junction lämpötilaanhan laittaa ropellin pyörimään nopeammin X malleissa, mikä tuossa kikkailussa oli tarkoituksena. @Sampsa

 

[lehtv]

Eli iotechin kellottamien Ryzenien lämpötilat todellisuudessa Handbrake-kuormituksessa :

1700@4GHz, 1,425V, 75°C
1700X@3,95GHz, 1,425, 66°C
1800X@4GHz, 1,4V, 60°C

Vaikuttaa vähän järkevimmiltä lukemilta kuin alkuperäiset, mutta silti aika väkevä ero 1700X:n ja 1700:n välillä.

Mikäs tämä testi sitten on? Ryzen 7 1700 @ 4GHz, 1.425V, 67.50 C

 

[Sampsa]

Mikäs tämä testi sitten on? Ryzen 7 1700 @ 4GHz, 1.425V, 67.50 C

Tuo 67,50 astetta on ihan testin loppuvaiheessa, todellinen lämpötila oli siis siinä 70 asteessa ja yksittäisiä 75-77 asteen piikkejä (näitä välillä tuntuu Ryzenillä ilmaantuvan, että hyppää ihan sekunnissa tuollaisen piikin). Eli 70 on oikeampi lukema kuin 75-77.

 

[Nerkoon]

On tuo kyllä huvittava ulostulo AMD:ltä. Linuxin kerneliin tuli scheduler patchiä Ryzenille, LLVM:lle on tulossa scheduler patchia ja peleille on tulossa Ryzen patchiä, mutta Windows ei tarvitse mitään. Aivan...

 

[mRkukov]

Tuo 67,50 astetta on ihan testin loppuvaiheessa, todellinen lämpötila oli siis siinä 70 asteessa ja yksittäisiä 75-77 asteen piikkejä (näitä välillä tuntuu Ryzenillä ilmaantuvan, että hyppää ihan sekunnissa tuollaisen piikin). Eli 70 on oikeampi lukema kuin 75-77.

Paljonko oli idle lämmöt? Itsellä 1700 kiven kanssa idlelämmöt tippuu alle 17 asteeseen, eli tuohon arvoon pitää lisätä 10-20 astetta oikean luvun saamiseksi. 17 astetta kun on aika mahdoton ilman kompuraa tai muuta. Olikohan tuo 67.50 siis oikealla skaalalla vai puuttuuko siitäkin 10-20 astetta, kuten minun arvoista?

 

[muppelo]

On tuo kyllä huvittava ulostulo AMD:ltä. Linuxin kerneliin tuli scheduler patchiä Ryzenille, LLVM:lle on tulossa scheduler patchia ja peleille on tulossa Ryzen patchiä, mutta Windows ei tarvitse mitään. Aivan...

Täydellistä ei tartte korjata. Jos pitäs veikata niin virallisesti mitään ei oo vialla mut kulisseissa mahdollisesti tapahtuu jotain.

 

[mRkukov]

Täydellistä ei tartte korjata. Jos pitäs veikata niin virallisesti mitään ei oo vialla mut kulisseissa mahdollisesti tapahtuu jotain.

"It's not a bug, it's a feature. And now we just optimize the feature a bit."

 

[Sargo]

Paljonko oli idle lämmöt? Itsellä 1700 kiven kanssa idlelämmöt tippuu alle 17 asteeseen, eli tuohon arvoon pitää lisätä 10-20 astetta oikean luvun saamiseksi. 17 astetta kun on aika mahdoton ilman kompuraa tai muuta. Olikohan tuo 67.50 siis oikealla skaalalla vai puuttuuko siitäkin 10-20 astetta, kuten minun arvoista?

Unohtakaa ne lämmöt nyt hetkeksi.
Emolevyvalmistajat tuunaa niihin liittyviä parametreja (jostain syystä) ja lukemat eri biosversioiden välillä ei sen takia ole vertailukelpoisia.
Lämpötilat ei ole todellisuudessa muuttuneet yhtään mihinkään eri biosversioiden välillä, pelkästään kalibroinnit on.

Esim. joku C6H:n omistaja voi testata mitä tapahtuu "lämpötiloille" tilanteessa, SenseMi offsettia muutetaan.
0902 vanhemmilla bioseilla arvoon 282 ja 0902 biosilla arvoon 271

 

[E.T]

On tuo kyllä huvittava ulostulo AMD:ltä. Linuxin kerneliin tuli scheduler patchiä Ryzenille, LLVM:lle on tulossa scheduler patchia ja peleille on tulossa Ryzen patchiä, mutta Windows ei tarvitse mitään. Aivan...

Kun viranomaiset eivät puutu MS:n harrastamaan kaiken aikaa kasvavaan "telemetriaan", niin luuletko niiden puuttuvan siihen jos MS rupeaisi viivyttelemään käyttiksen päivitystä kostona sille että AMD sanoisi Win10:n schedulerin toimivan yhtä luotettavasti kuin horoskoopit?

 

[peksi]

On tuo kyllä huvittava ulostulo AMD:ltä. Linuxin kerneliin tuli scheduler patchiä Ryzenille, LLVM:lle on tulossa scheduler patchia ja peleille on tulossa Ryzen patchiä, mutta Windows ei tarvitse mitään. Aivan...

Lähinnä CPU:n tunnistukseen tuli pätsiä Linuxissa eikä itse skeduleriin, skeduleri taipui ennenkin vielä hankalampiinkin tilanteisiin. LLVM:n osalta ihan luonnollista odottaa backendeihin päivitystä - kääntäjät tukee esim. usein tarkempia optimointeja per mikroarkkitehtuuri jos näin halutaan.

Ja mistä on edes muodostunut käsitys ettei Microsoft ole tehnyt _mitään_ Ryzenin suhteen Windowsissa? Linuxin kohdalla toki helppo grepata gitin logeista viestejä mitä AMD on itse sinne commitoinut (ensimmäiset julkiset Ryzen/family 17 muutokset muuten tehtiin jo 2015) mutta ihan varmasti MS:n kerneltiimikin on ollut tietoinen Ryzenistä hyvissä ajoin. Skedulereissa toki riittää silti ikuisuuksiin asti parannettavaa, Linuxin skeduleristakin on kaiken supertietokoneoptimoinnin jälkeen löytynyt melkosia bugeja edelleen ("A decade of wasted cores" paperi esim)

 

[Deussu]

@peksi aika hyvää luettavaa oli tuo A decade of wasted cores.