AMD en anderen over zin en onzin van 64-bit-processors

ExtremeTech heeft Dirk Meyer, Senior Vice President van Advanced Micro Devices, de vrije hand gegeven om een artikel te schrijven over het nut van het uitbreiden van de x86 architectuur met 64-bits registers en instructies. Nick Maclaren van The Inquirer heeft over hetzelfde onderwerp vorige week ook een artikel geschreven dat iets minder rooskleurig is dan het artikel van Dirk Meyer.

Een van de redenen die Dirk Meyer noemt om over te stappen op 64-bits cpu's heeft te maken met het adresseren van geheugen. Met 32-bits kun je 4GB aan geheugen aansturen, en dat zal volgens AMD binnenkort niet meer genoeg zijn. Applicaties worden namelijk steeds groter, en om deze te kunnen draaien heb je dus meer geheugen nodig. In de nabije toekomst zullen machines met meer dan 2GB aan geheugen volgens hem dan ook standaard zijn. Volgens The Inquirer is dat echter niet een goed argument. Met behulp van een techniek van Intel en Microsoft, die Physical Address Extension (PAE) heet, is het mogelijk om 64GB aan geheugen aan te spreken. De enige beperking vormen de processen zelf, die mogen namelijk niet groter dan 4GB zijn.

Het andere argument dat Dirk Meyer aankaart heeft te maken met bestanden. Deze zouden volgens hem niet groter kunnen zijn dan 4GB, omdat ook deze bestanden van 32-bits pointers gebruik maken. Volgens The Inquirer is dit echter een slecht argument. Een harde schijf is namelijk stukken trager dan een processor. Het uitrekenen van de waarde van een 64-bits pointer met behulp van twee 32-bits berekeningen neemt maar een fractie van de tijd in beslag vergeleken met het ophalen van de data. De gebruiker zal hier dus niks van merken.

Toch zijn er volgens The Inquirer ook goede argumenten om 64-bits instructies aan de huidige x86-architectuur toe te voegen. Als voorbeeld wordt een webserver genoemd waarop 256 threads op 16 cpu's draaien in een 32GB geheugen. Op zich geen probleem, zolang de threads niet met elkaar communiceren. Dat laatste is helaas bijna nooit het geval. Threads communiceren wel degelijk met elkaar en doen dat via shared memory. Je komt er in deze situatie dus niet onderuit om 64-bits pointers te gebruiken. De conclusie van The Inquirer is dan ook dat 64-bits cpu's vooral geschikt zijn voor zware servers. De thuisgebruiker zal er echter weinig baat bij hebben.

Reacties (97)

[Beaves]

Volgens The Inquirer is dat echter niet een goed argument. Met behulp van een techniek van Intel en Microsoft, die Physical Address Extension (PAE) heet,

Is het niet zo dat PAE langzamer werkt doordat er toch een vertaalslag moet plaats vinden?

In het begin (zeker de komende 1 1/2 jaar) zal de thuidgebruiker ook nog geen 4GB aan geheugen hebben, dus de thuisgebruiker heeft helemaal geen 64-bit nodig.

Alleen staat het leuk in advertenties en dus heeft 64-bit, voor thuis, zeker wel nut, het is gewoon een extra marketing mogelijkheid die AMD zeker zal aangrijpen. Het staat nou eenmaal leuk in de krant "Nu, een Athlon 64 met 64-bit instructies, voor nog sneller internet".

[Kwai_gon_jinn]

4GB aangeheugen lijkt me nog een verre dan nabije toekomst. Want applicaties hoor je te bouwen dat zo weinig mogelijk of zo efficient mogelijk met hun geheugen moet omgaan.
Hoe meer geheugen hoe meer "vertaalprocessen" die moet aanroepen waardoor het systeem "trager" loopt.

PAE zou eigenlijks sneller moeten werken dat wat efficienter om moet gaan met het geheugen. Maar of het trager is dan zonder PAE weet ik helaas niet

[Hertog_Martin]

Ehm programma's als Maya en 3dsmax enzo kunnen dat echt wel gebruiken hoor.

Gewone software voor de thuisgebruikers natuurlijk niet maar dat soort programma's gaat het erom dat het zo goed mogelijk is en dus niet dingen minderen om de systeemeisen te verlagen

de msi k8d master-l ondersteund 12gb aan geheugen.. met paar pc's zit je dan al snel op heel veel en denk dus dat die 64bit echt wel nodig is.

[Rapzar]

idd Ik heb een klein 3d-animatie bedrijfje van uit huis, en ga binnenkort wel naar 2Gb Ram upgraden. Dat is geen luxe, maar een 'must'. En voor een serieuze render is er geen alternatief (geweldige videokaarten of zo helpen nix voor je render-time).

