Voorbeschouwing Windows XP 64-Bit Edition voor AMD64

Onze collega's van GamePC wisten de spreekwoordelijke hand te leggen op een pre-release-versie van Microsoft's Windows XP 64-Bit Edition. Naast het installeren en bekijken van dit OS besloot men ook een stapel technische documenten van AMD door te spitten, om op deze manier tot een voorbeschouwing te komen van wat er in x86-64-land komen gaat. Het ontwikkelen van software voor het 64-bit-platform komt langzaam op gang, omdat ontwikkelaars van software wachten op ondersteunende hardware, terwijl hardware-producenten op hun beurt wachten tot er software op de markt gebracht wordt die er gebruik van kan maken. Microsoft is enige tijd geleden echter al begonnen met het ontwikkelen van de voor AMD64-architectuur aangepaste versie van Windows XP en Windows Server 2003. Verder zijn er ook al diverse varianten van Linux en FreeBSD die de benodigde x86-64-extensies hebben, waarmee de Opteron- en Athlon 64-processors langzamerhand draagvlak vinden.

De installatie van het OS verloopt zoals we die gewend zijn, hoewel er voor installatie wel een check wordt uitgevoerd om te controleren of het systeem geschikt is voor het 64-bits OS. Na installatie blijkt dat Windows XP 64-Bit Edition standaard niet de flashy GUI gebruikt die we gewend zijn van de 'gewone' Windows XP. Natuurlijk zetten de sys-admins en power users die gebruik zullen gaan maken van dit OS deze grafische extra's vaak al uit, dus het is mogelijk dat MS al deze extra's standaard uit zet. Aan de andere kant moeten we wel onthouden dat het hier een pre-release-versie betreft, en Microsoft wellicht nog zal sleutelen aan de standaard desktop en de verschillende componenten van het OS. Wellicht zal de uiteindelijke versie van Windows XP 64-Bit dus toch standaard de bekende XP-look krijgen.

Verder is er op het eerste gezicht weinig revolutionairs te ontdekken aan het 64-bits OS. Een van de dingen die wél opvalt is de aanwezigheid van een 'gewone' Program Files-map en een Program Files (x86)-map, waarmee het OS de 32- en 64-bits applicaties gescheiden houdt. Ook levert MS een 32- en een 64-bits versie mee van Internet Explorer 6, zodat ontwikkelaars beiden kunnen gebruiken. Voorlopig is de 64-bit-IE6 sowieso nog niet geheel bruikbaar, omdat belangrijke plug-ins, zoals die voor Flash, nog niet vertaald zijn naar de 64-bits architectuur. Gelukkig zijn er hier en daar toch al directe voordelen verbonden aan het overstappen naar x86-64. Zo kan eindelijk de 4GB-grens voor geheugenaddressering overschreden worden, waarbij MS de lat meteen maar op 16TB (16.384GB) heeft gelegd . Bovendien biedt de 64-bits architectuur prestatiewinst wanneer speciaal voor de architectuur gecompileerde software wordt gebruikt, gemiddeld zo tussen de vijf en vijftien procent.

Hét grote voordeel van de AMD64-architectuur is natuurlijk het feit dat het systeem tegelijk om kan gaan met 32-bits en 64-bits applicaties, waarbij 32-bit niet geëmuleerd wordt, zoals bij Intel's Itanium, maar direct uitgevoerd kan worden. Om dat echter binnen Windows XP 64-Bit Edition te implementeren heeft Microsoft een extra 'laag' gecreëerd binnen het OS. 'Windows on Windows 64' (WoW64) is zowel in XP 64-Bit als in Windows Server 2003 64-Bit Edition aanwezig en heeft als taak de 32-bit naar 64-bit te vertalen, zodat het OS er mee om kan gaan. WoW64 wordt overigens ook gebruikt voor de 32-bit-emulatie van Intel Itanium-processors. Hoewel dit vrij negatief en inefficiënt klinkt, blijkt de praktijk gelukkig positief. Deze extra laag zou ongeveer één à twee procent prestatieverlies opleveren, dat volgens de technische documenten van AMD direct gecompenseerd wordt door de toegenomen efficiëntie van de 64-bit-drivers en -geheugenaddressering. Al met al zouden 32-bits applicaties dus net zo snel moeten draaien als op de huidige 32-bit-versie van Windows.

Tot nu toe ziet de toekomst van de AMD64-architectuur en de bijbehorende Windows-versies er rooskleurig uit, maar met de 64-bit-driverondersteuning lijken we op een stevig probleem gestuit te zijn. De acceptatie van het platform door een brede groep gebruikers hangt namelijk in directe mate af van de beschikbaarheid van drivers voor IDE en SCSI controllers, netwerkkaarten, videokaarten, et cetera. Microsoft levert in het 64-bits OS wel native Microsoft-drivers mee, maar hiermee is nog lang niet alle huidige hardware ondersteund, laat staan oudere en meer exotische hardware. GamePC probeerde dan ook of de 32-bit-drivers voor hun Adaptec 2100S Ultra SCSI RAID controller op het 64-bits OS geïnstalleerd konden worden, maar daar steekt het systeem een stokje voor.

Dat betekent dus dat er voor alle hardware nieuwe, 64-bits drivers geschreven moeten worden. Dit proces zal veel tijd in beslag gaan nemen, en bovendien hangt de acceptatie van het hele x86-64-platform hiermee sterk af van de bereidwilligheid van hardware-producenten om speciale drivers te ontwikkelen voor dit platform. GamePC merkt hier overigens terecht op dat ook Intel een belangrijke speler is in de hardware-markt, en het zal dan ook uiterst interessant zijn om te zien of Intel x86-64-drivers gaat ontwikkelen voor zijn netwerkkaarten, RAID controllers, etc. Bedrijven als Broadcom, 3Com, nVidia, ATi en Adaptec zouden bij de introductie van het 64-bits OS wel drivers klaar hebben, maar de vraag is met name hoe snel zulke drivers in de toekomst ontwikkeld zouden worden; tegelijk met x86-drivers, of met enkele weken of maanden vertraging? De laatste optie zou namelijk een groot nadeel zijn in de ogen van veel enthousiasten, van wie verwacht wordt dat ze de AMD64-kar na introductie zullen gaan trekken. Uiteindelijk moeten we niet vergeten dat de hier bekeken versie van Windows XP 64-Bit Edition een pre-release-versie is, en dat er voor de introductie nog veel kan veranderen:

Of course, please consider that the operating system we're looking at today may look and function in a completely different manner. The current variant of Windows XP 64-bit Edition for AMD 64 is still in the pre-beta stages, and likely won't be hitting production-level quality for another few months. It's quite clear that Windows XP 64-bit for AMD64 will not be released in time for the Athlon 64 launch later this month, as was originally planned. Judging by our time with the operating system, our guesstimate would be that Microsoft could have a very solid product by the end of this year, which should be just when Opteron and Athlon 64 support is starting to pick up.

Just like Windows XP 64-bit Edition for Itanium, it is not expected that Windows XP 64-bit Edition for AMD64 will be widely released as a retail product. Pricing for the OS and how it will be distributed are still up in the air.

