Ubuntu Suomen keskustelualueet
Muut alueet => Yleistä keskustelua => Aiheen aloitti: Ganymedes - 21.01.21 - klo:20.32
-
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 (https://forum.ubuntu-fi.org/index.php?topic=56056.0)
-
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.
-
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.
-
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ä.
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ä):
cat /sys/devices/system/cpu/smt/active
Kytke pois päältä:
echo "off" | sudo tee /sys/devices/system/cpu/smt/control
Kytke takaisin päälle:
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:
7z b -mmt1
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
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ä:
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.
-
...
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ä.
-
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.
-
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.
-
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 (https://www.anandtech.com/show/16261/investigating-performance-of-multithreading-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.
-
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.
-
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öä?
-
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?
-
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ä.
-
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 :)
-
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.
-
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! ;)