Microsoft-ansat: Windows 8 bliver et 128-bit styresystem

Næste version af Windows, efter nummer 7, bliver tilsyneladende udviklet som et 128-bit styresystem, på trods af at der endnu ikke findes hardware, som understøtter mere end 64 bit.

To uger før Windows 7 rammer hylderne, summer internettet af snak om efterfølgeren, som i mangel af bedre bud bliver kaldt Windows 8.

En Microsoft-ansat er nemlig tilsyneladende kommet til at tale over sig på sin Linkedin-profil, hvor han nævner sit arbejde med at udvikle Windows 8 med en 128-bit-arkitektur, skriver Ars Technica.

De fleste computere har indtil nu været med 32-bit-arkitektur, selvom 64-bit-udgaver har været på markedet i seks år. Fordelene ved at skifte har været for små, indtil nu, hvor lanceringen af Windows 7 forventes at give 64-bit-hardware et solidt rygstød. For eksempel vil danske Zepto kun sælge 64-bit-hardware sammen med Windows 7.

At Microsoft allerede nu vil udvikle en afløser i 128-bit er derfor lidt at et tigerspring, hvis det altså lykkes og bliver brugt i den endelige version af Windows 8.

Microsoft-medarbejderen Robert Morgan deaktiverede straks sin Linkedin-profil, da han fik henvendelser fra pressen om en uddybning. Men det hjalp selvfølgeligt ikke stort.

Udover arbejdet med at gøre de eksisterende 64-bit-instruktioner kompatible med 128-bit-versionen, afslørede hans profil-tekst, at han også har til opgave at få partnerskaber med chip-producenterne Intel og AMD op at stå. Uden en 128-bit-processor er et 128-bit-styresystem nemlig ikke meget værd.

Hvornår Microsoft vil være klar med afløseren for Windows 7 er ikke meldt ud, udover at Steve Ballmer har sagt, at det ikke bliver før 2012.

En anden mulighed er også, at Microsoft prøver en ny strategi for at skabe hype om kommende produkter, ved bevidst at lægge små bidder information ud i sociale netværk som Linkedin. Tidspunktet - lige op til lanceringen af Windows 7 - tyder dog på, at det ikke er forklaringen.

Et 64-bit-styresystem behandler 64 bit data ad gangen. Når både hardware og software er udviklet til 64-bit, vil det give en højere hastighed. Grunden til, at et 64-bit-styresystem netop nu er ved at blive standard, er, at 32-bit-systemer ikke kan bruge mere end cirka 3,5 gigabyte RAM.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (37)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Nikolaj Brinch Jørgensen

Grunden til, at et 64-bit-styresystem netop nu er ved at blive standard, er, at 32-bit-systemer ikke kan bruge mere end cirka 3,5 gigabyte RAM.

Ret lige dette her til at "umodne Windoze styresystem ikke kan bruge mere end 4 GB RAM".

  • 0
  • 0
Anonym

Når både hardware og software er udviklet til 64-bit, vil det give en højere hastighed.

64 bit giver da på ingen måde højere hastighed, blot et større adresserum/instruktionssæt.

Jeg husker da tydeligt, at HP udsatte overgangen fra 16 bit til 32 bit, da man kunne opretholde en [b]noget[/b] større clockfrekvens på 16 bit, frem for 32 bit.