Reacties (84)

[Neus]

Dat betekent dus dat er voor alle hardware nieuwe, 64-bits drivers geschreven moeten worden.

Prima! Dus snellere drivers voor nog meer performance. Was bang dat 'oude' drivers een nieuwe bottleneck zou worden. Prima artikel trouwens.

Ps: je kan deze versie gewoon bij MSDN downloaden, mits je een geldige abbo hebt.

- Windows XP 64-Bit Edition For AMD 64-Bit Systems, Checked/Debug Version Beta Build 1039 (English)

- Windows Server 2003 Enterprise Edition For AMD 64-Bit Systems, Checked/Debug Version Beta Build 1039 (English)

- Windows Server 2003 Standard Edition For AMD 64-Bit Systems Beta Build 1039 (English)

[Olaf van der Spek]

Prima?
64-bit code is niet per definitie sneller dan 32-bit code.
Nu is het wachten op drivers voor alle hardware. Voor Windows 64-bit zal dat niet zo'n groot probleem zijn, maar voor Linux en andere exotische OSs zijn drivers bijvoorbeeld wel een probleem (geweest).

Ps: je kan deze versie gewoon bij MSDN downloaden, mits je een geldige abbo hebt.

Ik ben bang dat je er geen 64-bit CPU bij krijgt, dus dat is alleen interessant voor de paar tweakers die er al een hebben.

[Countess]

onder linux compileer je de drivers zelf.
jij krijgt de source en compileert gewoon voor 64bits
ok je kan dan (niet altijd) gebruik maken van de extra voordelen van 64bits maar het werkt wel gewoon op een 64bit OS.
daarnaast is het mogenlijk in de source te rommelen en te optimalizeren voor 64bits. kan je dit niet zelfs zullen er voor de meeste hardware wel 3de party (door mensen thuis) aangepaste drivers komen.
als de drivers er zijn (voor ATI zijn linux drivers schaars BV) dan kunnen ze werken met een 64bit OS.

[jiriw]

<reactie op DenDave>

Hihi daar ga je volgens mij toch mooi de mist in ....

Er zijn op het internet al verschillende ports te vinden van de GNU-GCC compiler voor AMD64. Dat is echt niet veel werk want GCC compileert al jaren voor 64 bit (o.a. Alpha) .. Je kan natuurlijk wel wat optimalisaties toevoegen voor specifieke hardware maar absoluut nodig is dat niet. Het draait alleen niet optimaal snel. Bovendien zijn die plaatsen waar je CPU optimalisaties in staan beperkt tot een paar headerfiles.

Vervolgens is alles te compileren met een z.g.n. cross compiler totdat je genoeg hebt om je systeem te booten en er mee te kunnen compileren.

Het is dus wel zo eenvoudig. Als je LFS kan kan je ook een systeem bouwen voor de AMD64.

En anders pak je gewoon een distro. Suse en Mandrake adverteren al druk met hun beta distro's voor de AMD64.

[Anoniem: 25586]

jouw post confirmde eigenlijk al wat ik vermoede, maar ik vraag het toch even

is het nou zo dat dit x86-64 verhaal echt DE tussen stap word? ofwel, de x86-64 kan zowel 32bit als 64bits code uitvoeren, de x86 kon enkel 32bits code aan, en de itanium enkel 64bits, dus dit betekent dat de oude windows programma's hierop werken, en de nieuwe 64bit proggies die normaal enkel op 64bit CPU's zouden draaien zoals dus de itanium? of zitten we straks WEER met een 'overstap' als we naar true 64bits computing gaan.

[TGEN]

AMD64 en IA64 zijn twee verschillende 64bits tegnologieen. De Opteron en Athlon64 maken gebruik van AMD64, de Itanium(2) van IA64. Dit zijn twee verschillende platformen, net als de 64bits Alpha verschilt van een 64bits SPARC. AMD64 is dus geen tussenstap tussen IA32/i386 en IA64, maar een directe concurrent voor IA64.

[Anoniem: 32075]

Gewoon effe compileren?

Nou dan heb je ten eerste nog een compiler nodig.. en voor zover ik weet is ie er nog niet... althans niet specifiek voor amd 64 bits.. dan nog, moet je redelijk wat naslagwerk opentrekken omdat je libs en .so 's er nog niet zijn... het is niet zo eenvoudig als je het voorstelt. x86-32 is vrij simple maar waar het hier om gaat is zeker nog niet klaar. Wellicht zal AMD wel snel komen met een c, C++, fortran compiler maar eer dat GCC enz full AMD64 zijn... hrmm..
'

[deadinspace]

Nou dan heb je ten eerste nog een compiler nodig.. en voor zover ik weet is ie er nog niet

Ooit van GCC gehoord? Of waar dacht je dat de huidige x86-64 GNU/Linux versies (zoals oa. SuSE al aanbiedt) anders mee gecompiled werden?

[edit: Hmm, iets te laat ]

[deadinspace]

Nu is het wachten op drivers voor alle hardware. Voor Windows 64-bit zal dat niet zo'n groot probleem zijn, maar voor Linux en andere exotische OSs zijn drivers bijvoorbeeld wel een probleem (geweest).

Hier zou GNU/Linux (en andere Free OSsen) wel eens in het voordeel kunnen zijn.

In GNU/Linux zijn het overgrote deel van de drivers Free software, net als GNU/Linux zelf. Dit houdt onder andere in dat de source vrij beschikbaar en aanpasbaar is. Bovendien zitten deze drivers ook bij de stock kernel releases, dus als de kernel geport wordt naar x86-64 (wat al gebeurd is), dan motiveert dat meteen om de drivers ook te fixen.

Met proprietary, closed-source drivers daarentegen ben je volledig afhankelijk van de goodwill van de fabrikant. Als zij (nog) geen zin hebben nieuwe drivers te maken, dan heb je gewoon pech. Deze afhankelijkheid is in mijn ogen ook een groot nadeel van proprietary software.

