To view parent comment, click here.
To read all comments associated with this story, please click here.
"It's taken us about 50 years to consume 32-bits of address space, so it should take another 50 years to consume the next 32 bits. This is the last transition we'll see in a long, long time. It's gone pretty smoothly so far, but a few hiccups are to be expected."
Hell yeah. In 2057 I expect computers will need to address more than 16 exabytes. That's 16,384 petabytes. That's 16,777,216 terabytes.
You can put me down as saying that we will not need any more than 16 exabytes for, maybe, 50^2 years. That's 2,500 years. (I'll revise that downwards to 500 years.) *
Of course, there may be other factors prompting an adoption of 128-bit processors and instruction sets. For example, IPv6 addresses are conveniently 128 bits.
* If quantum computers become viable, your license to discuss my prediction is revoked.






Member since:
2005-07-08
Suggest bad coding practices (assumption that there is <3Gb RAM present) and lack of thorough testing.
They should have caught this in testing, but it's actually a pretty interesting and fundamental problem. A 32-bit OS, even running on 64-bit hardware, provides each process with a 4GB effective address space that must be split into kernel and user space. The traditional split is 1GB for the kernel and 3GB for the user.
But these days most operating systems allow a few different segment layouts. Ideally you want at least as much kernel space as you have physical memory, because many parts of the kernel operate in real mode, where the code references physical memory instead of effective memory. If you have less kernel space than physical memory, there are physical memory pages that are off-limits for the kernel (called highmem). So we have 2/2 and 3/1 splits available for 32-bit operating systems.
If you have a 3/1 split to allow kernel-mode access to 3GB of physical memory, then each process only gets 1GB of user space. Paging (swapping) doesn't alleviate this restriction. If a process consumes its effective address space, then subsequent allocation requests will fail. Either the process will terminate itself or the kernel will force it to terminate by issuing a segmentation fault.
My guess is that the user process running the Vista installer can't run within 1GB of address space. This is only a problem if the installation kernel decides to use a 3/1 split, and this will only happen on systems with at least 3GB of memory.
This is what happens when you push up against the addressing limitations of the software or hardware architecture. If you want to run with 3GB or more of physical memory, and don't want lots of highmem, then you can't run large 32-bit processes. And this means 64-bit applications on a 64-bit operating system on 64-bit hardware is necessary.
It's taken us about 50 years to consume 32-bits of address space, so it should take another 50 years to consume the next 32 bits. This is the last transition we'll see in a long, long time. It's gone pretty smoothly so far, but a few hiccups are to be expected.