Microsoft bevestigt komst x64-versie van Office 12

Er zal een 64-bit versie van Microsoft Office op de markt komen, zo is te lezen bij CRN. De huidige plannen voorzien in een release van een 64-bit versie van Office 12 enige tijd nadat de officiële 32-bit versie van Office 12 is vrijgegeven. Er zal geen Itanium-versie van Office 12 geproduceerd worden. Erik Ryan, productmanager van Microsoft Office SharePoint, heeft laten weten dat het vrijwel zeker is dat er 64-bit versies van Windows SharePoint Services en SharePoint Portal Server op de markt zullen komen met de 'Office 12-wave'. Ryan wist echter niet te melden of en wanneer de desktopprogramma's binnen de Office-suite zouden overstappen op 64-bit. Volgens Brian Marr, senior productmanager van Windows XP Professional x64 Edition, is een transitie van 32- naar 64-bit niet te verwachten op korte termijn. De voornaamste reden hiervoor is dat vrijwel alle Office-programma's in een 32-bit omgeving prima presteren en dat er dus weinig zin om over te stappen naar 64-bit.

Vanzelfsprekend zal men over enkele jaren wel een 64-bit versie van deze programma's op de markt brengen, maar dat is niet specifiek omdat er vanuit performanceoogpunt een reden toe is, maar gewoon omdat 64-bit systemen meer verkocht zullen worden en gebruikers dus ook meer 64-bit software zullen willen. Verschillende softwareontwikkelaars en -verkopers menen echter dat ook de desktopprogramma's uit de Office-suite baat zullen hebben bij een 64-bit versie van Office 12. Een grote Excel-sheet bijvoorbeeld kan rekenvoordeel hebben van 64-bit ondersteuning. Daarnaast kan 64-bit software voordeel hebben als er veel gewerkt wordt met multimediabestanden en manipulatie van dat soort bestanden.

Reacties (55)

[Frubelaar]

"Wat is het nut van een specifieke x64 editie van Office 12?"
Je moet het op langere termijn bekijken.
Voor een OS is het het beste (stabieler/sneller/minder onderhoud/etc) als het maar 1 formaat ondersteunt (8/16/32/64)
Dat is marketing technisch niet haalbaar dus nu blijft 32 bit er in. 8 en 16 bit zijn eruit dus.
Zoals ook 32 bit er ooit uit zal gaan als (vrijwel) iedereen 64 bit office versies heeft.

Ik heb weleens het idee dat het verzinnen van nuttige nieuwe features voor Office lastiger is dan het programneren zelf. Nu kan MS van alle software een nieuwe 64bit versie uitbrengen en dat als een grote vooruitgang promoten.

"Zou het niet slim zijn om de hele boel ook vast geschikt te maken voor multi-core chips?"
Nee dat verkopen ze weer als een volgende versie :-)
Is de roadmap van multicore wel voldoende duidelijk om er al een grote productlijn op af te stemmen?
Misschien gebeurt het ook al wel maar zet MS die functionaliteit gewoon voorlopig uit....


Ryan did not comment on the desktop-oriented Office products but said that as 64-bit computing gets pervasive, the team will explore "how we can take advantage of the promise of this platform in other servers, applications and services."

Brian Marr, senior product manager for Windows XP Professional X64 edition, said there is more of a need to transition applications that are memory- or processor-bound to 64-bit than others, which can run well as 32-bit versions on a 64-bit operating system.

"Office is an example of an application that is not one of those," Marr said. "People don't typically have a 2-Gbyte PowerPoint application or 100,000 e-mails opened at the same time. [Office] is perfectly well-suited to run at 32-bit still at great performance. At some point, I'm sure they'll cut over, but there's nothing driving it to need to be 64-bit. At this point, there's no product road map for moving [Office] to 64-bit."
Als ik het artikel lees krijg ik juist de indruk dat MS office niet naar 64bit wil porten omdat ze het overkill vinden.
Het artikel gaan merendeel over server apps.

[tweakerbee]

Je kunt in Office niet eens met grote bestanden werken, anders slaat ie bijna altijd vast. Dat heb ik in ieder geval met vrijwel alle Office versies.
Wellicht is het een idee om die codebase toch een keer goed op te ruimen.

[kidde]

Zou het niet slim zijn om de hele boel ook vast geschikt te maken voor multi-core chips?
Men zegt dat binnenkort iedereen een 64bit CPU heeft, ik denk dat binnenkort ook iedereen een multi-core heeft.
Zou redelijk wat moeite besparen door het in1x te doen denk ik.