Beavis en consorten hebben dus geen gelijk dat de ram-grens volgens huidige systemen niet te dicht bij komt voor sommige 'thuis-gebruikers'.

Hertog_Martin; Ik denk dat je altijd je scenes zult moeten aanpassen aan wat je systeem zoal kan. Je kunt natuurlijk van allelei trucken toepassen (freeze, hide, display as box, LOD-X-ref etc tijdens het werken ), maar als het er op aan komt om de mut te renderen zullen alle driehoekies en textures hun eigen plekkie in je ram zoeken, en je wilt niet dat je bij iedere frame moet gaan 'scratchen' op je hd. Bovendien denk ik niet dat ik over 10 jaar met mn 20 Gb Ram en een 64 Ghz proc me geen zorgen over mn systeem meer hoef te maken. Ik wil dan gewoon meer!

[Cookie]

Beavis en consorten hebben dus geen gelijk dat de ram-grens volgens huidige systemen niet te dicht bij komt voor sommige 'thuis-gebruikers'.

Nou nee, jij bent in feite al lang geen thuisgebruiker meer, maar een (semi-)professional zo te horen; en die werken in principe met workstations. Dat jij uit kostenoogpunt wellicht met een 'thuisgebruikerssysteem' en hoogstwaarschijnlijk ook met gekopieerde software werkt, is een ander verhaal .

[deputy]

Dat is niet helemaal waar. Op het moment ligt bij veel bedrijven het accent meer op betrouwbaardheid van software, omdat je performance wel kunt kopen.

In veel gevallen zul je dus zien dat het (kleine) aantal regels code en betrouwbaarheid voorrang krijgt boven het optimaliseren van CPU en geheugen gebruik.

[Verwijderd]

Een gemiddelde computer heeft nu zo'n 512 Mb aan boord. Over 1,5 jaar 1 Gb, over 3 jaar 2 Gb, over 4,5 jaar 4 Gb ...

[sHiKoRa]

Het standaard worden van grote van geheugen wordt naar mijn inzien voor een groot deel bepaalt door Microsoft Windows. Zo wordt bij iedere nieuwe Windows versie nieuwe hogere systeem eisen gesteld. Zoals je onderstaand kan zien kan je wel stellen dat iedere Windows versie het minimum en "recommend" geheugen verdubbeld. En zoals de meeste hier wel weten is het minimum vereiste geheugen écht het minimum en dat wanneer je games/zware applicaties op je PC draait dat je gerust het dubbele van het "recommend" geheugen kan nemen.

Systeemeisen:
Windows 95 Minimum: 8 MB Recommend: 16 MB
Windows 98 Minimum: 16 MB Recommend: 32 MB
Windows ME Minimum: 32MB Recommend: 64 MB
Windows 2k Minimum: 64 MB Recommend: 128 MB or higher
Windows XP Minimum: 128 MB Recommend: 256 MB or higher
Windows Longhorn Minimum: 256 MB?? Recommend: 512 MB or higher??

[it0]

Een gemiddelde tweakers computer heeft 512 mb aan boord een gemiddelde pc 128 MB. Let hier op het woord gemiddeld!

[Olaf van der Spek]

Alsof Windows de enige software is die hogere eisen stelt. Games zijn bijvoorbeeld ook veel groter geworden.

[Verwijderd]

True, heb onlangs m'n 512MB PC2700 reepje ingeleverd voor een 256MB PC3200-exemplaar, en hoewel aanzienlijk sneller (in theoretische benches) heb ik de dag nadien een reepje bijbesteld, 256MB is echt niet (meer) vooruit te branden, heb ik willen merken, hoewel ik dacht dat het voldoende zou zijn voor hetgene ik met m'n PC doe, mooi niet dus
<-- me

[Verwijderd]

lol

Das ook niet echt verwonderlijk waar moet windows immers alles laten zodra het geheugen effe vol/bezet/effe buiten bereik is ? Juist ja de harddisk en laat nou deze in ms sec werken en geheugen in ns dan remt wel een beetje af nietwaar ?

Ik zou zeggen laat die 2700 nou maar lekker draaien op 166MHz en prop die 3200's er gezellig bij. Met 1GB aan boord is windows zonder extra trukjes in het algemeen soepeler om mee te werken namelijk er wordt veel minder geswapped nietwaar ?

ps. Eigenlijk heeft windows veel meer geheugen nodig dan aanbevolen maar die truk van de swapfile doet het nog steeds erg goed Zet hem eens uit zou ik zeggen en zie binnen niet al te lange tijd wat Windows eigenlijk verbruikt en dan komt ineens de beperking van 4GB een stuk dichterbij. Uiteraard doet bijna niemand dat en waarom laat zich raden of course

