Hypersäikeistyksen (HT/SMT) vaikutus suorituskykyyn

[Ganymedes]

Kuorman jako rinnakkaiseksi on mielenkiintoinen aihe.

Jos mietit ihan teoreettisesti muutaman termin yhteenlaskua, huomaat että sen laskeminen rinnakkain vie enemmän aikaa kuin yhdessä pötkössä laskeminen. Tämä johtuu siitä, jos annat jokaiselle askelmalle saman pituuden, että jakaminen, yhdistäminen ja sen jälkeinen yhdistelmälasku, vievät enemmän askelmia kokonaiskuvassa kuin muuten kuluisi.

Se, että Linux sitä ja Linux tätä, on aika paljon eri asia kuin yksittäinen sovellus, koska käyttöympäristössä pyörii aika monta eri prosessia samaan aikaan, varsinkin jos käyttö on intensiivistä. Toimintojen vasteaikojen vaatimukset ovat myös rinnakkaisia.

Sovelluksissa rinnakkaisuudesta on hyötyä silloin kuin laskenta-ajat ovat pitkiä tai laskussa on aidosti rinnakkaisia vaiheita, joiden jakaminen ja yhdistäminen koodissa ovat helppoja tehdä. Tällaisia ovat esim. kuva- ja videorenderoinnit. Aiemmin, kun useampia ytimiä tai prosessoreja ei ollut, käytettiin useampaa konetta, jotka voitiin pääkoneen ohjaamana valjastaa laskemaan esim. renderöinnissä kuvan eri alueita tai tuottamaan videon eri frameja. Tällaista tehdään vieläkin, mutta mittakaava on muuttunut: esim. SETI-projekti toimi näin ja muitakin on.

Seuraavaksi asia, mihin toivon kommentointeja tietäväisiltä, joita täältä epäilemättä löytyy. Olen saanut opetusta, että yleisesti ottaen työaseman säikeistäminen on vain hidastavaa, vaikka se onkin BIOS-asetuksena oletus. Nimittäin yhden coren suorituskyky jaetaan kahtia kahdelle säikeelle (thread). Coreja on i7:ssä tyypillisesti 4 eli säikeitä on yhteensä 8. Missään tyypillisessä käyttötilanteessa rinnakkaisesta laskennasta ei ole hyötyä - siis hyötyä, koska näin intensiivistä kuormitusta ei saa aikaiseksi edes yhdellä virtuaalikoneella ja useampaa virtuaalikonetta ei oikeastaan pysty interaktiivisesti käyttämään samanaikaisesti. Koneen suorituskyky heikkenee, koska tässä tilanteessa core toimii vain puolella teholla eikä tällainen 8:n säikeen rinnakkaisuus tyypillisesti nopeuta mitään, 4:n coren rinnakkaisuushan on joka tapauksessa käytössä. Poikkeuksena tietysti, tyypillisesti taustalla pyörivät sovellukset jotka ovat säikeistettyjä, esim. erilaiset analyysiohjelmat, jotka saattavat hyötyä rinnakkaisuudesta - tosin sekin pitäisi erikseen todistaa, että ne hyötyvät rinnakkaisuudesta. Yksinkertainen ohjelmahan ei hyödy mitään rinnakkaisuudesta, koska kaikki pitää laskea joka tapauksessa ennenkuin kokonaisuus on valmis - tällöin olisi nopeampaa laskea yhdellä corella joka toimii kaksinkertaisella vauhdilla.

Servereillä tilanne on toki eri, koska käyttäjät ovat keskenään rinnakkaisia jo luonnostaan ja heitä pitää palvella rinnakkaisesti.

Liekö näin yksinkertaista?

Muokkaus (Tomin): Tämä aihe on jaettu keskustelusta Kuorman jako monelle ytimelle

[nm]

Seuraavaksi asia, mihin toivon kommentointeja tietäväisiltä, joita täältä epäilemättä löytyy. Olen saanut opetusta, että yleisesti ottaen työaseman säikeistäminen on vain hidastavaa, vaikka se onkin BIOS-asetuksena oletus. Nimittäin yhden coren suorituskyky jaetaan kahtia kahdelle säikeelle (thread). Coreja on i7:ssä tyypillisesti 4 eli säikeitä on yhteensä 8. Missään tyypillisessä käyttötilanteessa rinnakkaisesta laskennasta ei ole hyötyä

