maailma on täynnä ARM kamaa jossa homma on jo hoidossa. Intel on myös sitä mieltä että on hyvä idea tehdä epäsymmetrisiä suorittimia. Mikä tässä olisi sellaista joka olisi erityisen vaikeata?
Ei. ARMin big.LITTLE on AIVAN ERI asia.
Ja jokaisessa luurissa voi olla sille customoitu kernel joka tasan tarkkaan tietää millaiset ytimet sieltä löytyy, ja voi valita sen skedulointistrategian joka sillä toimii hyvin.
x86ssa meillä on:
1) Ilman SMT:tä olevia prossuja
2) SMT:llä olevia prossuja (pitää jotenkin selvittää, mitkä virtuaaliytimet on samalla fyysisellä ytimellä ja ottaa tämä huomioon skeduloinnissa)
3) CMT:llä olevia prossuja (pitää jotenkin selvittää, mitkä "ytimet" on samassa moduulissa, ja ottaa tämä huomioon skeduloinnissa, välillä siten että vältetään näiden yhtäaikaista käyttöä, mutta ehkä välillä siten että jos nämä kommunikoivatkin paljon keskenään(mitä käyttis ei voi oikeasti tietää) , laitetaankin ne ehkä saman modulin "ytimille")
A) Prosessoreita joilla kaikilla ytimillä yhteinen L2-välimuisti
B) 4-ydin-prosessoreita joilla kahdella ytimellä yhteinen L2-välimuisti
C) Prosessoreita, joilla kaikilla ytimillä oma L2-välimuistinsa ja kaikilla ytimillä yhteinen L3-välimuisti
D) Prosessoreita, joilla kaikilla ytimillä oma L2-välimuisti ja M kpl L3-välimuisteja siten että N ydintä käyttä samaa L3-välimuistia.
ja
täysin saman kernelin pitää toimia näillä kaikilla.
Tässä on jo ennestään ihan hirveä suo sille, että mitä strategiaa käyttiksen skedulerin kannattaa käyttää minkäkintyylisellä prosessorilla.
Se, että meillä olisi vielä ihan samanlaisia ytimiä siten että saman L3-välimuistin jakavan ydinryhmän koko muuttuisi
olisi taas huomattavasti lisää vaihtoehtoja tähän suohon.
Ja tietääkseni nykyinen cpuid-käskyn toteutus ei edes antaisi mahdollisuutta tämän tiedon välittämiseen raudalta kernelille.
Hyöty olisi olematon, potentiaaliset haitat paljon suuremmat.
Vaikka nähtäisiin vaiva sen hirveän tunnistusspagetin kirjoittamiseen ja saataisiin se prossun rakenne tunnistettua, miten valittaisiin mitä siellä "yksinäisillä ytimillä" ajetaan?
Ei käyttis tiedä etukäteen, aikooko joku säie olla raskas vai ei. Sitten kun jotain on ajettu hetken aikaa, huomataan, että se on raskas.
Tyypillisesti ne "suorituskykykriittiset säikeet" on esim. pelin päälooppisäie. Mutta siellä pelillä tyypillisesti on myös muutama muu kevyempi säie, joka kuitenkin joka frame kommunikoivat melko paljon sen päälooppisäikeen kanssa. Se pelin raskas säie halutaan laittaa samaan CCXään näiden kanssa, koska muuten kulutetaan liikaa aikaa datan odotteluun näiden välillä.
Ja käyttiksen skeduleri ei voi mitenkään järkevästi ja luotettavasti tunnistaa, mitkä säikeet kommunikoivat paljon keskenään (teoriassa siitä, miten jotain lukkoja käytetään voisi tätä päätellä, mutta käytännössä ei; Niihin lukkoihin ei haluta ylimääräistä overheadia niiden seuraamisesta tällaista varten ja niistä saatava informaatio olisi kuitenkin hyvin vajaavaista, ei esim tiedetä siirtyykö kriittisen sektion sisällä yksi tavu vai megatavuittain dataa)
Logiikka "laitetaan raskaat säikeet omaan CCXään" siis vaan hidastaisi pelejä.