[Cyphax]

Ik weet het niet... '64 bits!' zegt de gemiddelde thuisgebruiker toch niet zo veel... of je krijgt iets als 'ja m'n Nintendo 64 was ook al 64bits' ofzo en daar was het aantal bits eigenlijk niet meer dan een klassificatie voor snelheid, en de PC heeft daar de gigahertzen momenteel voor
Daar zullen ze dan wel wat voor moeten verzinnen.

Nog even dit: "enigste" staat in het artikel, maak daar liever "enige" van

[DEXSTAR]

En dat zeiden ze vaak ook over AGP8x ook maar die gingen als warme broodjes over de toonbank.
(Sterker nog ik heb zelfs meerdere mensen ervan geprobeert ervan te overtuigen en die geloven het zelfs niet eens en betalen toch de meer prijs ervan)

IK zou zeggen gaan met die marketing banaan, ik zal zelf ook zoveel mogelijk mensen aan een 64bitter te helpen of ze het nou nodig hebben of niet. LANG LEVE de concurrentie !!, dat AMD weer eens winst mag maken !!

[TheEagle]

En de Nintendo 64 was eigelijk geen 64 bits. Het waren 2 cpu's van 32 bits. Als ik me niet vergis 2 gemodificeerde 4400 risc cpu's van mips met een snelheid van 97Mhz.

[RetepV]

Was dat niet de Atari Jaguar waar jij het over hebt?

[zakalwe]

Die had volgens mij 2 x 16 bits paden naar het geheugen.

Oh nee...

Jaguar:
CPU's: 32/16-bit Motorola 68000, 32/16-bit RISC DSP, 64-bit OP, 32-bit/64-bit GPU Risc

[zakalwe]

De Nintendo 64 had een 64bit R4300 RISC CPU.
En de R4400 is ook een 64bit cpu.

[TheOneLLama]

PAE is *stukken* trager dan direct acces, maar nog vele vele [i]vele[i/] malen sneller dan HD acces. Oftwel met PAE heb je ipv gebruik maken van een HD swap file of iets dergelijks een vele malen sneller alternatief. Dat geeft al zo'n enorme vebetering in prestasties voor bijvoorbeeld een database, dat je je af kan vragen of "native" 64-bit nodig is.

Ook apple met hun nieuwe processor die wel degelijk in staat is om native 64-bit te doen, beperken zich voorlopig tot een paging oplossing (al zal die wat sneller zijn als PAE denk ik) voor gewone applicaties.

[TheEagle]

Een processor is niet alleen bezig met gegevens van de harde schijf af te halen. Hij is waarschijnlijk ook nog met een boel andere dingen bezig. Dus PAE is eigelijk een verspilling van waardevolle klok tikken. Waarom moet er zo moeilijk gedaan worden met PAE als je eenvoudig de geheugen bewerkingen kunt beperken door er 64bits tegenaan te gooien?

[mdvmine]

"PAE ipv swap" is onzin want swap wordt gebruikt als virtueel geheugen en dat is beperkt tot 2GB per proces. Met swap krijg je geen grotere grens, met PAE wel.

[Ingmar]

Alleen staat het leuk in advertenties en dus heeft 64-bit, voor thuis, zeker wel nut, het is gewoon een extra marketing mogelijkheid die AMD zeker zal aangrijpen.

Voorlopig (helaas voor AMD) wel ja. Het grote voordeel voor de Athlon 64 gebruiker zit hem voorlopig alleen in de on-die geheugencontroller, die een van de grootste bijdragen aan de prestatiewinst van de Athlon64 levert. AMD heeft gekozen voor het ontwikkelen van een proc die 64 bits is (en 32 tegelijk) omdat zij daar in de toekomst veel van verwachten. In dat ontwerp is die on-die geheugencontroller opgenomen, en aangezien AMD 64 bit asl de toekomst ziet, zou het een beetje nutteloos (lees: weggegooid geld) zijn om na de XP een volledig nieuwe native 32 bits met een dergelijk feature te ontwikkelen.

De consequentie is dan wel dat de consument dadelijk wordt "opgescheept" met een processor die qua mogelijkheden (niet perse qua snelheid) op het moment nog overkill is. Maar ik denk dat AMD weinig anders kan (en ook wil) want de xp-generatie is aan het eind van zijn latijn, zeker als je de progressie bekijkt van Barton tov Tbred.

Maar als de visionairen van AMD gelijk krijgen en 64 bit wordt daadwerkleijk DE hit, zitten ze imo gebakken, hoewel Intel natuurlijk Yamhill achter de hand heeft.

edit@alex4you:
Opteron/athlon64 zijn wel degelijk echte 64 bitters, als dat niet zo zou zijn, zou een opteron nooit native 64bit kunnen werken en dat kan ie dus wel, als je naar Itanium kijkt, dat is een 64bitter die ook echt alleen voor 64 bits aplicaties is. bij Itanium heb je juist een emulering nodig om 32 bits code te draaien. Maar dan heb je het over een heels specifiek product, terwijl de insteek van AMD juist is om de hgele markt te kunnen voorzien met 1 basisontwerp.

[Madrox]

Wil 1 ding verduidelijke:

De Althlon 64 is geen 64 bits. T's is gebaseerd op een 32bitter, maar dan 2 onder 1 kap en met een paar slimme ingrepen kan die ook 64 bit draaien. Da's toch net ff anders....

[miller82]

Het is misschien een 'achterhaald' bericht, maar kijk 's op http://www.tweakers.net/reviews.dsp?Document=191 waar ook in wordt vermeld dat AMD voortborduurt op de huidige x86-structuur.

Citaat: '...maar in tegenstelling tot Intel heeft AMD niet de moeite genomen om een compleet nieuw ontwerp te maken. In plaats daarvan is simpelweg hun bestaande architectuur uitgebreid met een aantal 64 bit trucjes'

[leuk_he]

Daar is toch niets mis mee? Wat verwacht je dan eingenlijk van een 64 bitter:

-Kan meer geheugen aan.
Ok, dan doen die paar "kleine" extensies.
-Is 2xzo snel.
Dat is het misverstand dat leeft,64 bits is niet 2x zo snel als 32 bits. Zo werkt het nou eenmaal niet. (ook niet op de G5)

[mdvmine]

Miller82:

Oke...maar mijn punt is dat het een enorm vaag statement is van alex4you. De feiten zijn dat die 64bit proc nieuwe 64bit registers en instructies daarvoor bevat. Gewoon 'effe' 2 32bitters onder 1 kap schuiven kan niet zo maar werken.

[mdvmine]

Bron aub?

[marsattacks]

Een belangrijk voordeel van x86-64 is dat de instructieset meer general purpose registers heeft (8 geloof ik). Iedereen die wel eens x86 assembly heeft geprogrammeerd weet hoe droevig weinig registers een pentium heeft.

Register access is veel sneller dan memory access dus dit zal native x86-64 programma's (en compilers) veel snelheidsvoordeel doen behalen. Daarnaast kunnen ze (omdat ze 64 bits zijn) veel meer data ineens verwerken.

Verder is de x86-64 instructie set veel netter dan de ouwe 32 bits instructies. Alle ouwe 8 bits meuk van de 8086 is er uit gegooid.

Voor iemand die in C of Java programmeert lijken dit misschien overbodige verbeteringen, maar een goeie compiler kan met deze wijzigingen veel snellere code genereren.

[YaPP]

hehe ik vraag me dat steeds af: willen ze gewoon graag 64 bit halen, of gaan ze werkelijk een betere instructieset ontwerpen?

Ik ben dan geen assembly programmeur (heb er ff aan mogen snuffelen) maar van alles wat ik lees krijg ik de indruk dat de huidige instructieset echt een regelrechte ramp geworden is. (of in ieder geval, wat gerelativeerd; niet geheel optimaal) Er zijn immers in 1980 beslissingen genomen wat voor die tijd verstandig was, maar nu geheel achterhaald.

even afgezien van gigantische compatibiliteitsproberen, waarom willen ze niet nieuwere betere architectuur ontwerpen?

[TheEagle]

even afgezien van gigantische compatibiliteitsproblemen

De Athlon 64bits cpu's zijn juist zo ontwikkeld dat ze GEEN compatibiliteits problemen krijgen. De CPU's kunnen moeiteloos 32bits en 64bit software door elkaar heen draaien. Daar heeft AMD extra veel aandacht aan besteed.

waarom willen ze niet nieuwere betere architectuur ontwerpen?

Vanwege de compatibiliteit. Kijk maar eens naar intels itanium processor. Dat beestje heeft veel potentieel. Maar hij is nog niet ver genoeg uit ontwikkeld waardoor zijn prijs kwaliteit verhouding achter blijft bij de huidige cpu's. En door de compleet nieuwe architectuur(EPIC i.p.v. risc of cisc) wordt hij in de mark nog maar heel langzaam geaccepteerd. Laat staan dat ie snel naar de consumenten markt toe kan.

AMD daarin tegen wil een goedkope 64bits cpu op de markt brengen die meteen gebruikt kan worden. door iedereen. Zowel bedrijven als consumenten. En dat is alleen mogelijk als je er goed voor zorgt dat het nieuwe platform geschikt is om oude software software te kunnen draaien. Er zitten maar weinig mensen op een nieuw systeem te wachten waar ze ook nog eens hun oude systeem langs moeten zetten om hun belangrijke "oude" software op te kunnen draaien.

Als een nieuw platform niet backwards compatible is dan zal het maar heel langzaam of helemaal niet geaccepteerd worden.

[boner]

ooit van Itanium gehoord?
dat was preces de reden voor Intel en HP om aan dat verhaal te beginnen.
x86 emuleren en een compleet nieuwe instructieset.

Dus een beetje het MS pad met WoW, win16 en sow. eigenlijk dus x86-on-itanium.

Native speeds zijn veel beter dan de geemuleerde. Dat dit nu een nadeel is, komt omdat het wordt overdreven in de verschillende forums. Op een Itanium server draai je nooit je echte core apps in x86 mode. Die zijn gehercompileerd en draaien in native mode. het evulutionaire pad is alleen maar een beetje een hobbelpad geworden.

Als Intel nu een Transmeta koopt en de code-morphing engine weet in te bouwen in die proc..........

[Bas!]

Mjah ik denk dat dat een vraag aan microsoft en softwareboeren is. Waarom niet linux draaien met een power4 of zo meteen een ppc970, een alpha, een arm of whatever je leuk vindt? Zal allemaal best werken, alleen kost zo'n stap voor microsoft waarschijnlijk te veel geld, dan melken ze liever op de huidige architectuur.
Legacy support is altijd belangrijk.
Intel heeft niet voor niets zoveel commentaar gehad over de performance van de x86-emulator voor de ia64 architectuur gehad, er draait gewwon nog ontzettend veel op.
Verder moet nog maar blijken of er api's zijn onder windows die de verschillende architecturen ondervangen. Ik weet niet in hoeverre de HAL dat doet.

edit:

beetje een dubbelpost, sorry

[lintux]

Verder is de x86-64 instructie set veel netter dan de ouwe 32 bits instructies. Alle ouwe 8 bits meuk van de 8086 is er uit gegooid.

Ten eerste: De 8086 was toch echt wel 16-bit.

Ten tweede: x86-64 is zo backward-compatible als morgen de hele dag, zoals we van de x86 architectuur gewend zijn. Theoretisch gezien is het nog altijd mogelijk DOS 1.0 te booten op zo'n machine. Het zou me weinig verbazen als dat in de praktijk ook zo blijkt te zijn. IOW, die zooi ligt er echt niet uit. Dan worden de bootloaders helemaal gek.

[marsattacks]

Die zooi ligt er uit in pure x86-64 mode: als je dus 64 bits programma's draait, gecompileerd met de x86-64 instructie set.

Ik had het niet over de compatibiliteits modus van de opteron, allicht dat de ouwe instructies het dan wel doen. Het OS bepaalt welke processen in echte 64 bits modus draaien (met alle extraatjes) of in 32 bits modus waarin je dat voordeel niet hebt.

[Olaf van der Spek]

Er is ook nog zoiets als cache. Data die nu in registers kan blijven zat in x86-32 in cache en cache-access kost niet zoveel tijd als memory-access.

[Verwijderd]

Natuurlijk kloppen deze argumenten, op dit moment. Totdat de programmeurs het voordeel zien van 64 bits, dan wordt het weer een ander verhaal.
Trouwens, hebben we dit soort argumenten toevallig ook gehoord bij de stap van 16 bits naar 32 bits ?
En kunnen we nu nog terug naar 16 bits ?

Voorlopig is voor de thuisgebruiker 32 bits de standaard, verwachting is echter dat over een paar jaar de standaard in ieder geval gedeeltelijk 64 bits zal zijn, en als het aan AMD ligt gebeurd dat binnen 2 jaar. Intel heeft de technologie achter de hand, zij waren iets voorzichtiger met de overstap (hadden ook PAE), wilden vermoedelijk eerst andere bottlenecks oplossen.
Voor de servermarkt ligt het zeker anders, meer is vaak beter. Zo ook datapadbreedte. En de x86-64-CPU's hebben hier en daar hun voordeel al bewezen.
Het zal voorlopig een heel stuk marketing zijn die het succes van de 64 bitters zal bepalen.

[jp]

Als programmeur heb je AFAIK weinig met 16/32/64 bit te maken, maar gebruik je alleen API's.

En als je nette code maakt, compiled het ook als je uint ineens 64 bit is

[Mizitras]

Wat met variabelen die je als 64-bit super doubledeluxe float wil initialiseren?

[Verwijderd]

32 = float
64 = double
80 = long double

[quote]Als programmeur heb je AFAIK weinig met 16/32/64 bit te maken, maar gebruik je alleen API's./quote]
Jij bent zeker een Java programmeur. Ga voor de lol es naar wat 16-bit code kijken, bijvoorbeeld de source code van Wolfenstein.

Verder ben ik 't ermee eens dat dat PAE verhaal gewoon himem 2.0 is. 64-bit CPU is de onvermijtbare opvolger van de huidige 32-bit.

btw zomaar een vraag maar een 64-bit CPU is toch ook veel krachtiger omdattie 2 keer zoveel bits tegelijk uitrekent? dus hij werkt veel efficienter met double bijvoorbeeld waarom lult iedereen alleen maar over adress space?

[Verwijderd]

Ehm... een standaard floating point nummer (double) is in bijna alle talen nu al 64 bit.

[Shockyboy]

Ja, je hebt gelijk. Een 64-bitter is wel efficienter met 64-bit integer rekenen dan een 32-bitter. De reden waarom dat niet of nauwelijks genoemd wordt, is omdat het ook niet of nauwelijks een probleem is. De meeste variabelen in een programma (tellertjes voor for... next, etc) hebben meer dan genoeg aan 64-bit.
De extra memory-capaciteit is al wel degelijk een bottleneck.

[Little Penguin]

Jij bent zeker een Java programmeur

Ook onder Delphi (Object Pascal) heb je weinig met de onderliggende implementatie te maken - Zolang je geen assembler gebruikt tenminste.

Hetzelfde geldt (in meer of minder mate) ook voor C/C++.

[Olaf van der Spek]

PAE is eerder EMS 2.

[Kahlan]

80 toch

[Verwijderd]

Als voorbeeld wordt een webserver genoemd waarop 256 threads op 16 cpu's draaien in een 32GB geheugen.

Wat een dom argument. Alsof iemand een dergelijk hardwareplatform zal gebruiken als webserver.
Men zal normaal voor veel "kleine" servers kiezen met een loadbalancer er voor.
Dit is volslagen onrealistisch.
8 dual CPU servers met 2GB geheugen zijn samen een stuk goedkoper dan 1 machine met 16 CPU's en 32 GB geheugen.

[TheEagle]

Als ik in mijn windows takenbeheer kijk dan lopen daar op dit moment 272 threads. Ik heb windows XP en de opera webbrowser open staan. Nu zullen een heleboel threads wel liggen te slapen natuurlijk. En ik heb op dit moment maar een cpu in mijn systeem zitten.

Maar er zijn toch threads genoeg die onderling met elkaar willen communiceren. Intel speeld daar al goed op in met behulp van Hyper Threading. Dat lever een groote snelheidswinst op.

En AMD probeert snelheids winst te berijken via een 64bits cpu.

Dus die webserver met 16 cpu's er in mag dan in werkelijkheid niet voorkomen. Het is volgensmij wel een mooi voorbeeld. En ben je het daar niet mee eens verander dan "webserver" in "super computer" of "huis tuin en keuken pc van de toekomst".

Trouwens ik denk dat het in de toekomst best mogelijk is dat dual cpu systemen ook toegankelijk worden voor de consument.

[farlane]

Hmmm,

Uitrekenen van een 64bit pointer mbv twee 32bit pointers.
Heeft wel wat weg van de oude dostijden waarbij een pointer uit een segment en offset bestond. ( Is niet geheel correct, maar het idee toch wel enigzins )

Ik kan me niet voorstellen dat we daarop zitten te wachten.

[Vorlon]

Jah, en dat is nu dus PAE...

Je hebt 64gb met een 4gb window erop. Die kan je dan verschuiven met een offset.

Dat is hetzelfde verhaal als dos met 32mb en dan ems en xms hacks erbij om alles te adresseren.

Als ik me trouwens goed herinner heeft elke pentium (vanaf de P60) die PAE ondersteuning. Ooit eens gelezen in een handleiding van een Intel P60 In Circuit Emulator.

[Big4SMK]

Ik vraag me toch af waarom een artikel over de zin en onzin?

In de toekomst zal het zowiezo nuttig zijn om 64bit te hebben. Op dit moment is alles nog netjes op te lossen met 32bit en dingen als PAE maar uiteindelijk zal de groei toch wel doorzetten. En als de 64bit architectuur pas losgelaten wordt op het moment dat het ECHT nodig is...dan is het wel mooi te laat...

edit:

over te laat gesproken, hierboven staat hetzelfde ongeveer....toch te laat gepost

[Verwijderd]

Ik snap het probleem niet helemaal.

Sowieso is 4GB toch zat voor de gemiddelde desktopmachine en tegen de tijd dat dat gaat wringen, dan is de consumentenmarkt al voor het grootste deel overgestapt op 64-bit processors.

En over de populariteit van 64-bit ben ik niet ongerust... Op computergebied blijkt altijd weer dat de behoefte van de consument toch voor 99% gekweekt is. Dus idd marketing-afhankelijk. En dat is een kwestie van tijd.

