Slashdot Mirror
Itanium Update
NegaMaxAlphaBeta writes: "For those of you interested in Intel's Itanium 64 bit processor, EETimes has a nice update article to let us know what's happening with this beast. With an 8 stage pipeline, as opposed to the 20 stage pipeline in the P4, clock frequencies are obviously not as high (~1 GHz). Other notable numbers extracted from the article: 130 Watts power consumption, 328 registers, 6 MB of onchip L3 cache ... quite nice (well, not the power thing). I'm sure many people can appreciate 64 bit integer ops; for me, it means single instruction xor for the 64 bit hash codes used in chess transposition tables."
As someone with a few friends that recently made the move from Compaq's Alpha division over to Intel, what I'm most curious about is what revision of the chip will we see any improvements being incorporated from the Alpha design. I can't imagine Intel would want to let out any news on work that they bought instead of engineering themselves, but I think it'd be interesting to hear what exactly was directed ported over in the designs, if anything, as well as a detailed comparison of the two processors. Any info, anyone? Perhaps the second big revision of the IA64 chips?
Interested in open source engine management for your Subaru?
Right. And there's no indication that something similar will appear in IA64 until at least 2006 (which is the *earliest* that the Alpha team could likely add it to that complex - or if you prefer messy - an architecture if the hooks for it weren't already built in).
It's a weak second to SMT. With HT, as I understood it, if a processor happens to have a floating point op and an integer op on hand at the same time, it can run both of 'em at once, instead of sequentially. That's the limit to the HT magic. It can't do two FP or integer ops at once.
Well, real-world server applications could be sped up by 30%, which would mean that HT could execute multiple *non*-FP instructions at once (and the article doesn't say it can't, just that it can't execute two FP ops at once).
It actually seems to look quite a bit like EV8's SMT, except that we don't know if it currently adds more execution units to the P4 architecture and whether all execution units can be applied to service a single thread if multiple threads aren't present. And, of course, it only supports two concurrent threads rather than four.
Intel stole and then implemented Alpha technologies for its Pentium, and only much later did it negotiate with Digital to get the official right to use that stuff.
No: I'm assessing the situation, unlike your propensity for drawing conclusions based on vague speculation and no data.
IA64 has to all appearances been developed with zero attention paid to things like out-of-order execution (in fact, it was developed explicitly to *avoid* out-of-order execution). OOO and SMT are intimately intertwined in EV8's SMT design, and apparently also in HT's. There's no indication that Intel has until now given any thought toward incorporating SMT/HT technology in EPIC, and every indication that it will thus take at least close to 5 years before such IA64 technology hits the street (especially as incorporating it into EPIC will almost certainly involve radically different internal approaches than those used to incorporate it into EV8 and P4).
Shades of the whole 486SX debacle?
The way I understand it, Intel bought Alpha not to praise it, but to bury it.
I will now translate the thoughts of an average American regarding this article:
"Wow, a 64-bit processor with 6MB? I can finally have a computer more powerful than my N64! I hope it doesn't let little Billy access all of that satanic-internet-porn any faster, though...."
I'm sure it is proprietary, but Intel has written it's own optimizing compiler for the IA64 instruction set.
It is an interesting solution to the performance problem: Rather than just increase clock speed again, figure out the performance details at compile time and arrange the code to help the processor run it more efficiently.
For example, if you have an if statement and the compiler can determine that 95% of the time the TRUE block will be executed, the code can be arranged so the branch prediction will choose the more frequent route and the pipeline penalty won't need to be paid as frequently. (This is just a simple case of optimization, the IA64 will require insanely complex optimizations, but that is just expanding on what compiler writers have been doing for years.)
It makes the compiler orders of magnitude more complex, but it could potentially increase execution speed by a couple orders of magnitude too.
So when most people go out and buy a computer, they see a lot of mhz and think it's really fast. So if they're use to 2ghz+ pentiums, why would they even think of buying a 1ghz itanium? Sure, I know it'll probably be faster, but how does intel plan to market these? Will they also drop mhz ratings like AMD? Or will they go on some major re-educaiton campaign, like Apple?
F-bacher
James Tiberius Kirk: "Spock, the women on your planet are logical. No other planet in the galaxy can make that claim."
...the Itanium product line will see its speed increase from 800 to 1 GHz, which is half the frequency of the company's fastest 2-GHz Pentium 4....Intel contends, however, that the faster front-side bus, more on-chip memory and redundant logic resources will more than make up for the processor's lag in clock speed.
We can only hope that this chip helps the media away from using clock speed as the primary (often only) measure of performance.
for me, it means single instruction xor for the 64 bit hash codes used in chess transposition tables
Watch where you say that, or you'll be using that nifty Itanium to repel the hordes of women instinctively flocking to you like the salmon of Capistrano.
Is anyone else so completely stunned as me, that essentially everyone (except AMD) has rolled over and allowed the IA64 to be crowned heir apparent as the new high-end microprocessor? The Alpha is dead by acquisition, HPPA is dead by partnership, MIPS is lost somewhere in the low end, and Sparc and Power4 are both retreating upstream.
It's amazing that ANYONE can field the number of mistakes that Intel has, and get away with it. For some time now, their first-outs have been essentially flops:
Pentium: Remember the 5V room heaters?
Pentium: Then the 3.3V units with floating point bugs?
Pentium Pro: The ancestor of the Pentium II/III line was a good CPU in its own right, and worked well for Unix and OS/2. But it completely missed the market, performing terribly on 16 bit code.
Celeron: DeCeleron, until they put the cache back on. From another point of view, the whole Celeron program has been a disaster, either by its own crippling, or by revealing how overpriced the PII/PIII line is.
Pentium III: CPUID - A 'workstation idea' that once again missed its market. Maybe if they'd found a way to node-lock software that can't be used for machine tracing. Maybe that's not what they were after.
Pentium 4: Let's face it, this CPU is just plain uneven and imbalanced. After a round of redesign to even it out, just like with the others, it could very well be an excellent CPU. Tame the prefetch, expand the trace cache, etc.
Itanium: Didn't even make it out the door before spin-doctoring began. "Just wait for McKinley!" I've already heard one set of rumors that McKinley isn't going to *really* do it either, so just wait for IA64-III.
Is all this any better than the "Just wait for this new release!" that Microsoft keeps pulling? Though I guess Intel does generally get each family right on the second shot.
AMD has a good product, I just wish they were a little less mum, and had a better response than warmed-over P-numbers. I also wish we could hear a bit more noise about the Hammers.
The living have better things to do than to continue hating the dead.
Intel has a lot of smart people working for it (smarter than either you or I). They have done some dumb things, but overall they've been on the mark a surprising number of times (even the P4 looks pretty impressive now that clock-speeds have ramped up). It would be a serious mistake to underestimate them like that. If Intel is putting this product on the market, you can bet that they've fixed the compiler problem. Initial benchmarks of the Itanium seem to show that it can keep right up there with the Alphas and SPARCs in terms for performance (fp, at least).
As for compilers, don't discount Intel so easily. They make incredible compilers. The features of ICL for x86 make compiler designers cream their pants. Read this article for some info about Itanium's compiler design.
A deep unwavering belief is a sure sign you're missing something...
The article states that the Itanium pulls 130 watts of power. That seems rather high, even for the space heaters that we like to call cpu's nowadays. Is the Itanium using the new all-copper .13 micron process, or an older technology?
(bolding is my emphasis)
To protect against heat-related system meltdowns, McKinley includes a programmable thermal trip that can throttle processor performance by 40 percent to cut power consumption. But the company sees that more as a safety net, not as an answer to thermal issues. "This should never be needed in a properly designed system," said Naffziger.
Yea, they are. As I remember it, 128 general purpose integer and 128 general purpose fp. Download the Intel C++ docs for some info about the ASM-viewpoint architecture of the Itanium.
My only question is for the OS guys out there. How does an OS handle context switches with 328 registers? With 8 bytes per register, thats more than 2K of data to dump out every context switch!
A deep unwavering belief is a sure sign you're missing something...
Apparently you're not familiar with VLIW processor design. It's not "throwing it off" to the software guys because it's too difficult to implement. It is dramatically reducing the complexity of the pipeline, thereby increasing throughput by orders of magnitude (see CISC vs. RISC).
And the compiler has far *more* information than the runtime hardware has. The scheduling hardware is only capable of looking a few instructions at a time to decide how to enhance ILP, whereas the compiler by its very nature has access to the entire program at once, and can perform optimizations not possible in hardware.
This is further enhanced by a development cycle that includes profiling. As you use the program during development, the compiler can use the same profiling information that is used to "manually" optimize code to perform its own optimizations. With an advanced OS, this become extremely powerful, as some of the registers on the processor actually keep track of profile data at runtime. Then, during page swaps to/from virtual memory, the processor has the opportunity to dynamically optimize and recompile the code.
Yes, any decent compiler will perform this optimisation. In C there's no difference, because you're not using the value of the expression. In C++ 'i' could be of a class with an overloaded operator++(int) which would involve creating a temporary. It's not always possible to optimise that away.
My god. I'll never learn assembly on a modern chip. I tried on the 386/486, but gave up, and opted for the 65c02 (a fine little chip). I'm getting to the point where it's time to move on, and I was going to attempt the 68k or even PPC (no altivec though). I think I might actually manage to learn that, but I can't even begin to imagine 328 registers. Especially arranged the way intel tends to arrange them...
Will anyone outside of cpu engineers and compiler authors even learn asm on this monster? Or have we truly moved past the point where programmers understand the cpu?
328 *physical* registers, not logical (ISA accessible). with 128 context switches will hurt big time ia64. yet another bad design decision of the itanic.
A context switch happens one in a blue moon. Fast context switches are not going to make up for sluggish performance for the real work the machine is doing between context switchs. Registers are considerably faster than cache; the absolutely fastest cache in the world is P4's L1 cache which has a load latency of 2 cycles, and on most architectures it is 3 cycles. Putting 128 qwords into registers is an absolutely dramatic speedup for programs which have a working set more than 8 dwords (all that IA-32 gives you).
Damn, I guess a large scale SMP machine will be dual use convection oven then. Oh wait, by the time I add in FSB buffering and memory maybe that will be true of the workstations :-).
I think I've figured out what the whole 64-bit thing is about. It means that each instruction (right term?) has more capacity to carry data. This doesn't necessarily mean that it will be twice as fast, of course, because not all instructions are that large.
What I'm confused about is how it affects programming. Does this mean that everything will need to be optimized for you to take advantage of the higher bitrate? How will programs that are written for 32-bit systems handle it; can they handle it? How about backwards compaibility?
Do any other people read these sort of threads even though they know that it will be over their heads most of the time?
--Kintara
I received this from one of my intel comrades which was sent to all of the intel eployees.
Speed is important. On Monday, Intel launched the Intel® Pentium® 4 processor at 2 GHz. Tuesday, during his keynote atthe Intel Developer Forum, Paul Otellini, executive vice president and general manager, Intel Architecture Group, demonstrated a processor operating at fully 3.5 GHz.
But that's not the half of it. Otellini went on to note that the Pentium4 microarchitecture is expected to scale to a whopping 10 GHz.
Now that's a "Wow!"
But, exciting as speed is, it isn't everything. While it is important,"it is not sufficient to drive the levels of growth and innovation that will allow our industry to prosper," Otellini said.
Speaking before an audience of 4,000 developers, designers, and executives Tuesday, Otellini noted that as the computing industry has grown and new technologies have evolved, purchasing criteria are changing. "We all need to change the pattern of our investments," he cautioned the crowd. "We need to think beyond gigahertz and build substantially better computers."
Buyers now look to a variety of features, noted Otellini: style, form factor, security, power consumption, reliability, communications functions, price, and overall user experience. Combinations of these and other features are driving end-user technology requirements in individual market segments. Intel plans to develop technologies that will help address these changing requirements in each of the key market segments.
Here are just a few of the ways Intel plans to go beyond gigahertz, as Otellini revealed in his keynote address:
It's like multiple processors on a single chip
Otellini introduced the audience to a breakthrough in processor design called hyper-threading. This technology allows microprocessors to handle more information at the same time by sharing computing resources more efficiently. The technology provides a 30 percent performance boost in certain server and workstation applications and will first appear next year in the Intel® Xeon[tm] processor family.
This makes me wonder, how many Crusoe processors could you put in a box (all other components equal) and equal this power consumption? Would the performance of such a box meet or exceed the performance of an Itanium box for real-world servers?
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
but that is just expanding on what compiler writers have been doing for years.
What they've been doing wrong for years.
Simplicity is the correct answer, Intel clearly didn't understand the question.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
It is dramatically reducing the complexity of the pipeline, thereby increasing throughput by orders of magnitude (see CISC vs. RISC).
Brought to us by the same people that told us the big pipeline would solve all our problems and that RISC was a deadend, that bought up and squashed the ARM, that thought that no one would need more than 8 registers or 640K of memory and all the other crap Intel have spouted since it invented the 4004 and then proceeded to get everything else wrong.
Intel has spent the last twenty years proving how little it knows and how much it depends on MS for a free ride onto the desktop.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
With an 8 stage pipeline, as opposed to the 20 stage pipeline in the P4, clock frequencies are obviously not as high (~1 GHz).
...6mb of on die cache...
This beast has a small wang... its not the size that counts, but how you use it. (no giggling from the girls damn't)
130 Watts power consumption...
Who needs space heaters anyway?
OY! Hold your wallet tight, not for the light bank accounted!
I'm sure many people can appreciate 64 bit integer ops; for me, it means single instruction xor for the 64 bit hash codes used in chess transposition tables.
Not quite what the intel boys will be using in their next commercial. However, the wizards in marketing will be stressing the enhanced features of porn browsing. The fourth blue intel commando will be a scantily clad woman... further emphasizing the need for this processor which will not just make the internet faster, but will speed on your favorite pron sights.
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
So where do I download a free reader that runs on Linux for that file of binary garbage?
now we need to go OSS in diesel cars
I don't care of you have the smartest people in the world, which is likely with Intel, if you mismanage and drive products the way Intel has it does not matter.
Sure you have a ton of smart people but I just have a lack of faith in the whole architecture. You can have the brightest bunch of people in the world but if you make them cook burgers does it matter? Not to discredit your post on other means, but saying because Intel has smart people is kinda silly. They also have stupid people by the same token, does that make them less likely to suceed?
Jeremy
Simplicity is the correct answer, Intel clearly didn't understand the question.
That's assuming they were listening in the first place.
If Intel had big plans for the long run, they'd create a "simple" processor, let's take the original Pentium as a bad example:
Add MMX. Customers upgrade.
Change processor form factor. Upgrades galore.
Add SSE. More upgrades.
Change proessor form factor again. Upgrade.
Change form factor, add SSE2 and slap on a few marketing terms. Further upgrades.
The advantage is each time you can say the processor is "new and improved" so people will buy new ones. Does it really matter that a Pentium III 600 is more than enough power for 90% of computer owners? Of course not.
What makes me laugh, though, is how Intel switched to the Slot 1 form factor so it would be easier for customers to install processors (how often does that really happen?) and then switched back. I'll bet they were planning it all along.
My point was that you can't outright say "why is Intel doing such a dumb thing?" (Which the original poster did). Intel is not a stupid company (like MS). They have been very sucessful, not based only on their monopoly status (AMD has been making significant inroads into their turf) but because of the quality of their products. Within the constraints of the x86 architecture, Intel's chips have been incredible. Even now, the P4 looks really promising in its 2GHz+ varients. You just can't discount such a company so easily.
A deep unwavering belief is a sure sign you're missing something...
Apparently, this poster things that cutting edge designs get written at the moment of their release.
A deep unwavering belief is a sure sign you're missing something...
You're right, I had a brain blip on that. I meant PSN instead of CPUID.
I merely wish they had looked into some PSN-type technique that would let software be nodelocked without being usable for tracking. I don't believe PSN must be bad, at least not to anyone other than a fanatical Free Software type, who believes NO software should need to be paid for. I'm sure a technique can be used which will not alarm privacy advocates.
The living have better things to do than to continue hating the dead.
So, by the way that's phrased, either you have no idea what the number of bits per instruction has to do with anything, or you're dumbing down your language because you think the rest of Slashdot doesn't.
"G4 has 128 bits in it! Bits make computer go fast! Bits good!"
Win dain a lotica, en vai tu ri silota
anybody would want to do that
Think NOP. I believe on the alpha a nop was implemented as add r0, r0, r0. Possibly on other architectures as well.
"When you sit with a nice girl for two hours, it seems like two minutes. When you sit on a hot stove for two minutes, it
The thing sucked eggs, and I threw the motherboard in the trash and used the CPU as a paperweight.
At some stage, I needed a faster CPU, needed a motherboard to go with it, so I made the jump to a PentiumIII/450. I needed to revive my firewall, so I bought a decent ASUS 486 mobo at a fair. On a hunch, I put my paperweight AMD133 in. I was pleasantly surprised, and I only replaced the thing when I got a real cheap 300MHz Cyrix mobo.
Bottom line, it't the motherboard (or rather the chipset on it) that makes or breaks the CPU. I'm now running an ASUS A7V-E with a 1GHz Athlon, and I've been a happy camper. I'm not an overclocker (matter of fact, I underclock some machines just because I don't need CPU power for other things than video recoding, and some machines are on the other end of the globe, so I don't want to lose sleep over fan failure).
My main gripe with the VIA KTA133 chipset is the fact that I have to sign a $#@#%$#% NDA to get decent specs on it. FreeBSD doesn't seem to grok its I2C based hardware monitoring, and without those docs I'm SOL. Apart from that, it's working great. Even under Carmageddon^WWindows.
Bert Driehuis -- All I asked was a friggin' rotatin' chair. Throw me a bone here, people.
Why do I have visions of new computers plugging into a 230V AC socket, like dryers and ovens? 130 watts an awful lot of juice when you consider most power supplies only put out around 5 volts DC or so.
For those that don't remember their EE or physics courses: watts = volts * amps. And one amp through your torso is enough to kill just about anybody.
True, but probably unimportant. OpenFirmware has been around (I think even as an IEEE standard) for ages, but apparently the PC world doesn't care.
If I sound frustrated, it's because I am. OpenFirmware is such a small bone to throw the techies that I think it's criminal it never came about in the PC world. After years of haggling the BIOS vendors, we now have BIOSes on some machines that can optionally emulate an ANSI terminal for console access on a serial port. Which means you can use Kermit under DOS to manage the machine remotely. Even "tip" on UNIX is suboptimal here, and the best this BIOS will do is emulate the full-screen config menu. Beeeuuurk.
Bert Driehuis -- All I asked was a friggin' rotatin' chair. Throw me a bone here, people.
Needless to say, this great concept had gone to the dogs before the first consumer laid his/her hands on the device. Oblivious to the CPU design, a major manufacturer of operating systems (we called them BASIC interpreters at the time, by the way) has decided that most of page zero should be allocated to the OS^WBasic interpreter. I'll leave it to our hidden conscience to name the prepretrator of this gruelsome mistake.
I have long grown over the idea of using assembly as a faster programming language. The number of times I beat an assembly program with something hacked up in Perl, I don't even want to remember. Not because Perl is the best thing since sliced bread, but because humans are so poor at dealing with complexity. Get it working first, and leave optimization to the compiler. Then, if you have a bottleneck, analyze it, and fix the bottleneck in a targeted piece of code (whether C, or assembly, or something else).
Bert Driehuis -- All I asked was a friggin' rotatin' chair. Throw me a bone here, people.
> It is an interesting solution to the performance
> problem: Rather than just increase clock speed
> again, figure out the performance details at
> compile time and arrange the code to help the
> processor run it more efficiently.
That is neither interesting nor a solution. People (i.e. compiler writers) have been working on this for forty years with some (limited) success.
> the IA64 will require insanely complex
> optimizations, but that is just expanding on
> what compiler writers have been doing for years.
Just because the IA64 demands heroic compiler optimization to make up for its shortcomings doesn't mean that the ability to write such compilers will suddenly spring out of nowhere.
Compiler researchers haven't just been sitting on their butts for the last forty years.
> For example, if you have an if statement and the
> compiler can determine that 95% of the time the
> TRUE block will be executed, the code can be
> arranged so the branch prediction will choose
> the more frequent route and the pipeline penalty
> won't need to be paid as frequently.
This was a bad example. Dynamic branch predictors (such as you find in any modern fast CPU) do a great job in practice, better than any known static predictors.
It's already a reality. What Intel calls hyperthreading is coming in the next generation Alpha, is already shipping in POWER-based AS/400 systems, and is also in some specialized network processors.
> Having more data at compile time does not
> preclude having the same branch prediction and
> memory access data in hardware, as you imply.
> Itanium still has the ability to do branch
> prediction and handle memory latency the same as
> any modern processor.
No, it does not. In the quest for increased scalability they threw out "out of order" execution. All instructions must retire in order. This cripples its ability to tolerate unpredictable memory latencies.
> It's not "throwing it off" to the software guys
... or whatever improvements there have been are trashed by other problems in real-world applications.
> because it's too difficult to implement. It is
> dramatically reducing the complexity of the
> pipeline, thereby increasing throughput by
> orders of magnitude
That's what they say, yet somehow decreasing the complexity of the pipeline hasn't produced many benefits in practice. The clock speed is low and the throughput (as measured by benchmarks) hasn't increased by orders of magnitude
> The scheduling hardware is only capable of
> looking a few instructions at a time to decide
> how to enhance ILP
This is quite false. Modern CPUs can have over 100 simultaneously executing instructions in flight. Furthermore modern CPUs take advantage of hardware such as branch predictors which records information on hundreds or thousands of instructions in order to make better execution decisions.
Profile-based optimization is a cool idea in theory but despite decades of research, it's seldom used. I suspect that one reason why is that (in C programs) reoptimization can reveal bugs in your code that were previously hidden (like an uninitialized variable that, by luck, always happened to be zero when the code was optimized a certain way). People don't like it when their system suddenly starts exhibiting new bugs that no-one else can reproduce.
Groups of people often act much more stupidly than their constituent members. Intel has certainly made a few stupid moves over recent years:
-- IA64
-- Rambus
-- The home wireless network standard they pushed that got beaten by 802.11
> If Intel is putting this product on the market,
> you can bet that they've fixed the compiler
> problem.
Your faith is touching. Another possibility is that the Itanium project was way behind schedule and that they had to ship something, anything, because their competitors and the rest of the industry were laughing at them. And so they shipped a CPU with the worst SpecInt number in the industry and even warned their customers that this was really just a development chip and 'real' hardware would have to wait for the next generation.
Alan Shurgart (the man credited for creating the floppy drive) left Shurgart Associates in 1974 due to a dispute about the direction of the company.
In 1979, Finis Conner (who later founded Conner which was bought by Seagate) approached Shurgart to develop 5 1/4" hard drives and the two founded Seagate.
I believe Shurgart Associates was purchased by Xerox around the time when Seagate was founded.
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
Yup, exactly right. It means that the CPU tends to deal mainly with 64-bit (8 byte) chunks of data at a time, instead of the more common 32-bit chunks. As far as programming goes, not everything needs larger instructions. For example, to program a user interface, 32 bit integers are quite sufficient for most purposes (unless you have over 4 billion items in a listbox or something). If you only need to store a number from 1 to 10, using 8 bytes instead of 4 is a waste of memory. (This happens a lot.) However, it is useful for many operations, such as multimedia, games, DSP applications, crypto, etc. etc. These applications would run faster on a 64-bit processor because they can use 1 instruction to manipulate a 64 bit number instead of 2 or more that are necessary to do the same thing on a 32-bit processor.
The other reason to use 64-bit processors is that it makes it easier to use 64-bit memory addressing. (For various reasons, it's a little easier to program if memory addresses are the same size as integers.) If you have more than 4 GB of RAM, (or you want more than a 4GB address space more precisely) then you need larger pointers. At the moment x86 programs use 32 bit pointers, but the Pentiums and above actually have 36 address lines, so they can use up to 64GB of RAM. Anyway, a 4 GB address space will be fairly cramped in about 10 years, so it's time they bumped that up a bit.
Intel has an emulation mode in the IA-64 series to allow people to run existing 32-bit programs, but at the moment it's dog slow. (It runs at about the speed of a Pentium 133, if that, when the processor is running at around 700 MHz.) The IA-64 architecture is completely different from the current IA-32 (x86) stuff. I get the impression that the 32 bit emulation doesn't use as many tricks as the existing processors to get programs to run faster. They're also overhauling the motherboard/BIOS stuff that's been around for a long while. (Some of it since the original IBM PC.)
Of course, just because a processor can do 64-bit operations, it doesn't mean that it's actually faster than its predecessors. For instance, IA-64 has a few weaknesses:
- It doesn't have an integer multiply instruction. You have to convert to floats and back if you don't want to program the multiply using shifts or something.
- It doesn't support a floating-point type with better precision than 64 bits (called "double" in many programming languages). This makes it unsuitable for high-precision calculations. Current IA-32 chips can use up to 80 bit floating point values.
- Intel seems to have tried to include every feature (except see above) but the kitchen sink in the instruction set. Loads of processor hints about instruction grouping, branch prediction, cache hints, and heaps of other stuff. This makes quite a complex design that could be difficult to implement and write really good compilers for. (Then again, Intel could always sell their own...)
- And all of the space-heater comments.
Anyway, it remains to be seen what effect the above points will have on its acceptance.Backwards compatibility did not require the retension of a tiny register set (no general purpose registers - Jesus Christ!) and was a fairly bogus concept anyway when the 386 came in.
The 386 family is a bad design and if you'd ever programmed it you'd know. There is nothing good about the design.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Doesn't really matter if you're playing Japanese chess with 81 squares. The interesting point here is that it shows how over-specialised chess programs have become and how little they tell us about artificial intelligence. A really intelligent chess program could play either game (and any other varient) equally well. The 64bit transposition tables tell us nothing about how a human plays chess.
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Well its fairly obvious that you are an expert on cpu design.
I've programmed about a dozen chips in both the games field and compiler-writing field, I don't design chips any more than Eddie Irvine designs racing cars. But I don't think I'll ever see him getting into a tractor for his qualifying lap.
Raw speed became less important for most applications, so intel added mmx to speed up multimedia.
What planet are you on? MS and Intel have conspired to make raw speed as important as possibe for years. I personally have been offered payment by Intel to produce slower software as part of their "everybody must upgrade" roadmap. MMX came as a direct response to the increasing performance of 3D boards which reduced the need for a faster CPU. Intel fear anything which reduces the need to upgrade so they tried to fight back with MMX. That fear led to the only sigificant addition to the instruction set since the 386.
Once a few quality compilers are around this won't even be an issue.
You grossly underestimate the difficulty of this instruction set. I doubt there will ever be more than one (ie Intel's) good compiler and I doubt there will ever be even one which is reliable and predictable.
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
if you dont have the cash for the kilowatts,
Dude. 130 watts of power dissipation. My 17" monitor only draws 125 watts. What's the surface area of the packaged chip?
Forget the old 5V Pentiums (P60/66) being nicknamed "coffee warmers". They were known for all sorts of overheating problems, but they only drew 3.2 amps at 5V. P = I x E = 3.2 x 5 = 16 watts of power.
I could use one of these new chips for the heater in my backyard foundry.
There's soon gonna be a boom market for tungsten and ceramic heat sinks.
Sheesh.
Fire and Meat. Yummy.
I'm sure many people can appreciate 64 bit integer ops; for me, it means single instruction xor for the 64 bit hash codes used in chess transposition tables.
Yes, 64-bit operations have a handful of general uses, but when you weigh the benefits against the huge increases in transistor count, power consumption, and memory usage, are they worth it? I argue that they aren't. Doubling the size of almost every unit on the chip is a steep price to pay.
The Itanium is not a clear replacement for the x86 line by any means. If we're going to toss the x86 architecture completely, then there are lots of options: PowerPC, StrongARM, Alpha, SPARC, something else. Now switching the entire PC world to a SPARC chip sounds crazy, but it's not any crazier than switching to Itanium.
For the record, Intel has cooked up x86 "replacements" before, like the i860 and i960.
-- IA64 cannot officially be called "dumb" yet.
-- RDRAM was a mistake, but it wasn't just Intel. Nintendo bought into RDRAM, as did Sony and several graphics card makers. RDRAM fizziling was NOT something that could have been predicted. I kept up with the reporting back when RDRAM was still called nDRAM (as in unknown), and nobody expressed any objects.
A deep unwavering belief is a sure sign you're missing something...
Ever read "Soul of a New Machine"?
One goal of the protagonists was to have the architecture extensions be clean, and if there was a wart, it would be the legacy part. After this topic came up, I took a quick look at some X86-64 stuff, and it looks as if AMD may have done just that. The 8 new GPRs are really GPRs, and I suspect the whole batch of 16 64-bit GPRs really are GPRs. It may be a cleaner 64 bit machine than it was 32 bit. I hope so.
Actually, I had to learn 8080 pretty thoroughly in college, learned a fair amount of 8086, less 80286, and by the time 80386 came around, was pretty well esconced into HLLs. So I can't speak very authoritatively on that side of it.
The living have better things to do than to continue hating the dead.