Tässä puhut suorittimien tarjoamasta hypersäikeistyksestä (HT tai SMT). Se ei yleensä hidasta yhdessä säikeessä suoritettavaa laskentaa juuri lainkaan, joskin tietyissä erikoistapauksissa voidaan saavuttaa pieni etu kytkemällä hypersäikeistys pois päältä. Se onnistuu Linuxissa tarvittaessa vaikka lennossa.

Lähes kaikessa tavanomaisessa käytössä hypersäikeistys kuitenkin parantaa suorituskykyä. Mm. selaimet suorittavat eri välilehdet rinnakkain eri prosesseissa tai säikeissä, mikä onkin mukavaa ottaen huomioon nykyisten sivustojen raskaan toteutuksen.

[Ganymedes]

Tässä puhut suorittimien tarjoamasta hypersäikeistyksestä (HT tai SMT). Se ei yleensä hidasta yhdessä säikeessä suoritettavaa laskentaa juuri lainkaan, joskin tietyissä erikoistapauksissa voidaan saavuttaa pieni etu kytkemällä hypersäikeistys pois päältä. Se onnistuu Linuxissa tarvittaessa vaikka lennossa.

Lähes kaikessa tavanomaisessa käytössä hypersäikeistys kuitenkin parantaa suorituskykyä. Mm. selaimet suorittavat eri välilehdet rinnakkain eri prosesseissa tai säikeissä, mikä onkin mukavaa ottaen huomioon nykyisten sivustojen raskaan toteutuksen.

Tarkoitin i7:n BIOS-asetusta Hyper threading ON/OFF .

Siis väite siitä, että yhden coren suorituskyky puolittuu jos asetus on ON - ei siis pidä paikkansa? Väite esitettiin tarkemmin ottaen serverille - en tiedä prosessorin tarkkaa tyyppiä, mutta luultavasti joku (hyvälaatuinen) Xeon.

Mielestäni tavanomaisessa käytössä hyvän koneen ei tarvitse olla äärimmäisen nopea - ei niillä WEB-sivuilla ole mihinkään kiire eikä suorituskyky johdu monestikaan prosessorin nopeudesta. Viihdekäytön vaatimukset ovat aivan oma lukunsa.

Teknisessä ammattikäytössä, uudet (kalliit) ohjelmat ovat aina olleet suorituskyvyn kanssa kuilun partaalla. Huono suorituskyky on harmillista kahta eri kautta: 1. Hidastelu haittaa interaktiivista työskentelyä, 2. Varsinainen odottelu tarkoittaa huonoa tehokkuutta työssä. Kyse on siis täyspäivätoimisesta työstä, jossa hiiren napautuksen jälkeen pitäisi tapahtua jotakin mahdollisimman nopeasti. Tekniset laskelmat ovat oma juttunsa, monet niistä ovat vanhakantaisia eivätkä ole säikeistettyjä. Niissä 25-50% säästö laskenta-ajassa on aina hyvä.

Enkä tarkoita sitä, ettäkö yhdellä corella toimittaisiin - onhan niitä 4 tyypillisesti i7:ssä joka tapauksessa. Interaktiivisessa käytössä on kuitenkin aina useampia prosesseja käynnissä, mutta ei välttämättä oleellisesti kahta enempää (itse sovellus ja grafiikka), jotka veisivät CPU:ta merkittävästi. Teknisen laskennan aikana työasemalla tehdään jotakin muuta, mutta 3 corea on jäljellä kaikkeen muuhun.

Tämä on siis tausta kysymykselle.

[nm]

Tässä puhut suorittimien tarjoamasta hypersäikeistyksestä (HT tai SMT). Se ei yleensä hidasta yhdessä säikeessä suoritettavaa laskentaa juuri lainkaan, joskin tietyissä erikoistapauksissa voidaan saavuttaa pieni etu kytkemällä hypersäikeistys pois päältä. Se onnistuu Linuxissa tarvittaessa vaikka lennossa.

Lähes kaikessa tavanomaisessa käytössä hypersäikeistys kuitenkin parantaa suorituskykyä. Mm. selaimet suorittavat eri välilehdet rinnakkain eri prosesseissa tai säikeissä, mikä onkin mukavaa ottaen huomioon nykyisten sivustojen raskaan toteutuksen.

