LevelOneTechs ja Bitsum uskovat korjanneensa Threadripper 2990WX:n suorituskykyongelmat

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
21 448



AMD julkaisi viime vuonna toisen sukupolven Ryzen Threadripper -prosessorit, jotka on varustettu parhaimmillaan 32 ytimellä, jotka kykenevät SMT-teknologian avulla suorittamaan samanaikaisesti 64 säiettä. Etenkään 32-ytiminen Ryzen Threadripper 2990WX ei kuitenkaan selvinnyt kaikista suorituskykytesteistä odotusten mukaisesti.

Ryzen Threadripper -prosessoreiden suorituskykyongelmia on ratkottu jo monella taholla. AMD on julkaissut oman Dynamic Local Mode -ominaisuutensa, joka parantaa suorituskykyä useissa tilanteissa ja NVIDIA korjasi ajureistaan löytyneen ongelman, joka puolitti suorituskyvyn 32-ytimisillä, 64 säiettä suorittavilla prosessoreilla. Osa ongelmista on kuitenkin edelleen ratkomatta ja LevelOneTechs uskoo selvittäneensä mm. Bitsumin ja AnandTechin avustuksella mistä on kyse, eikä se ole monien syyttämä muistiohjainten puute kahdella sirulla, mikä varmistettiin ajamalla testejä Threadripperin lisäksi 32-ytimisellä Epyc-prosessorilla.



LevelOneTechs käsittelee Windowsin ytimestä tämän hetken tietojen perusteella löytyvää ongelmaa sekä blogissaan että YouTube-videolla. Esimerkiksi Indigo-testiohjelmassa TR2990WX:n suorituskyky on Windowsilla vain puolet tai alle Linux-versiosta, eikä Linux-version ajo Windowsin alla auta tilanteeseen, koska Windows Subsystem for Linux suorittaa kaiken edelleen Windowsin kernelillä, ei Linuxin. NUMA-tilassa myös Epycin suorituskyky on Windowsilla heikko, mutta UMA-tilassa suorituskyky vastaa Linuxia.

Prosessorin rasitusaste on kuitenkin kummallakin alustalla identtinen 100 % riippumatta suorituskyvystä, joten Windowsilla prosessori hukkaa johonkin merkittävän osan suoritusajastaan. Tarkempien tutkimusten jälkeen syylliseksi paljastui Windows, joka merkitsee Indigon säikeet ideal_cpu-tagilla käynnistyksen yhteydessä. Jos käytössä on maksimissaan kaksi NUMA-noodia, kaikki toimii kuten pitää ja ideal_cpu-tagi syntyy edelleen, mutta säikeet löytävät kotinsa kummankin NUMA-noodin sisältä.

Kun NUMA-noodeja on yli kaksi, rupeaa Windows noudattamaan ideal_cpu-tageja ja säikeet pyritään saamaan vain yhden NUMA-noodin sisälle, jolloin Windows käyttää puolet prosessoriajasta siirrelläkseen säikeitä ytimiltä toisille. Yksi ratkaisu bugiin on ottaa ensimmäinen prosessoriydin pois ohjelman käytöstä, kun ohjelma on jo päällä, jonka jälkeen Windows jättää ilmeisesti jälleen ideal_cpu-tagit huomiotta. Ohjelman käytöstä poistetun ytimen voi ilmeisesti myös ottaa takaisin käyttöön ilman, että suorituskyky putoaa uudelleen, mutta sama kikka on toistettava joka kerta, kun ohjelmaa käytetään.

Bitsum on näiden löydösten myötä päivittänyt CorePrio-ohjelmaansa NUMA Dissociater -ominaisuudella, joka pyrkii automaattisesti tunnistamaan edellä kuvatun ongelman ja korjaamaan sen, ilmeisesti käyttäen juuri yllä kuvattua metodia. Indigon lisäksi vastaavaa ongelmaa esiintyy myös muilla sovelluksilla ja esimerkiksi 7zipin suorituskyky nousee CorePrion korjauksen avulla peräti 70 % noin 41 000 MIPS:sistä noin 70 000 MIPS:iin.

