mboost-dp1
Intel
Og spild ikke tiden med videoen. Den er dødkedelig og fyldt med marketing-crap.
Det eneste man ser er task manager med 128 cpu-grafer. Weee.
Det eneste man ser er task manager med 128 cpu-grafer. Weee.
"Sammen med IBM kunne Intel fremvise en 8-socket server, der på den måde indeholder 64 fysiske kerner, som kan håndtere 128 tråde, hvilket de har optaget en video af."
Samtidig er det også IBM der samarbejder med AMD om at udvikle produktionsmetoder til at minimere størrelsen på deres cpu arkitektur. Det er bl.a. IBM der står bag udviklingen af Cell teknologien til PS3, de leverer PowerPC arkitekturen til XB 360 og til Wii...........
OT
Sweet. Det bliver fedt når 8 kerne cpu'erne kommer til desktop markedet :D
Samtidig er det også IBM der samarbejder med AMD om at udvikle produktionsmetoder til at minimere størrelsen på deres cpu arkitektur. Det er bl.a. IBM der står bag udviklingen af Cell teknologien til PS3, de leverer PowerPC arkitekturen til XB 360 og til Wii...........
OT
Sweet. Det bliver fedt når 8 kerne cpu'erne kommer til desktop markedet :D
Da der er tale om Nehalem-arkitekturen understøttes der hyperthreading, hvilket vil sige, at den kan håndtere op til 16 tråde samtidigt
....
Sammen med IBM kunne Intel fremvise en 8-socket server, der på den måde indeholder 64 fysiske kerner, som kan håndtere 128 tråde
Det er altså ikke korrekt.
Hyperthreading øger ikke antallet af tråde der kan processeres samtidigt - det gør det billigere at foretage et context switch imellem 2 tråde, men der er altså stadig kun 8 execution units i en 8-kerne processor med HT, ikke 16, selvom HT granted kan få det til at _se ud_ som om det dobbelte antal tråde kan afvikles samtidigt (hvis man f.eks. kigger i task manageren i Windows).
Måske lidt flueknepperi, men HT er altså ikke den hellige gral - i mange tilfælde resulterer det endda i forringet performance.
#8: Wikipedia siger nøjagtig det samme som jeg gør.
Bemærk:
Det betyder for alle praktiske formål at det ikke kan lade sig gøre at afvikle 2 tråde simultant - ihvertfald ikke ægte simultant. Det HT sætter processoren istand til er at lagre en ekstra trådcontext i CPU'en, som den kan skifte meget hurtigere til og dermed kommer det til at virke som om de afvikles "samtidigt", men den pågældende execution unit afvikler altså stadig kun 1 instruktion ad gangen og de 2 tråde kan dermed aldrig komme til at afvikle instruktioner i ægte parallel tilstand, sådan som 2 kerner er istand til.
Bemærk:
This means that only one processor is physically present but the operating system sees two virtual processors, and shares the workload between them.
....
Hyper-threading works by duplicating certain sections of the processor—those that store the architectural state—but not duplicating the main execution resources
Det betyder for alle praktiske formål at det ikke kan lade sig gøre at afvikle 2 tråde simultant - ihvertfald ikke ægte simultant. Det HT sætter processoren istand til er at lagre en ekstra trådcontext i CPU'en, som den kan skifte meget hurtigere til og dermed kommer det til at virke som om de afvikles "samtidigt", men den pågældende execution unit afvikler altså stadig kun 1 instruktion ad gangen og de 2 tråde kan dermed aldrig komme til at afvikle instruktioner i ægte parallel tilstand, sådan som 2 kerner er istand til.
#10 Det er ikke helt rigtigt.
Ideen med HT er at køre to tråde "simultant" på en processor, ved at danne to køer af instruktioner. Der tages så en instruktion fra hver kø ad gangen, og dermed kører de to processer samtidigt (interleaved).
Fordelen ved dette er, at hvis den ene proces står og venter på et svar fra en multiplikationsenhed el.lign. så tager processoren bare ekstra mange instruktioner fra den anden kø, og dermed får man bedre utilization af processorens beregningsenheder. Yderligere kan processoren afvikle flere instruktioner samtidigt. Hvis den ene proces er igang med en masse additioner, så kan processoren afvikle instruktioner fra den anden proces, hvis den anden process ønsker at benytte andre beregningsenheder end den første.
Altså kører to processer enten simultant, eller interleaved på instruktionsniveau, hvilket i praksis betyder simultant.
Dette kræver naturligvist at man kan lave instantane kontekst-skift, hvilket kræver duplikering af alle "architectural state holding registers" som beskrevet.
Ideen med HT er at køre to tråde "simultant" på en processor, ved at danne to køer af instruktioner. Der tages så en instruktion fra hver kø ad gangen, og dermed kører de to processer samtidigt (interleaved).
Fordelen ved dette er, at hvis den ene proces står og venter på et svar fra en multiplikationsenhed el.lign. så tager processoren bare ekstra mange instruktioner fra den anden kø, og dermed får man bedre utilization af processorens beregningsenheder. Yderligere kan processoren afvikle flere instruktioner samtidigt. Hvis den ene proces er igang med en masse additioner, så kan processoren afvikle instruktioner fra den anden proces, hvis den anden process ønsker at benytte andre beregningsenheder end den første.
Altså kører to processer enten simultant, eller interleaved på instruktionsniveau, hvilket i praksis betyder simultant.
Dette kræver naturligvist at man kan lave instantane kontekst-skift, hvilket kræver duplikering af alle "architectural state holding registers" som beskrevet.
#11 eller help simpelt sagt: at to tråde deler en execution pipeline.
#13 jeg tror ikke den fes ind endnu, skal vi prøve igen?
Oh well here goes:
En kerne har typisk flere units på sig, det kan være en ALU til fixed point aritmetik og en til floating point aritmetik. Forestil dig nu at der er to tråde der deles om en pipeline. Den ene benytter sig kun af fixed point, og den anden kun af floating point. Kernen er så heldig at ha' HT, så den deler dem op og kører samtidigt på hver sin enhed. Det er satme smart. ;)
#13 din tur næste gang ;)
Oh well here goes:
En kerne har typisk flere units på sig, det kan være en ALU til fixed point aritmetik og en til floating point aritmetik. Forestil dig nu at der er to tråde der deles om en pipeline. Den ene benytter sig kun af fixed point, og den anden kun af floating point. Kernen er så heldig at ha' HT, så den deler dem op og kører samtidigt på hver sin enhed. Det er satme smart. ;)
#13 din tur næste gang ;)
#15
Har du nogensinde udviklet paralle systemer, ved du hvad compare exchange instruktionen gør? eller hvad cache coherency er?
HT giver ikke noget der tilnærmelsesvist er sammenligneligt med en ekstra kerne og afvikling af instruktioner i parallel mode med FPU og ALU er vist ude i det ret teoretiske.
En del systemer som f.eks. SQL Server performer rent faktisk dårligere med HT slået til.
Og, #11, det her fantiske ord "interleaved" betyder jo ligepræcis det modsatte af parallel - en dansk oversættelse af interleaved er skiftevis
Har du nogensinde udviklet paralle systemer, ved du hvad compare exchange instruktionen gør? eller hvad cache coherency er?
HT giver ikke noget der tilnærmelsesvist er sammenligneligt med en ekstra kerne og afvikling af instruktioner i parallel mode med FPU og ALU er vist ude i det ret teoretiske.
En del systemer som f.eks. SQL Server performer rent faktisk dårligere med HT slået til.
Og, #11, det her fantiske ord "interleaved" betyder jo ligepræcis det modsatte af parallel - en dansk oversættelse af interleaved er skiftevis
#16, nu er argumentet ikke om det giver en ydelses forbedring, kun om der på det logiske plan kan udføres to instruktioner samtidigt vha. HT. Har hørt forskellige steder at 25 % vist er nogenlunde hvad man kan opnå med HT, men gider ikke lige finde en kilde der kan dokumentere det. Det skal dog nævnes, som du selv er inde på, at tidligere tiders implementationer har været mindre optimale end de nye. Jeg ved dog slet ikke noget om det.
Ja, yderlige kan jeg også nævne test and set instruktionen, atomic increment. ;)
Cache coherency er bl.a. noget jeg har skrevet om tidligere i denne tråd: http://newz.dk/flere-kerner-er-ikke-altid-godt
Noget helt andet er, om jeg har udviklet parallelle systemer. Ja det har jeg. Både på OS niveau, og på system niveau.
Så er det vist din tur til at forklare hvorfor cache coherency er relevant for noget der foregår på een kerne?
Har du nogensinde udviklet paralle systemer, ved du hvad compare exchange instruktionen gør? eller hvad cache coherency er?
Ja, yderlige kan jeg også nævne test and set instruktionen, atomic increment. ;)
Cache coherency er bl.a. noget jeg har skrevet om tidligere i denne tråd: http://newz.dk/flere-kerner-er-ikke-altid-godt
Noget helt andet er, om jeg har udviklet parallelle systemer. Ja det har jeg. Både på OS niveau, og på system niveau.
Så er det vist din tur til at forklare hvorfor cache coherency er relevant for noget der foregår på een kerne?
#14 Hvis den ene proces benytter en ADD instruktion og den anden en MUL, så vil disse to instruktioner foretages samtidigt. Eller parallelt om du vil.
Det er rigtigt, at hvis begge processer vil benytte en MUL og der kun er 1 til stede, så må de skiftes om at benytte den. Så kører det interleaved på instruktionsniveau.
Hvis du kræver at begge processer skal køre fuldstændigt uafhængigt af hinanden for at du vil kalde det parallelt, så skal du benytte to processorer. Det kan HT ikke hjælpe dig med.
Men for alle os andre er det vist rigeligt at sige, at de to processer afvikles samtidigt. Antag f.eks. at de to processer hver ønsker at udføre 1000 ADD instruktioner, så vil de afslutte efter 2000 clock ticks. Ja den ene afslutter 1 clock tick efter den anden. Med en 4 GHz processor snakker vi som 250 picosekunder.
Det er da parallelt så godt som det kan blive uden at have to separate processorer.
#15 Jeg prøver, men jeg ved ikke, om det lykkedes.
#16 Jep, det er skiftevist. Men fordelene ved HT er, at en del instruktioner kan udføres ægte parallelt, når den ene eller anden proces ikke benytter en beregningsenhed (execution unit).
En forklaring på, at SQL server yder dårligere med HT slået til kan være, at når to processer kører samtidigt, så stiller man større krav til hukommelsessystemet, da det skal have flere bolde i luften samtidigt. Det må programmørerne af SQL server kunne lave en løsning på. Det er ikke chippen, der er noget galt med. imho.
Det er rigtigt, at hvis begge processer vil benytte en MUL og der kun er 1 til stede, så må de skiftes om at benytte den. Så kører det interleaved på instruktionsniveau.
Hvis du kræver at begge processer skal køre fuldstændigt uafhængigt af hinanden for at du vil kalde det parallelt, så skal du benytte to processorer. Det kan HT ikke hjælpe dig med.
Men for alle os andre er det vist rigeligt at sige, at de to processer afvikles samtidigt. Antag f.eks. at de to processer hver ønsker at udføre 1000 ADD instruktioner, så vil de afslutte efter 2000 clock ticks. Ja den ene afslutter 1 clock tick efter den anden. Med en 4 GHz processor snakker vi som 250 picosekunder.
Det er da parallelt så godt som det kan blive uden at have to separate processorer.
#15 Jeg prøver, men jeg ved ikke, om det lykkedes.
#16 Jep, det er skiftevist. Men fordelene ved HT er, at en del instruktioner kan udføres ægte parallelt, når den ene eller anden proces ikke benytter en beregningsenhed (execution unit).
En forklaring på, at SQL server yder dårligere med HT slået til kan være, at når to processer kører samtidigt, så stiller man større krav til hukommelsessystemet, da det skal have flere bolde i luften samtidigt. Det må programmørerne af SQL server kunne lave en løsning på. Det er ikke chippen, der er noget galt med. imho.
#4: Faktisk ér jeg vant til at arbejde med servere, hvorfor jeg netop er i stand til at værdsætte 128 CPU-grafer.
Til dagligt kommer jeg aldrig over 32.
Til dagligt kommer jeg aldrig over 32.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund