Bilder av Tejas - Pentium V

[Simen1]

Pureblade: godt forklart! (Jeg leste artikkelen da den kom ut og skummet bare gjennom den nå)

 

Jeg tror flertråding (norsk for HyperThreading ) er en trend som kommer til å fortsette. SUN utvikler f.eks med 32-trådete 8-kjerners CPU'er (4 tråder per kjerne) For å minse die-size så har de heller kuttet i hvor avansert hver kjerne er og cachen. De har vist funnet ut at 32tråder/8kjerner er optimalt ytelsemessig og størrelsemessig. Fordelen med 4 tråder per kjerne er at man kan skifte tråd veldig ofte (hver tråd kommer til å stoppe opp langt oftere pga enklere design og mindre cache) Det betyr at den intense trådbyttingen langt på vei skjuler all venting på data fra minnet. Med 8 slike enkle kjerner på en chip som deler ressurser (8 FPU-pipelines, 8 ALU-pipelines etc) så kan man holde alle pipelinene i arbeid hele tiden selv om det hele tiden er mange tråder som venter på data.

 

All ventetiden skules så godt at man ikke er så avhengig av minne med lav latency, men kan nøye seg med høy båndbredde. (f.eks 4-8 kanal DDR2).

 

Til sammenlignign har dagens AthlonXP, Athlon64 og Pentium4 en ytelse på i snitt ca 2-3 ALU/FPU-operasjoner per klokkesyklus. SUN's nye chip vil altså utføre nær 8 ALU- og 8 FPU-instruksjoner samtidig for hver klokkesyklus. Med såpass mye forenklede kjerner (hver enkelt-kjerne) kan man sikkert regne med en god del høyere klokkehastighet også. Men før dere begynner å sikle og spare pengene deres: Dette er en klar server-CPU og ennå rundt 4-5 år fra lansering. *dagens antiklimax*

 

Vi får heller se på utviklingen på mer jordnære AMD/Intel CPU'er. Kanskje vi får se flertråding i K9? Det blir i hvertfall spennende å følge med i årene som kommer.

Endret 14. januar 2004 av Simen1

[Martin Lie]

Nå har det seg slik at jeg faktisk leste alt (...)

Nå som jeg så signaturen din på nytt (Knick Knack), kom jeg forresten på at jeg hadde sett den også et sted. Sjekket på nytt nå, og jaggu: Du har hentet den fra første siden i HT-artikkelen jo.

 

Simen1: *være terminologi-freak* Takk for det norske begrepet "flertråding". Men er det ikke mer korrekt å si at flertråding er norsk for SMT, og ikke HT? Det jeg tenker er at "HyperThreading" er Intels buzzword for SMT (siden "Simultaneous MultiThreading" ikke høres like kult ut, og "Hyper" generelt er i vinden). Mulig jeg tar feil her da, og at HT er et generelt begrep brukt også av andre (eks: Sun) også!?

 

Ellers: Enig i at intens trådbytting vil skjule minne-latency, men det vil jo også øke antallet context switches ("CS"), som i seg selv tar tid? Aner du/noen hvor lang tid ett CS tar, i forhold til gjennomsnittlig minne-latency?

Endret 14. januar 2004 av Pureblade

[Knick Knack]

*kremt* Mener du at hvis jeg leser alt, så skjønner jeg sammenhengen og endrer mening? Altså at konklusjonen jeg dro tidligere er feil? Det er hvertfall slik jeg forstår deg nå, men rett meg gjerne om jeg tolker deg feil.

Nei da. Det virket bare som om du ikke fant noe særlig om HT der, i følge den første posten.

 

"The fact that Intel until now has made use of hyper-threading only in its SMP Xeon line is telling. With hyper-threading's pitfalls, it's perhaps better seen as a compliment to SMP than as a replacement for it. (...) In the end, I expect SMT [HT = SMT -Pureblade] to shine mostly in SMP configurations [sMP = fler-prosessor-oppsett -Pureblade], while those who use it in a single-CPU system will see very mixed, very application-specific results."

Han mener vel at HT ikke vil gi ytelsesforbedring i systemer som har lasten på en enkelt tråd. Noe som er typisk for den programvaren som kjøres på mange singel cpu systemer. Har derfor ingen ting med samspill mellom SMP og SMT å gjøre, men samspill mellom HW og den SW som en typisk kjører. Nå blir SMT støtte mer og mer vanlig for typisk arbeidsstasjon rettet programvare, ergo vil SMT ikke lengre kun være nyttig i SMP systemer! Du er med på den? HW/HW relasjonen er ikke viktig, men det er HW/SW relasjonen.

 

