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.
The first Itaniums WILL only be able to address 16-64 gigabytes, because of chipset limitations. A later release of the motherboard chipset will expand beyond that.
Oh, you're not stuck, you're just unable to let go of the onion rings.
but the reason the Enterprise market has been so Solaris
based, is that their hardware is rock solid in comparison
yeah, and swapping to a new CPU is going to change that? Face it, Intel and it's cronies just want to sell commodity hardware at enterprise prices. As long as they continue to do so, they will not unseat Sun - unless Sun decides to try to do the same thing (hey, why did that plastic face plate just snap off of my brand new $20k Sun E250? )
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
The Itanium, on the other hand, will run 32-bit software like a one-legged garden slug; it will debut no higher than 800 Mhz, and clock-for-clock will be terrible on 32-bit code (as in, much worse than any other Intel chip currently on the market). But if you must have a 64-bit chip now (for values of now equal to early next year), it's the only x86-ish game in town.
(Though given its performance shortfalls, that it will be a brand new chip -- with all the baggage that carries -- and the expense, I'm not sure why anyone who needs 64-bit now wouldn't go buy something from one of the big-box vendors...)
Basically C is full of assumptions that an integer can store the difference between pointers. You can change all the arguments that you know are "sizes" to size_t, but you will eventually find code that takes this and calls functions (like math functions) where it is perfectly legit to pass an integer and you don't want to change those to size_t, so you end up with impossible-to-remove type conflicts. Size_t is also causing all kinds of portability problems when trying to go between platforms that make it the same or different than int, or that don't define it, for instance I have to type in a prototype for the missing snprintf function a lot and it is different on every machine.
The problem is of course huge amounts of code that assumme int==32 bits. C should have defined some syntax to say exactly how many bits a variable has, perhaps "int var:32", much like a bitfield (the compiler is not required to support all possible sizes, only 8,16,32,sizeof(int)*8 and can round smaller sizes up and can produce an error if larger than the largest is requested).
Unfortunately that did not happen and we are in the mess we are now with all these typedefs and the inability to do clean pointer arithmetic.
It really drives me nuts to see people screaming about how hot the "new" 64-bit Itanium is. Like it's never been done before.
The Alpha processors have been 64-bit for a long time already. I went through college thinking 64-bit was perfectly standard because we were using an Alpha. Then I graduated a few years back and found that the rest of the world was still stuck at 32 bits, waiting breathlessly for the Itanium.
I've been running 64-bit apps under a 64-bit OS on a 64-bit chip for quite a while (recent Solaris on a V9 UltraSPARC cpu).
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Windows Me still has 16-bit system code necessary even if you run only 32-bit software. It's got less then 98 did, which had less than 95, which had less than WfWG 3.11 w/Win32s and 32-bit file access enabled did; but it's still around.
OS/2 5.0 also has a morass of 16-bit code in system areas, still left over from OS/2 1.3, and a lot more Windows for Workgroups 3.11 code and architecture is in Windows Me than OS/2 1.3 code and architecture is in OS/2 5.0
There's no "we" in team, only "me"
pitiful 486SX chip, a crippled CPU that probably had no right to exist
Well, the 486SX wasn't supposed to exist. SXs were merely DXs whose FPUs failed in testing, and were shipped with the FPU disabled.
There's no "we" in team, only "me"
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.
Actually, the Itanium will run x86 code (slowly); it has hardware emulation (which can't take full advantage of the Itanium's parallelism). You must have an OS compiled for the EPIC instruction set.
For Clawhammer/Sledgehammer, you can run legacy 16- and 32- bit software under a new 64-bit x86 OS, or you can contiune to run your 32-bit or 16-bit x86 OS on the chip.
Personally, I expect that the Itanium will wind replacing Alphas running Linux and NT, and inherit the current PA-RISC market. Intel will wind up creating server variants of its x86 chips to hold on to the current x86 server/workstation market, with marketing demanding those to stay confined to 32 bit instruction sets.
The Sledgehammer will thus have no real competition as it seizes the entire Linux-on-x86 server and workstation markets, with a 64-to-32 bit advantage. If Microsoft delivers an x86-64 NT, the NT-on-x86 market will certainly go Sledgehammer; otherwise, the high end will migrate to Itanium and the rest stay on Intel and AMD x86 chips running 32-bit NT.
If the marketers were to be shoved aside, Intel would crash-engineer and release its own 64-bit x86, and maintain unquestioned dominance. They won't be. Instead, Intel will enter a market where it will be one of four players (with Compaq, IBM, and Sun), and lose dominance of its current cash-cow market to a codominion with AMD.
There's no "we" in team, only "me"
It is a 64 bit processor because it has 64 bit registers, ALUs (execution units), and memory space.
No, an individual instruction cannot carry a full 64 bit address - but then neither can a single 32bit RISC instruction carry a full 32bit value, nor a 64bit RISC instruction carry a full 64bit value. No difference on MIPS or Sparc.
If you need to load a new 64 bit address you probably have to do it it two instructions - one containing the lower 32bits and one containing the upper 32bits. But how often are you going to have individual program with a grobal dat segment in excess of 4gb?
(btw, the instructions are 41 bit, not 42.)
cheers,
G
Some people don't seem to get why a 64-bit architecture would be useful. Let me say that it's not just about doing 64-bit computations and having a larger address space.
I'd say that transferring more data and having more registers to play with are more important features, as well as being able to do 32-bit computations in paralell. (having 64-bit computations in hardware is nice too; that makes it all possible)
Also, remember that the Itanium is an architecture that's designed to grow. Much like how Transmeta's chips will improve in speed as the software is being fine-tuned, the Itanium's software should show massive speedups once (a) the compiler is optimized, (b) everything is recompiled natively, and (c) code is rewritten (as needed) to exploit the architectural featueres.
I'd say that we've already seen a preview of what sort of difference this sort of thing can make with the Pentium 4. (if you missed it, it's on Tom's Hardware) It can make a huge difference. I'll be interested in seeing how Linux stacks up, and how optimized gcc is at the moment; I'm sure we'll have our work cut out for us.
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Most of the top rated systems throughout the world, sending packets for SETI@Home, are Compaq servers running Tru64 Unix. Most of this is due to the scientific data using 64bit accuracy, for which the "contemporary" systems of 32 bits just aren't adequate.
Other applications that crush with 64 bits include high-quality graphic rendering, vast database addressing, and, oh yeah, NETSCAPE 6! ;-)
I get impatient enough as it is waiting for self-test of 4 GB RAM on some of my larger boxes. Imagine waiting around for 4 TB! Better hope they never have to reboot....
On a more serious note: Unless overall RAM bandwidth starts taking some major leaps soon, it will become an ever narrower bottleneck to overall system performance.
#include "disclaim.h"
"All the best people in life seem to like LINUX." - Steve Wozniak
#include "disclaim.h"
"All the best people in life seem to like LINUX." - Steve Wozniak
The math co processor was onboard during the 386DX as well. That was the difference between the DX and the SX.
They released the 386 with the co processor onboard, then removed and and sold the SX as a cheaper model.
The did the same thing with the 486, releasing DX and SX models of them as well.
I managed to make one turn a fascinating shade of puce by asking him "So, are you actually confident that you'll be able to ship ia64 boxes in quantity by the end of Q1?" He managed to choke out something along the lines of "well, obviously we're somewhat constrained by other vendors here" before changing the subject back to how nice AIX5L was going to be.
If I were Scott McNealy, I would not be overly concerned.
News for Nerds. Stuff that Matters? Like hell.
Point 1: from what I've read, Itanium will only be offered in high-end server configurations for the first year. Desktops will come noticably late afterwards. Point 2, more importantly: is Linux ready to take advantage of Itanium features? Support for P3 instructions in Linux have been slow at best, and Itanium will apparently be so different from x86 code that entire software that recompilations of software and OS's will be necessary in general. Are we ready to take the plunge?
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
Maybe you should get a new keyboard first...
--
--
Mod up a post Rob doesn't like and you'll never mod again
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
I'm just wondering if having a 64 bit RAM address bus is really practical right now or in the near future? A typical server board can hold at most about 8 memory slots. The largest chip that I know of is a 512MB. That's 4 GB of RAM, which is in the 32 bit addressing scheme.
Is there any practical application for a single system to require more than 4 GB of RAM? It seems to me that once a task becomes so huge as to require 4GB of RAM, it might be time for a cluster or a mainframe type solution rather than one massive system.
Don't get me wrong, I think the development of the 64 bit technology is awesome; I just wanted to raise the question of practicallity.
Those'll be one helluva desktop box.
Actually, no they won't. Not unless all your apps are 64-bit, and even then....
-----
YOUR statements are baseless. I beleive I have a basis for my statements. I believe I've repeated it enough times here: The vast majority of all uses of the registers will be for =32 numbers... the wasted silicon and engineering could have been spent elsewhere... GET IT? Brandon
11*43+456^2
I'm not aguing against VLIW.... whole other matter... your argument there makes me feel better about Itanium. I'm just arguing against 64-bit processors for non-engineering/scientific/heavy-visualisation tasks.
11*43+456^2
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 wouldn't rate Solaris over say Linux or FreeBSD, but the reason the Enterprise market has been so Solaris based, is that their hardware is rock solid in comparison and their use of SMP (Symetric Multi Processing). Linux and FreeBSD have come along way in utilizing these features in their kernels... but hardware is where they have been lacking. When XFS or ext3 JFS's (Journaling File Systems) become stable and with an Enterprise class processor like the Itanium, I see a big change in the .com industry or any E-commerce industry... Comments? flames? questions? discussions? arguments?
Sarcasm is the recourse of a weak mind...
--
Someday, when everyone's standard gui interface is a a full VR gear type of thing, 64-bitness will be neccesary at the desktop, but not today. What I'm fighting against is the marketing of 64-bit CPU's as a great new feautre for desktops
11*43+456^2
God does not play dice with the universe. Albert Einstein
Those who fail to understand communication protocols, are doomed to repeat them over port 80.
I have been working in IBM Java Tech Centre (http://developers.ibm.com/java this summer (as an intern) with an Intel Itanium box developing the Java VM for IA64.
;-p
Linux is ready for IA64 - by the time I left the compiler and OS is relatively stable enough to compile most things. Though Intel still has a few things it need to iron out in the hardware........
Most stuff in fact compile directly - I used turbolinux frontier ia64 (http://frontier.turbolinux.com/ia64 - they got helixcode and stuff working! There is a porting guide on that website as well and those of you who have an opensource project on sourceforge should be able to use the sample hardware to try to recompile and test your software.
IBM is really big about Itanium - wait for more and more announcement
One might also use the Pro64 compiler from SGI. This compiler does implement IA-64 specific optimizations and it even generates assembler code which is easily readable. The compiler does not come with an assembler or a linker, however, so you'll have to rely on GCC to do that part of the job for you.
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.
This still allows for more then 16Gb of RAM, however the workstations probably only allow 16Gb of RAM. This is probably not an error. It doesn't necissarily have to be a processor limitation, it can be a motherboard limitation...
11*43+456^2
from Sharky Extreme Article
Someone you trust is one of us.
For a less pie-in-the-sky example, most any RDBMS will use up every byte of memory you can throw at it. Page cache, page cache, page cache. High-volume enterprise systems suck up RAM like no tomorrow, and put it to good use.
--
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
IBM's support of its own hardware choices for Linux systems is sketchy at best... ThinkPads were merely the best example because of the fact they must use cutting edge technology to provide the best performance per battery costs.
Just as the S3 video for a ThinkPad's Mobile/Savage IX is hard to configure, so it is with the majority of the S3 line IBM uses. Does IBM take notice? If you examine the servers on their website, They say they support their hardware, but in the asterisksed footnotes, they say it is only tested to work is a plain-jane SVGA display.
Recently DELL made an announcement that it would incentivize hardware manufacturers to be more forthcoming on their specifications for Linux drivers. Can't IBM do likewise? Is the crippled support they actually impliment worth claiming as support at all?
Another site to check is Red Hat. They sort supported systems by manufacturer, including IBM. There you can see which systems are "supported" for RedHat (which in turn should mean support for redhat compatible Mandrake), and in what ways the support is held short.
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
It is great that IBM is offering a choice of distributions, rather thatn just RedHat (whihc is what most OEMs do), but there doesn't seem to be any mention of Debian or Slackware, which I thought were very popular. I don't know if they count as "top 4" which is what the article says IBM is supporting, but I know they're very widely used. Is this a sign of corporate foul play or just financial necessity. It doesn't seem that if they're supporting (or at least installing) four different distributions that it would hurt them terribly to install one or two more, especially since Slack users tend to be pretty Linux-savvy already and one could probably say the same about Debian users, too. I'd be inclined to say that IBM is just afraid of non-commercial backing for the distributions it supports, which is unfounded if you ask me.
-----
# cd /