(Jeg taler ikke om PC'ere, men at HP forlængede deres CISC(16-bit) linie fordi deres RISC (32-bit) ikke performede 'godt nok' i starten.

Vi taler midt '80-erne, just in case.

At gå fra 32 bit til 64 bit betyder sådan set kun at programmerne fylder nærmest det dobbelte, og betyder ikke at der er 'dobbelt ydelse'.

Det er antallet af instruktioner/clock cykle, der betyder noget.

  • 0
  • 0
Torben Mogensen Blogger

At gå fra 32 bit til 64 bit betyder sådan set kun at programmerne fylder nærmest det dobbelte, og betyder ikke at der er 'dobbelt ydelse'.

Nu skal du ikke blande ordlængde og instruktionslængde sammen. Du kan ændre et instruktionssæt fra 32 til 64 bit ordlængde uden overhovedet at ændre instruktionsformatet. Du skla måske tilføje et par instruktioner til at bygge store konstanter, men det er ikke strengt nødvendigt: Du kan altid bygge store konstanter ved at bruge aritmetik (shift og add) på mindre konstanter.

Fordelen er alene, at tal og adresser, der kan ligge i et enkelt register, bliver større. For adresser er 32 bit ganske rigtigt ved at være for lidt, da det (med byteadressering) kun giver 4GB, men 64 bit er nok til at give hvert atom i universet sin egen adresse (og lidt til), som Poul-Henning antydede. Og man kan selv med 32 bit sagtens udnytte en del mere RAM f.eks. ved at have flere kerner, der deler et større logisk adresserum. Hver proces vil så (medmindre man gør noget særligt) være begrænset til 4GB, men det skulle række et stykke tid endnu. Ja, jeg ved godt, at man sagde i starten af 80'erne, sagde, at 64KB var nok til hver proces, så man bare kunne page i et større adresserum. Men der er immervæk et stort skridt fra 64KB til 4GB.

Selv om det er en fordel at have et meget større logisk adresserum end fysisk samme, er 64 bit rigeligt til det meste. Og til talbehandling synes jeg, at man bør bruge ubegrænsede tal, hvis 64 bit ikke er nok. Der er nogle få kryptografiske anvendelser, hvor det er vigtigt at kunne arbejde hurtigt på store tal, men der er 128 bit i reglen ikke nok, så man skal alligevel til at sammensætte flere maskinord til større tal. Man kan selvfølgelig lave vektoroperationer ved at lægge flere små tal ind i et stort register, men her synes jeg, at det er bedre med egentlige vektorregistre i stedet.

  • 0
  • 0
Daniel Kristensen

Det har ikke noget med Windows at gøre, og andre operativsystemer har det samme problem. Det er fordi systemet skal bruge noget af adresserummet til at mappe hardware - jeg mener det hedder PCI Memory Hole eller noget i den retning, og størrelsen kan godt variere fra motherboard til motherboard.

Hvis CPU'en understøtter PAE og operativsystemet kan udnytte det, så kan adresserummet udvides til 36-bit altså 64GB. På Linux kræver det ofte at der installeres en speciel kerne, og på Windows er det vist kun server-udgaverne der understøtter det.

  • 0
  • 0
Poul-Henning Kamp Blogger

Apollo markedsførte DN10000 der så vidt jeg ved var verdens første masseproducerede 64bit computer i 1988.

Ud over at være 64bit var den også SMP med op til fire CPU'er.

Geofysisk Institut i Haraldsgade havde en.

Poul-Henning

  • 0
  • 0
Anonym

Nu skal du ikke blande ordlængde og instruktionslængde sammen. Du kan ændre et instruktionssæt fra 32 til 64 bit ordlængde uden overhovedet at ændre instruktionsformatet

Det synes jeg nu heller ikke jeg gør.

En pointer i et 32-bit system fylder 32 bit, og en pointer i et 64 bit system fylder 64 bit, ligeledes native 'integer' osv.

Og til talbehandling synes jeg, at man bør bruge ubegrænsede tal, hvis 64 bit ikke er nok

Jo, men tal 'størrelsen' er ikke begrænset til 'bitstørrelsen' på CPU'er.

Nu nævnte jeg selv HP's 16-bits systemer i '80-erne, og dér havde vi ingen problemer med at benytte 64 bits tal (banksystemer med integers/implied decimal så man undgår fejl med floating points).

At tro at 64-bit er langt hurtigere end 32 bit er en fejl.

Der snakkes Windows, så jeg går ud fra man tænker på PC'ere, og ikke mainframes.

På mainframes, og servere, giver det mening med en større busbredde, så man kan rykke flere data, men det er næppe relevant på PC'ere.

Jeg kan ikke forestille mig ret mange applikationer (bortset fra tung grafik), der skulle have behov for mere end 32 bit - jo måske nogle særdeles beregningstunge, men det er ikke 'mainstream'.

  • 0
  • 0
Christian Nobel

At tro at 64-bit er langt hurtigere end 32 bit er en fejl.

Klart fuldstændigt på linie med alle mulige andre fejltagelser, f.eks. ensidig fokusering på clockfrekvens osv.

Herudover, så er det væsentlig mere interessant hvor meget processoren skal flytte rundt på data, og der er Intels arkitektur rædselsfuld - var meget tydeligt i gamle dage hvor BBC computeren var væsentlig hurtigere end en PC, trods det at Intel processoren havde højere clockfrekvens og var 8/16 bit og ikke kun 8/8 bit.

Så 5 instruktioner på en 32 bit processor kan snildt være hurtigere at udføre end 8 på en 64 bit processor.

Endvidere er det interessant at se på om hvorvidt man kan arbejde direkte mod en given adresse, eller data skal flyttes først - osv. osv.

/Christian

  • 0
  • 0
Torben Mogensen Blogger

[quote]Nu skal du ikke blande ordlængde og instruktionslængde sammen. Du kan ændre et instruktionssæt fra 32 til 64 bit ordlængde uden overhovedet at ændre instruktionsformatet

Det synes jeg nu heller ikke jeg gør.

En pointer i et 32-bit system fylder 32 bit, og en pointer i et 64 bit system fylder 64 bit, ligeledes native 'integer' osv.[/quote]

Nu sagde du faktisk, at [i]programmerne[/i] fylder dobbelt så meget. Et program fylder ikke mere af, at de pointere, den bruger, fylder mere.

Det er heller ikke sikkert, at data kommer til at fylde mere. Du kan sagtens gemme en pointer i lageret som en 32-bit værdi, selv om du bruger et 64-bit register inde på processoren. De fleste processorer har jo half-word load/store instruktioner.

Og det mest pladsrøvende data på moderne PC'er er typisk mediedata, som normalt er kodet uafhængigt af ordlængde. Det er sjældent, at du har kæmpestore datastrukturer, der mest består af pointere. Så selv om alle pointere kommer til at fylde det dobbelte, vil det være meget få programmer, hvis data kommer til at fylde et tocifret antal procent mere.

  • 0
  • 0
Torben Mogensen Blogger

Herudover, så er det væsentlig mere interessant hvor meget processoren skal flytte rundt på data, og der er Intels arkitektur rædselsfuld - var meget tydeligt i gamle dage hvor BBC computeren var væsentlig hurtigere end en PC, trods det at Intel processoren havde højere clockfrekvens og var 8/16 bit og ikke kun 8/8 bit.

Ja, BBC mikroen var ret hurtig for sin tid. Men det skyldes ikke alene 6502 processoren (selv om den havde en del af æren), men mestendels, at Acorn havde nogle rigtigt gode kodere, bl.a. Sophie Wilson.

  • 0
  • 0
Jacob Christian Munch-Andersen

Torben Mogensen:

64 bit er nok til at give hvert atom i universet sin egen adresse

Det må være dagens vildskud, prøv at regn lidt på det, du har ikke nået din egen næsetip før du er løbet tør for adresser.

At 64 bit giver et rigeligt adresserum til en computer er så en anden sag.

Mht. artiklen så forekommer historien ikke specielt troværdig, med mindre vi hører andet fra en officiel kilde vil jeg betegne den som en and.

  • 0
  • 0
Torben Mogensen Blogger

O.K, jeg bør checke mine astronomiske facts lidt bedre. :-)

Mht. artiklen så forekommer historien ikke specielt troværdig, med mindre vi hører andet fra en officiel kilde vil jeg betegne den som en and.

På OSNews mener de, at der nok er tale om support af 128-bit filsystemer snarere end 128-bit processorer. Det giver lidt mere mening.

  • 0
  • 0
Anonym

O.K, jeg bør checke mine astronomiske facts lidt bedre. :-)

Disse ting bliver diskuteret i en uendelighed, men her er en posting (incl lidt humor) fra en af de grupper jeg følger :-)

> This link is to an article the claims that the next Windows version
> will be 128 Bit.

No, it won't, at least not for the address space. With 64 bit pointers you can
address up to 16 billion GB of RAM. Within the next years no personal computer
will have that much RAM.

Of course more than 64 bits can be used for other things than addressing memory.
But that doesn't require another platform. In fact even 32 bit CPUs can work
with more than 32 bit at once (think of MMX and SSE), but not for addressing memory.

Also take a look at the development in the past, here is a table for the Intel CPUs:

year  CPU        bits time span
1974  8080       8    -
1978  8086       16   4 years
1986  80386      32   8 years
2003  Athlon 64  64   16 + 1 years

As you can see the time span doubles. So the first consumer 128 bit CPU will be
released in 2034 :-)

Isn't that violating Moore's law? No. Doubling the pointer size doesn't just
double the address space, in fact it's y = 2^2^n (where n is the processor
generation). So it's quite naturally that new processor generations arrive
slower and slower.

Eventually we will reach a limit. A 256 bit address space doesn't really make
sense. With 256 bit you can address 1/10 of the number of atoms existing in our
universe. Provided that we don't find a way to store bits in a subatomic way, we
could only build 10 such computers. There wouldn't be enough matter to build more.

Ok, maybe we find a way to store more than one bit per atom. Still it doesn't
really make sense. It's much better to parallelize. Clock frequencies used to
get higher exponentially at the beginning, but haven't changed much during the
last few years. Still CPUs get faster, using more intelligent designs
(pipelining etc.) and more cores per CPU.

I think it will be similar with the address space. There will be other ways to
make computers more powerful, for example connecting more of them. You can see
this today, super computers are based on clusters of many small computers, and
the internet is our biggest super computer. It holds a lot of information, but
works with single 32 and 64 bit CPUs. Addressing works differently, URLs instead
of traditional pointers. It's simply another abstraction layer to make computers
more powerful. Increasing the address space it kind of archaic.

Og jo, jeg snakkede om at programmer fylder mere, da instruktionssættet er udvidet til 64/128 bit (afhængig af hvordan vi definerer et 64/128 bit system).

Hvis instruktionerne kan holdes inden for 32 bit, er der jo ingen grund til at udvide det til 64/128?

Endvidere går jeg ud fra, at en god compiler vil aligne data på word boundaries aht performance, så en bit vil 'fylde' 32/64/128 bit.

Jo, /data/ (hmm. hvordan laver man italics i det her system?) vil fylde det samme, i det omfang der er tale om kontinuerte blokke, men min pointe var sådan set, at 64/128 bit ikke i sig selv gør noget /hurtigere/.

Snakker vi om busbredder og clockfrekvenser er det en anden snak, igen afhængig af hvordan vi definerer et givet system.

  • 0
  • 0
Dennis Krøger

64-bit kan sagtens gøre beregninger hurtigere.

F.eks. arbejder man ofte med bitboards i skak (et bitboard til hvor der står hvide bønder, et til hvor der står sorte tårne, o.s.v.). Mulige træk og konsekvenser kan dermed findes med simple beregninger.

Med instruktioner som kan regne direkte på 64 bit værdier, og registre der har plads til dem, er der store performance forbedringer at hente.

For andre programmer der i forvejen bruger 64 bit værdier vil det være det samme.

  • Men det er helt korrekt at det nævnte citat er en ret grov generelisering.
  • 0
  • 0
Jarle Knudsen

Ikke ment som MS bashing.

Typisk Microsoft: når andre taler om aktuelle produkter, snakker MS om kommende (og lover gulde og grønne skov). Svært at konkurrere med noget der findes kun på papiret.

På den anden er jeg overbevist at til den tid vil Linux køre 256 bits eller mere (om mulig)

Det er ikke uden grund at 443 af top 500 supercomputers samt. Dreamworks, ILM, Weta Digital, Pixar (i alt 95% af servere & desktop i store animation og "visual effects" virksomheder) kører udelukkende Linux :o)

  • 0
  • 0
Anonym

På den anden er jeg overbevist at til den tid vil Linux køre 256 bits eller mere (om mulig)

Pointen var at der findes ikke noget storage media, og sikkert heller ikke kommer til at findes, der kan indeholde dette adresserum, med mindre man først inddrager samtlige atomer i universet, og derudover finder en metode til subatomare 'placeholders'.

  • 0
  • 0
Jacob Christian Munch-Andersen

På den anden er jeg overbevist at til den tid vil Linux køre 256 bits eller mere (om mulig)

Typisk udtalelse fra folk som ikke forstår hvad de her bits drejer sig om.

Når vi snakker x-bit arkitektur er det typisk to ting vi snakker om:

Den maksimale ordlængde operationer kan udføres med, altså hvor store tal computeren kan regne med. Man kan altid uanset arkitektur udføre beregninger med vilkårligt store tal ved at kombinere flere beregninger med mindre tal, det går dog typisk hurtigere med større ordlængder. Langt de fleste programmer til almindelige mennesker har slet ikke eller næsten slet ikke behov for at regne med tal større end 64 bit. Dermed må behovet for en udvidelse her betegnes som meget begrænset. For supercomputere kommer det meget an på opgaven, men jeg vil da tro at der nok skal være nogen som indenfor en overskuelig fremtid vil producere processorer til det nichemarked som 128 bit operationer er.

Adresselængder, afgører hvor meget ram computeren kan adressere. 64 bit er rigeligt og vil være det i hvert fald de næste 25 år.

Andre bitbredder:

SIMD instruktioners datablokke. X86 processorer har længe været i stand til at behandle større datablokke som flere mindre tal og bruge disse til at udføre flere beregninger samtidig. Pt. er de længste datablokke 128 bit. Her vil en udvidelse give rimeligt god mening, da det vil føre til mulighed for at udføre flere operationer per instruktion.

Instruktionslængde. Antallet af bits som en instruktion fylder, den er variabel i X86 familien. Jo kortere jo bedre, men på den anden side også jo flere, jo mere fleksibelt kan processoren programmeres, og jo mere kan den per instruktion. SIMD instruktionssætne kræver ret mange instruktioner.

Div. busbredder er sammen med sendefrekvensen for bussen afgørende for hvor meget data der kan flyttes af gangen, fx er ram busbredden på 64 bit per kanal, dvs. samlet 128 bit for de fleste processorer, men 192 bit for Core i7 processorer. Intel har planer om gå helt op til 4 kanaler/256 bit i næste generation. Jo flere kanaler, jo flere ledere skal der til på bundkortet, det sætter en grænse, men vi bør forvente at se producenterne presse citronen når det drejer sig om busbredder, for der er ikke nogen grænse for hvor meget vi kan bruge.

  • 0
  • 0
Lasse Reinholt

Nu findes der i x86/x64 både de klassiske integer operationer samt floating-point operationer (SSE).