Mikäli LevelOneTechsin johtopäätökset ovat oikeita, voidaan toivoa Microsoftin päivittävän kerneliään tarpeellisilla muutoksilla ongelman ratkaisemiseksi lähitulevaisuudessa.

Lähde: LevelOneTechs, Bitsum CorePrio

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

IcePen

Typo Generaatroti ;-)
Tukijäsen
Liittynyt
17.10.2016
Viestejä
5 966
Otsikossa on Pahavirhe tässä korjattu versio

"LevelOneTechs ja Bitsum uskovat korjanneensa Windowsin suorituskykyongelmat Threadripper 2990WX prosessoria käytettäessä."

Alkuperäine otsiko antaa sen kuvan niin kuin Threadripper 2990WX prosessorisssa olisi ollut jotain vikaa mikä ei pidä paikaansa.
 
Viimeksi muokattu:
Liittynyt
27.12.2016
Viestejä
1 837
Jos olisi foliot tiukemmalla voisi haistaa jonkun salaliittoteorian siitä että TR prossuja jarrutellaan tarkoituksella. En tiedä Intelin enterprise palvelimista tarpeeksi, mutta onkohan mitään muuta ympäristöä, jossa Windows 10 oikeasti olisi ajossa NUMA ympäristössä?
 
Liittynyt
27.12.2016
Viestejä
854
Herää kysymys miksei näin selvää bugia ole löydetty ja korjattu MS toimesta? Onko windowsin serveriversioissa eri scheduleri jossa ei tätä bugia ole, luulisi että siellä noita useamman noden koneita olisi. Vai onko tämä ongelma spesifi pelkästään threadripperille?
 

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
21 448
Herää kysymys miksei näin selvää bugia ole löydetty ja korjattu MS toimesta? Onko windowsin serveriversioissa eri scheduleri jossa ei tätä bugia ole, luulisi että siellä noita useamman noden koneita olisi. Vai onko tämä ongelma spesifi pelkästään threadripperille?
Koskee myös Epyciä NUMA-tilassa, UMA-tilassa ei koske Epyciä.
 
Liittynyt
05.02.2017
Viestejä
5 124
Herää kysymys miksei näin selvää bugia ole löydetty ja korjattu MS toimesta? Onko windowsin serveriversioissa eri scheduleri jossa ei tätä bugia ole, luulisi että siellä noita useamman noden koneita olisi. Vai onko tämä ongelma spesifi pelkästään threadripperille?
Ei kannata aina olettaa pahantahtoisuutta tilanteessa, jossa useimmiten kyse on vain ammattitaidon puutteesta. Ihan mahdollista on, että siellä on vain ajateltu, että 2990WX on persiistä, ja siksi suorituskyky on huono. Koska markkinaosuus on pieni, ei ole laitettu asiaan enempää paukkuja.
 
Liittynyt
05.11.2016
Viestejä
2 133
Jos olisi foliot tiukemmalla voisi haistaa jonkun salaliittoteorian siitä että TR prossuja jarrutellaan tarkoituksella. En tiedä Intelin enterprise palvelimista tarpeeksi, mutta onkohan mitään muuta ympäristöä, jossa Windows 10 oikeasti olisi ajossa NUMA ympäristössä?
Ihan "puhdas bugi" tämä on minun mielestäni kun otetaan huomioon kuinka erilaisia nämä prosessorit on useamman NUMA noodinsa kanssa. Wendell veikkaa että tämä voisi liittyä 1 tai 2 kannan XCC Xeoneja varten tehtyyn bugi korjaukseen.
Enkä tiedä onko Wendell tai joku muu testannut mutta veikkaisin että Server 2016/2019 on sama ongelma kuin Windows 10:ssä.

When only one NUMA node is recommended via the “ideal CPU” the windows kernel seems to spend half the available CPU time just shuffling threads between cores. That explains the high-CPU -utilization-but-nothing-gets-done aspect of the low performance. It also means it’s a bit tricky to spot apps/threads that are flailing about this way.