Voor GNU/Linux zijn er ook wel proprietary drivers (zoals NVidia's drivers), maar dit is maar een zeer klein deel van de drivers. Windows daarentegen kent vrijwel uitsluitend proprietary drivers, en is daarom in zijn geheel afhankelijk van de hardware fabrikanten.

En als je het artikel had gelezen, dan hebben ze oa een SCSI kaart en een Intel netwerkkaart (beiden wel ondersteund in de gewone Windows XP) niet werkend gekregen.

[Fairy]

Ik kan me vergissen, maar voor Linux ZIJN er al 64 bits versies, denk maar aan de 64 Bits RISC versies.

Linux/Unix kun je met gemak al bijna op een stuk hout draaien dus x86-64 zal ook wel niet lang duren denk ik.

Vooral voor bedrijven als SuSe, Redhat en Mandrake is het juist een race om als eerste een 64 bits versie klaar te hebben.

[Olaf van der Spek]

Dat klopt, maar wat is de relatie met mijn post?

[EfBe]

Bovendien biedt de 64-bits architectuur prestatiewinst wanneer speciaal voor de architectuur gecompileerde software wordt gebruikt, gemiddeld zo tussen de vijf en vijftien procent.

Die winst heeft overigens niets te maken met 32bit vs 64bit maar met de nieuwe processor die dan niet 32bit hoeft te emuleren en de nieuwere architectuur van de processor.

Verder is er geen user programma te vinden dat door veel mensen zal worden gebruikt dat meer dan 2GB fysiek geheugen nodig heeft, dus zo nodig is die 64bit niet, wel is het wellicht nuttig als je de de nieuwe architectuur van de processor kunt benutten.

[dmantione]

Otis: In 64-bits mode hebben de hamers twee keer zoveel registers. De prestatiewinst daarvan is aanzienlijk, in sommige situaties spectaculair.

Het gebruik van 64 bits pointers zal applicaties afremmen, vanwege de grotere hoeveelheid data die heen en weer bewogen wordt. De x86-64 staat echter ook 32 bits pointers toe in 64 bits mode, zodat als je programma geen 4GB geheugen nodig heeft je dit nadeel niet hoeft te hebben. Ben benieuwd of compilers dit toe gaan staan.

En uiteraard gaan 64-bits operaties die nu gesimuleerd worden veel sneller.

[Olaf van der Spek]

Maar de CPU hoeft helemaal niks te emuleren voor 32-bit code, 32-code wordt gewoon native ondersteund.

[MacD]

Nou en? Leuk dat ik 32 bit code op een 64 bit platform kan draaien...maar ik heb (zelfs als 3d-er/matlab-er en CAD/CAM-er) niets aan meer dan 4gig geheugen. Ik ben al blij dat ik 1 gig heb, en is bijna geen geval te bedenken dat ik meer dan 2 gig nodig heb.

Feit is en blijft dat je alleen wat hebt aan 64 bits als je een gigantische server(s) draait of grote databases moet aanspreken. De gemiddelde (en zelfs de cutting edge) tweaker heeft dan ook nooit voordeel met het 64-bits systeem. De servers van twekers.net wellicht wel, maar zelfs dat is afhankelijk van de grootte van hun backend data.

[bille]

"640kb should be enough for everybody"

Het is gewoon een kwestie van tijd voordat je met textures van 10MB per stuk gaat werken.. en objecten met miljoenen.. miljarden polygonen. En dan ben je ineens blij met een 64bit cpu en 16TB geheugen

[Anoniem: 14842]

Nou en? Leuk dat ik 32 bit code op een 64 bit platform kan draaien...maar ik heb (zelfs als 3d-er/matlab-er en CAD/CAM-er) niets aan meer dan 4gig geheugen. Ik ben al blij dat ik 1 gig heb, en is bijna geen geval te bedenken dat ik meer dan 2 gig nodig heb.

Staar je niet blind op geheugen adressering. Het is inderdaad leuk dat je 4GB+ rechtstreeks kunt benaderen, maar voor de non-server markt niet erg relevant.

Wat wél relevant is is het feit dat deze processor berekeningen van meer dan 32bits (cad/cam/simulaties) efficiënter kan uitvoeren, dus sneller dan een 32 bits. En dan nog de snellere architectuur, waardoor deze processor gewoon sneller is.

Daarbij komt nog dat het nú nog niet nuttig is, maar in de toekomst zeker wel. Of denk je dat over 5 jaar 1GB nog steeds erg veel is? Als iedereen zo zou denken dan waren we nu aan het photoshoppen met 640k (kopje koffie?)

En voor mij is de geilheidsfactor ook erg belangrijk. Vergis je niet in de "pats factor" als een consument een nieuwe pc koopt

[SG]

D'r zijn al aps gebenched op AMD64 OS en zoals Ut2003 64 versie en er is ene prestatie winst

Gamers een prestatie hongerige doelgroep van de desktopmarkt heeft er dus wel degelijk baad bij.
Zelfs ook al getest op de mobile Athlon64

En het resultaat is dat er duidelijk een prestatie verschil is tussen 32bit mode en 64bit mode.

dus SSE en SSE2 is niet het hele verhaal

Denk bijvoorbeeld aan een in IA32 dubbele 32bit flag variable wat nu één 64bit flag variable kan zijn.
ene vereist twee stappen de ander een 2x performance winst minus overhead d'r zijn geheid veel mee rvoorbeelden die niet opgevangen konden worden door SSE(2) waar dit dus ook voor geld.

Daarbij worden de SSE & SSe2 aangestuurd op 64bit manier voor hun 128bit registers te vullen.

[Olaf van der Spek]

Waar zeg ik dat 64-bit voor de gewone gebruiker binnenkort nuttig is?

Bovendien is die 32-bit grens niet alleen van toepassing op fysiek geheugen maar ook op virtual geheugen.

[Olaf van der Spek]

Wat wél relevant is is het feit dat deze processor berekeningen van meer dan 32bits (cad/cam/simulaties) efficiënter kan uitvoeren, dus sneller dan een 32 bits. En dan nog de snellere architectuur, waardoor deze processor gewoon sneller is.

Daar gebruik je toch 64-bit floating point (iets dat de 8087 FPU al had) voor?

[Countess]

64bit is wel nutis. zeker voor prestie winst.
de 64bit versie van UT2k3 liep BV sneller in 64bit dan in 32bit op het zelfde platform (dus zelfde OS (linux) en spel, 1 keer gecompileert voor 32bit en 1 keer voor 64bit.
de 64bit complilatie gebruikte wel optimizers voor 64bit. doe je dit niet zal 64bit niet of nowelijks sneller draaien als 32bit software op de athlon64 (de prestatie winst komt dus puur uit de extra mogenlijkheden die 64bit bied en niet omdat de CPU sneller is met 32 dan wel 64bits)

[Femme]

Staar je niet blind op geheugen adressering. Het is inderdaad leuk dat je 4GB+ rechtstreeks kunt benaderen, maar voor de non-server markt niet erg relevant.

Wat wél relevant is is het feit dat deze processor berekeningen van meer dan 32bits (cad/cam/simulaties) efficiënter kan uitvoeren, dus sneller dan een 32 bits. En dan nog de snellere architectuur, waardoor deze processor gewoon sneller is.

SSE en x87 floating point heeft al een precisie van 64-bit of hoger. Integers groter dan 32-bit worden weinig gebruikt omdat het dynamisch bereik van een 32-bit integer (4,3 miljoen mogelijkheden) voor de meeste toepassingen meer dan voldoende is.

32-bit geheugenadressering gaat voor workstationgebruikers op niet al te lange termijn een echte beperking vormen. De problemen komen al in zicht als applicaties meer dan 2GB willen gebruiken. Tim Sweeney heeft al gezegd dat ze bij Epic dagelijks tegen de 2GB limiet van Windows oplopen. Voor de development tools van de volgende engine zal 64-bit een praktische vereiste zijn. In de animatiewereld (bedrijven als Pixar, ILM en Weta Digital) zullen ze ook graag betaalbare 64-bit workstations zien. Het is een kwestie van enkele jaren voordat 32-bit voor de zwaardere desktoptoepassingen een beperking wordt.

De meeste winst van AMD64 zal het gevolg zijn van de extra registers. Het gaat dan nog steeds om maximaal zo'n 20 procent prestatiewinst dus niet echt wereldschokkend.

[TGEN]

80bits intern, met 64bits registers.

offtopic:
T valt me op hoe slecht t staat met t Nederlands twee posts hierboven...

[_JGC_]

Jij hebt ook liever een 286 dan een 386

Nou leuk dat er nog steeds Windows 3.1 op mijn 386 kan draaien, nou en? dat draait op mijn 286 ook wel.

[Anoniem: 41851]

'Windows on Windows 64' (WoW64) is zowel in XP 64-Bit als in Windows Server 2003 64-Bit Edition aanwezig en heeft als taak de 32-bit naar 64-bit te vertalen, zodat het OS er mee om kan gaan.

Windows XP 64-bit behandelt dus de 32-bit applicaties netzoals Windows XP32 de 16-bit applicaties afhandelt.

Windows XP draait standaard alle 16 bit applicaties in dezelfde geheugenruimte. Als 1 applicatie crasht, dan kan het hele 16 bits subsysteem binnen de WoW laag crashen. Er is een instelling om elke applicatie zijn eigen geheugenruimte te geven. Dit kost echter zeer veel geheugen, want voor elke 16 bit applicatie wordt een WoW laag gecreëerd.

Wat zal de standaard instelling zijn in XP64?

Als alle 32 bit applicaties in dezelfde geheugenruimte draaien, dan zullen deze applicaties op XP64 meer problemen geven/onstabieler zijn dan op XP32. 1 app kan namelijk het hele 32 bit subsysteem laten crashen.

Aan de andere kant is het ook bijna ondoenlijk om elke applicatie zijn eigen 32 bit WoW laag te geven... ik denk dat dit heel erg veel geheugen gaat kosten.

(OS/2 had vroeger Win-OS/2, een aangepaste versie van Windows 3.1 onder OS/2. Men kon alle Windows 3.1 programma's in 1 Win-OS/2 draaien, maar als er 1 neerstortte, dan ging heel Win-OS/2 er ook aan. Je kon ook voor elke applicatie een aparte Win-OS/2 sessie starten, maar dat kostte zo'n 2 MB extra per app, wat toen, in 1994, heel erg veel was.)

[Brent]

Overigens zullen 16-bit applicaties niet meer werken onder Windows 64-bit.

Maar wat ik mij afvraag is waarom Microsoft heeft besloten zo'n laagje ertussen te stoppen.

[Anoniem: 41851]

Dat is nogal duidelijk. De vertaalslag is wel wat trager dan directe ondersteuning door het OS, maar het is veel stabieler. Kijk maar naar Windows NT/2000/XP: die draaien 16 bit applicaties enigszins trager dan Windows 9x. Dat komt omdat NT/2000/XP geen directe ondersteuning voor 16 bit hebben (die loopt via de extra WoW laag), en Win9x wel.

Zou je echter een hybride 32/64 bit OS willen? We zijn nét met Windows XP af van de Win9x hybride crime, in het mainstream segment. (Dat wil zeggen dat vanaf nu de mensen thuis een op NT gebaseerd systeem gebruiken.)

De WoW laag werkt goed, dat hebben Windows NT en opvolgers bewezen. Als het voor 16 naar 32 bit goed werkt, dan zal het ook goed werken voor 32 -> 64 bit.

Het heeft niet erg lang geduurd voordat mensen volledig overgingen op 32 bit. In het eerste jaar of zo werden er onder Windows 95 nog Win31 programma's meer gebruikt, maar eind 1996 waren de meeste Win31 programma's wel uitgefaseerd.

Als het AMD systeem doorbreekt, en Intel introduceert ook een 64 bit processor voor consumenten, dan zal de overstap op 64 bit ook niet langer duren dan 1 tot 2 jaar. Blijft het AMD systeem alleen, terwijl er ook nog 32 bit processoren worden doorontwikkeld, dan zal het overstappen veel langer duren, zeker als de 64 bit processoren en systemen duurder zijn dan de 32 bit versies. Dan hoop ik voor de "early adopters" dat XP64 een goede WoW heeft, want die moet dan nog wel een paar jaar mee.

[Anoniem: 88387]

er is wel een groot en belangrijk verschil bij de overstap van 32-64 vergeleken met 16-32.

bij 16 naar 32 bits werd je gedwongen over te stappen doordat ms windows dat vereiste. het draaide gewoonweg niet op 16 bits processoren (vanaf 386 werkte het). echter, alle nieuwe processoren waren ook 32 bits en compatible met i386; er was dus genoeg kritieke massa om dit af te dwingen.

de situatie nu met amd64 is volstrekt anders. je kunt eventueel overstappen, uit eigen vrije wil, naar 64 bit windows. voorwaarde is wel dat je een amd 64 processor hebt (beperkte doelgroep). echter: zowel de amd64 als de intel pentiums draaien uitstekend 32 bits versies van windows. bovendien is het aandeel amd64 minimaal en dat blijft voorlopig nog wel even zo. alleen als intel de x86-64 instructieset licenseert van amd zie ik genoeg kritieke massa ontstaan (dit is echter een hoogst onwaarschijnlijk scenario, waarschijnlijker is dat intel de yamhill troefkaart uitspeelt.).

de overgang naar 64 bits windows is door dit kleinere draagvlak en de duidelijk geringere meerwaarde er van dus niet vergelijkbaar met de overgang naar windows in protected mode (16 naar 32).

[toevoeging]

de intel 386 processor was de eerste 32 bits x86 variant en werd geintroduceerd in 1985. in 1990 werd windows 3.0 gereleased. windows 3.0 heeft als requirement minimaal een 386 processor. inmiddels was in 1989 de 486 al gereleased. de 386 was alweer opgevolgd voordat windows ook maar gebruikt had gemaakt van de 32 bits protected mode mogelijkheden van die processor. de markt moet dus verzadigd zijn van een bepaalde processorarchitectuur voordat een bepaalde variant van windows echt aan kan slaan.

http://www.computerhope.com/history/windows.htm
http://www.wikipedia.org/wiki/List_of_Intel_microprocessors

[/toevoeging]

[Anoniem: 41851]

Als je het vanuit het oogpunt van de processor bekijkt, dan heb je gelijk. Het heeft 10 jaar geduurd voordat er voor de "standaard-consument" een 32-bit OS op de markt kwam. 10 jaar lang zijn de 32-bit processoren onderbenut geweest.

Bekijk je het echter vanuit de kant van het OS, dan is de overstap snel gegaan. Toen er eenmaal een 32-bit OS uit was, waren de meeste mensen binnen 1 tot hoogstens 2 jaar compleet overgestapt.

Nu komt de eerste 64-bit processor op de markt die voor consumenten betaalbaar is. Er is echter ook al een OS beschikbaar (of komt binnenkort beschikbaar), en niet over 10 jaar. Als ik een 64-bit systeem koop, zal ik er zeker een 64-bit OS op draaien. Alles of niks. Ik denk dat de meeste mensen (zeker diegenen die er wat meer vanaf weten) dit ook willen, vanuit de gedachtengang: "Waarom zou ik een 64 bit computer kopen als ik toch alleen maar 32 bit programma's kan draaien?"

De overstap zal dit keer sneller gaan, als het AMD systeem aanslaat. Indien Intel uitkomt met een x86-64 compatible processor (Yamhill in de Pentium4/Pentium5 ?) dan gaat de overstap snel geregeld zijn. Blijft Intel voor de consumentenprocessors bij 32 bit, dan wordt het moeilijker...

Komt Intel uit met een 64-bit processor (mét 32-bit ondersteuning) die op 64-bit gebied NIET compatible is met AMD's proc (een die dus weer een ander 64-bit OS nodig heeft), dan wordt het nóg veel ingewikkelder.

[TD-er]

Je vergeet een heel groot ding, namelijk dat de CPU's ten tijde van de introductie van windows '95 eigenlijk vrijwel allemaal al 32-bits waren.
Vanaf de 386 DX is de x86 al 32-bits namelijk. In '95 waren er ook al mensen die een Pentium hadden. Kortom het heeft dus van de 386 tot de Pentium geduurd voordat er voor de gewone consument ook echt veel 32-bits apps en een OS verschenen.
Nu zal dat allemaal wel iets sneller gaan, maar ik vrees dat het grootste deel van de gedraaide software in het begin toch wel 32-bits apps zullen zijn.

[Garyu]

Ik denk dat je hier een goed punt maakt, maar is er wel zo'n groot verschil tussen de overstap 32-64 en de overstap 16-32? De processors gaan eerst om naar 64-bits architectuur, en een tijdje later volgt de software vanzelf.

De Hammer ondersteunt toch native 32-bits? Dan is Windows XP "Original" geen probleem.. Het maakt alleen niet ten volle gebruik van de mogelijkheden van de processor. De gemiddelde thuisgebruiker zal het verschil niet merken. Als het aanbod 64-bits processors maar voldoende stijgt (lees: marketpush), dan zullen mensen vanzelf overstappen. Misschien duurt het even, maar waarom haast maken? De overstap 16-32 ging goed, dus zal het hier ook wel goedkomen.. Het is nou eenmaal 'natuurlijke' evolutie.

[Anoniem: 41851]

De Hammer ondersteunt toch native 32-bits? Dan is Windows XP "Original" geen probleem.. Het maakt alleen niet ten volle gebruik van de mogelijkheden van de processor.

Dat is juist WEL een probleem. Als de 64 bit processoren worden gebruikt, maar iedereen blijft hangen bij 32 bit software omdat die toch wel werkt, dan evolueert de software niet met de hardware mee. Dat moeten we niet hebben. Als het wéér 10 jaar duurt, tot 2014 of zo voordat alles 64 bit is, dan heeft AMD nu voor niks een processor op de markt gebracht met 64 bit mogelijkheden.

De overstap van 16 naar 32 bit is echt NIET goed gegaan voor de gewone consument. De processor was er al in 1985, maar de Windows OS'sen bleven 16 bit tot 1995. (Het enige 32 bit OS dat kans maakte bij de consument vanaf 1986, en die verspeelde, was OS/2.) Toen kwam in 1995 de hybride Windows 95 op de markt, die onstabiel was, zeker als er nog 16 bits programma's werden gebruikt. Win95 ondersteunde zelfs vele 16 bits DOS en Win31 drivers, die de stabiliteit niet ten goede kwamen.

Edit: Win95 werd toch het besturingssysteem voor consumenten, ondanks dat OS/2 zwaar superieur was qua specificaties en performance. De bekendheid van MS en Windows, en de goede ondersteuning van DOS/Windows 3.1 (vooral van spellen!) in combinatie met een fenomenale marketing, brachten OS/2 de genadeslag.

Nu starten we beter, in de overgang naar 64 bit: het consumenten-OS WinXP64 is niet hybride, maar volledig 64 bit (hoop ik), met een WoW laag zoals in 2000/XP, met volledig 64 bit drivers. Laten we dan ook alles meteen goed doen, en met de 64 bit processor ook een 64 bit OS gaan gebruiken. Dan kunnen alle volgende versies van programma's ook 64 bit worden, en dan zijn we binnen 2 jaar over.

OT: (Het wordt tijd dat ik erover ga denken om 1 computer vast te houden om oudere spellen te draaien. Er zijn een paar spellen die koste wat kost moeten blijven lopen, zoals alle Infinity Engine spellen... Baldur's Gate en consorten.)

[Femme]

Het draagvlak voor een 64-bit Windows wordt vanzelf groter zodra er een noodzaak ontstaat voor >32-bit geheugenadressering. Met keuze uit twee architecturen (IA-64 en AMD64) heeft iedereen ruim de tijd om zich op die overgang voor te bereiden.

alleen als intel de x86-64 instructieset licenseert van amd zie ik genoeg kritieke massa ontstaan (dit is echter een hoogst onwaarschijnlijk scenario, waarschijnlijker is dat intel de yamhill troefkaart uitspeelt.).

Wat is volgens jou dan Yamhill? Een hybride x86 / IA-64 processor of een nieuwe 64-bit variant op de x86 instructieset? Het is absoluut kansloos dat Microsoft vier soorten Windows (x86, AMD64, IA-64 en Intel x86-64) gaat onderhouden. Een x86/IA-64 hybrid kan Intel nooit op korte termijn uit de hoge hoed toveren. Gezien de die-size van de Itanium 2 zullen de productiekosten van zo'n core veel te hoog zijn.

De snelheid waarmee AMD64 marktaandeel kan winnen zal mede afhankelijk zijn van het prijsbeleid van Microsoft. Als Windows XP 64-bit Edition een premium prijskaartje krijgt, zullen veel OEMs hun Athlon 64-systemen bundelen met een regulieren 32-bit Windows. Gezien de eenvoud waarmee applicaties naar de AMD64-architectuur geport kunnen worden en de in absolute aantallen toch aardig grote verkoopaantallen van AMD-processors (meer dan er Macs worden verkocht) zullen de softwarefabrikanten van bekende workstationapps toch wel redelijk vlot AMD64-versies uitbrengen (tenzij deze bedrijven gelieerd zijn aan Intel). Voor de consument maakt geen drol uit of simpele proggies zoals een FTP client beschikbaar zijn in een AMD64-versie.

[Anoniem: 88387]

Wat is volgens jou dan Yamhill?

een intel versie van x86-64. niet compatible met x86-64. ik denk ook niet dat het zo waarschijnlijk is dat intel hier mee komt, maar ik acht de kans hiervoor groter dan dat intel een licentie neemt op x86-64 van amd. ze zullen nooit het initiatief willen verliezen.

voor de consument maakt geen drol uit of simpele proggies zoals een FTP client beschikbaar zijn in een AMD64-versie.

nee dit klopt. ik denk dat sowieso de belangrijkste verworvenheid van 64 bits de grotere geheugenruimte is.

ik kan me heel goed voorstellen dat Intel uiteindelijk met een soort van 'kludge' komt waarbij men er in slaagt meer geheugen beschikbaar te stellen zonder dat applicatie code binaries gewijzigd hoeven te worden. de toegevoegde kludge instructies zullen alleen in supervisor mode kunnen werken. een soort yamhill light scenario. impact op windows is minimaal, alleen een geisoleerde "memorydriver" hoeft aangepast te worden.

de applicaties blijven gewoon 4GB native geheugenruimte hebben (IA32 binaries). het os zorgt middels gebruik van de 'kludge' voor het toewijzen van blokken fysiek geheugen aan processen uit de grote DRAM pool (>4GB). hiermee heeft elk proces welliswaar niet meer dan 4G ter beschikking maar zitten ze elkaar qua fysiek geheugen niet meer te beconcurreren.

met deze taktiek kan intel de geheugen problematiek oplossen voor de korte tot middenlange termijn. en zal amd meer moeite hebben klanten te overtuigen gedurende deze termijn.

een andere oplossing is natuurlijk het toevoegen van NUMA functionaliteit aan de XEON. elke XEON krijgt dan net als de k8 een eigen 4G geheugen. in een NUMA multiprocessor oplossing kun je deze hoeveelheden geheugen gewoon optellen. voila meer geheugen zonder modificaties aan de IA32 instructieset. dit is eigenlijk nog wel het meest waarschijnlijke scenario. het lost ook schaalbaarheidsproblemen van de XEON op en je target gelijk daar waar geheugentekort het meeste pijn doet namelijk de server.

edit:

er bestaan overigens al NUMA systemen op basis van XEON echter niet 'glueless'. bijvoorbeeld modules van 2 XEONS met 4GB geheugen, de modules onderling verbonden met inifiniband. dat levert dan per module maximaal 4G extra geheugen op. glued NUMA heeft een hogere kostprijs dan de glueless NUMA van de k8. echter intel kan de marktprijs van glued NUMA machines subsidieeren doordat het een enorme economische macht heeft tov amd. dit zou je de "economische variant van yamhill" kunnen noemen. IA32 kan nog jaaaaaaaren mee!

Windows 2003 feature:

32 gigabytes (GB) of RAM in 32-bit versions, 64 GB in 64-bit versions.  By adding memory, a computer can work with more information at once. Windows Server 2003, Enterprise Edition, includes enhanced memory capabilities that let you increase the memory available for server processing to as much as 32 GB of RAM in 32-bit versions and 64 GB of RAM in Itanium-based 64-bit versions.

[Darthroy]

"Verder is er op het eerste gezicht weinig revolutionairs te ontdekken aan het 64-bits OS"

Dat is ook wel logisch. Anders zouden de diverse Windows varianten weer uit de pas lopen. En dat wilde Microsoft nou net niet met XP.

[Anoniem: 88387]

precies. maar sommige tweakers denken dat de amd athlon 64 hun desktop computerexperience wezenlijk gaat veranderen. door alle amd marketing en hype op techy sites verwachten ze iets bijzonders van windows 64 en dan is het gewoon op het oog een gestripte versie van windows xp. teleurstelling! echter: de voordelen van windows 64 zijn vooral voor de server van belang.

de k8 is in feite gewoon de zoveelst x86 cloon. er draaien dezelfde os-en op. compatibility is key. de x86 compatibility route wordt verder vervolgd. verschillen in software tov 32 bits amd zijn enkel de performance. alle oude software draait weer wat sneller. dit is een patroon dat al jaren gaande is in x86 land. de zware overgang van 32bits naar 64 bits op hardware nivo, echt een schok, zie je als rimpeling terug in de software user interface.

echter: voor enthusiasts is het gewoon een -feature- van hun systeem als ze -weten- dat er een 64 bits processor in zit. in de realiteit echter draait er op zn best dezelfde windows software op. de enduser experience is hetzelfde als met een snelle 32 bits processor (p4/prescott). de eerste gebruikers van athlon 64 processoren zullen om deze reden vooral enthusiasts zijn. moederbord fabrikanten anticiperen hier op door athlon 64 processoren mee te bundelen met hun produkt. voor jan-met-de-pet is de meerwaarde van een AMD64 processor veel minder "voelbaar".

[Femme]

maar sommige tweakers denken dat de amd athlon 64 hun desktop computerexperience wezenlijk gaat veranderen. door alle amd marketing en hype op techy sites verwachten ze iets bijzonders van windows 64 en dan is het gewoon op het oog een gestripte versie van windows xp

Ik wist niet dat de marketing van AMD zoveel invloed had op de eindgebruiker. AMD adverteert vooral op zakelijk sites met reclameuitingen voor de Opteron (die als serverproc daadwerkelijk een groot voordeel heeft met 64-bit geheugenadressering).

De grootste schuldige is de slecht geïnformeerde pers waarvan een groot deel denkt dat 64-bit twee keer zo snel is als 32-bit of iets in die orde.

de enduser experience is hetzelfde als met een snelle 32 bits processor

Tja, dat heb je bij elke 64-bit platform waar je exact hetzelfde besturingsysteem kunt draaien als op een modern 32-bit platform. Het maakt niet uit of het Windows op een Athlon 64 of MacOS X op een PowerPC 970 is. De noodzaak voor 64-bit op de desktop is er momenteel niet en het prestatieverschil is niet of nauwelijks groter dan we gewend zijn van een reguliere opvolging van een processorarchituur.

[Anoniem: 88387]

Tja, dat heb je bij elke 64-bit platform waar je exact hetzelfde besturingsysteem kunt draaien als op een modern 32-bit platform. Het maakt niet uit of het Windows op een Athlon 64 of MacOS X op een PowerPC 970 is.

misschien kun je nog het beste overstappen van Windows/x86 naar MacOSX/ppc970. dan komt de overstap naar 64 bit hardware ook heel duidelijk in de software user interface naar voren.

[Olaf van der Spek]

de eerste gebruikers van athlon 64 processoren zullen om deze reden vooral enthusiasts zijn.

Voor persoonlijk gebruik wel. Maar er zijn best veel zakelijk gebruikers die wel met zware apps werken en die wel baat hebben bij 64-bit CPUs. Die zullen de 64-bit AMD CPU zeker ook kopen.

[SG]

Ja sommige tweakers maar dat zijn ook geen tweakers als je gewoon elke hype volgd zoals

MMX, 3dKnow, SSE, SSE2, HT, SSE3, AMD64, nV30

dan ben je geen tweaker maar iemand die als een dodo in de Hype trapt, niet zozeer alleen van de marketing maar van de geruchten engine waar iNtel en AMD niet verantwoordelijk voor zijn maar enkele/vele geruchten sites.

Ik verwacht er niet veel van iig geen wonderen, maar wat performance winst van -10% tot 30% is App(code mix) afhankelijk en address limiet bariere doorbroken, met behoud van performance vs PAE.

Dus voor de zware desktop gebruiker & gamer heeft het wel meerwaarde vanwege die extra performance.

Maar dat gold ook voor al zijn gehypte voorgangers
MMX 3dKnow SSE SSE2 HT SSE3 vs AMD64

dus daarom zal AMD64 aan mijn verwachtingen voldoen.

Omdat ik geen wonderen verwacht

Maar gewoon hier en daar wat perfornmance winst

Wat het voor mij ook inhoud is dus dat je weer een OS moet kopen om van nieuwe techniek gebruik te kunnen maken, gelukkig draaied ie op de IA32 ook goed
Dus de overstappen zit niet zo'n hoge druk op maar dat kan met de tijd.

En wat gaat ie kosten ? $$

Gezien MS uitstellingen zal de athlon 64/FX teneerste de komende maanden of half jaar vooral met de oude al ijhuis aanwezige IA32 win OS'en gebruikt worden en zal die performance in de eerste plaats ten tijde van release belangrijk zijn.

AMD64 Software platform is iets voor 2004

Dit doet mij sterk denken aan de 286 naar 386 overstap

[Webdoc]

Hmm ik was zelf niet op de hoogte dat alle drivers voor alle hardware ook 64 bits moeten worden. Nooit aan gedaacht eigenlijk.

Dat is best wel MINDER voor AMD!! Ik kan me zo voorstellen dat er voor zo grofweg 70% van alle hardware (vooral pleb el-cheapo merken) geen 64 bit versie wordt gemaakt, of inderdaad zoals het hierboven staat, veel later.

Dat maakt het dus onmogelijk om oudere componenten in je computer te gebruiken, en dat is best wel irritant. Moet je dus als je AMD64 wil hebben ALLEMAAL nieuwe(re) hardware hebben. Geen TV kaart uit 2001. Geen Printer van voor 2000. Dat maakt zo'n PC een stuk minder aantrekkelijk EN duurder.

[BruT@LysT]

Wat is in hemelsnaam jouw probleem! -> webdoc
Net zogoed toen Win2K verscheen, moesten er allemaal nog drivers gemaakt worden. Erg veel hardware wilde niet werken, maar als je een beetje op de hoogte bent kon je zo raden welke hardware wel ondersteuning zou bieden. Je moet dus niet van die 3rd party scsi adapters gaan gebruiken, of de meest onbekende kut hardware, die gaan niet werken. En hoezo wordt die pc daar niet aantrekkelijker op? sinds wanneer zou iemand een nieuwe pc aanschaffen met hardware uit 2001... das pas een stomme uitgave.
Waarom zou je 'als' je al een AMD64 mobo + proc kunt/wilt aanschaffen niet al een systeem hebben die redelijk up-to-date is? Een nono gaat niet zomaar een AMD64 systeem kopen die duurder is en nauwelijks voordelen biedt. Je moet gewoon een 'enthousiast' zijn, ben je dat niet, dan kom je wel in aanmerking met dit soort systemen over een paar jaar, en dan is de driversupport ook al prima. Hardware uit 2000 is dan allang versleten

Of bedoelde je dat je het al ziet aankomen dat je weer veel geld moet uitgeven als je een dergelijk systeem binnenkort wilt gaan bouwen? hou dan je klep en ga werken.

[Webdoc]

Nou nou... ff chillen dude... wat ik bedoel is dat 32 bit Windows 98 drivers naar 32 bit Windows 2000 porten nou eenmaal *EVEN* wat makkelijker is dan 32 bit naar 64 bit, en DAARBIJ, Windows 2000 is al snel de standaard geworden.

x86-64 is dat ZEKER niet, en zal voor nog een redelijk lange tijd een zeer kleine slice blijven van het totale aanbod. Als x86-64 in 2005 10% van alle computers is, is dat ECHT impressive!!

Dus het is helemaal niet te vergelijken. Er is dan dus ook veel minder incentive om maar heel hard voor ALLE nog gebruikte hardware 64 bit drivers te maken, want maar een klein deel van de klanten gebruikt x86-64. en DUS zal het (veel) langer duren dan jouw nieuwe Windows 2000 drivers.

[ronny]

Het lijkt me niet nootzakelijk om alle hardware in 1 keer te vervangen.
Als ik een goede TV kaart heb uit 2001 waarom zou ik die willen vervangen
Zo zijn er nog veel meer dingen die ik helemaal niet moet vervangen als ik toe ben aan meer rekenkracht wil dat toch niet zeggen dat de rest niet meer voldoet
Weet je wel wat bijvoorbeeld een goede capture/videobewerkings kaart kost.
Dat is niet iest dat je zo aan de kant doet omdat er geen drivers voor uitkomen.
En voor Webdos. Het is veel eenvoudiger om een dirver te hercompileren naar 64 bit als een dirver van win98 naar win2k om te zetten.
bovendien heeft AMD ongeveer 25% van de markt in handen en ze willen volgend jaar hoofdzakelijk overgeschakeld zijn op 64 bit dus dat is in 2004 al meer als 12%, dus dat schiet lekker op.

[MPAnnihilator]

Neen, dat maakt voor jou die 64 bits Windows een stuk minder aantrekkelijk, en niet de pc. Laten we niet vergeten dat tot nu toe blijkt dat die Opteron/Athlon64 voor gamers bijvoorbeeld een ideale keuze is. Zelfs in 32 bit

Tegen de introductie van de Ahtlon64 verwacht men dat die op 2.2 gig zal lopen dus eens die Athlon64 in effectieve mhz'en naar boven zal gaan, zal uiteindelijk ook de divx rar performance gaan toenemen. Dus zal die Athlon64 , ook al gebruik je hem slechts met een 32 bits Windows, wel degelijk de moeite zijn om te kopen. Na een jaartje zullen de drivers goed op gang komen en kan je alsnog overschakelen op een 64 bits Windows.

Tevens snap ik niet waarom men nu pas zo begint te panikeren over 64 bits drivers. AMD had toch al duidelijk gemaakt dat het gewoon hercompileren van de drivers zou zijn en dat overschakelen naar 64 bit , niet echt zo veel moeite zou kosten. Of ben ik nu verkeerd ? En dat Intel niet mee zou gaan willen doen, tjah, so what, alle andere grote merken lijken mij al mee te gaan werken met AMD , dus als in je pc hardware zit van bekende merken, denk ik niet dat je veel problemen zal hebben met drivers. En het is trouwens met iedere nieuwe Windows zo, dat je wel eens een stuk hardware hebt die problemen heeft.

[VHware]

Of je gebruikt tot zo lang de gewone WinXP ....

[MaxxBass]

Nou, de meeste fabrikanten zullen op den duur hun drivers wel aanpassen hoor... zal wel loslopen...

[hardwareaddict]

De vraag die hier gesteld wordt moet je net andersom stellen. Namelijk, is het acceptabel als er hardware uitkomt in de toekomst dat mensen lang moeten wachten op de 32 bits versie van de driver, terwijl de 64 bits driver voor x86-64 direct klaar is.

Als je tenslotte een nieuwe sneller grafische kaart ontwerpt, dan wil je dat natuurlijk demonstreren op een zo snel mogelijke PC. Dat is dan een x86-64 systeem. Dus daar bouw je een snelle driver voor. Dit waar de 32 bits users natuurlijk lang kunnen wachten.

In 32 bits zijn er namelijk veel meer issues om drivers voor een hardware product te ontwikkelen als in x86-64. Bovendien draait 't al bij voorbaat trager daar.

MVG

[Anoniem: 88387]

Als je tenslotte een nieuwe sneller grafische kaart ontwerpt, dan wil je dat natuurlijk demonstreren op een zo snel mogelijke PC. Dat is dan een x86-64 systeem.

dit is natuurlijk onzin. welk systeem sneller is x86-64 of intel pentium 4/prescott, good old 32 bit, is nog helemaal niet een uitgemaakte zaak.

bedenk ook dat intel sse/sse2/sse3 heel belangrijk is voor het grafische segment. en bedenk dat sse werkt met registersizes van 128 bit. qua sse implementatie heeft intel juist een voordeel op amd 64 (de netburst architectuur).

het wordt nog heel spannend voor amd hoor. het (zelfstandig) voortbestaan van amd staat of valt met het succes van de x86-64 extensies.

[35MHz OC]

Bierbuik, Athlon64 en Opteron hebben ondertsteuning voor SSE en SSEII, dus jouw vlieger gaat niet op.

[Anoniem: 88387]

duh. weet ik ook wel. sse3 echter niet en de snelle caches/netburst architectuur geeft p4/prescott ondanks het feit dat k8 sse/sse2 geimplementeerd heeft een voordeel.

[Olaf van der Spek]

waarbij MS de lat meteen maar op 16TB (16.000GB) heeft gelegd

Is het niet AMD die de lat daar gelegd heeft?
16 tb is trouwens 16384 gb

[Anoniem: 55563]

Officieel, volgens de S.I.-norm dus, is het voorvoegsel 'tera' nog altijd 1000 miljard, oftewel 1000 'giga'. Een 'i'tje ertussen (TiB), dan heb je pas gelijk .

[Anoniem: 53692]

Blah, en niemand die zich daaraan houdt, en dus heeft die officiële afkorting geen defacto waarde. TB is dus 16384 Giga. Onafhankelijk van wat SI-normen voorschrijven.

[Shockyboy]

Harddiskfabrikanten houden zich er wel degelijk aan. (Niet dat dat fijn is...)

[Flatline]

In hoeverre zitten we te wachten op ondersteuning voor oude hardware?
Verwachten we werkelijk dat het teletext kaartje uit 1996 nog ondersteund gaat worden?
Gangbare hardware zal ondersteund gaan worden, het niet uitbrengen van drivers diskwalificeert in deze markt direct een leverancier die dit niet doet.

Ik durf er wel een goeie fles op in te zetten dat over een jaar een flink deel van de Tweakers een 64bit systeem heeft draaien... Proost!

[Olaf van der Spek]

Wat vind jij oude hardware? Als Creative Labs voor de Sound Blaster Live bijvoorbeeld geen 64-bit drivers schrijft maar alleen voor de Audigy (2) vind ik dat toch zonde, zeker als die Live nog gewoon voldoet.

[Flatline]

Dat is dus een prima voorbeeld van een kaart waar ik die voornoemde fles wel op wil inzetten. Daar komt wel een driver voor.
Maar een shin zen scanner uit 19 heel lang geleden, gekocht bij kwantum...

[BruT@LysT]

juist, een Live! valt ook nog net in de huidige catagorie geluidskaarten kwa techniek en vorm.
Geluidskaarten voor de 10K1 chip zal je hoogstwaarschijnlijk geen drivers voor vinden. Maar een Live! heus wel. Je kunt met een beetje ervaring zo zeggen wat driversupport krijgt en wat niet. Tis net alsof je het al aan de printplaat kunt zien, grappig is dat

[Cyberdude47]

MS de lat meteen maar op 16TB (16.000GB) heeft gelegd

"Er zal nooit meer dan 16TB geheugen nodig zijn"

[source]

Kun je je nog herrinneren de tijd dat we zeiden dat 640 KB genoeg was?

[Anoniem: 60001]

Dat was zo'n twintig jaar geleden ?
Met 16 TB kunnen we ook zo'n 20 jaar voort:
1 (GB) * 2 exp(t/1,5) = 16.000 (GB)
=> t = 20.9 jaar
Ergo: over 20 jaar denken we net zo over 16 TB geheugen als nu over 1 GB aan geheugen in ons systeempje (uitgaande van huidige verdubbeling elke 1,5 jaar). Niet eens zo gek dus; die afgelopen 20 jaar zijn ook omgevlogen ...

[Olaf van der Spek]

2^64 b is veel meer dan 16 tb, dus zelfs als 16 tb niet genoeg is, is de 64-bit CPU nog bruikbaar.

[Anoniem: 53692]

http://www.kurzweilai.net/meme/frame.html?main=/articles/art0134.html

Hier kun je vinden dat Moore's law accelereert. De verdubbeling vindt tegenwoordig elk jaar plaats, ipv elke anderhalf jaar.

[Olaf van der Spek]

Waarom denk je dat die smily erachter staat?

Ik kan het me trouwens wel herinneren, maar zelfs toen was het al niet meer genoeg.

[_Thanatos_]

Jij gaat uit van 4 geheugenbankjes... Op een mobo (zeker op een opteron mobo) kunnen er best 8, 12 of zelfs 16 zitten.

En dan kom je op EUR 2.608,--

[source]

Ik had 't door hoor

btw: 8 GB aan geheugen reepjes kost nu (wat is zo snel kon vinden) 20.591,76 euro.

[Anoniem: 7750]

Vroeger.....

[TeunSegers]

ff voor de duidelijkheid: "we" zeiden dat niet, Bill Gates zei dat. Was 1 van zijn beroemdste blunders... blijft leuk

[MacD]

Het geinige is dat Billy dat nooit heeft gezegd. Typisch geval van 'urban legend'.

[C7RL]

Intel een belangrijke speler is in de hardware-markt, en het zal dan ook uiterst interessant zijn om te zien of Intel x86-64-drivers gaat ontwikkelen voor zijn netwerkkaarten, RAID controllers, etc. Bedrijven als Broadcom, 3Com, nVidia, ATi en Adaptec zouden bij de introductie van het 64-bits OS wel drivers klaar hebben,

Intel zal WEL moeten om drivers te ontwikkelen, eenvoudig weg omdat Intel geen monopoly heeft op de hardware markt, dit zou namelijk betekenen dat Intel hier markt aandeel zou kunnen gaan verliezen als men het niet gaat doen. De kat uit de boom kijken of x86-64 een succes word en daarna pas beginnen levert je direct een achter stand op tov de concurrentie. Aan de andere kant wil je je huidige klanten natuurlijk kunnen bedienen en ondersteunen als zij om x86-64 hardware/drivers vragen. Nee verkopen kan dus geld gaan kosten voor Intel en ook voor andere bedrijven en dat is natuurlijk het laatste wat je wilt.