Slashdot Mirror
IBM Itanium Based Systems and Linux
ErrantKbd writes "An
article at Infoworld discusses IBM's plans to release Itanium-based systems sometime in the January/February timespan. They will be building systems running Windows of course, but also ready-made servers running RedHat, Caldera, TurboLinux, and SuSE. Should be pretty sweet provided everything goes smoothly with the 64-bit processor. Note: there is an error in the article, a 64 bit system can directly address approximately 1 billion times more than the article suggests." Those'll be one helluva desktop box.
Nobody has noted the real virtue of a 64 bit address space, even if the Itanium itself only supports about 50 for VM. With a 64 bit address space, there is no longer any need to run applications in their own address space. You can finally recognize that protection is orthogonal to addressing, and start to gain the benefits of not having to invalidate the TLB and other parts of the VM system when you do a context switch. That is, all processes run in the same address space, so they can share memory with no effort whatsoever, and you use an explicit protection mechanism to avoid memory stomping. Opal was an experimental system that tried to explore some of these ideas. It was a PhD thesis at the University of Washington. The tech report notes that with a 64MB address space, you can allocate 1MB/sec and not run out of VM space for a period of time larger than the estimated current life of the sun. The real benefits of 64 bit addressing have little to do with increasing the data width. Avoiding a TLB flush when doing a context switch will provide one of the most dramatic speedups for multi-tasking systems that you can imagine.
Oh come on... 16 gigabytes ought to be enough for everybody.
--
--
Mod up a post Rob doesn't like and you'll never mod again
The address space may be less than 64-bits wide.
There's a difference between the architecture and the implementation. The architecture may allow for a 64-bit address space, but not require it. In many 64-bit processors, many of the address lines are hard-wired to zero. I would not be at all surprised if this is true for Itanium.
Also, even if the processor actually supports true 64-bit addresses, that doesn't mean the motherboard chipsets will support it. Hence, real systems may be limited in their memory configurations.
I know that VA Linux sells some systems that have 16 memory slots (yes, Intel machines!).
:-).
here is a link to a HP server that supports up to 128GB of memory in one box. I know it's a high end unix server, but wasn't itanium intel's pathetic attempt to compete with these kind of machines?
then there is the coveted Sun Enterprise 1000 which seems to support up to 68GB of RAM, plus a bunch of others from SUN
Then there is this bad-boy from IBM, which supports up to 96GB
Of course there are the Alpha servers, of which the GS series is an example. Up to 256MB.
There are boards that support way more than 8 RAM slots and have been for some time. Hell, you can get a system that supports more than 16GB from ebay.
PS, anyone who wants to donate one of the linked systems, please reply to this and we will arrange something
-----
# cd /
It's not just a matter of address bus... If you have a bunch of programs and you want to do virtual memory and you want each program to see the full address space.... well, you need 64bit addressing in your virtual memory system. It helps when that's just an int you can stick in a register....
I think we're ready to take the plunge. All Itanium really is is just another platform. I don't see any difference in the relationship between Itanium and x86 and say the relationship between x86 and SPARC. Once the compilers are ported to the new architecture, I'd say a good portion of the existing code will compile nicely on the Itanium.
At EMC, we sell high-end storage systems. They're essentially supercomputers dedicated to providing high-performance ultra-reliable storage. We currently support upto 32GB of cache RAM in one system.
I've seen low-end storage systems based on Linux in the one TB range. As these systems grow up, they'll quickly get into the >4GB range if they want any sort of performance.
That being said... In many circumstances today 64-bit processors are a waste... especially in a desktop. 64-bit (and wider) data paths are certainly a big help even on a consumer desktop. 64-bit registers and instructions to natively and atomically handle 64-bit values are not a gain, they are a loss. My reasoning here is that on a desktop-type machine, most (90%+??) of the numbers traversing the registers are will within the 32-bit range... and you've wasted a buttload of {silicon|power|heat|engineering_talent} on that 64-bit support that could've been spent elsewhere.
Given two machines with wide data paths, 4GB of memory (which fits in both architectures) a 32-bit processor would blow the socks off of a 64-bit processor assuming both have equivalent number of transistors, power input, and engineering input. And remember, I'm talking about desktop apps and games here.... Obviously everything I've said above is invalid when you do _real_ scientific computing, which regularly involves >32 bit numbers, or really needs direct access >4GB of memory.
11*43+456^2