Here’s an interesting twist: If you only have one OTHER NUMA node – windows seems to fall back to allowing the threads to establish themselves on the second NUMA node (the ideal CPU tag is ignored, basically).

This is most likely related to a bugfix from Microsoft for 1 or 2 socket Extreme Core Count (XCC) Xeons wherein a physical Xeon CPU has two numa nodes. In the past (with Xeon V4 and maybe V3), one of these NUMA nodes has no access to I/O devices (but does have access to memory through the ring bus).

If that’s true, then that work-around to make sure this type of process stays on the “ideal CPU” in the same socket has no idea what to do when there is more than one other NUMA node in the same package to “fail over” to.

In the case of the Threadripper 2990, there are three other NUMA nodes in the socket.

As such that algorithm seems to just aimlessly shuffle threads and that is one plausible explanation for why the Indigo performance is so much worse on the 2990WX than the 16-core 2950X.
P.S. Eikö se ole virallisesti Level1Techs eikä LevelOneTechs About Us
 

Marti77

Team H2O
Liittynyt
16.12.2016
Viestejä
4 395
Hyvä ettää löytyy asialla omistautuneita ihmisiä kun noiden suorituskykyasioiden etsintään kuluu varman aika paljon miestyötunteja mitä helpottaa paljon korjauspäivitysten teossa.
 

Nerkoon

Se ainoa oikea
Platinum-jäsen
Liittynyt
18.10.2016
Viestejä
5 625
Herää kysymys miksei näin selvää bugia ole löydetty ja korjattu MS toimesta? Onko windowsin serveriversioissa eri scheduleri jossa ei tätä bugia ole, luulisi että siellä noita useamman noden koneita olisi. Vai onko tämä ongelma spesifi pelkästään threadripperille?
Nyt puhutaan samasta firmasta joka pisti ulos dataa hävittävän ja bugiseksi tiedetyn päivityksen Windows 10:lle. Jos he eivät tajua korjata edes raportoituja bugeja, niin miten joku piilossa oleva olisi sitten korjattu?
 

Kapteeni_kuolio

⚓Ledimestari⚓
Team R&T
Liittynyt
16.10.2016
Viestejä
1 797
Tuskin mitään tahallista hidastamista, näyttäis aika tyypilliseltä windows-bugilta. Niinkuin Wendell videollaan kertoo niin AMD on historiansa aikana tarponu jo monen monta kertaa windowsin bugisuossa, lähinnä koska AMD kehittää usein uusia ratkaisuja joille sitten joutuu odottamaan windows-tukea joskus pitkäänkin. Nythän tässä on kyse siitä että AMD on kehittänyt ensin tämän chiplet-arkkitehtuurin (ja intel on lähdössä tähän mukaan viiveellä), ja MS:llä ei ole ehkä tieto-taitoa viilata kerneliä niin että kaikki toimii täydellisesti. Ihmetyttää oikeastaan se että näillä yhtiöillä ei ole parempaa kommunikaatiota keskenään ja että tämän tason bugi löytyy vielä näin pitkän aikaa tuotteen julkaisun jälkeen :darra:
 
Liittynyt
12.12.2016
Viestejä
3 930
Hyvä ettää löytyy asialla omistautuneita ihmisiä kun noiden suorituskykyasioiden etsintään kuluu varman aika paljon miestyötunteja mitä helpottaa paljon korjauspäivitysten teossa.
Ja tekijätkin ovat sellaisia joilla ei ole mitään sisäpiiritietoa Windowsista. Silti pystyvät parempaan kuin Microsoft ":tup:"