Of zie ik dat nou verkeerd...

[jp]

En een nut is: patsen.

Kijk mij eens! Ik heb een 64 Bit CPU!!!!1

(let op de "1" op het eind )

[Verwijderd]

Als je het bij 1 CPU houd ... tja dan is het patsen. IMHO zullen we het thuis in de toekomst niet meer met 1 CPU vol houden. En AMD maakt richting mulit-processor PC's nu wel de juiste stappen. Ik snap echter niet het laatste deel van het verhaal over het feit dat 64 bits daar aan bij zouden dragen. Het slaat volgens mij nergens op om laten we zeggen alle 16 CPUs aan te sluiten op één blok geheugen van 32GB. Ik zie meer in het idee dat elke CPU zijn eigen geheugen heeft en dat er een blok geheugen gedeeld wordt (zoals eigenlijk ook in het verhaal verteld wordt), maar waarom is die 64 bits dan zo belangrijk ???

[Verwijderd]

De meest eenvoudige architectuur is 1 CPU met geheugen en daarom per definitie het snelst en het meest betrouwbaar (KISS).

Q1: Waarom heb je 64 bit nodig?
A1: Omdat je meer dan 4GB wilt adresseren.

Q2: Waarom wil je meer dan 4Gb adresseren?
A2: Een database die groter is dan 4GB is niet abnormaal. Om de snelheid erin te houden wil je alle data in memory hebben. 4Gb is zo op.

Q3: Waarom geen PAE
A3: Deze techniek kennen wel al uit het DOS tijdperk en heeft vooral veel overhead. Geheugenblokken worden of geswapped of memorywindows worden verschoven. Het is applicatie transparant, dat wel, maar voor de snelheidsmaniakken onder ons nog te langzaam. Ik meen dat Windows 2000 DataCenter edition deze techniek ondersteunt.

Q4: Waarom geen meerdere processoren met eigen geheugen en een shared memory blok?
A4: Zie KISS stelling waarmee ik begon. Dit vereist nogal wat architectonische hoogstandjes. Verder heb je overhead zie A3. 64-bit multiprocessor is eigenlijk het enige echte valide optie voor de toekomst.

Q5: 32-bit instructie uitbreiden (AMD) of een clean room 64-bit (Intel)?
A5: Hmmmm, geen idee. Argument is dat AMD een ontwerp misbruikt en dat het daarom een tijdelijke oplossing is en dat er voor echte oplossingen ook een revolutie nodig is. Hmmm, hoe zijn we ook al weer van 16-bit naar 32-bit gegaan. We hadden een clean room 32-bit CPU die 16-bit boxen kon draaien voor DOS. Van de nieuwe software waren er 32-bits edities. Werkte best ok - soort revolutie dus.

[Olaf van der Spek]

PAE is niet applicatie transparant.
En 80386 was geen clean start maar gewoon een uitbreiding van de 80286 met x86 instructieset.

[Ritch]

Ik heb een 64bits Alpha bakkie staan hier die niet vooruit te branden is, ben ik nou ook een patser?

[Verwijderd]

gaan we weer terug naar af . . .

moeten we straks weer geheugen reserveren etc in himem, of nu dan PAE.
weer houtje-touwtje vlgs mij.

[Verwijderd]

Precies. Ik weet nog wel dat ik voor het eerst kennis maakte met 32-bit flat addressing. Zomaar een array van 1M bytes aanmaken zonder problemen.

Nee, dat was een stuk beter dan dat geklooi met expanded en extended en high memory, en dan nog maar 64kB per blok addresseren.

Vroeger werd gezegd dat 640kB genoeg was, nu durven mensen weer te roepen dat 4 (of 64) GB wel genoeg is. Tuurlijk, nu lopen de meeste dingen nog prima, maar alles groeit gewoon door, dus zeg over 10 jaar heb je echt wel meer dan dat nodig, en zal het nut van 64-bit processoren duidelijk zijn

(Ja ok, dan zijn ze misschien wat vroeg, maar dan hebben we ten minste tijd genoeg om het nieuwe 'millenniumprobleem' op te lossen voor het zover is )

[Verwijderd]

Quote uit een interview met Bill Gates, n.a.v. jouw opmerking over 640 kB memory:

QUESTION: I read in a newspaper that in 1981 you said, ``640K of memory should be enough for anybody.'' What did you mean when you said this?

ANSWER: I've said some stupid things and some wrong things, but not that. No one involved in computers would ever say that a certain amount of memory is enough for all time.

The need for memory increases as computers get more potent and software gets more powerful. In fact, every couple of years the amount of memory address space needed to run whatever software is mainstream at the time just about doubles. This is well-known.