Med SSE 4.x begyndte man at lægge mere vægt på masse-afvikling af integer beregninger, men SSE har stadig ulempen, at udlæsning af resultater har et stort overhead. Det overhead er ca. 9 clocks, sammenlignet med ca. 2 clocks for udførslen af en SSE 4.x instruktion. Integer operationer udføres derimod med op til 2 operationer pr clock og har intet overhead.

Så det at blande SSE med forretningslogikken kan ikke betale sig hvis SSE beregningerne er få. I så fald bør man bruge de klassiske integer operationer i stedet.

Hvis integer registre bliver 128 bits, og vi får nogle SIMD operationer på disse integer registre, så vil man få fordelen fra begge verdener - hurtig afvikling og intet overhad når det blandes med forretningslogikken.

Ved ikke, om det var til at forstå :D

  • 0
  • 0
Anonym

Hmm.. - gudskelov havde jeg gemt mit indlæg, da det der javascript, de bruger på V2 m.m får min browser til at crache) - nåh men jeg prøver igen:

Kom i tanke om et 'møde', eller 'scenarie' fra midt '90-erne, afholdt af HP (for 'the inner circle').

Her fortalte man, at man havde indgået samarbejder med hhv. Intel og MS.

Intel, fordi HP var(er?) eksperter i udvikling af processorer, og Intel var(er?) eksperter i masseproduktion.

Aftalen gik ud på, at HP udviklede processorer(en), og Intel stod for masseproduktionen.

Den første prototype (codename='merced') var allerede klar, og outperformede konkollegaerne, allerede ved 100MHz, da den kunne lave 4 operationer/clock.

Det vi fik at vide (og her snakker jeg top folk fra Palo Alto), var, at intel forpligtede sig til ikke at lave systemer med mere end 2 CPU'ere.

'merced' var codename til det, der senere er kendt som Itanium.

Samtidig fik vi at vide, at HP havde udlånt 470 systemprogrqammører til MS, så Windows kunne køre på denne arkitektur.

I denne kontekst snakker vi om highend udstyr, men prøv gerne at tænke over på hvilken mådfe MS har fået Windows til at køre på et (itanium baseret cluster).

Samme gælder i øvrigt Linux - Hvis man tror det er et par hobbyprogrammører, der får Linux til at køre på sådan et cluster, så skal man nok tro om igen.

Jo, men 'merced' var ukendt i midt 90'erne, og man kan tænke den tanke, at man allerede nu er igang med en 128-bits version, men jeg vil nu stadig tro, at det er til [b]server[/b] markedet.

Og som andre skriver, så findes 128 bit registre allerede i dag.

Men der har ikke været så mange indlæg om ulempen ved at 'manipulere' 64/128 bit data i forhold til mængderne til/fra memory/cache(L1/l2)).

  • 0
  • 0
Jens Madsen

Hvis alt udføres som 128 bits, så fylder ALU'en naturligvis dobbelt af en 64 bit. Og den 16 gange så meget som en 8 bit. Eller, vi kunne vælge at lade ALU'en udføre 16 indstruktioner i et huk i stedet.

I mange tilfælde, vil det give bedre udnyttelse af hardware, end at udvide til 128 bits.

Med hensyn til addresserum, giver 128 bits naturligvis meget, i forhold til 64 bits. Så er det bare lige at få fat på nogle hukommelser. Selv microsoft, tror jeg endnu ikke har fået anskaffet hardwaren. Ram'en skal være på 16777216 terabytes eller derover, før bit 65 tages i brug. Selv harddiske, skulle det være rigeligt til at memorymappe.

Det er så til gengæld også en ganske god idé, at memorymappe hele harddisken. Det gør opstart af programmerne hurtigere, da de så allerede ligger i ram'en, og ikke skal kopieres til swap fil først, når de hentes ind. Et lille program, på nogle terabytes, kører derfor hurtigt og nemt, hvis hele harddisken memorymappes. Idag, skal den først kopieres til en kæmpe swap fil, fordi der ikke er plads i CPU'ens ram. Denne kopiering tager masser af tid. Hvis man havde nøjes med 32 eller 64 bit, vil det kun være muligt at memorymappe åbne filer, og det vil ikke være adgang til lukkede. Med 128 bits addressebus, kan også memorymappes lukkede filer, og dem man ikke har adgang til...

Hele problematikken omkring 8 bit, 64 bit osv. skyldes en designfejl som sædvanlig. Dem, der laver operativsystemer, har ikke forstået hvad et operativsystem gør godt for - meningen er, at denne skal virke som grænseflade til hardwaren, og muliggøre at dine programmer kan skrives IDENTISK uanset hardware. Dette betyder, med andre ord, at det er operativsystemets opgave, at lave programmet så det passer til hardwaren, ved hjælp af en såkaldt driver - i tilfældet her, en CPU-driver. I Microsofts operativsystemer mangler CPU-driveren, og det gør at det ikke er muligt at tilpasse hverken operativsystem eller software, til den pågældende CPU. Et "rigtigt" operativsystem, vil du kunne lave om til en anden CPU, ved at udskifte CPU driveren. Denne står, for low-level compileringen, meddens at high-niveau sprog kun står for high-level compileringen, og det betyder, at koden som overleveres til operativsystemet, er såvel 8 bit, som 64 bit, eller 128 bit, afhængigt af hvad high-level compileren angiver. Parallelisering, er et andet problem, som ikke "tillades", fordi at man igen skal til at skrive programmerne specielt til parallelisering, eller lave operativsystemet om til dette. Fleksibiliteten mangler, fordi at operativsystemet har misforstået sin funktion, og tror det skal være et brugerinterface, og ikke et maskininterface. Windows, er et brugerinterface, og indeholder intet rigtigt maskininterface. Selvom der er masser af muligheder for VXD'er, og alt muligt andet, udgør de ingen mulighed for at fungere som maskininterface, således operativsystemet kan køre på forskellige maskiner, med forskellig CPU. Til en vis grad, kan laves drivere til forskellige printere ol. men de mere advancerede dele af et operativsystem, som f.eks. at kunne parallelisere, og de-parallelisere, og tilpasse til den pågældende CPU arkitektur, er helt udeladt i windows.