Tuskin mitään tahallista hidastamista, näyttäis aika tyypilliseltä windows-bugilta. Niinkuin Wendell videollaan kertoo niin AMD on historiansa aikana tarponu jo monen monta kertaa windowsin bugisuossa, lähinnä koska AMD kehittää usein uusia ratkaisuja joille sitten joutuu odottamaan windows-tukea joskus pitkäänkin. Nythän tässä on kyse siitä että AMD on kehittänyt ensin tämän chiplet-arkkitehtuurin (ja intel on lähdössä tähän mukaan viiveellä), ja MS:llä ei ole ehkä tieto-taitoa viilata kerneliä niin että kaikki toimii täydellisesti. Ihmetyttää oikeastaan se että näillä yhtiöillä ei ole parempaa kommunikaatiota keskenään ja että tämän tason bugi löytyy vielä näin pitkän aikaa tuotteen julkaisun jälkeen :darra:
Tässähän ei varsinaisesti ole kyse chipleteistä. Onkin jännittävää nähdä miten se oikea chiplet-homma tulee toimimaan.

Tuskin se kommunikaatiosta on kiinni. Microsoftia ei vaan kiinnosta.
 
Liittynyt
17.10.2016
Viestejä
162
Aika selvää, että jokin bugi on ollut, kun useampi testi antaa saman tuloksen 32-corelliselle Threadripperille kuin 16-corelliselle esim. PassMark ja Indigo. Ei sitä selitä mikään muistin pullonkaula. Joko bugi on windowsissa, kuten nyt selvisi sen olevan, tai sitten testeissä, mikä olisi vähän outoa, kun ne testit kuitenkin toimii 16+ corellisilla Intel prosessoreilla. Joo, ei siinä winkussa ole vain ollut tukea vielä uudenlaiselle arkkitehtuurille ja siksi se kusee. Mutta hyvä juttu, että Threadripperit on mainettaan parempia. Tosiaan on ollut tiedossa, että 32-corellinen pyörii paljon paremmin Linuxin puolella se on näkynyt testeissä. Minäkin vaik en oo Linux-miähiä huomasin semmoisen testiartikkelin.
 

IcePen

Typo Generaatroti ;-)
Tukijäsen
Liittynyt
17.10.2016
Viestejä
5 966
Jos olisi foliot tiukemmalla voisi haistaa jonkun salaliittoteorian siitä että TR prossuja jarrutellaan tarkoituksella. En tiedä Intelin enterprise palvelimista tarpeeksi, mutta onkohan mitään muuta ympäristöä, jossa Windows 10 oikeasti olisi ajossa NUMA ympäristössä?
Ei voi koska sama ongelma on myös Epyceissä ja tuo on iso ongelman Microsoftille joka kuvittelee vieläkin tunkevansa omaa käyttistään todellisiin palvelimiin ja muuhun raskaaseen käyttöön.
 

IcePen

Typo Generaatroti ;-)
Tukijäsen
Liittynyt
17.10.2016
Viestejä
5 966
... Ihmetyttää oikeastaan se että näillä yhtiöillä ei ole parempaa kommunikaatiota keskenään ja että tämän tason bugi löytyy vielä näin pitkän aikaa tuotteen julkaisun jälkeen :darra:
Eiköhän AMD:n ja Microsoftin välillä kommunikaatio kulje ihan hyvin.

Kun tuntuu Microsoftin kymmeniävuosia jatkuneen töpeksimisen perusteella siltä että ne kommunikaatiotukokkset on siellä Microsoftin sisällä.
 
Liittynyt
02.06.2017
Viestejä
374
Kenenkään ei pitäisi olla yllättynyt tällaisesta. Samat ongelmat vaivaavat myös moniprosessorijärjestelmiä.
Windowsin oma scheduleri toimii hienosti, kun käytössä on yksi NUMA-node ja yksi processorgroup. Kun määrät nousevat, scheduleri rupeaa nikottelemaan. Käytännössä Windowsin scheduleria on jo vaikea käyttää, jos loogisten prosessorien määrä ylittää yhden Processorgroupin rajan. Eikä ole kauaa, kun ominaisuus, jossa yksi numa-node saattoi pilkkoutua useampaan processorgrouppiin korjattiin.

Tosiasiassa Windowsille ei ole juuri muita softia, kuin niiden oma SQL-server joka tukisi kunnolla montaa prosessoria/processorgrouppia. Ja olen aivan varma, että käyttävät julkaisemattomia rajapintoja tämän tuen saavuttaakseen. MSDN:n dokumentaatio on totaalisen perseestä koko NUMAn ja schedulerin osalta, myöskään Wininternals (joka on erinomaisen lavea joissain muissa asioissa) ei avaa tätä toiminnallisuutta mitenkään. Lisäksi Windowsissa on kaameita legacyrajoitteita koko schedulerin suhteen (koko Processor Group himmeli).