[Countess]

niet perse
voor multicore moet je vaak je hele programa herschrijven.
voor basic 64bit support is enkel een hercompilatie nodig van de bestaande code.

[dj.verhulst]

Ik denk dat je een punt heb ,, denk je alleen niet dat je dan naast de suite een pack krijgt zoals bij de ofice xp die wat voor win98 upgrade en andere dingen aan w2k toevoegde ... en er aparte update waren als je een terminal bak draaid om het één en ander te optimaliseren.

misschien zou het dan ook het moment om office niet op cd maar dvd te zetten ... en is beter te beveilingen....

[TheGhostInc]

Office is al multi-threaded.
Kijk maar naar de verschillende spellingscontroles en andere achtergrond taken. Terwijl je aan het typen bent worden op de achtergrond taken uitgevoerd.

Hierdoor zal Office waarschijnlijk direct baat hebben bij meer (deel)cpu's.

Toch zijn er maar weinig mensen die het verschil zullen merken. De gemiddelde dual core cpu is per cpu al dusdanig snel dat er weinig meer te wensen valt.

[Verwijderd]

Als je Office nog goed laat functioneren op single-core 500 mhz bakkies, zoals nu het geval is, hou je veel meer marktaandeel dan wanneer je het gaat tweaken voor performance users. Laten we wel wezen, dat er bij mij 2GB ddr/400 in zit, een HT cpu op 3.6 Ghz en een goeie 800 gb aan opslag is niet omdat ik regelmatig een flinke Excel file wil maken. dat kan ik op m'n werk ook op m'n 800 mhz p3 systeempje. nu kun je op elke ouwe rampenbak nog office XP of office 2003 zetten en dan werkt het en nog snel genoeg om werkbaar te zijn ook. En dat is voor en office pakket het boeiendst, want het bedrijfsleven upgrade z'n pcs niet, die worden na een jaar of vier, vijf vervangen.

[Verwijderd]

Als je Word en Excel tegelijk open hebt, heb je al 2 aparte applicaties draaien, die prima over meerdere cpu's (of het nou fysieke cpu's, hyperthreading-achtige logische cpu's, of multi-core cpu's zijn maakt niet uit) verdeeld kunnen worden door het OS.

[Phyxion]

Wat is het nut van een specifieke x64 editie van Office 12?
Aangezien Office 2003 hier ook prima onder Windows XP x64 Edition draait...
En zoals de tekst aan aangeeft:
De voornaamste reden hiervoor is dat vrijwel alle Office-programma's in een 32-bit omgeving prima presteren en dat er dus weinig zijn om over te stappen naar 64-bit.

[Countess]

het zelfde nut dat het toen had om een 32bit versie van office te maken toen 16bit software ook nog prima werkte. (die werkt nog steeds prima trouwens. zullen dus we maar allemaal terug gaan naar 16bit?)

uiteindelijk moet toch alles over op 64bit, dus waarom niet vroeg beginnen.
en lees het hele artical eens, er staan nog meer voordelen in.

[Phyxion]

Ja, financieel oogpunt, maar dat is het bij Microsoft altijd geweest, het is niet voor niks een commercieel bedrijf. Maar je kan toch ook gewoon support adden, en niet allemaal verschillende versies uitbrengen... Dat leek mij iig makkelijker dat dit zal zijn. Of gebeurd dat ook?

[Countess]

je software moet zijn geheel 64bit zijn, je kan niet een patch uitbrengen die van je 32bit programa ineens 64bit maakt.
ja kan wel maar dat moeten mensen eigenlijk gewoon je hele programa opnieuwe downloaden.

[Phyxion]

Ik bedoel meer in de richting van dat als je Office 12 uitbrengt, dat je gewoon alles ondersteund, en niet meerdere versies uitbrengt van hetzelfde product, dit zorgt nml voor verwarring bij mensen die geen idee hebben wat op hun PC staat e.d.

[Ackermans1973]

Begrijp dan dat dat niet kan, je kunt niet 32 en 64bit versies in 1 programma frotten.

Draaiend onder 64bit wil niet zeggen dat het 64bit is.

[Phyxion]

