Linked by Jordan Spencer Cunningham on Wed 7th Oct 2009 19:15 UTC, submitted by JayDee
Microsoft has been thinking about Windows 8 for a while now even through the production of Windows 7. Some information has been gathered by our friends over at Ars, and all of this said information points to possible 128-bit versions of Windows 8 and definite 128-bit versions of Windows 9. Update: Other technophiles better-versed than I in this whole 64/128-bit business pointed out that it must be for the filesystem (such as ZFS described in this article) rather than the processor and memory scheme.
Thread beginning with comment 388253
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Eventually, but now?
by sbenitezb on Thu 8th Oct 2009 14:21
in reply to "RE[4]: Eventually, but now?"
Member since:2005-07-22
RE[6]: Eventually, but now?
by galvanash on Thu 8th Oct 2009 17:12
in reply to "RE[5]: Eventually, but now?"
Member since:2006-01-25
Not only 64 bits computations, but the 64 bit mode also includes more registers available, so functions can be optimized to pass parameters through registers and not use the slow stack.
True, but in real world code more often than not the extra registers simply don't offer enough benefit to compensate for the slowdown caused by doubling the size of pointers... There are times where it helps A LOT of course, and it certainly doesn't hurt, but it isn't always effective. Besides, there is nothing magic about have 16 GPRs that makes it possible to use registers instead of the stack - you can use reg calling conventions with just 8 registers in 32-bit code as well - it just depends on how many parameters you are using, their types, and how many local variables you are defining. If your code has a lot of parameters or a lot of local variables then 16 GPRs will probably help, otherwise it will not have any effect or very little effect.
Member since:
2006-01-25
He didn't say it wasn't needed. He said it wasn't needed for most programs, which is absolutely true. He also said it WAS needed for programs which required large working sets (more than about 2GB, i.e. video editing and such), and to give the OS more address space to map processes into.
For virtually any 32-bit piece of software that has a working set less than 2GB and that doesn't require any 64-bit calculations, there is virtually no benefit to moving to 64-bit. In fact it can and will often do nothing but make it run slower.
That in no way means that moving to 64-bit addressing wasn't needed - it was absolutely needed, but most of the problem it addressed is isolated to OS memory management. There is simply no compelling reason to port a working 32-bit application to 64-bit unless you need the additional address space or you need to do 64-bit computations.
There are of course cases where a port is needed because of the need to interface existing 64-bit DLLs and executables (i.e. explorer extensions, plugins, etc.) But that is simply a side effect of moving one or the other to 64-bit - it isn't in and of itself a reason to do it.