Linux, er bedre, da man her kan "compilere" det til den pågældende CPU, og at de "rigtige" filer, er C koder, og ikke maskinkoder. Sproget C, mangler dog også mange features, f.eks. at man som standard har mulighed for at selv sætte opløsning og bits for alle typer (float, integer, osv.) Det betyder, at sproget dermed ikke er et hardwareuafhængigt sprog, og det er derfor ikke egnet til at køre under et operativsystem. Derimod, er det egnet til microconrolere, og processorer som Z80.

At begynde at omskrive et operativsystem til 128 bit, giver ingen mening. Det rette er, at kun udskifte en driver, så der supporteres 128 bit. Det er driverne, der foretager omskrivning - ikke noget der må gøres "by hand".

  • 0
  • 0
Lasse Reinholt

Hvis alt udføres som 128 bits, så fylder ALU'en naturligvis dobbelt af en 64 bit. Og den 16 gange så meget som en 8 bit. Eller, vi kunne vælge at lade ALU'en udføre 16 indstruktioner i et huk i stedet.

I mange tilfælde, vil det give bedre udnyttelse af hardware, end at udvide til 128 bits.

Du kan ikke udføre flere instruktioner samtidig hvis deres resultater afhænger af hinanden. Fx

mov rax, [myint]
add rbx, rax

Du kan ikke udføre add rbx, rax før mov rax [myint] er udført.

Løsninger er:

  • Lange pipelines og out-of-order eksekvering, som finder uafhængige instruktioner i et stort vindue vindue fremfor kun nær rip. Men dette kræver transistorer og watts

  • SIMD som fx SSE eller på videokort, men her kan du ikke udføre springoperationer (og dermed er problemerne, man kan løse, temmelig begrænsede)

  • Itaniums princip med at lade det være op til udvikler og compiler at arrangere instruktionerne så de ikke har afhængigheder

Der er ikke nogen gylden løsning.

  • 0
  • 0
\n \r

> SIMD som fx SSE eller på videokort, men her kan du
> ikke udføre springoperationer (og dermed er
> problemerne, man kan løse, temmelig begrænsede)

Det kan man sagens, og ofte kan problemerne om organiseres så der passer ind i den parallel pipeline.

  • 0
  • 0
Lasse Reinholt

Det kan man sagens, og ofte kan problemerne om organiseres så der passer ind i den parallel pipeline.

Med SSE er du nødt til at kopiere et resultat fra SSE registre til memory eller integer registre og sammenligne og branche fra integer instruktioner. Det giver et overhead når man blander integer med SSE. SSE 4.2 har dog fået en PTEST instruktion som kan sætte CF, men PTEST udfører kun en == operation. Ikke >, >=, < eller <= eller bitwise tests og hvad man ellers har brug for.

  • 0
  • 0
Anton Lauridsen

Som en tidligere skribent har nævnt, undrer jeg mig meget over hvordan Intel vil håndtere deres level 1 og 2 cache. Mig bekendt er den stadigvæk på 128 bits, selv på deres nyeste processorer. Allerede nu - med 64 bit data - giver det anledning til bottlenecks. Med en 128 bit processor vil der så være et 1-1 forhold mellem ordstørrelsen og bredden på L1 og L2 cache.

Så uden en omskrivning af cache håndteringen, og afledte der af: compiler, cache optimerings algoritmer i diverse programmer, risikerer kernen at komme i en "lock-step" situation med RAM hovedlageret.

  • 0
  • 0
\n \r

Lasse Reinholt

> SIMD som fx SSE eller på videokort, men her kan du
> ikke udføre springoperatione

Tror det er mange år siden du sidst har leget med gpu kode...
moderne videokort som du vidst kalder det er meget avancerede vector processorer og ofte vil du opleve at man med lidt gpu-magi kan omforme uhyr mange problemer på en sådanne måde at gpu'en kan holdes beskæftiget.

  • 0
  • 0
Jens Madsen

Du kan ikke udføre flere instruktioner samtidig hvis deres resultater afhænger af hinanden. Fx

mov rax, [myint]
add rbx, rax

Problemet er at hente data i ovenstående fra ram'en eller cache. Antages, at de er skrevet ind i lageret i nogle indstruktioner før, f.eks.

mov rax, 6
mov [myint], rax
...
...
mov rax,[myint]
add rbx, rax

så vil de "interne" indstruktioner henvise til, hvor mange indstruktioner før at [myint] fik sin værdi. Det betyder, at add indstruktionen ikke henter værdien fra [myint], men fra indstruktionen mov [myint], rax, der blev udført lidt før - eller normalt den forrige, hvor den får værdien 6 - eller måske direkte med værdien 6. Hvis indstruktionen blev udført lang tid før, så den ikke ligger i lageret, når den udføres, så vil [myint] blive hentet ind i hukommelsen, så dataene kan hentes, når de skal bruges.

I nogle tilfælde, er det derfor nemmere, hvis en værdi netop er blevet gemt i hukommelsen, da værdien så hentes direkte fra indstruktionen.

Hvis du eksempelvis udfører to add indstruktioner:
add rbx, rax
add rbx, rcx

Så vil nummer to ikke tage meget ekstra tid, fordi den udføres samtidigt med den første, trods de bruger samme data. Det skyldes, at bittene "flyder" igennem regneenhederne, og det betyder, at de laveste bits ankommer først, og næste operation starter før første afsluttes.

Kunsten er, at "omskrive" et program, således det består af interne indstruktioner, der fortæller hvilken indstruktion at data skal tages fra - og eventuelt, hvilke data der skal hentes ind, hvis dataene skal hentes ude fra eller fra cache. I praksis, betyder det, at addresserne der skal læses "bobler op" i systemet, og hentes ind, så de er til rådighed.