Waarom zou dat niet kunnen? Je kan toch aparte aansturingsbestanden speciaal voor x64 maken. Net als je ook 98ME en 2KXP hebt, dan kan je ook nog wel speciaal een maken voor x64. De hoofdbestanden blijven toch hetzelfde. Kijk als voorbeeld een game. Videobestanden hoeven niet 2x hetzelfde, hetzelfde geldt voor de gamefiles. Die hoeven niet in een keer anders gemaakt te worden. Hetzelfde leek mij gaan voor Office 12. Plugins en drivers moeten wel speciaal geschreven worden voor x64, maar datzelfde heb je met het 98ME en 2KXP verhaal. Ik denk dat het best wel mogelijk is om gewoon 1 CD of DVD uit te brengen die meerdere ondersteund. Een groot gedeelte van de files kan je toch wel herbruiken, het gaat immers om de aansturing van de files.

[Ackermans1973]

Heb je het nog steeds over 2 of meer versies.

[The Noid]

Het is trouwens wel mogelijk om code voor verschillende besturingssystemen in 1 executable te stoppen. Ik ben alleen vergeten hoe dat ook al weer heette.

[Countess]

De hoofdbestanden blijven toch hetzelfde. Kijk als voorbeeld een game. Videobestanden hoeven niet 2x hetzelfde, hetzelfde geldt voor de gamefiles. Die hoeven niet in een keer anders gemaakt te worden.

da klopt. maar hoeveel plaatjes filmpjes en geluidsbestanden denk jij dat office heeft? een stuk minder als de gemiddelde game iniedergeval
en al de rest zal toch echt opnieuwe gecomplieerd moeten worden.

[Verwijderd]

uiteindelijk moet toch alles over op 64bit, dus waarom niet vroeg beginnen.
en lees het hele artical eens, er staan nog meer voordelen in.

Er 'moet' niks over. Omdat je cpu 64bit is wil het nog niet zeggen dat die slecht werkt met 32bit software of zelfs 64bit software die eigelijk maar 32bits van alle registers benut.

Geoptimaliseerde code schrijven houdt niet zondermeer in dat alles ook 64bit moet zijn.

Op een 680x0 had je bijvoorbeeld de moveq.l #1,D0 instructie. Een 16 bit instructie waarin de operand mee inzat, en het resultaat van die instructie was een zuiver 32bit getal in een 32bit register.

Ik kan het nog sterker zeggen trouwens : op een 680x0 cpu is het de kunst van elke instructie 16bit te houden, inclusief operand (er bestaan verschillende instructies met de 'quick' optie) waardoor je programmacode compleet 16bits lijkt maar toch is het resultaat van elk van die instructies 32bit.

moveq.l #1,D0
addq.l #1,D0

Nogmaals, dit resulteert in 2x16bit aan code (4 bytes) en toch voert het 32bit bewerkingen uit...

Ik erger me hoe langer hoe meer aan al die mensen die wat dingen lopen blaten zonder dat ze ook maar het minste idee hebben van waarover ze blaten.

[Verwijderd]

Dat was de 68000 dus niet.
Hij had 32 bit registers, maar intern was hij voornamelijk 16 bits, en extern dus ook (databus).
Vandaar dat het verstandig was om de code zoveel mogelijk 16 bits te houden (vooral muls en divs).
Pas sinds de 68020 was de CPU intern ook geheel 32 bits.

Intel had iets dergelijks met de 8088. Het was een 8-bit processor, maar met 16-bit registers.

[Olaf van der Spek]

Intel had iets dergelijks met de 8088. Het was een 8-bit processor, maar met 16-bit registers.

Nee, de 8088 is een 16-bit processor met een 8-bit databus.

[OMX2000]

Het is ook niet nieuw dat een 68000 CPU intern altijd al 32 bits was.

[Verwijderd]

Intel noemt het zelf toch echt een 8-bit processor: http://titan.etf.bg.ac.yu/~gvozden/mips/download/i8088_microprocessor. pdf

The 8088 CPU is an 8-bit processor designed around the 8086 internal structure.

Evenals de 68000 moeten de meeste operaties dus in 2 kleinere operaties opgedeeld worden.

Tegenwoordig is het juist andersom trouwens...
Sinds de Pentium hebben we 64-bit databussen, maar nog steeds 32 bit registers en ALUs (op uitzonderingen als FPU/MMX/SSE na dan).
Dat maakt de invoer van 64-bit x86s dus een stuk minder interessant qua prestaties.

[Olaf van der Spek]

Intel noemt het zelf toch echt een 8-bit processor:

