Threads (processorer)

Vad är threads för nåt? Jag har sökt på Google men jag får bara engelska resultat :/ så..

1. Vad är det?

2. Vi säger att det är 4 kärnig processor med 2threads är det 2 threads i varje kärna eller är det totalt? Samt vad är deras uppgift?

Funkar inte, står bara att det itne skapats en artikel om det ännu.

Vad är threads för nåt? Jag har sökt på Google men jag får bara engelska resultat :/ så..

1. Vad är det?

2. Vi säger att det är 4 kärnig processor med 2threads är det 2 threads i varje kärna eller är det totalt? Samt vad är deras uppgift?

Funkar inte, står bara att det itne skapats en artikel om det ännu.

TS: Nu kan jag ha väääldigt fel men som jag uppfattat det så är det simpelt förklarat ungefär som följande.
En i7a har 4 fysiska kärnor.. men med hyperthreading som den har som alternativ kan den skapa 4 stycken logiska kärnor.. så kallade threads. D.v.s det blir som den har 8 kärnor att dela upp arbetet på men det 4 extra trådarna man aktiverar är inte fysiska utan de är virtuella. 4 fysiska som är default och 4 extra logiska med HT aktiverat vilket ökar arbetspotentialen för processorn då den kan dela upp jobbet mer och på så sätt klara mer.

Detta är vad jag har för mig att det innebär, kortfattat och inte så tydligt förklarat kanske. Kan dessutom ha fel men folk som KAN kommer svara inom kort

Så fungerar inte SMT (och HT är bara Intels namn på deras SMT implementation).

CPUer med HT har verkligen två uppsättningar av CPU-register per CPU-kärna, vilket betyder att sett ur OS:ets synvinkel finns det ingen logisk skillnad mellan en CPU-tråd och en "riktig" CPU-kärna. Däremot delar de två CPU-trådarna i en CPU-kärna på nästan alla resurser. Att duplicera register-filen för varje CPU-tråd är något som alla implementationer av SMT gör.

Så vad är då poängen med SMT om allt delas, blir inte farten per tråd då halv?

I viss fall är det inte så långt från sanningen, SMT ger normalt sätt väldigt liten effekt i program som kör i princip uteslutande ur CPU-cachen. Nästan allt man gör på en "desktop-dator" har ett s.k. "working-set" (storlek på data som man aktivt jobbar på för stunden) som är mindre än CPU-cachen, spel hör definitivt till den kategorin. I dessa lägen blir den enda bonus från SMT att antalet möjliga sätt att lägga ut instruktioner som kan köras oberoende av varandra ökar, vilket gör det möjligt att öka IPC sett för en fysisk kärna, men denna ökning är relativt liten, typ 10-30%.

Då varje CPU-tråd i HT har sin egen uppsättning register, vilket då inkluderar en egen programräknare (pekare till nästa instruktion att köra) så är det fullt möjligt att båda trådarna kan avancera under samma klockcykel, d.v.s inga byten sker och OS:et är överhuvudtaget inte involverad i processen att välja vilken CPU-tråd som kör när och vilka ALU-enheter tråden får ta i anspråk en viss cykel.

Finns andra implementationer av SMT, vissa version av SPARC t.ex., där det är omöjligt att mer än en tråd avancerar sin programräknare en viss CPU-cykel. Men det är som sagt bara en implementationsdetalj som inte OSet behöver bry sig om (eller ens kan påverka).

Så vad är då poängen med SMT, framförallt på SPARC-processorn ovan? SMT är ett väldigt effektivt sätt att dölja latens.
Så vad menas med det?
I program som har ett "working-set" som är för stort att få plats i CPU-cachen så kommer minnesoperationer få vänta på att data ska hämtas/skrivas till RAM. Accesstiden mot RAM är från CPUs perspektiv väldigt lång, 100-tals cykler. Till en viss gräns kan moderna CPUer (tack vare s.k. out-of-order execution) utföra andra saker medan de väntar, men det räcker inte då man ganska snart når en punkt när man måste få resultatet från det som väntar på RAM för att kunna gå vidare.

Notera att för OS:et så är allt detta osynligt, det finns inte möjlighet för ett OS att "byta tråd" i detta läge då det som nu hänt är bara att en "mov" instruktion råkar bli väldigt dyr, tråden är inte "blockad" ur ett OS-perspektiv.

Men om CPUn har flera CPU-trådar som alla kör olika program så kan CPUn fortfarande utföra arbete så länge som någon tråd har de data den behöver. Och om man har många trådar, SPARC har i dag 8 trådar per CPU-kärna, POWER, vissa MIPS samt Xeon Phi har 4, så sjunker i.o.f.s. prestanda per CPU-tråd men det betyder också att latensen mot RAM räknat i CPU-cykler också sjunker sett ur perspektivet frå varje enskild tråd. Att gå mot RAM är därför, relativt sätt, inte lika dyrt och SMT kan i dessa fall ge nära nog lika stor effekt som en "riktig" kärna (då den ändå bara skulle få vänta på RAM om den bara hade en CPU-tråd).

Så HT/SMT är typiskt ganska meningslöst för desktop, det kan faktiskt vara rent negativt om det enda man är ute efter är låg latans. Men HT/SMT kan vara väldigt bra för vissa specifika arbetslaster.