Tarkoitin i7:n BIOS-asetusta Hyper threading ON/OFF .

Juu. Kuten sanottu, prosessorin HT/SMT-ominaisuus on kuitenkin kytkettävissä pois käytöstä ja takaisin päälle myös käyttöjärjestelmän suosituksen aikana, jolloin suorituskykyä voi verrata helposti. Tällöin tosin virtuaaliset HT-ytimet näkyvät edelleen /proc/cpuinfo-tiedostossa ja ohjelmien listauksissa, mutta ne eivät ole käytössä.

Koodia: [Valitse]

What: /sys/devices/system/cpu/smt
/sys/devices/system/cpu/smt/active
/sys/devices/system/cpu/smt/control
Date: June 2018
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Control Symetric Multi Threading (SMT)

active:  Tells whether SMT is active (enabled and siblings online)

control: Read/write interface to control SMT. Possible
values:

================ =========================================
"on"   SMT is enabled
"off"   SMT is disabled
"forceoff"   SMT is force disabled. Cannot be changed.
"notsupported"   SMT is not supported by the CPU
"notimplemented" SMT runtime toggling is not
  implemented for the architecture
================ =========================================

If control status is "forceoff" or "notsupported" writes
are rejected.
Tarkista hypersäikeistyksen tila (1=päällä):

Koodia: [Valitse]

cat /sys/devices/system/cpu/smt/active
Kytke pois päältä:

Koodia: [Valitse]

echo "off" | sudo tee /sys/devices/system/cpu/smt/control
Kytke takaisin päälle:

Koodia: [Valitse]

echo "on" | sudo tee /sys/devices/system/cpu/smt/control

Siis väite siitä, että yhden coren suorituskyky puolittuu jos asetus on ON - ei siis pidä paikkansa? Väite esitettiin tarkemmin ottaen serverille - en tiedä prosessorin tarkkaa tyyppiä, mutta luultavasti joku (hyvälaatuinen) Xeon.

Ei pidä paikkaansa.

Tässä 7zipin (Ubuntun paketti p7zip-full) yhden säikeen rasitustesti, kun hypersäikeistys on päällä i7 6700K:lla:

Koodia: [Valitse]

7z b -mmt1

Koodia: [Valitse]

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=fi_FI.UTF-8,Utf16=on,HugeFiles=on,64 bits,8 CPUs Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (506E3),ASM,AES-NI)

Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (506E3)
CPU Freq:  3049  3368  4196  4192  4188  4198  4205  4201  4206

RAM size:   15974 MB,  # CPU hardware threads:   8
RAM usage:    435 MB,  # Benchmark threads:      1

Koodia: [Valitse]

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:       5207   100   5075   5066  |      49612   100   4242   4236
23:       4864   100   4963   4956  |      49602   100   4294   4294
24:       4623   100   4971   4971  |      49040   100   4305   4305
25:       4451   100   5082   5082  |      48332   100   4302   4302
----------------------------------  | ------------------------------
Avr:             100   5023   5019  |              100   4286   4284
Tot:             100   4654   4651

Saman testin lopputulos, kun hypersäikeistys on pois päältä:

Koodia: [Valitse]

Avr:             100   5071   5065  |              100   4293   4288
Tot:             100   4682   4676

7zip oli siis yhdellä säikeellä alle prosentin hitaampi, kun hypersäikeistys oli päällä.

Kokeilin myös neljällä ja kahdeksalla 7zip-säikeellä. Neljällä säikeellä ero oli odotetusti hyvin pieni, mutta kahdeksalla säikeellä hypersäikeistys suoriutui tehtävästä 30 prosenttia nopeammin. 30%:n nopeusetu on yleensäkin validi hihavakio Intelin ja Amd:n HT:lle/SMT:lle silloin, kun kuorma saturoi kaikki HT-ytimet.

[Ganymedes]

...
7zip oli siis yhdellä säikeellä alle prosentin hitaampi, kun hypersäikeistys oli päällä.