De 'breedte' van een CPU geeft over het algemeen de breedte van normale registers en ALU aan (16-Bit Internal Architecture).

Evenals de 68000 moeten de meeste operaties dus in 2 kleinere operaties opgedeeld worden.

Waarom?
De ALU en registers waren gewoon 16-bit.

Dat maakt de invoer van 64-bit x86s dus een stuk minder interessant qua prestaties.

x86-64 is meer dan een verbreding van de registers.

[Verwijderd]

De 'breedte' van een CPU geeft over het algemeen de breedte van normale registers en ALU aan (16-Bit Internal Architecture).

Helemaal niet.
Het is niet eenduidig gedefinieerd. Het kan slaan op registers, ALUs, databus, en wie weet wat nog meer.
Vroeger was alles even breed, dus was het makkelijk... Als bv de databus verschilt van de rest, is het lastig om te spreken van 16-bits. Kennelijk vindt Intel een 8-bit databus genoeg om te spreken van een 8-bit processor.

Waarom?
De ALU en registers waren gewoon 16-bit.

Omdat de meeste operands (zowel geheugen als immediate) dus niet in 1 operatie ingeladen konden worden.
Bij de 68k was bovendien de ALU niet compleet 32-bit.

x86-64 is meer dan een verbreding van de registers.

Ja duh. Maar de grootste winst zou je krijgen van een twee keer zo brede databus... Maar in dit geval had je die brede databus al, dus maakt dat het minder interessant.
Voor de meeste software heb je genoeg aan 32 bit integers... de floats en MMX/SSE zijn niet veranderd, dus daar hoef je ook geen 64-bit x86 voor te hebben...
Blijft over dat je meer registers hebt... Dat is leuk en aardig, maar heeft natuurlijk niets te maken met 64-bit technologie.
Je zou net zoveel winst hebben als je die registers aan de 32-bit architectuur toegevoegd zou hebben.
Al met al is deze overgang van 32 naar 64 bits een stuk minder spectaculair dan die van 16 naar 32 bits... Dit dus omdat de overgang gedeeltelijk al was ingezet met de Pentium.

[Olaf van der Spek]

Vroeger was alles even breed, dus was het makkelijk... Als bv de databus verschilt van de rest, is het lastig om te spreken van 16-bits.

Vroeger? Wanneer was dat?
Zo lastig is het niet hoor. Volgens mij is iedereen het er over eens dat de 8086, 8088, 80186 en 80286 16-bit CPUs, 80386 - P4 zonder x86-64 32-bit en met x86-64 64-bit.

Kennelijk vindt Intel een 8-bit databus genoeg om te spreken van een 8-bit processor.

http://www.intel.com/design/intarch/intel186/index.htm

Available in commercial and extended temperatures
CHMOS, 8- and 16-bit external bus versions
16-bit architecture

16-bit archiecture dus (is wel 80186), ondanks dat er een 8-bit CHMOS external bus is.

Omdat de meeste operands (zowel geheugen als immediate) dus niet in 1 operatie ingeladen konden worden.

Wat bedoel je met operaties?
Een enkele mov instructie kan gewoon een 16-bit operand uit het geheugen laden, ook als de databus 8-bit is.

Dat is leuk en aardig, maar heeft natuurlijk niets te maken met 64-bit technologie.

Dit artikel gaat over software voor x86-64. Dus niet over 64-bit in het algemeen.

Dit dus omdat de overgang gedeeltelijk al was ingezet met de Pentium.

En jij vindt dat de overgang naar 128-bit CPUs al is ingezet met dual-channel RAM en een passende FSB? Ik echt niet.
En dat P4s met RDRAM 16-bit zijn?

[Verwijderd]

Vroeger? Wanneer was dat?

Toen CPUs overal hetzelfde aantal bits gebruikten... registers, alu, databus... etc.

Zo lastig is het niet hoor. Volgens mij is iedereen het er over eens dat de 8086, 8088, 80186 en 80286 16-bit CPUs, 80386 - P4 zonder x86-64 32-bit en met x86-64 64-bit.

Het was toch echt de Intel manual voor de 8088 waarin Intel zei dat het een 8-bit processor was. Zie PDF.
Zoals ik al zei, het is niet eenduidig gedefinieerd, dus is het nutteloos om te discussieren wat jij vindt dat het is. Ik hou maar aan wat Intel in z'n documentatie zegt... verder vind ik het niet belangrijk, we weten allebei waar we het over hebben.