Var vissa formuleringar som jag reagerade emot, t.ex. det finns inget koncept av en primär/sekundär tråd. Faktum är att en sådan uppdelning skulle definitivt kunna vara en fördel på desktop (och än större fördel på mobiler där CPUn är mycket klenare) då man skulle kunna köra GUI på den primära tråden och därmed slippa den nackdel SMT har med ökad latens, men alla (nuvarande) SMT-implementationer har samma prioritet på alla trådar.

Sedan i just fallet HT så körs båda trådarna verkligen samtidigt, visst blir prestanda per tråd lägre när båda trådarna används, men summan utfört arbete på två trådar blir större än när bara en tråd används. Jämför man med AMDs moduler så har ju Intel mycket högre IPC när en CPU-tråd används och när båda trådarna används så sjunker IPC/tråd mer på Intel men i genomsnitt har redan Sandy-bridge faktiskt något bättre IPC/tråd än FX-8350 när båda trådarna används (ungefär samma totala prestanda men SNB är lägre klockad).

Det finns SMT implementationer där man switchar, men den policy du beskrev där man kör till det tar stopp används så vitt jag vet inte av någon. Anledningen är med stor sannolikhet att en sådan policy skulle väldigt lätt kunna leda till helt horribel prestanda (eller till och med total utsvältning) på en tråd som ganska ofta får en cache-miss och som delar fysisk CPU med en tråd som nästan aldrig får en miss. SPARC T1-T3 byter tråd varje cykel, medan alla övriga SMT jag känner till är som Intels HT, trådar körs verkligen samtidigt i bemärkelsen att mer än en tråd kan avancera sin programräknare samma cykel (gäller till och med Atom).

Sedan tillför HT mer "rå-kraft" i de lägen det är en bra idé (och i fallet Atom så tillför HT i princip alltid runt 50% extra). En server som jobbar med ett stort "working set" kan hantera fler transaktioner per sekund, d.v.s. kapaciteten ökar. Också applikationer som använder sig mycket av SSE/AVX, även med ett litet "working set" får mer kapacitet av HT (FLOPS ökar). I fallet SSE/AVX beror det på att flaskhalsen inte alls är avkodning- och "dispatch" av instruktioner (något som delas mellan trådarna) då SSE- och framförallt AVX-instruktioner har relativt hög latens men utför också mycket. HT blir då igen effektiv p.g.a. latensen.

Sorry om det uppfattades som drygt, var inte min menig. Inget fel att göra förenklingar, kan vara rätt svårt att göra bra (tyck i alla fall jag). Är lite väl mycket nörd för att kunna se förenklingar som beskriver tekniken felaktigt.

Är det egentligen någon här som svara på den ursprungliga frågan av TS?

1. En CPU består av en eller flera "kärnor" och varje sådan kärna har en eller flera trådar. En kärna består av en rad olika funktionella enheter som kan t.ex. hämta/skriva ett tal från/till minne, kan addera/subtrahera två tal från varandra och liknande.

En CPU tråd är i sin absoluta mest nedskalade variant bara en pekare (representerat som ett tal mellan 0..2^32 alt. 0..2^64 för 32-bitars resp 64-bitars CPUer) som talar vilken den nästa instruktionen som ska köras är. En sådan instruktion skulle kunna vara "addera innehållet i minnescell X med talet 17 och skriv ner resultatet i minnescell X igen". Har din CPU två trådar finns det två sådana pekare som delar på (nästan all) de beräknings-enheter som finns i kärnan.

2. Om du har 4 kärnor med 2 trådar så menar man 2 trådar på varje kärna. En CPU-kärna utan minst en tråd skulle vara meningslös. Så i fallet 4 kärnor / 2 trådar skulle ditt operativsystem "se" totalt 8 CPU-trådar.

Läser man teknisk dokument från Intel så brukar den tala om fysiska kärnor (som i ditt exempel är 4) och logiska kärnor (som i ditt exempel då är 4*2=8).

Logiska kärnor är nog bättre då ordet "tråd" är kanske lite olyckligt valt då, som redan påpekats i här, ordet är betydligt mer välanvänt för att mena "en serie instruktioner som ditt operativsystem kan välja att köra på en lämplig logisk CPU-kärna".

Och rent krasst skulle någon som skriver operativsystem helt kunna ignorerar "fysiska kärnor" då man rent logiskt kan behandla en CPU-tråd på samma sätt oavsett om det finns en eller två sådana per CPU-kärna. Men rent praktiskt så vill man hålla isär begreppen då det i (nästan) alla fall är betydligt mer effektivt att använda en logisk kärna som inte delar fysisk kärna med någon annan aktiv logisk kärna. I.e. Windows/Linux/OSX kommer i första hand sprida ut ditt program på CPU-trådar som tillhör olika fysiska kärnor och först när alla har en tråd aktiv kommer man använda den andra CPU-tråden.

Så har du en 4 kärnors CPU med HT så kommer HT överhuvudtaget inte att används så länge som du har färre än 4 OS-trådar aktivt körande samtidigt.

Så man kan alltså säga att jag öppnar 2 internet samtidigt och då jag bara har 1 kärna med en 1 tråd så öppnar processorn 1 själv medans den andra instruktionen om att öppna den andra internet ligger i tråden? Har jag rätt?

Ungefär så ja. men en sån logisk kärna är sämre än en riktig.

Det var ju precis det jag sa. Sämre än en riktig. Hur mycket sämre har väl mycket att göra med vad man gör? i vissa saker kan det vara en stor begränsning?

Fast jag sa aldrig något om logisk och riktig tråd. jag sa logisk och riktig kärna.