Alle disse operationer, kan ske før den inderste cache, og betyder at forwardingen mellem indstruktioner, at hente de rette ram addresser ind osv. kan udregnes inden det lægges ind i cachen. Selve cachen, kan nemt indeholde 16 eller 32 indstruktioner der udføres samtidigt. Alt det med at det ikke er muligt, at udføre indstruktioner der afhænger af hinanden, er noget datalogfis, fordi de ikke forstår hvordan hardwaren fungerer. Det går ganske udmærket, fordi at ALU'en nærmest kan beskrives som at udføre f.eks. en dobbelt-add. Og ved de fleste indstruktioner, såsom AND, OR, osv. er forsinkelsen så lav, at man skal op over 40-50 milliarder indstruktioner per sekund, før at forsinkelsen i indstruktionen betyder noget. Det er ikke i ALU'en, at forsinkelsen er et problem. Flere ADD's, flere AND's osv. kan nemt udføres samtidigt i en WLIW indstruktion, hvor de henter dataene direkte fra hinanden, uden at det tager lang tid. Du skal tænke på, at indstruktionerne her er ALU'er, der er optimeret til at forwarde data direkte til hinanden, og det betyder at det ikke er mere end et enkelt gate niveau, mellem indstruktionerne i den kritiske vej. De går ikke op i en registerfil, og tilbage igen.

At analysere indstruktionerne, med henblik på at finde ud af, hvordan der skal forwardes mellem indstruktionerne ved at tage fra den indbyggede pipeline, er muligt at gøre før dataene lægges ind i cachen. Det kan endog foretages af software, hvor programmet oversættes til det interne format, og gemmes på harddisk. I så fald, bruges ikke resourcer på disse opgaver, og det koster ikke strøm. Programmet oversættes ganske enkelt til et nyt maskinsprog, som ligger på harddisken, og hentes når programmet hentes. Det er også muligt, at gøre i CPU'en, og det kan i princippet lægges ind et vilkårligt sted i mellem cacherne. Ved samme operation, optimeres også for branch retningen - det betyder, at man kan udregne hvor på pipelinen data skal forwardes fra, med hensyn til hvilken typisk retning programmet tager. Du kan forestille dig, at du har et bredere indstruktionsformat, og at indstruktionerne i den typiske retning efter branch indstruktionen lægges ind på indstruktionerne efter branchen, indenfor det pågældende ord.

Det med at "plukke" hvilke indstruktioner der kan udføres, er omtrent ligegyldigt. Der er ingen væsentlige blokeringer i ALU'en, da denne ikke er en flaskehals.

En gang, kom IBM også med en af de skægeste historier: Nu har vi bevist, at en computers hastighed afhænger af hvor hurtig du kan læse en indstruktion fra registerfilen, udregne den, og skrive resultatet til registerfilen igen. Igen, det rene vås. Indstruktioner skrives ikke til en registerfil - de går direkte videre, til en ALU, der udfører næste indstruktion, uden data opbevares i registre undervejs. Data forwardes mellem ALU'er, og normalt er forward vejen udregnet, inden indstruktionerne placeres i cache, så det i det interne program, direkte står hvor i ALU'en, og i hvilken ALU, at værdien kan hentes fra. Det kan generalt bevises, at skrivetid til registerfiler, og ram'er, intet betyder. Selve skrivebåndbredden, kan betyde noget, men det kan ved interne registerfiler altid opnås, ved at parallelisere skriveadgang til registerfilen. Den tid, som en indstruktion tager, er den tid det tager at hente den fra udgangen på en forrig ALU, og direkte sende den videre til indgangene på den næste ALU. Dette er også, den højeste indstruktionsfrekvens, for indstruktioner i rækkefølge, at processoren kan køre med. Normalt, vil det gå hurtigere, da langt de fleste indstruktioner ikke har afhængighed. I nogle tilfælde, som f.eks. rax AND med nul, vil data også vandre hurtigere igennem, da resultatet kommer ud, før at rax kommer ind. Det er ikke unormalt, at f.eks. mente, og lignende "flaskehalse", derfor ikke er reelle flaskehalse, men kun datalogiske flaskehalse, der intet betyder og reelt er ikke eksisterende.

  • 0
  • 0
Anton Lauridsen

@Jens Madsen
Tak for den udemærkede gennemgang, men det ændrer ikke ret meget på den overordnede problemstilling, uanset om du bits fra direkte fra en alu til en anden alu eller om du gemmer dem i en registerfil. På en måde kan du tænke på banerne mellem to alu'er som en form for "register" hvor bittene lagres, om den har et navn som AX eller eller ej ændrer ikke på at en vilkårlig alu ikke kan påbegynde add før første bit i de to operander er tilstede.

mov rax, [myint]
add rbx, rax

Det vil altid være muligt at opbygge en kæde af instruktioner, der vil medføre en stall, uanset antallet af alu'er i kernen. Alt hvad der behøves er en kæde af instruktioner der er afhængige af n+1 læsninger fra ram hvor n er antallet af alu'er, eller er der noget jeg har misforstået?

  • 0
  • 0
Jens Madsen

Det vil altid være muligt at opbygge en kæde af instruktioner, der vil medføre en stall, uanset antallet af alu'er i kernen. Alt hvad der behøves er en kæde af instruktioner der er afhængige af n+1 læsninger fra ram hvor n er antallet af alu'er, eller er der noget jeg har misforstået?

Ja, lidt er det. Hvis du så i eksemplet, så kunne indstruktionen add rbx, rax faktisk udføres før mov rax,[myint]. Rækkefølgen, blev gjort ikke afhængig, fordi at det på tidspunktet hvor indstruktionerne indslæses til cachen, blev erstattet [myint] med en reference til indstruktionen 5 før. Det betyder, at den egentligt kunne være udført, allerede efter indstruktionen "mov rax, 6". Det kan give problemer, hvis flere CPU'er deler hukommelsen, men det antager vi, at det ikke sker - ellers er vi ude i en række problemer, hvor vi skal genudføre koden, hvis addressen ændres. Normalt vil det ikke ske, og det vil også give problemer med cache osv. hvis det sker.

At tage data direkte fra pipelinen - altså relativt til et antal indstruktioner tilbage - har mange fordele, fremfor at bruge registerfilen. Udfører du eksempelvis 32 indstruktioner samtidigt, og skal skrive til registerfilen, så skal du nu kun skrive for den sidste indstruktion, der gemmer noget i f.eks. rax. Hvis du skriver for flere, så giver det kortslutninger, og den ved ikke hvilken der skrives. Dette regnes ud på forhånd, når data lægges i cachen. Det betyder også, at hvis du henter noget fra rax, så vil det ikke være rax du henter - men data der er "ældre" end første indstruktion blandt dem der er læst samtidigt. Og det kan endog være endnu flere indstruktioner tidligere. Alle senere indstruktioner, skal derfor hentes fra køen, og må ikke hentes fra rax, da denne ikke nødvendigvis har den rette værdi. Det er i praksis umuligt, at få smidt data op i rax og hentet dem ned igen, og op igen, og ned igen, osv. Hvis derimod, at du detekterer hvor data skal tages fra, så den hentes direkte fra indstruktionen, så fungerer det - og det udgør en form for et dataflow træ - hvor indstruktionen endog kan udføres tidligere. I tilfældet her, vil den måske udføres som den første indstruktion, hvis konstanten 6 lægges direkte ind. I nogle tilfælde, vil man ikke lægge konstanter direkte ind, men tage den fra den første sted hvor rax får en værdi. Men det er næsten ligegyldigt.

