Tästä oli jossain ketjussa jo vääntöä, mutta MLID ainakin oli jotain tietoja saanut että Zen6 saattaisi olla 12 core CCD.
Huhuja siitä, että olisi 12 ydintä on liikkunut jo paljon kauaemmin paljon luotettavammissa lähteissä kuin MLID.
Ja MLID:llä ei ole käytännössä koskaan mitään
tietoja, MLID:llä on vain
huhuja
Tällä kerralla MLID on todennäköisesti oikeassa(en kuitenkaan olisi varma tästä), mutta yleisesti:
MLID on näitä netin epäpätevämmästä ja epärehellisemmästä päästä olevia huhujen levittäjiä.
Juuri näitä tahoja jotka levittävät todella huuhaata olevia huhuja joita jotkut laittavat liikkeelle joko
1) ihan piloillaan ja nauravat perässä kun MLID:n tapaiset tahot ottavat ne tosissaan
2) manipuloidakseen osakemarkkinakursseja ja myyvät/ostavat jos kurssi heilahtaa "huhun" takia
ja sitten MLID ei koskaan myönnä olevansa väärässä. Kun ovat väärässä, syy on aina muualla "valmistaja muutti suunnitelmiaan" sen sijaan että myöntäisivät "uskottiin täyttä huuhaata olevaa huhua"
Ja tosiaan jos olisi, suurin osa peleistä kannattaisi varmaan ajaa ilman SMT siinä vaiheessa. Nykyään taas jos ajaa pelkästään 8 corella ilman SMT, oma käsitys on että stutteria saattaa tulla (näin oli jo intel 9700k vs 9900k Far Cry muistaakseni)
SMT:tä ei voi disabloida koneen ollessa käynnissä, vaatii reboottia. Jos haluaa koneella sekä pelata että ajella jotain monisäikeistyviä hyötysoftia(eikä reboottailla välissä), sitten tuo on vähän ongelmallista.
Mutta käyttiksen skedulerit ovat kyllä fiksuja, että vaikka SMT on päällä, jos säikeitä on ajossa vähemmän kuin ytimien määrä, sitten kaikki menee omille ytimilleen.
Lähinnä sitten tulee tilanne, että peli käyttää kaikkia ytimiä, sitten joku taustatask haluaa samalla hetkellä tehdä jotain pientä, niin missä sitä taustataskia ajetaan.
Parempi, että sitä ajetaan SMTllä samalla ytimellä kuin pelin jotain säiettä, kuin, että ilman SMT:tä pelin joku säie heitetään kokonaan pois suorituksesta siksi ajaksi kun tuota taustataskia palvellaan.
Mutta toki usein tilanne on se, että peli ei rasita 100% kuormituksella kaikkia säikeitään vaan siellä on esim. yksi raskas säie ajossa melkein koko ajan ja monia kevyempiä säikeitä ajossa silloin tällöin.
Lähinnä tulee mieleen että SMT voi olla haitallinen pelien suorituskyvylle tilanteessa, kun pelillä on joku thread pool jossa säikeitä on sama määrä kuin vaikka rautasäikeitä prossulla , mutta silti siellä tämän thread poolissa ajettavien taskien lisäksi on myös se yksi suorituskykykriittinen "pääsäie", tai yksi niistä thread poolin taskeista on efektiivisesti pääsäie joka ajautuu hyvin pitkään, muiden taskien yllessa lyhyitä ja yhdessäkin valmistuessa paljon nopeammin. Tällöin ilman SMT:tä pääsäie/päätask saa koko ytimen, mutta SMT:n kanssa se silloin tällöin jakaa ytimensä jonklun thread poolin kautta tulevan taskin kanssa.
Tällainen rakenne jossa on sekä yksi hyvin raskas pääsäie että thread pool jossa säikeiden määrä sama kuin systeemin rautasäikeiden määrä on kuitenkin huonosti optimoitua koodia. Sille pääsäikeelle pitäisi antaa suurempi prioriteetti kuin niille pienille "helpertaskeille" ja pitäisi yrittää varmistaa että helpertaskit ei kisaa samasta ytimestä päätaskin kanssa, mikäli vaan järkevästi mahdollista.
Mutta joo, jos softat mitä ajetaan käyttävät maksimissaan vaikka vaan 10ntä ydintä ja piirillä on ytimiä 12, sitten se SMT tosiaan on turha, koska se pari ylimääräistä ydintä riittä oikein hyvin niille kaikile taustataskeille.
Ja jos jotkut niistä peleitä on koodattu tyhmästi että siellä on liian ahne thread pool, sitten siinä SMTn disabloinnissa voi olla pointtia.
On nyt vähän tullut töissä seurattua meidän yhden testiserverin kuormitusta ja on tullut yritettyä vähän säädeltyä parametreja, että saataisiin maksimaalinen määrä testiajojamme läpi siitä aikayksikköä kohden. Palvelimen ylläpitäjät ovat kytkeneet SMTn pois päältä logiikalla, että optimoidaan että kukin testiajo ajautuisi maksiminopeudella, mutta käytännössä nyt tilanne meillä on se, että jos yritetään välttää sitä, ettei ajossa ole niin paljoa säikeitä, että joudutaan vaihtamaan ajossa olevien taskien välillä (missä on huomattavaa hidastavaa overheadia, kun myös esim sisemmillä välimuisteilla on huono osumatarkkus vaihdon jälkeen) , niin sitten melkein aina meillä onkin monia idlaavia ytimiä, koska kunkin testisetin yhtä aikaa ajossa olevien testien määrä vaihtelee, ja keskimääräinen kuormitus on selvästi pienempi kuin maksimikuormitus.
Nyt pitäisi varmaan yrittää ruinata ylläpidolta että SMT kytkettäisiin tuolla palvelimella päälle, koska sitten voitaisiin päästää selvästi suurempi määrä testejä yhtäaikaiseen ajoon ilman pelkoa siitä, että vaihtelu samalla ytimellä eri säikeiden välillä hidastaa suorituskykyä, ja saada keskimäärin parempi suorituskyky koska voitaisiin ajaa palvelinta oikeasti 100% kuormituksella.