16-bit archiecture dus (is wel 80186), ondanks dat er een 8-bit CHMOS external bus is.

Ja, dat is de architectuur ja. Dat wil nog niet zeggen dat de implementatie van die architectuur 16 bits moet zijn.
Bovendien gaat dit steeds om bepaalde onderdelen (databus, architectuur, etc)... En niet om de processor als geheel. Zeggen dat de architectuur 16 bits is, is dus niet hetzelfde als zeggen dat de processor 16 bits is.

Wat bedoel je met operaties?
Een enkele mov instructie kan gewoon een 16-bit operand uit het geheugen laden, ook als de databus 8-bit is.

Niet in 1 operatie. Met een 8-bit bus kun je dus met 1 operatie 8 bits op de bus zettten. Vandaar dat het ding een 8-bit bus genoemd wordt. Je hebt dus 2 lees- of schrijfoperaties nodig om een 16-bit operand te lezen of schrijven.
De mov-operatie is dan dus trager met 16 bits als met 8 bits, wat dus ongeveer hetzelfde is als waar Green.Velvet op doelde in zijn verhaal over de 68000.

Dit artikel gaat over software voor x86-64. Dus niet over 64-bit in het algemeen.

Het gaat erom dat bij x86 de overgang naar 64 bit niet zo heel noodzakelijk is voor een hoop software. En daar sloeg mijn post dus ook op.

En jij vindt dat de overgang naar 128-bit CPUs al is ingezet met dual-channel RAM en een passende FSB? Ik echt niet.
En dat P4s met RDRAM 16-bit zijn?

Volgens mij begrijp je het verhaal niet. Dual-channel heeft niets te maken met de breedte van de databus van de CPU. Die is nog steeds 64 bit. Een 128-bit load kost dus nog steeds 2 operaties, en is dus trager dan een 64-bit load. Bij de Pentium was dit niet het verhaal. De CPU had een 64-bit databus, en kon dus in 1 operatie 1 64-bit load doen, of 2 32-bit loads. Wat voor memory controller en geheugen je er vervolgens aanhangt, heeft daar niet veel mee te maken. Dat is in principe onafhankelijk van de processor (bij Athlon64 natuurlijk niet meer).

[Olaf van der Spek]

Dual-channel heeft niets te maken met de breedte van de databus van de CPU. Die is nog steeds 64 bit. Een 128-bit load kost dus nog steeds 2 operaties, en is dus trager dan een 64-bit load.

Nogmaals, wat bedoel je met operaties?
De bus is wel QDR en je kunt (dus) niet vier onafhankelijke loads binnen een klok uitvoeren.
Een enkele bus transactie is een load voor (minimaal) 256 bits.

[Verwijderd]

Nogmaals, wat bedoel je met operaties?

Heb ik al uitgelegd, loads en stores op de bus.

De bus is wel QDR en je kunt (dus) niet vier onafhankelijke loads binnen een klok uitvoeren.
Een enkele bus transactie is een load voor (minimaal) 256 bits.

Volgens mij haal je CPU en chipset enorm door elkaar ofzo.
Als het waar is wat jij zegt, dan moet een 128 bit load niet trager dan een 64 bit load zijn op een P4, en dat is het dus wel. Dat heeft er niets mee te maken of de chipset via QDR communiceert of niet, maar alles met het feit dat de P4 geen loads van meer dan 64 bits kent, en dus een 128 bit load in 2 sequentiele operaties van 64 moet omzetten.
Zou hij echt een 256 bit bus hebben, dan zou een 128 bit load geen probleem moeten zijn.
QDR verhoogt kunstmatig de kloksnelheid (het aantal transacties per seconde), het verandert de woordbreedte niet.

[Olaf van der Spek]

Als het waar is wat jij zegt, dan moet een 128 bit load niet trager dan een 64 bit load zijn op een P4, en dat is het dus wel.

Hoe time jij loads op de data bus?

QDR verhoogt kunstmatig de kloksnelheid (het aantal transacties per seconde), het verandert de woordbreedte niet.

ftp://download.intel.com/design/Pentium4/datashts/303128.pdf