Det betyder ikke, at registre skrottes totalt, selvom alt læses fra "pipelinen". Registrene bruges, til "gamle data" der er gået ud af pipelinen. Men registrene, har ingen betydning, i de kritiske dele.

Det er delvis korrekt, at hvis du skal læse et antal data fra rammen - at det så tager den tid, som det tager at læse disse. Men det er kun "delvis" korrekt. Hvis - som ovenstående - at en værdi netop er blevet skrevet til ram, så vil den stadigt ligge i køen, og dermed betyder det intet om data skal skrives. Hvor længe skriveoperationen tager betyder hellerintet, da CPU'en bare fortsætter, efter skriveoperationen, også selvom den endnu ikke er foretaget. Det giver ikke problemer, for hvis du tager data fra cellen, som du har skrevet - så tages den direkte fra indstruktionen. I nogle tilfælde gemmes også resultaterne fra indstruktionsord der er ældre, og det betyder at hvis 32 udføres af gangen, kan du nemt gå 64 eller mere tilbage, og tage resultatet fra de gamle indstruktioners udgang. Registerfilen, bruges ikke. Og i mange tilfælde bruges ram'en ikke, hvis bare data er gemt indenfor dette vindue. Er de gemt før, vil man normalt forsøge at skubbe opslaget op, så det ikke tager tid, for CPU-eksekveringen.

Hvad er så den mest besværlige indstruktion? Jo, det er indexeret hukommelse.

mov rax,[rbx]

er et eksempel på en indstruktion, der først kan udføres når rbx er kendt, og opslået fra hukommelsen. De fleste andre, indgår ram'en ikke i. De udføres direkte på pipelinen.

Ved indstruktioner som ovenstående, kan man søge at skubbe opslaget op, så det udføres så snart rbx har aflagt en værdi. Og om muligt, også skubbe denne indstruktion op. Men nu begynder det at være lidt advanceret. Mange, vil foretrække, at lægge det ind i compileren. Men det kan også lægges i hardware, med lidt større strømforbrug osv. som følge. Heldigvis, behøver det ikke at blive lagt i de kritiske dele, da det kan lægges før cachen osv.

Mange ting, kan gøre CPU'en mere effektiv. Hvis vi eksempelvis vidste noget om hvilket interval, at vores indexregister antager, så vil være muligt at skubbe rundt på indstruktionerne. Det bedste er, at compileren derfor angiver intervallet for en index addressering, og dermed også altid laver range-check af CPU'en. Sprog, som ikke inkluderer range-check som standard, er reelt dårligere, og sværre at optimere til at køre hurtigt. Hvis range-check er lagt ind, kan man i nogle tilfælde analysere sig til hvad der sker, og dermed udelukke rbx er udenfor visse grænser, og dermed muliggør bedre out of order execution.

Vi er dog nu langt ude over det egentlige problem. Men, for dem der udvikler programmeringssprog, kan det måske have betydning, at de tænker på hvordan man håndterer index problemet optimalt, på fremtidens CPU'er, således det muliggør optimal parallelisering og så lidt blokering som muligt, når indstruktioner reorganiseres.

I ganske specielle tilfælde, kan også undgås at data læses fra hukommelsen, fordi at operationen håndteres i hardware. Det kan eksempelvis være kopiering af en ram blok. Her, kan bruges specielt hardware, til at foretage den fysiske kopiering, og det betyder at man så bare holder øje med, at data er kopieret, og tager dem fra original positionen, indtil de også er fysisk kopieret - hvis de nogensinde kopieres. Indbygning, af en sådan "logisk kopiering" i processorer, eksisterer til dels i form af MMU'en. Men den er ikke så fleksibel indbygget, at den kan klare den normale kopi indstruktion der kopierer byte vis. Havde man gjort dette, og implementeret harddisk og internet som memory mapped, vil det ikke mere tage tid og resourcer at kopiere, så længe det er på en fast device på computeren. Jeg plejer, at kalde det mulighed for "gratis kopiering", da det ikke tager tid. Men det understøtter kommercielle processorer, så vidt jeg ved endnu ikke, og der er måske også noget politisk i det... Men jeg glæder mig, til den dag, at Intel reklamerer med, at deres CPU nu håndterer "free copying".

  • 0
  • 0
Anton Lauridsen

Jeg kom vist til at udtrykke mig lidt uklart

mov rax, 6
mov [myint], rax
...
...

kan lægge meget meget før:
mov rax, [myint]
add rbx, rax

og så vil cpu'en kræve en pæn størrelse for at kunne huske værdien "6". Sagt lidt mere generelt, hvis man kender algoritmerne i cpu'en, og den tilgængelige samlede system hukommelse er mere end 2 gange cpu'ens indbyggede hukommelse vil det - som jeg ser det - altid være muligt at opbygge en sekvens af instruktioner der medfører en stall.

Hvorfor man så skulle ønske at opbygge en sådan sekvens er en helt anden sag.

  • 0
  • 0
Jens Madsen

Forestiller vi os følgende program:
mov rax, 6
mov [myint], rax
...
...
mov rax,[myint]
add rbx, rax

Så vil alle disse indstruktioner præsenteres til CPU'en på samme tid. De medfører ingen "lock-up", men oversættes allerede på det tidspunkt de indskrives i cachen til følgende:

mov rax, 6
mov [myint], {-1}
...
...
mov rax, {-3 + -1 = -4}
add rbx, {-1 + -4 = -5}

hvor tallet i tuborg klammen, angiver hvilken ALU, eller hvorfra pipelinen det tages. Har ALU'en et nummer, tages resultatet fra den pågældende ALU med nummeret i forhold til tallet i tuborg parantesen.

