04. januar 2007 - 10:57
#3
De fleste, der er vokset op i 1980'erne, husker sikkert deres første computer, der med stor sandsynlighed har været en Commodore 64. Grunden til dens navngivning var den mængde af RAM, som den var født med; 64KB - en stor mængde efter datidens standarder mente mange dengang. Sammenlignet med i dag, har stort set alle applika-tioner overgået denne størrelse, og omfanget af disse stiger eksponentielt dag for dag. Computere bliver udstyret med mere og mere RAM for at få applikationer til at køre gnidningsløst, og samtidig gør applikationerne brug af den voksende mængde hukommelse for at tilbyde et stigende antal features.
Det kan nærmest sammenlignes med "en slange, der forsøger at sluge sin egen hale".
Med andre ord, står it-industrien overfor et dilemma, der sammen med behovet for at tilgå og håndtere indholdet af store RAM-blokke hurtigt gør, at begrænsningen i den nuværende teknologi er ved at være nået. De fleste 32-bit CPU'er ved at nå dette loft inden for både forbruger software og kommerciel/enterprise software.
Hér vil teknologi, baseret på 64-bit arkitektur, være den hellige gral...
Hvad er det, der gør dette udsagn så tillokkende? Hvad er 64-bit egentlig? Og hvorfor vil det være løsningen
på de evigt voksende datamængder og det ligeledes stigende behov for at behandle dem hurtigt? 64-bit kan betyde meget. Det kan betyde, at et bestemt set af registre er 64-bit bredt, eller at en intern struktur i processoren er 64-bit bred. Selvom der ingen standarder er defineret for at kalde en processor for 64-bit, er en sådan ofte defineret ved, at den opfylder følgende; General-Purpose Registret er 64-bit bredt,
heltal og logiske operationer foregår i 64-bit, og virtuel adressering kræver 64-bit pointers. Men for at forstå, hvad der ellers ligger i begrebet "64-bit", kan en lille rejse tilbage til informationsteknologiens spæde barndom, med rette bruges til at belyse det nærmere.
Hvis vi tænker på dengang, man bevægede sig fra 16-bit til 32-bit arkitektur, fik integreret floating-point instruktioner*, fik en matematisk co-processor (FPU) og senere floating-point SIMD (SingleInstruction stream, Multiple Data streams), så havde de første microprocessorer (også kaldet SISD, Single Instruction stream, Single Data stream), ikke nogen floating-point muligheder; de var med andre ord rene tal knusere. Floating point beregninger blev udført separat i dedikeret hardware ofte i form af en matematisk co-processor.
Det varede dog længe, før transistorer blev så små, at det kunne betale sig at flytte co-processoren ind i selve CPU-kernen. For at komme tilbage til udgangspunktet, så fulgte en masse nye spændende udvidelser og nyskabelser i kølvandet på overgangen fra 16-bit til 32-bit, og i takt med at flere transistorer kunne presses ned på silicium kerner af stadig mindre dimensioner steg antallet af instruktioner, som en CPU kan udføre, men medførte samtidig at den arkitektur, som de har været baseret på i mange år (32-bit), er blevet en begrænsende faktor i sig selv.
* Floating point (eller flydende tal, flyende komma-tal) er et matematisk begreb, som dækker over tal, der ikke er hele. Fx er 32 helt, mens 32,5164 er en floating point/flydende komma-tal. Det er krævende for en CPU at bearbejde flydende kommatal, for der skal mange bits til at lave en præcis beregning. Matematik med heltal (integers) er meget enklere, og der bliver resultatet helt korrekt, hver gang. I CPU'er er floating point tals størrelse angivet ved den mængde bits, der bliver brugt på at lagre dem, for det meste 32-bit eller 64-bit.
Hvorfor er 32-bit en begrænsning?
Man fristes til at spørge hvorfor 32-bit er en begrænsning?
Meget enkelt betyder 32-bit, at det logiske adress-rum en CPU kan håndtere eller "se" om man vil) maksimalt kan være 4GB. Matematikken bag 32-bit, vil forklare det således; 232 = ca. 4.3 milliarder bytes / 1024 kb = 4GB. Ved at bruge den samme formel (264) kan en 64-bit processor teoretisk adressere ca. 18 milliarder GB - eller 16 exabytes! Dette er i dag ligeså ubegribelig en størrelse, som 4GB var for mange år siden.
Problematikken opstår i dag, når fx meget store databaser med lethed overstiger 4GB, eller en forskers avancerede realtids-simulering af fx drivplasma i en fusionsreaktor kræver ekstreme mængder RAM-kapacitet - for blot at nævne nogle tunge opgaver; noget som kræver meget båndbredde inde i CPU'en og presser dens evne til at have store datamængder i luften på én gang - så selv de største datacentre kan bringes i knæ i det lange løb på denne måde. Et skift fra 32 til 64-bit arkitektur er en fundamental ændring, som operativ systemet naturligvis også skal være forberedt på, foruden de applikationer man vil afvikle. Som det var for mange år siden, og som det er i dag, kan man ikke bare slukke for 32-bit og tænde for 64-bit, og næste morgen forvente at hele verden kører i denne arkitektur. Det er en gradvis proces, hvor 32-bit langsomt over tid fases ud præcist, som det skete for 16-bit.
64 vs. 32
Der findes i dag overgangs CPU'er (produceret af bl.a. Intel og AMD), der kan håndtere et blandet miks af 32-bit og 64-bit instruktioner på én gang. Det er der både fordele og ulemper ved. I disse blandede miljøer kan nogle applikationer teoretisk være hurtigere i 32-bit tilstand, hvor 64-bit instruktioner optager mere
plads i forhold til 32-bit. Derfor kan der opstå situationer, hvor nogle 32-bit applikationer passer bedre ind i CPU cachen, og tilsvarene 64-bit ikke passer. Kort fortalt betyder det, at når der foretages context-switch for at behandle en 32-bit instruktion, mens en 64-bit instruktion er aktiv i memory, vil det optage en del
process-tid med at flytte til/fra hukommelsen, da instruktionerne, der optager adresseområder, har forskellige størrelser. Men f.eks. i videnskabelige applikationer, hvor instruktionslængden har en fast størrelse på 64-bit og derfor passer naturligt ind i arkitekturen, vil 64-bit være hurtigere, netop fordi CPU'en er designet til at håndtere blokke af denne størrelse. Det samme gør sig også gældende for en 32-bit CPU.
En anden væsentlig ting at kunne skelne, er nemlig selve tallet "64" i forhold til "32", da disse henviser til antallet af bit, som en CPU's General-Purpose Register (GPRs) kan indeholde. Så når man bruger begrebet 64-bit processor, menes der en processor, som har et GPRs, der kan indeholde "64-bit tal" og i samme vending
er en "64-bit instruktion" altså en instruktion, som opererer på 64-bit tal. Dette betyder, at registrene i en 64-bit CPU er noget bredere, faktisk dobbelt så brede, som i en 32-bit CPU.
Citrix og 64-bit
I april 2005 demonstrerede Citrix ved den forrige iForum konference i Skotland en version af Presentation Server, der kørte i 64-bit miljø. Dog var der fra Citrix' side ingen udmeldinger om en officiel udgivelsesdato for en "ægte" 64-bit version. Udgaven, de fremviste, var en modificeret udgave af deres 32-bit version. I oktober måned sidste år kom den så, den færdige Citrix Presentation Server 4.0 til Microsoft Windows Server 2003 x64. Denne version tillader at bygge bro mellem 32-bit og 64-bit applikationer på samme server. Det har ingen betydning om applikationen er 64 eller 32-bit, den vil stadigvæk kunne køre på enhver enhed via en Citrix klient - inklusiv tynde klienter. I og med at denne version af CPS tillader, at man kører et blandet udvalg af applikationer i enten 32 eller 64-bit på samme server. hvad den egentlige bevæggrund for at træde ind i et 64-bit miljø har været for Citrix. Deres produkter ligger jo ikke umiddelbart inden for kategorien "mega-databaser" eller viden-skabelige realtids simuleringer. Stadigvæk vil serverbased computing miljøer som Citrix kunne drage klar fordel af de muligheder der er åbnet op for i 64-bit miljø, og vi skal se hvorfor. I første del af artiklen antydede vi styrker, der gjorde en
64-bit CPU stærk i forhold til en konventionel 32-bit. Det er de styrker, som vil kunne forbedre performance og åbne op for nye muligheder i serverbased computing miljøer. Som det er i dag, er der en anbefalet grænse for, hvor mange brugere, man kan afvikle samtidig på en Citrix server, før de enkelte brugere begynder at kunne mærke en nedgang i performance. Afhængig af serverkonfiguration, og hvilke applikationer der afvikles, vil den anbefalede mængde være ca. 20-30 brugere pr. server. En af de mest fremhævede fordele ved lanceringen af den nye CPS 4.0 x64 version, er dens evne til hæve antallet af samtidige brugere pr. server betragteligt. Ifølge Citrix selv, en forøgelse på helt op til 65 % pr. server i forhold til den alternative 32-bit version.
Hvordan kan det så hænge sammen?
Som vi har set tidligere, er der en begrænsning i den mængde af hukommelse et 32-bit system er i stand til at adressere - nemlig 4GB. Med 64-bit arkitektur vil brugere kunne drage klar fordel af et system, der har mulighed for fx 256GB RAM og adskillige terabytes af virtuel hukommelse. Dette betyder, at mængden af brugere
pr. server pludselig kan sættes i vejret, uden at det skorter på performance. Ligeledes behøver applikationer fremover ikke være så visuelt begrænset, når de skal afvikles i et Citrix miljø, da hukommelse ikke længere er en begrænsende faktor. Dog skal man være varsom med ikke at smide hukommelse ud på fx multimedie-features, da
man bør være opmærksom på, at applikationer skrevet i 64-bit også fylder mere i hukommelsen. Så alt med måde gælder også her. Det er altså mængden af brugere og applikationer, der stiger pr. server, hvilket set med kundens øjne vil være med til at reducere total-cost-of-ownership (TCO), da færre servere kan klare mindst det
dobbelte...
Ny bruger
Nybegynder
Opret
Preview