The processor’s Intel NetBurst microarchitecture FSB uses a split-transaction, deferred reply
protocol like the Pentium 4 processor. The Intel NetBurst microarchitecture FSB uses Source-
Synchronous Transfer (SST) of address and data to improve performance by transferring data four
times per bus clock (4X data transfer rate, as in AGP 4X). Along with the 4X data bus, the address
bus can deliver addresses two times per bus clock and is referred to as a "double-clocked" or 2X
address bus. Working together, the 4X data bus and 2X address bus provide a data bus bandwidth
of up to 6.4 GB/s.

Een transactie is dus wel meer dan 64 bits.

[Verwijderd]

Ik haalde dan ook specifiek de instructies aan die een quick versie hadden...

[Verwijderd]

Hoe time jij loads op de data bus?

Stukje code, rdtsc enzo. Dan kun je het verschil timen tussen 64 bit loads en een set 128 bit loads.

Een transactie is dus wel meer dan 64 bits.

Hoe kom je daarbij? Dat staat er helemaal niet.

improve performance by transferring data four
times per bus clock.

Kortom, er worden 4 transacties (voor data, of 2 voor adres) gedaan per clk, niet 1.
Maar iedere transactie is natuurlijk nog steeds 64 bits, omdat de bus nu eenmaal niet breder is.
Om de analogie over te nemen die ze daar gebruiken... Een AGP4x poort is toch ook nog steeds 64 bit... en een 8x poort? Of hebben we het daar ineens over 256 en 512 bit poorten, omdat er meer transacties per seconde gedaan worden dan bij 1x?

[Olaf van der Spek]

Kortom, er worden 4 transacties (voor data, of 2 voor adres) gedaan per clk, niet 1.

Een transactie is volgens mij een adres en operatie (read of write) en data, niet alleen een adres of alleen data.

[Verwijderd]

Een transactie is volgens mij een adres en operatie (read of write) en data, niet alleen een adres of alleen data.

Ja, en dus? Dat maakt de rest van jouw verhaal nog niet kloppend. De CPU moet die transacties over de bus doen. Als de CPU niet meer dan 64 bit kent, dan kan hij dus geen grotere transacties doen... wat voor bus je er ook aan hangt.

Het bus-protocol is maar 64 bit, en de QDR werkt alleen om een 4x zo hoge kloksnelheid te simuleren, zie ook: http://www.csd.uoc.gr/~hy425/pentium4.pdf

[Olaf van der Spek]

Als de CPU niet meer dan 64 bit kent, dan kan hij dus geen grotere transacties doen... wat voor bus je er ook aan hangt.

Waarom zou een transactie beperkt moeten zijn tot een kloktik (of een deel daarvan bij DDR)?

[Verwijderd]

Waarom zou een transactie beperkt moeten zijn tot een kloktik (of een deel daarvan bij DDR)?

Heb ik gezegd dat een transactie beperkt moet zijn tot een kloktik?
Ik zeg alleen dat de CPU geen transacties groter dan 64 bit kent, dus een 128-bit load of store wordt gedaan door twee afzonderlijke 64-bit transacties. Het is dus geen 128-bit databus, maar 64-bit. Maar daar heeft ook niemand ooit aan getwijfeld, op jou na dan.

[Olaf van der Spek]

Heb ik gezegd dat een transactie beperkt moet zijn tot een kloktik?

Omdat een transfer van 64-bit een kloktik duurt en jij claimt dat transacties van 128-bit niet kunnen.

Stukje code, rdtsc enzo.

Dan kom je toch L1 en L2 caches tegen. En IIRC zal de CPU dan een hele cache line (ik dacht 256 bits) loaden/storen dus daarmee kun je niet een individuele load of store op de data bus timen.

[Verwijderd]

Omdat een transfer van 64-bit een kloktik duurt en jij claimt dat transacties van 128-bit niet kunnen.

Ik claim dat niet, Intel's specificaties zeggen dat.
Waar wil je eigenlijk heen?

Dan kom je toch L1 en L2 caches tegen. En IIRC zal de CPU dan een hele cache line (ik dacht 256 bits) loaden/storen dus daarmee kun je niet een individuele load of store op de data bus timen.

Er zijn instructies om cache te omzeilen. Maar de CPU moet altijd de transacties instantieren, al dan niet met behulp van cache... Als de CPU dus geen 128-bit transactie kent, kun je er nooit een krijgen.
Normaal gesproken zal een CPU met cachelines werken... maar dat wil niet zeggen dat de breedte van de databus ook de breedte is van een cacheline. Als dat zo was, zou het geheugen ook die breedte moeten hebben, en dat heeft het dus ook niet. Dus worden er trucjes gebruikt met meerdere signalen per cycle, en buffertjes hier en daar, om meer bandbreedte te genereren... Maar nog steeds met 64 bit breedte. Een cacheline (of meerdere) wordt dus gelezen of geschreven met een burst van 64 bit operaties.
Zoals ik al zei, volgens mij haal je CPU en chipset gigantisch door elkaar.