Kokeilin myös neljällä ja kahdeksalla 7zip-säikeellä. Neljällä säikeellä ero oli odotetusti hyvin pieni, mutta kahdeksalla säikeellä hypersäikeistys suoriutui tehtävästä 30 prosenttia nopeammin. 30%:n nopeusetu on yleensäkin validi hihavakio Intelin ja Amd:n HT:lle/SMT:lle silloin, kun kuorma saturoi kaikki HT-ytimet.

Kiitokset testauksesta!

Testasin vielä lisää ja homma muuttui mielenkiintoiseksi - tai riippuu mitä tekee ...

Aluksi: Muutokset olivat ainoastaan BIOS-muutoksia. Sekä Ubuntulla että Windowsilla, asianomaiset monitorit näyttivät kaikkien säikeiden tilanteen ihan asiallisesti (System monitor ja Task manager). Zipattava tiedosto oli Ubuntu Studio 20.04.1 - 3.7 GB. Windows-kone ja Ubuntu-kone ovat periaatteessa identtisiä.

i7-koneessa oli 4 corea ja hyper-threadingin kanssa 8 rinnakkaista threadia ajamaan sovelluksia. Sitä tarkoittavat luvut 8 ja 4 jatkossa.


1.
Testasin samat asiat kuin sinä, Ubuntu 20.04.1, i7-kone ja Pzip -ohjelma pakettivarastosta.

- 8 säiettä versus 4 säiettä, 4:n säikeen ajan piteneminen oli +28 %
- tämä oli siis sama tulos kuin sinulla

Tämä ei kuitenkaan tyydyttänyt, koska kyseessä on hyvin toimiva, säikeistetty sovellus. Sellaisesta ei ollut kysymys.

2.
Testasin Windows 10:llä (1909) käyttäen "Send to compressed file" -funktionaalisuutta

- tämä ei ole säikeistetty
- 8 säiettä versus 4 säiettä - ei suorituskyky eroa

Tähän vielä se selitykseksi (muille lukijoille), että tokihan kaikki säikeet ovat käytössä. Näin Windows on toiminut ensimmäisestä Windows 10 ja tuplaprosessorikoneista lähtien. Ne vaan eivät toimi samalla prosessilla samanaikaisesti ilman säikeistettyä sovellusta.

Eli hyper-threadingin pois ottamien ei nopeuttanut yhtään.


3.
Testasin 7zip-32-bit ohjelmistolla, koska se on verrannollinen Ubuntulla käytettyyn softaan. Tämäkin on kuitenkin hyvin säikeistetty ohjelma.

- ajan kasvu 4-säikeellä versus 8-säikeellä oli 19%

7zip-ohjelmalla säikeistyksen parannus ei siis ollut yhtä hyvä kuin Ubuntulla (28% versus 19%)


TÄMÄKÄÄN ei vielä tyydyttänyt, koska todellinen tilanne, josta kerroin, liittyy teknisiin softiin. Ne eivät suinkaan ole säikeistettyjä eivätkä edes 64-bittisiä. Windows-maailmassa 64-bittisyys on verrattain uusi ilmiö. Teknisten ohjelmien käyttöikä on varsin pitkä eikä niitä ole useinkaan modifioitu 64-bittiseen maailmaan. Jotkut firmat käyttivät jopa 32-bittistä Windows 7:aa, koska heillä oli vielä omia softia käytössään jotka olivat 16-bittisiä. Tämä Windows-maailman vanhakantaisuus oli perussyy sille, että siirryin vaativammassa ammattikäytössä, virtualisoinnissa käyttämään Ubuntua, 15 vuotta sitten - tottakai VMware on ollut pitkään 64-bittinen. Windows XP oli hirvittävän huono tässä asiassa, monestakin syystä johtuen.

SITEN halusin testata säikeistämättömällä 32-bittisellä softalla.

4.
Etsin arkistoista WinZip version 9, vuodelta 2014, joka suostui vielä asentumaan Windows 10:een.

- 8-säikeellä aikaa kului 20% enemmän kuin 4-säikeellä

Eli hyper-threadin hidasti


YHTEENVETO:

Vanhakantaisilla 32-bit softilla, hyper threadingin hidastava vaikutus näyttäisi pitävän paikkansa. Tällaisten softien suorituskyky voi myös olla tärkeää.