When IBM introduced its PC in 1981, many people attacked Microsoft for its role. These critics said that 8-bit computers, which had 64K of address space, would last forever. They said we were wastefully throwing out great 8-bit programming by moving the world toward 16-bit computers.

We at Microsoft disagreed. We knew that even 16-bit computers, which had 640K of available address space, would be adequate for only four or five years. (The IBM PC had 1 megabyte of logical address space. But 384K of this was assigned to special purposes, leaving 640K of memory available. That's where the now-infamous ``640K barrier'' came from.)

A few years later, Microsoft was a big fan of Intel's 386 microprocessor chip, which gave computers a 32-bit address space.

Modern operating systems can now take advantage of that seemingly vast potential memory. But even 32 bits of address space won't prove adequate as time goes on.

Meanwhile, I keep bumping into that silly quotation attributed to me that says 640K of memory is enough. There's never a citation; the quotation just floats like a rumor, repeated again and again.

bron: http://www.urbanlegends.com/celebrities/bill.gates/gates_memory.html

[Cookie]

Tuurlijk, nu lopen de meeste dingen nog prima, maar alles groeit gewoon door, dus zeg over 10 jaar heb je echt wel meer dan dat nodig, en zal het nut van 64-bit processoren duidelijk zijn

Juist, maar over 10 jaar is IA-64 inmiddels al in tweedehands low-budgetsystemen aan te treffen .

Edit:
Waarmee ik probeerde aan te geven dat 64-bit in de toekomst pas echt nodig zal blijken, dat Intel daar al lang in voorzien heeft en niet te laat komt met z'n Itanium-serie, en dat de haast die AMD-desktopfans hebben t.a.v. 64-bit-cpu's gebaseerd is op een marketingverhaal over zogenaamde beperkingen van 32-bit-systemen. AMD kan maar één processorcore ontwikkelen i.t.t. Intel, en probeert daarmee nu in het marketinggat tussen x86-32 en IA-64 te springen met x86-64 in een tijd en marktsegmenten waar er eigenlijk nog geen noodzaak voor is, en met de oude strategie om op prijsconcurrentie van onderaf markten te betreden i.p.v. van bovenaf zoals Intel; Intel maakt wel winst, AMD niet.

[TheEagle]

Juist, maar over 10 jaar is IA-64 inmiddels al in tweedehands low-budgetsystemen aan te treffen

x86 achitectuur gaat ook al meer als 25 jaar mee.

[Beaves]

moeten we straks weer geheugen reserveren etc in himem, of nu dan PAE.

Zucht, nee, de gebruiker moet niets, alles wordt door de hard- en software gedaan, de gebruiker hoeft niets te doen en nergens aan te denken behalve aan het geld om meer als 4GB te kunnen kopen.

PAE bestaat al sinds de Pentium, alleen zijn de chipsets die het ondersteunen niet echt voor de thuismarkt bedoeld.

PAE lijkt op Extended geheugen, maar dat is het dus niet.

weer houtje-touwtje vlgs mij.

Nee, dat is het niet, het enige nadeel is dat het er een vertaalslag moet plaatsvinden waardoor je dus performance verlies hebt.

[mjtdevries]

Je software moet er speciaal voor aangepast worden om er gebruik van te kunnen maken.
Het is niet zuiver een hardware kwestie.

[arjankoole]

Je kan natuurlijk uren en wellicht veel langer duurzeuren over het wel of niet nuttig zijn van 64 bit, maar ik zie 1 doorslag gevend argument.

in 2024 ofzo raken de 32 bit seconden op, waarmee ieder systeem z'n tijd bijhoudt. Zie het als de y2k bug, maar dan reeel en veel linker.

nou zal je denken: da's nog ver weg, maar zo ver is het nog niet... en het is dan handig als de hele wereld al op 64 bit draait (en misschien al op 128 bit tegen die tijd) zodat je niet de gigantische chaos en stress hype krijgt die je bij de y2k bug zag.

als nu iedereen als zoetjes aan gaat overschakelen op 64 bit cpu's heb je over 20 jaar heel wat minder gedonder aan je koppie

[Verwijderd]

Dude!! je hebt het wel over 21 jaar hoor!!! er gebeurt ZO ontzettend veel in zo'n tijd!! kijk naar de laatste 21 jaar! tegen die tijd zullen we imho op dezelfde manier naar de 32 bits cpu kijken als dat we nu naar een 8088 (of lager) kijken! Dus ik denk niet dat het relevant is om je daar druk over te maken...

[Olaf van der Spek]

Om de tijd in een 64-bit variable bij te houden heb je geen 64-bit processor nodig maar slechts een compiler met support voor 64-bit variables.