Intelin kääntäjän mukana tulee TBB, jonka pitäisi ratkoa näitä ongelmia, mutta enpä ole tästäkään kovin vakuuttunut.

Jos tarvitsee paljon säikeitä, valinta on selkeästi Linux. Jos/kun perinteiset UI-softat (kuten pelit) rupeavat vaatimaan 64+ säiettä, on Windows kusessa processor grouppeineen.
 
Liittynyt
13.12.2016
Viestejä
988
Jos olisi foliot tiukemmalla voisi haistaa jonkun salaliittoteorian siitä että TR prossuja jarrutellaan tarkoituksella. En tiedä Intelin enterprise palvelimista tarpeeksi, mutta onkohan mitään muuta ympäristöä, jossa Windows 10 oikeasti olisi ajossa NUMA ympäristössä?
Ei voi koska sama ongelma on myös Epyceissä ja tuo on iso ongelman Microsoftille joka kuvittelee vieläkin tunkevansa omaa käyttistään todellisiin palvelimiin ja muuhun raskaaseen käyttöön.
Juu. Samaa tässä konesalimiehenä ihmettelin. Ei näy tällä Winukkaa missään. Tai on yksi kone missä on Windows mutta se ei ole kiinni missään vaan toimii pasianssi konenna Artolle ku se tykää pelata...
 
Liittynyt
13.12.2016
Viestejä
988
Kenenkään ei pitäisi olla yllättynyt tällaisesta. Samat ongelmat vaivaavat myös moniprosessorijärjestelmiä.
Windowsin oma scheduleri toimii hienosti, kun käytössä on yksi NUMA-node ja yksi processorgroup. Kun määrät nousevat, scheduleri rupeaa nikottelemaan. Käytännössä Windowsin scheduleria on jo vaikea käyttää, jos loogisten prosessorien määrä ylittää yhden Processorgroupin rajan. Eikä ole kauaa, kun ominaisuus, jossa yksi numa-node saattoi pilkkoutua useampaan processorgrouppiin korjattiin.

Tosiasiassa Windowsille ei ole juuri muita softia, kuin niiden oma SQL-server joka tukisi kunnolla montaa prosessoria/processorgrouppia. Ja olen aivan varma, että käyttävät julkaisemattomia rajapintoja tämän tuen saavuttaakseen. MSDN:n dokumentaatio on totaalisen perseestä koko NUMAn ja schedulerin osalta, myöskään Wininternals (joka on erinomaisen lavea joissain muissa asioissa) ei avaa tätä toiminnallisuutta mitenkään. Lisäksi Windowsissa on kaameita legacyrajoitteita koko schedulerin suhteen (koko Processor Group himmeli).

Intelin kääntäjän mukana tulee TBB, jonka pitäisi ratkoa näitä ongelmia, mutta enpä ole tästäkään kovin vakuuttunut.

Jos tarvitsee paljon säikeitä, valinta on selkeästi Linux. Jos/kun perinteiset UI-softat (kuten pelit) rupeavat vaatimaan 64+ säiettä, on Windows kusessa processor grouppeineen.
Eli Windowssilla on vielä paljon aikaa korjata tuotteensa kuluttajapuolella koska eihän niiden softaa juurikaan missään muualla käytetä. Siinä vaiheessa kun pelit alkavat käyttää 64+ säiettä voi kestää jokunen vuosi;)
 
Liittynyt
18.10.2016
Viestejä
2 903
Herää kysymys miksei näin selvää bugia ole löydetty ja korjattu MS toimesta? Onko windowsin serveriversioissa eri scheduleri jossa ei tätä bugia ole, luulisi että siellä noita useamman noden koneita olisi. Vai onko tämä ongelma spesifi pelkästään threadripperille?
Suosittelen joskus menemään töihin johonkin tuollaiseen suuryritykseen, karisee nopeasti suomut silmiltä että vaikka firma olisi markkinajohtaja niin että siellä olisi töissä ammattikunnan terävin kärki :D