Ero ei kuitenkaan ole suuri ja hyvin säikeistetyillä softilla ja useampia softia samanaikaisesti käyttäen, tilanne voi muuttua päinvastaiseksi. Mikäli 4 rinnakkaista corea ei riitä, on hyper-threadingin päälläpito aina parannus.  Kokonaisuudessaan hyper-threadin on tuskin milloinkaan oleellinen huononnus.

Alkuperäinen väite esitettiin MS SQL Server -koneelle, jossa kyseinen väite tuskin pitää paikkansa. SQL Server on 64-bittinen ja oletettavasti säikeistetty. Ainakaan nämä testit eivät anna aihetta sellaista olettaa, koska tällaisessa tapauksessa suorituskyky on oletettavasti 8 säikeellä sama tai parempi kuin 4 säikeellä.

[_Pete_]

Asiasta on tehty ja julkaistu virallisempiakin tutkimuksi, esim.

https://www.nas.nasa.gov/assets/pdf/papers/saini_s_impact_hyper_threading_2011.pdf


Win vs Linux vertailut vähän huonoja koska yleensä win jutuissa virustutkat sotkee kuviota aika paljon. Jopa tämmöisissä
missä kysessä melko puhtaasti cpu intessiivisestä toiminnasta.

[Ganymedes]

Asiasta on tehty ja julkaistu virallisempiakin tutkimuksi, esim.

https://www.nas.nasa.gov/assets/pdf/papers/saini_s_impact_hyper_threading_2011.pdf


Win vs Linux vertailut vähän huonoja koska yleensä win jutuissa virustutkat sotkee kuviota aika paljon. Jopa tämmöisissä
missä kysessä melko puhtaasti cpu intessiivisestä toiminnasta.

Kiitos linkistä, mielenkiintoista! Näköjään asia on askarrattanut muitakin. Teoriaa on siinä selvitytty varsin laajasti.

Nämä Nasan supertietokonetestit kymmenillä tai jopa sadoilla ytimillä kääntyvät kuitenkin huonosti 200 euron (aikoinaan maksoi tämän verran) 4-ytimiselle i7-prosessorille ja tavanomaiselle käyttöjärjestelmälle.

Testini eivät olleet sinänsä Linuxin ja Windowsin vertailua - eihän ohjelmatkaan olleet saman tahon luomia, jos sekään mitään automaattisesti todistaisi. Windows-testit ajan kuitenkin aina itse asentamilla puhtailla versioilla, Windows siten kuin Microsoft sen jakelee, eikä siinä siten ole "korporaatio-moskaa tai päivityspuutteita" eikä omia virityksiä eikä vuosien muita ohjelmalatauksia ja poistoja. Eikä tietenkään ole mikään 8-version päivitys vaan puhdas asennus. Virusasetukset olivat Microsoftin oletukset.

Sanoisin, että oma testini, joka on periaatteessa sama kuin nm:n lausunto, osoittaa että hyper-threadingin poisotto ei kannata. Ainoastaan vanhakantaisella (mitä se nyt tarkemmin tarkoittaakaan), 32-bit, säikeistämättömällä sovelluksella, syntyy ehkä 20%:n hyöty ilman hyper-threadingiä, mutta kaikissa muissa tapauksissa hyper-threading on hyödyllinen tai ei ainakaan hidasta missään tilanteessa.

... en sinänsä epäile, etteikö voisi löytyä sovelluksia jotka käyttäytyvät hivenen toisinkin, mutta tällöin mennään oletettavasti ylläesitettyihin NASAn kuvailemiin teorioihin, jotta niitä käytöksiä voi ymmärtää ... Käyttämäni prosessorihan on vanha, noin 9 vuotta vanha - tälläkin voi olla oma merkityksensä, jota en pysty spekuloimaan ainakaan vertailutilanteessa - muuten, uudet tuskin ovat huonompia säikeistystilanteessa.

[Tomin]

Onhan tässä sekin, että nuo uudemmat prosessoriytimet ovat entistä "leveämpiä" eli niissä on enemmän suoritusyksiköjä, joille sitä konekielistä koodia levittää suoritettavaksi rinnakkain saman ytimen sisällä. Tällöin SMT:stä on enemmän hyötyä, koska sillä koodilla on yleensä rajallinen kyky rinnakkaistua ja niitä rinnakkaisia yksiköitä voidaan hyödyntää paremmin toisistaan riippumattomien prosessien kesken.