[Verwijderd]

Lijkt mij simpel. De 32 bits versie heeft nog lang geen verzadigde markt (er worden nog veel oudere versies gebruikt). En als hun verkoopcijfers een bepaald punt bereikt hebben zullen ze pas gaan nadenken of ze de nieuwste office versie naar 64 bit gaan porten. (mag hopen dat ze dat nu al doen)

Als ze het maar niet bij Office 13 gaan doen.

[Verwijderd]

Als ze het maar niet bij Office 13 gaan doen.

Ooit zal er een Office 13 zijn... of ze moeten zo bijgelovig zijn dat ze van 12 naar 14 gaan

[WinL]

De 32 bits versie heeft nog lang geen verzadigde markt (er worden nog veel oudere versies gebruikt).

off-topic: en wat zijn die andere versies volgens jou? 16-bit? Persoonlijk denk ik dat 32 overal (praktisch) wordt gebruikt. 16-bit is out off the picture.
In het oude tijdperk had men sterk behoefte aan 32-bits. Bij deze nieuwe overgang speelt dit allemaal wat minder.

on-topic
Microsoft kan haar krachten beter investeren in nieuwe features... betere code etc... Als ze daarbij ook nog eens een 64-bitter moet gaan maken (compilen) en sowieso testen dan komen de prioriteiten toch anders te liggen.

Naar 64-bit verhuizen, is net iets meer dan effe een ander compiler inschakelen.

[Verwijderd]

Het lijkt mij dat als over een aantal jaar alle software 64bits is het voor programmeurs wat makkelijker wordt. Er hoeft immers geen rekening meer gehouden te worden met x86-32 (x32 ??) en dat scheelt tijd, geld en moeite. Dat er dus een x64-versie van Office aankomt, is in dat licht niet zo verwonderlijk en slechts een kwestie van tijd. Bovendien kunnen we met x64 weer een hele poos vooruit. Een flinke marge is nooit verkeerd en ik denk dat we reeds binnen 10 jaar heel blij zullen zijn dat de overstap naar 64bit is gemaakt.

Serieuze n00b-vraag: waarom niet meteen 128bits? Als we dan toch overstappen...

[Munters]

Tja, In Word gebeuren hele gekke dingen als je meer dan 255 dingen opneemt. Pagina's, plaatjes of voetnoten, maakt niet uit. Lijkt een beetje op 8 bits m.i.

Excel kent maximaal 255 kolommen en 65536 rijen. Een echte 8/16 bits applicatie dus.

Laat MicroSoft eerst maar eens een echte 32-bits Office maken.

[CH4OS]

Serieuze n00b-vraag: waarom niet meteen 128bits? Als we dan toch overstappen...

Omdat de CPU het ook moet ondersteunen, anders heb je er helemaal niets aan... En zolang er geen 128 bits CPU's zijn, is het (in mijn ogen) logisch, dat je dan ook geen 128 bits software maakt...

En waarom er nog geen 128bit CPU's zijn... Tja... Waarom stappen overslaan? Des te harder ga je op je bek, als het fout gaat... Probeer maar is te schakelen, vanuit zijn 3, naar zijn 5... Lukt je ook (bijna) niet... Plus dat het niet zo lekker vloeiend doorloopt ook...

[]D)izzy][\/][an]

Gaat best, gewoon flink doortrappen in zijn 3

Maar idd de techniek is nog niet zo ver, en de performance boost moet wel opwegen tegen alle kosten voor zowel hard als software ontwikkeling...

[nAFutro]

De voornaamste reden hiervoor is dat vrijwel alle Office-programma's in een 32-bit omgeving prima presteren en dat er dus weinig zijn om over te stappen naar 64-bit.

De programma's van Windows 3.11 werkten ook perfect.. waarom nieuwe versies in 32 bits maken?

[Verwijderd]