Som det ses, er referencen til ram lageret forsvundet i indstruktionen mov rax, [myint]. Den betyder derfor intet. Du vil kunne skubbe add rbx,rax 4 indstruktioner op, uden problemer, da rbx ikke bruges. Det betyder også, at når indstruktionerne udføres i en stor blok, der udfører alt i et huk, så vil den ikke tage tid, da CPU'en får sine værdier fra den første indstruktion og rbx registeret (der enten tages fra pipelinen, hvis den har fået en værdi indenfor overskuelig tid, eller fra registerfilen, hvis den ikke har fået nye værdier i en evighed).

Du vil måske så tænke noget i retning af, hvordan branches klares - den kunne jo "hoppe" ind midt imellem. I så fald, regnes ud efter dette. Det regnes ud for et indstruktionsord af gangen, og denne kan normalt ikke brydes af en branch. I stedet, laves en "branch-indhop" kode, hvor det er optimeret med dette, således den kan køre videre i koden.

Udfoldning af kode, sker også, inden det lægges ind i den inderste cache. Normalt, vil man altid udfolde koden det antal indstruktioner frem, som der læses samtidigt - det er meget svært at undgå. Der læses jo eksempelvis 32 eller 64 indstruktioner af gangen, og hvis koden går i loop, og det skal optimeres for den gængse koderetning, så medfører dette en udfoldning.

Hvis koden ikke går i den gængse koderetning, så vil en del af indstruktionerne skulle ignoreres. Her er det specielt skrivningerne til registerfilen der skal ignoreres, da registrene ikke må få aflagt værdier fra ikke kørte indstruktioner. I nogle tilfælde, forsinkes skrivningen en cycle, så der er tid nok, til at forhindre en eventuel skrivning, på baggrund af flags.

I mange tilfælde, er der måske indstruktioner der af den ene eller anden grund ikke skal udføres. Er der så mange ALU'er, at det reelt er dataafhængigheder mellem ALU'erne, der er bestemmende for hastigheden, og ikke rom og ram'ens cycletid, så vil hastigheden gå op, hvis der er indstruktioner der ikke udføres, da dybden dermed oftest også gøres mindre. En NOP indstruktion, tager i princippet ingen tid, da den ikke giver afhængigheder, og samme med en ignoreret indstruktion. Dataene derfra, bliver ignoreret, men det betyder intet for hastigheden.

Intel har en anden måde, at løse nogle af ovenstående problemer på. Men det laver ikke om på, at flaskehalsen ikke er CPU'en, og delayet mellem indstruktioner. Flaskehalsen, ligger i højere grad, i den advancerede logik, som f.eks. står for den dynamiske pipelining. Hvis denne fjernes, og arealet bruges til regnekraft, er sandsynligt at processoren vil blive noget hurtigere.

Vi skal have op til 8 - 10 gange flere ALU'er, og større hastighed, i en Intel processor, før vi løber imod en hastighed der skyldes ALU'er. Sandsynligvis skal antallet være over 40 gange større, da der kun er ringe sandsynlighed for afhængigheder. Intels CPU, er derfor langtfra hvad der kan opnås, i nuværende teknologi, med hensyn til at udføre indstruktioner i rækkefølge - og endnu længere væk fra det er muligt at opnå, når det sker out-of-order.

Blandt andet, tager Intels CPU ikke højde for dataene under beregningen af den dynamiske pipeline, og det betyder, at hvis det eksempelvis viser sig, at du AND'er med nul, eller på anden måde blokerer vejen igennem ALU'erne, så dybden er mindre end den teoretisk udregnede - så tages ikke hensyn til dette. Det er meget sandsynligt at dette sker, og sandsynligheden øges med antallet af ALU'er. Af samme årsag, siges også at den advancerede carry-lookahead, i virkeligheden giver ringere ydelse, end hvis det var lavet uden. Årsagen er, at det tager længere tid at udføre indstruktionen, og tilfældende hvor menten ribler igennem, set udfra et dybdesynspunkt har en sandsynlighed der er logaritmisk til antallet af bits. Tages højde for dette, så vil det reelt gå hurtigere, så er ribbel-mente hurtigere end look-ahead. Tager du eksempelvis en blok af mange komponenter med ribbel mente, så vil du få et hurtigere svar i middel. Kun, når ribbelen går igennem samtlige 64 bits, er du uheldig, og det er ganske sjælden. Det er mere væsentligt, at du kan opnå hurtigere svartider uden - og lavere strømforbrug.

Den indstruktion, som er mest effektiv til at opnå stall's, er mov rax, [rbx]
Denne kræver - desvære et ramopslag. Og er der flere, vil det være de afgørende for, hvor lang tid indstruktionerne tager. Normalt, er det ikke CPU'en der er afgørende. Selve forsinkelsen i en ALU er kort, og de har en kapacitet til at udføre op til 30 - 40 giga indstruktioner per sekund ved indstruktioner der kræver hinanden. Intels processor, er kun ca. 1/5 i hastighed. Dertil kommer, at kæden der kan medføre stall, oftest brydes, når der udføres mange indstruktioner - og at dette sker på et niveau det ikke er nemt at analysere datalogisk, da det skyldes data. Som eksempel, vil en datalog komme til, at den tid en ribbelmente tager er lig worst case tiden - meddens det rette svar er, at der svares hurtigere, fordi at menten ikke ribler igennem alle bits. Den typiske forsikelse, er i højere grad logaritmisk til antallet af bits. Også, når der udføres mange indstruktioner, "brydes" afhængighedskæden på et datalogisk ikke analyserbart niveau, og det betyder, at hastigheden er langt hurtigere end datalogernes modeller forudsiger.

Det er korrekt, at du kan konstruere et program, der medfører afhængigheder i alle indstruktionerne. Men, selv der, vil du kunne opnå en hastighed der er ca. 5 gange hurtigere, end den Intels processorer har idag. Så konklusionen er derfor, at beregningen ikke er problemet. I de fleste tilfælde, vil det være indexeret ram opslag, som er problemet, og altså access tiden til rammen. Hvis det er i CPU'ens cache, kan man måske læse flere data samtidigt ol. Alligevel, er det sandsynligvis det, som vil medføre flest stall's.

  • 0
  • 0
Log ind eller Opret konto for at kommentere