Anandtech teki SMT:n hyödyistä ja haitoista Zen 3:lla kirjoituksen joku aika sitten: Investigating Performance of Multi-Threading on Zen 3 and AMD Ryzen 5000. Lopputulos oli se ettei SMT:ä ole syytä ottaa pois päältä.

Voisi olla aika jaa tämä aihe kahtia, kun keskustelu on siirtynyt uusille urille.

[kaulahuivi]

Ketjun aloittaja on oikeassa. Asia on juuri noin.  Koko ohjelmointi pitää miettiä uusiksi ennen kuin näistä ytimistä ja säikeistä saadaan kunnon hyöty irti, mutta kiva kehitellä kaikkea ja markkinoida sen varjolla vaikka mitä. Suuri yleisö uskoo ihan mitä vaan.

[_Pete_]

Ketjun aloittaja on oikeassa. Asia on juuri noin.  Koko ohjelmointi pitää miettiä uusiksi ennen kuin näistä ytimistä ja säikeistä saadaan kunnon hyöty irti, mutta kiva kehitellä kaikkea ja markkinoida sen varjolla vaikka mitä. Suuri yleisö uskoo ihan mitä vaan.

Mitä "mitä vaan" nyt on markkinoitu ja suuri yleisö on uskonut? Oletko osa suurta yleisiöä?

[Ganymedes]

Eikös tämä nyt ole itsestään selvää?

"Mitä vaan" tarkoittaa yleistä hypetystä. Sen määrähän on kasvanut vuosikymmen vuosikymmeneltä, kun markkinoijien taidot ovat kasvaneet.

"Suuri yleisö" - tunnetusti suuri osa ihmisistä lankeaa hypeen, vähäksi aikaa. Tähän liittyy varsin oikeaan osunut sanonta: "Voit myydä mitä vain 90%:lle ihmisistä hetken aikaa ja 10%:lle kaiken aikaa."

"Oletko osa suurta yleisiöä?" - miksi kirjoittaja tuijottaisi vain omaan napaansa ja puhuisi ainoastaan omista asioistaan? Eikö yleissivistykseen kuulu se, että osaa yleistää ja keskustella muistakin kuin itsestään?

[_Pete_]

Eikös tämä nyt ole itsestään selvää?

Ei, siksipä juuri kysyin.

Lähinnä siksi että oletin tämän nyt liittyvän ketjun aiheeseen ja suhteellisen tarkkaan alaa seuranneen useamman kymmenen vuoden niin en kyllä itse ole huomannut mitään tähän liittyvää markkinointi hypetystä.

[Ganymedes]

Eikös tämä nyt ole itsestään selvää?

Ei, siksipä juuri kysyin.

Lähinnä siksi että oletin tämän nyt liittyvän ketjun aiheeseen ja suhteellisen tarkkaan alaa seuranneen useamman kymmenen vuoden niin en kyllä itse ole huomannut mitään tähän liittyvää markkinointi hypetystä.

Yep, en ole minäkään, mutta en nyt juuri tätä asiaa ole erityisesti seurannut. Varmaan ihmisten puheissa on perusteettomia odotuksia, mutta sehän on eri. Itse termi tietysti on kaikkien hypetysten äiti: "hyper-threading" ... mutta eihän nimi itse asiaa pahenna 

[_Pete_]

Yep, en ole minäkään, mutta en nyt juuri tätä asiaa ole erityisesti seurannut. Varmaan ihmisten puheissa on perusteettomia odotuksia, mutta sehän on eri. Itse termi tietysti on kaikkien hypetysten äiti: "hyper-threading" ... mutta eihän nimi itse asiaa pahenna 

Ehkä se on selkokielisempi kuin super-scaalari arkkitehtuuriin perustuva cpu op code pipeline hyödyntäminen threadukseen.

[Ganymedes]

Yep, en ole minäkään, mutta en nyt juuri tätä asiaa ole erityisesti seurannut. Varmaan ihmisten puheissa on perusteettomia odotuksia, mutta sehän on eri. Itse termi tietysti on kaikkien hypetysten äiti: "hyper-threading" ... mutta eihän nimi itse asiaa pahenna 

Ehkä se on selkokielisempi kuin super-scaalari arkkitehtuuriin perustuva cpu op code pipeline hyödyntäminen threadukseen.

Point taken!