Forutsetter to arkitekturer med kort og lang pipeline produsert på sammenlignbare prosesser og kjørt på sine respektive maksimum frekvenser i det følgende:

 

Lange pipelines gjør at det er plass til langt flere instruksjoner inne i pipelinen til enhver tid, samt at hver del i pipelinen tar mindre tid å utføre. Tiden det tar fra en instruksjon entrer pipelinen til den kommer ut i andre enden med et resultat er omtrent den samme uansett lengde på pipeline*, men en lang pipeline vil spytte ut flere resultater og bobler pr. tidsenhet enn en kortere pipeline (kommer ut ett resultat eller en boble pr. klokkeslag). Pipeline bobler er klokkeslag da neste resultat skulle ha kommet ut i andre enden, men av en eller annen grunn hadde ikke cpu noe å lese inn for X antall klokkeslag siden eller det har oppstått en branch miss predict. X er lengden på pipeline. Så langt skulle alt være rimelig greit!

 

Hadde det ikke vært for bobler i pipelinen så hadde det vært enkelt å se hvilken løsning som hadde vært raskest. "Megahertz is everything" hadde blitt riktig. Sånn vet vi at det ikke er. Den lengste pipelinen får alltid størst straff om vi antar at delay mot minne er den samme for begge systemene siden flere sykluser vil gå forbi uten at det blir lest inn en ny instruksjon. Her kommer HT inn i bildet. Siden en lang pipeline vil få flere bobler enn en kort ved "vanlig" single thread opperasjon så betyr det at det også er mer plass til å putte inn instruksjoner fra en annen tråd, forutsatt at denne funksjonen er implementert og at de nødvendige data er tilgjengelige i cache. Altså vil SMT favorisere lange pipelines. Q.E.D.

 

Dette ble strengt tatt forklart for Super Threading, men prinsippet blir det samme for HT, bare enda større forskjell fordi en x86 tråd har 2,5 IPC i snitt og en superscalar prosessor kan typisk legge inn max 3 IPC (NW) eller 4 IPC (Prescott).

 

*: Praktisk "bevis" for at påstanden er rimelig riktig, for de som ikke ønsker å sette seg inn i teorien.

NW: pipeline = 20 steg, "Max" frekvens = 3.2GHz T=20/3,2GHz=6,25ns

K8: pipeline = 17 (fp) steg "Max" frekvens = 2.4GHz T=17/2,4GHz=7,1ns

Altså rimelig lik tid for å komme seg gjennom en K8 og NW pipeline. Husk at K8 har forskjellig lengde på pipeline for fp og int. En må sammenligne med den lengste for at det skal gi et meningsfullt svar. Merk også at K8 og NW er produsert på forskjellige prosesser og at nivået av optimalisering vil være ulikt av forskjellige årsaker. Dette forklarer nok mesteparten av forskjellen.

 

Pureblade: CS switch blir nok skjult av dagens superskalare prosessorer. Ellers hadde HT vært vanskelig (eller umulig?). Super threading hadde fungert om CS switch skulle tatt noe tid, men ikke HT så langt jeg kan se, siden instruksjoner fra to tråder går simultant.

 

Siemen1: IA64 håndterer 5-6 IPC i dag. Og det er på en tråd! Det er ikke bra med for mye parallellitet heller siden det ikke alltid er mulig å utnytte like mange tråder som systemet kan kjøre samt at en vil bli begrenset av korrelasjon mellom trådene. Tror det er Amdahl's lov som beskriver dette.

Endret 15. januar 2004 av Knick Knack

[Simen1]

Pureblade:

Jeg slang bare ut ordet "flertråding" som litt sunn fornorsking av begrepene. Er fullt åpen for varianter av ordet og varianter av bruken av det.

 