Voi kun vain voisi kertoa millaista shittiä sitä on nähnyt, mutta heitetään nyt pari täkyä, olen nähnyt kuinka IT alan PhD ei osannut vaihtaa näytön resoluutiota ja tuijotti sitä siksi 5cm etäisyydeltä tai että kuinka porukka koodaa Notepadilla ja valittaa ettei koodia voi refaktoroida koska muutaman muuttujan nimen vaihtamiseen koodista menee tunteja....
 
Liittynyt
02.06.2017
Viestejä
374
Onko windowsin serveriversioissa eri scheduleri jossa ei tätä bugia ole, luulisi että siellä noita useamman noden koneita olisi. Vai onko tämä ongelma spesifi pelkästään threadripperille?
Itseasiassa Windowsin server-versiot scheduloivat oletuksena hieman eritavalla kuin desktop-versiot. Tätä voi toki muuttaa yhdellä täpällä System/advanced settings/performance osassa.
Sovellussäikeet saavat aina pienen aikaikkunan, jonka jälkeen säie rescheduloidaan prioriteetti ja jonotussääntöjen mukaan. Tämä aikaikkuna on desktop-windowseissa merkittävästi lyhyempi, kuin serveriversioissa. Tästä johtuen desktop-versiot ovat paljon alttiimpia context-switcheille kuin serveriversiot tilanteissa, joissa on paljon säikeitä odottamassa suoritusta.
Kyseessä on osittain legacy-juttu, juontaen yhden hw-säikeen koneista, joissa on haluttu UI-softien olevan vastaavampia käyttäjää kohtaan. Nykyisinkin desktop-koneilla on vähemmän samanaikaisuutta, joten ominaisuus puoltaa paikkaansa.

Runsas vääränlainen context-switchailu voi johtaa todella ikäviin tilanteisiin monen Numanoden koneilla, jos säie joutuukin seuraavalla scheduloinnilla vääriin välimuisteihin väärälle Numa-nodelle. Tästä seuraa memory barriereiden tarve tai välimuistisynkkaus, joka heikentää suorituskykyä roimasti. Schedulerin pitäisi yrittää välttää tällaisia tilanteita, mutta ilmeisesti jokin nimenomaan tässä bugittaa, ehkä Windows ei vain tajua Threadripperin Numa-rakennetta oikein.

Joku Threadripperin omistajahan voisi kokeilla tätä, laittakaa täppä "optimize for background services" päälle ja katsokaa miten suorituskyvyn käy?
 

IcePen

Typo Generaatroti ;-)
Tukijäsen
Liittynyt
17.10.2016
Viestejä
5 966
Itseasiassa Windowsin server-versiot scheduloivat oletuksena hieman eritavalla kuin desktop-versiot. Tätä voi toki muuttaa yhdellä täpällä System/advanced settings/performance osassa.
...
Se että prioriteeteja pystyy muuttamaan ei tarkoita sitä että muuttaisi sitä miten se toimii siinä vain mutetaan sitä hetkä milloin se toimii.
 
Liittynyt
02.06.2017
Viestejä
374
Ei tällä ole mitään tekemistä prioriteettien kanssa vaan yhdelle säikeelle kerralla annettavan suoritusaikaikkunan pituuden kanssa. Prioriteetti vaikuttaa siihen kuinka usein säie päätyy suoritettavaksi.
Ks. Windows Internals 6th edition osa 1, sivut 423-429 "Quantums"
 
Liittynyt
09.11.2016
Viestejä
1 330
Joku Threadripperin omistajahan voisi kokeilla tätä, laittakaa täppä "optimize for background services" päälle ja katsokaa miten suorituskyvyn käy?
Yhtä huonosti toi pelasi Windows Serverilläkin, jossa oletettavasti tuo on päällä
A Quick Look At The Windows Server vs. Linux Performance On The Threadripper 2990WX - Phoronix