De overstap van 32 bits naar 64 bits is feitelijk veel kleiner dan die van 16 naar 32 bits.
Immers: 80386 en 80286 verschillen nogal.
Zo kan een 80386 tot 4GB geheugen adresseren terwijl een 80286 maar 16 MB (24 bits adressering) aan kon spreken. En 16MB is toch best snel een beperking.
Daarnaast beschkt de 80386 over speciale instructies voor multitasking en geheugenbescherming.
De overstap van 32- naar 64 bits is minder baanbrekend. Welke applicatie heeft er nu meer dan 4GB nodig? Alle belangrijke functionaliteit zit reeds in 32 bits processors.

[Codin the Coder]

De overstap van 32- naar 64 bits is minder baanbrekend. Welke applicatie heeft er nu meer dan 4GB nodig?

Er was een tijd waarin men dat zich hetzelfde afvroeg over 16MB.

Alles is relatief.

[Verwijderd]

Het verschil zit hem niet direct in het totaal aanspreekbare geheugen... Maar meer in de manier waarop je addresseert...
Met 16 bits heb je segmenten van 64 kb. Met 32 bits heb je segmenten van 4 gb.
Zodra je iets hebt dat groter dan 64 kb is, moet je dus van segment wisselen... en dat is lastig, en kost tijd. En 64 kb is natuurlijk niet zoveel. De meeste programma's en data zijn al meer dan 64 kb, en zijn dit bijna altijd al geweest. In 64 kb zou je bijvoorbeeld net een plaatje van 320x200 kwijt kunnen met 256 kleuren. Dat vonden we zelfs 20 jaar geleden al niet echt toereikend voor publicatie.

Maar 4 gb is dermate groot dat het voor de meeste dingen totaal geen beperking meer vormt. Voor dagelijks gebruik is het genoeg. Daarom is het een stuk minder interessant dat je voor sommige dingen nog wel segmented geheugen nodig hebt. Die dingen zitten niet meer in de categorie 'dagelijks gebruik'.. en zullen dat waarschijnlijk ook niet snel worden.
De limiet is overigens 64 gb op moderne 32 bit x86s, en daar is vast nog wel een tijd mee te leven. Ik zie het nog niet gebeuren dat we binnen een paar jaar ineens applicaties en data krijgen die meer dan 4 gb is. 64 kb daarentegen was eigenlijk altijd al te klein, en dat 16 mb wat krapjes zou worden, was ook nogal voorspelbaar. Zeker toen we GUIs kregen... hogere resoluties en meer kleuren zijn ideale manieren om grote hoeveelheden te laten verdwijnen... Maar nu hebben we al 32 bit kleur en resoluties van 1920x1440... Moet het nou nog hoger dan dat? Dat heeft weinig effect meer... je zit toch al tegen de grens waar je het verschil niet meer ziet. Daarom zul je op dergelijke gebieden niet zoveel groei meer in het geheugengebruik gaan zien.

[Olaf van der Spek]

In 64 kb zou je bijvoorbeeld net een plaatje van 320x240 kwijt kunnen met 256 kleuren.

Niet dus. Daarom was CGA ook 320 x 200 (320 x 240 = 75 k).

[Verwijderd]

niet dus. Daarom was CGA ook 320 x 200 (320 x 240 = 75 k).

VGA bedoel je zeker... CGA was planair, en 4 bitplanes... Dan heb je weer een heel ander verhaal.

[Olaf van der Spek]

VGA bedoel je zeker... CGA was planair, en 4 bitplanes...

Ja, klopt, MCGA/VGA, alhoewel CGA ook 320 x 200 was.

[CH4OS]

Welke applicatie heeft er nu meer dan 4GB nodig? Alle belangrijke functionaliteit zit reeds in 32 bits processors.

Is eigenlijk hetzelfde als zeggen van "Who needs more memory than 640K"

Maar ff zonder gekheid....

Programma's die megaveel geheugen (durven te) vragen. Denk hierbij bijvoorbeeld aan SolidWorks, AutoCAD en dat soort programma's. Maar denk ook aan bijv. VMWare, zeker als je meerdere virtual PC's tegelijk draaid, op 1 machine...

Of wat denk je van servers? Bijvoorbeeld (grote) databases?

[Verwijderd]

Tegen de tijd dat er een nederlandse versie is is er al XP128

[zzzzap]

Het zou slimmer zijn alle toekomstige software te baseren op het .NET Framework. Dan maakt het voor de programmeur weinig meer uit op welk platform zijn/haar software draait, het Framework voert in de JIT-compiler de nodige taken uit om de software voor het platform waar de software gestart wordt een optimalisatie uit te voeren.