CS er at alt må skylles ut av interne buffere (ikke L1/L2, men etter dekoderen), skylle ut registere og pipelinene. Jeg har egentlig null peiling på hvor lang tid dette tar, men kan gjette på opptil ca 15-20 CPU-klokkesykluser på P4/Opteron, men det kan sikkert gjøres mye raskere om man har større interne buffere som kan holde alle trådene samtidig (sikkert noe sånn SUN har tenkt på). Latency til minnet er normalt på rundt 100 ns. (kanskje ned mot rundt 60-70 for de raskeste A64'ene, rundt 90-110 for P4, og 120-130 for Athlon XP)

 

Knick Knack:

Jeg er enig på at IA64 er imponerende på enkelttråder, men jeg tenkte nå mer på vanlige forbruker CPU'er. Den SUN-CPU'en jeg pratet om er jo heller ikke noen normal sak, men var nå mest for å illustrere at man kan utnytte HT på helt andre måter inn i dag og at HT ikke er i nærheten av å være optimalisert sammen med CPU-størrelse etc på dagens CPU'er. F.eks skal vi ikke se bort i fra at IA64 får 2- eller 4-tråds HT-støtte (om den ikke allerede har det) Per i dag er vel die-size en viktigere prioritet enn HT.

[Knick Knack]

Deerfield er mindre enn Athlon64! 180mm2 vs 193mm2 og det med 0.5MB mer cache på Deerfield. Tror heller ikke HT vil gi IA64 særlig forbedring siden den er spesielt designet med tanke på å skjule delay mot minne og redusere pipeline bobler.

[[Protus]]

Pureblade: godt forklart! (Jeg leste artikkelen da den kom ut og skummet bare gjennom den nå)

 

Jeg tror flertråding (norsk for HyperThreading ) er en trend som kommer til å fortsette. SUN utvikler f.eks med 32-trådete 8-kjerners CPU'er (4 tråder per kjerne) For å minse die-size så har de heller kuttet i hvor avansert hver kjerne er og cachen. De har vist funnet ut at 32tråder/8kjerner er optimalt ytelsemessig og størrelsemessig. Fordelen med 4 tråder per kjerne er at man kan skifte tråd veldig ofte (hver tråd kommer til å stoppe opp langt oftere pga enklere design og mindre cache) Det betyr at den intense trådbyttingen langt på vei skjuler all venting på data fra minnet. Med 8 slike enkle kjerner på en chip som deler ressurser (8 FPU-pipelines, 8 ALU-pipelines etc) så kan man holde alle pipelinene i arbeid hele tiden selv om det hele tiden er mange tråder som venter på data.

 

All ventetiden skules så godt at man ikke er så avhengig av minne med lav latency, men kan nøye seg med høy båndbredde. (f.eks 4-8 kanal DDR2).

 

Til sammenlignign har dagens AthlonXP, Athlon64 og Pentium4 en ytelse på i snitt ca 2-3 ALU/FPU-operasjoner per klokkesyklus. SUN's nye chip vil altså utføre nær 8 ALU- og 8 FPU-instruksjoner samtidig for hver klokkesyklus. Med såpass mye forenklede kjerner (hver enkelt-kjerne) kan man sikkert regne med en god del høyere klokkehastighet også. Men før dere begynner å sikle og spare pengene deres: Dette er en klar server-CPU og ennå rundt 4-5 år fra lansering. *dagens antiklimax*

 

Vi får heller se på utviklingen på mer jordnære AMD/Intel CPU'er. Kanskje vi får se flertråding i K9? Det blir i hvertfall spennende å følge med i årene som kommer.

Finnes det andre teknologier som ligner Ht ? Kan du navnet på noen ?

Kan du gi meg link til info ? Er interessert.

[Simen1]

Siemen1: IA64 håndterer 5-6 IPC i dag. Og det er på en tråd! Det er ikke bra med for mye parallellitet heller siden det ikke alltid er mulig å utnytte like mange tråder som systemet kan kjøre samt at en vil bli begrenset av korrelasjon mellom trådene. Tror det er Amdahl's lov som beskriver dette.

Jeg vet ikke om jeg skal oppfatte dette som at du ikke tror flertråding er noe for IA64, men jeg kom i hvertfall over denne plansjen i dag som sier noe om satsing på flertråding (DualCore for å være presis) på IA64: (klikk på bildet for å følge linken)

Endret 16. januar 2004 av Simen1

[Simen1]

<dobbelpost>

Endret 16. januar 2004 av Simen1

[Knick Knack]

Jeg vet ikke om jeg skal oppfatte dette som at du ikke tror flertråding er noe for IA64, men jeg kom i hvertfall over denne plansjen i dag som sier noe om satsing på flertråding (DualCore for å være presis) på IA64: (klikk på bildet for å følge linken)

 

Joda jeg har tro på flertråding for IA64, men da som dual/multi core. Har ikke tro på at SMT/HT vil kunne tilføre så veldig mye til IA64. Noe selvsagt, men ikke like mye som for en superscalar prosessor. Dette bør ikke tolkes som en svakhet, men heller som en styrke at SMT ikke vil kunne tilføre IA64 så mye. Sier bare noe om effektiviteten til IA64.