Eli mitään yksinkertaista asetussäätöä tämän ongelman ratkaisuun ei ole, muuten se olisi jo todennäköisesti löydetty Microsoftin, AMD:n tai jonkun testaajan puolesta.
 
Liittynyt
02.06.2017
Viestejä
374
Enpä näin kyllä uskonutkaan, ongelma on edelleen sama, vaikka säie jatkaisikin pidempään ennen reschedulointia, tällöin säie on vain pidempään oikeassa/väärässä paikassa kerrallaan.

No kuten jo aiemmin kirjoitin, Windowsin scheduleri on Numan kanssa tosi kuppainen. Kaipaisi isompaa remonttia, mutta harmittavasti scheduleri on käyttiksen yksi oleellisimmista osista ja sen isompi ronkkiminen ilman tarpeeksi hyvää syytä ei ole hyvä idea ihan pienestä syystä.

Yksi syy miksi monet korporaatiot käyttävät Windowsia Linuxin sijaan palvelimissa on nimenomaan legacytuki vanhoille jutuille. Käytännössä voit olettaa minkä vain Win32 softan toimivan edelleen ilman mitään ongelmia uusimmissakin windowseissa - ja oikeastaan myös uusimman softan voi olettaa toimivan vanhoissa, jos olet vain pitäytynyt vanhassa apitasossa. Tätä ei haluta rikkoa.
Linux on tässä mielessä vähän ankea, koska pienikin kernel/libc päivitys voi rikkoa ABI yhteensopivuuden, pääsääntöisesti tosin vain taaksepäin, mutta käy välillä toisinkin päin. Tästä syystä meilläkin töissä käännämme softaa vielä Rhel4:llä ja roikutamme Redhat9 imageja virtuaalikoneina. Ja kääntöpuolena uusimman softan pitää olla sitten jotenkin semi-uutta (muttei liian), koska vanha ei sitten toimi (oikein) uusimpien kanssa. Eli konservatiivisessa windows mallissa on myös puolensa - ja tämä on muuten sama syy miksi Redhat on Linuxina niin suosittu yritysten käytössä.
 

IcePen

Typo Generaatroti ;-)
Tukijäsen
Liittynyt
17.10.2016
Viestejä
5 966
Ei tällä ole mitään tekemistä prioriteettien kanssa vaan yhdelle säikeelle kerralla annettavan suoritusaikaikkunan pituuden kanssa. Prioriteetti vaikuttaa siihen kuinka usein säie päätyy suoritettavaksi.
Ks. Windows Internals 6th edition osa 1, sivut 423-429 "Quantums"
Se että suoritusaikaikkunan pituuden pystyy muuttamaan ei tarkoita sitä että muuttaisi sitä miten se toimii siinä vain mutetaan sitä hetkä milloin se toimii.
 

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
21 448
AMD Comments on Threadripper 2 Performance and Windows Scheduler

AMD Comments On The Findings
There have been questions about how much AMD/Microsoft know about this issue, who they are in contact with, and what is being done. AMD was happy to make some comments on the record.

AMD stated that they have support and update tickets open with Microsoft’s Windows team on the issue. They believe they know what the issue is, and commends Wendell for being very close to what the actual issue is (they declined to go into detail). They are currently comparing notes with Bitsum, and actually helped Bitsum to develop the original tool for affinity masking, however the ‘NUMA Disassociator’ is obviously new.

The timeline for a fix will depend on a number of factors between AMD and Microsoft, however there will be announcements when the fix is ready and what exactly that fix will affect performance. Other improvements to help optimize performance will also be included. AMD is still very pleased with the Threadripper 2 performance, and is keen to stress that for the most popular performance related tests the company points to reviews that show that the performance in rendering is still well above the competition, and is working with software vendors to push that performance even further.
 
Liittynyt
09.11.2016
Viestejä
1 330
Toggle Sidebar

Statistiikka

Viestiketjut
237 331
Viestejä
4 157 436
Jäsenet
70 409
Uusin jäsen
Eycte

Hinta.fi

Ylös Bottom