Slashdot Log In
Itanium Preview And 32-bit Benchmarks
Posted by
michael
on Thu Jan 25, 2001 08:03 AM
from the as-long-as-it's-before-2038 dept.
from the as-long-as-it's-before-2038 dept.
XBL writes: "Tweakers.net has posted a preview of the Itanium that includes benchmarks of the x86 emulator. Looks pretty dismal here, as it struggles to keep up with even a Pentium I in many areas! Let's just hope that 64-bit apps will make this thing not look so bad. That $4k pricetag hurts though, no matter how fast it will be."
This discussion has been archived.
No new comments can be posted.
Itanium Preview and 32-bit Benchmarks
|
Log In/Create an Account
| Top
| 118 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
|
2
(1)
|
2
Temporary design.. (Score:3)
Perhaps what some clever people should come up with is a way to shoehorn in a traditional X86 32bit CPU (P3, Athlon..) either into the motherboard, as an add-on PCI card, or through a custom slot (much like the Amigas had for their processor card upgrades). This would allow you to have some way to execute 32bit code at a reasonable speed, and could let the core architects work on a better 64 bit CPU instead, maybe.
Although I guess you could just have your old box, anyway, since this will probably require a 1kg heatsink and new case anyhow *chuckle*.
nice assembling language (Score:3)
You people sound like football fans! (Score:3)
If Itanium sucks, too bad for intel, go buy AMD. If Sledgehammer sucks, too bad for AMD, go buy Itanium.
They are just companies competing. They are both publicly traded, multibillion dollar massive corporations who care about profit.
I think slashdot has become a site for corporate cheerleading. Can we discuss something else, technical perhaps?
$4K is a bargin ... IF and its a BIG if (Score:5)
Now that I'm don'e trolling... Seriously, this article was an EXCELLENT overview of the new IA-64 architecture. Intel did a great job on trying to fix the many problems of ia-32 and I believe they did very well. I don't think there will be any contest between the AMD x86-64 and the Intel IA-64 processors. Intel will win hands down on ONE condition. If they manage to develop the compilers to handle all of the parallel compilation and predicition. COmpilers are difficult enough to design. This design increases the complexity by a magnitude at least. A telling quote is "The compilers have been under development almost as long as the hardware"
So the next few years should be very interesting. If INtel and their partners can get compilers available that do what they need to, the IA-64 architecture will probably scare even the most diehard AMD person. Even at $4K a processor - the potential processing power is scary and would be a steal.
But they may not. And it will be interesting if the AMD x86-64 stuff comes out ready to go and the IA-64 processor is still hampered by compiler issues. The tables could be completely turned where AMD wins in the short term based mostly on the speed gain of mega memory and bus bandwidth while hte IA-64 lags due to compiler issues. By the time the compiler is really taking advantage of the IA-64's cuttin gedge features, Intel could possibly have a lot of ground to catch up. A complete reversal.
Who knows. I love my Athlons and still feel they are today's top performers for the price. I hope AMD scores a homerun with their x86-64 architecture and I really like how they are opening up the development efforts so early. It was a shrewd move on their part. But the next 5 years will be astonishing and I have to say, if Intel pulls this off and succeeds in developing these compilers, the first time I run IA-64 compiled software on an IA-64 would give me goosebumps at the massive amount of computing power at my fingertips in a mid tower case ;)
Re:Benchmark the Itanium on a 64bit OS w/ 64bit co (Score:3)
Because they didn't have the option to. This isn't an Intel sponsored benchmark as they actually "borrowed" the machine for a while and did their stuff.
Installing Linux would be the best idea because they could've compiled benchmark apps but they were afraid to do so. They didn't want to alter the benchmark machine much and probably had a strict deadline.
Flavio
Re:64bit = 32bit*2? (Score:3)
if you'll remember correctly, the pentium was released in 1992. windows 95 wasn't released until 1995. most of the end users of the world WERE running 16 bit code on their pentiums for 3 years as win 3.11 was popular then.
"I hope I don't make a mistake and manage to remain a virgin." - Britney Spears
Try out the Itanium yourself (Score:5)
Itanium 4 (Score:3)
Re:someone else will mention this, (Score:5)
but, the itanium should excell mostly at running native 64-bit code, hopefully mostly in the floating point area. x86 emulation shouldnt have even been included, let alone talked seriously about.
One would indeed wonder how much smaller / cheaper / cooler / insert-good-thing-here the Itanium would be if they hadn't wasted the effort on hardware x86 emulation then? Surely any modern CPU should be able to do software x86 emulation with better performance than those Itanium benchmarks revealed.. which makes this look like (yet another) costly mis-step for Intel.
dont judge these things by their x86 emulation, benchmark them against a similarly clocked (or similarly priced) alpha
Well, one of the "selling points" for an Itanium over an Alpha is that it does emulate x86.. if the Alpha can do it in software better than the Itanium can do it in hardware (and it does [google.com]) then where does that leave this as a selling point?
Wanna see some in action? (Score:3)
If anyone is interested in seeing Itaniums first hand, Intel will be running Linux on Itanium at LinuxWorld. Dell also will have Redhat running on Itanium in their booth at LinuxWorld working with our 64bit version of the TowerJ compiler ( http://www.towerj.com ).
See you at LinuxWorld!
Full disclosure: I work for Tower Technology.
Absolutely (Score:3)
and this is a Good Thing(*). I propose to you that faster processors are not encouraging bloatware, but rather enabling more complex applications to be build. In a way, upgrading processors is a Computer Tax. It goes indirectly to software companies by making constructing large apps cheaper.
Applications are much larger now than they were before. In order to effectively build large applications, you need abstraction. Abstraction is the enemy of buffed code. Of course, we always hope that compiler technology and coding wizardry (ever see code speed up by a factor of two after adding a few inline pragmas?) will claw back performance, but it is clearly the case that we need to increase processor speed for one main reason: to pay for increased levels of abstraction.
After all, my 1 Mhz Z-80 card for the Apple II ran wordstar just fine, so why do I need a 500 Mhz PIII to run Office 2000? Because Office does so much more. Of course it's huge and overwrought, but that is a side-effect of the programming technologies that allowed it to be built at all, not evidence of shoddy construction. Taken to an extreme, I wonder whether it would be in the interest of large software houses to subsidize processor upgrades. hrm.
An interesting economic question: are we better of with this indirect software tax, or would the world as a whole be better off if Office cost more but ran on lower end hardware?
I posit that we are better off now; the trickle down effects from advancing chip technology benefit all and all software can take advantage of fast chips. Furthermore, if software were efficient, this would not drive semi-conductor innovations, and you would have very expensive hardware that runs more slowly than it does now.
Basically, I suspect the bloatware or buffware scenarios would have similar total costs to the end consumer, but bloatware additionally drives semi-conductor innovation, which benefits everyone in the world. The same resources spent on better software engineering tools to make buffware would only benefit software houses.
Lastly, let me conclude with the most exciting technology out there now: dynamic optimization.
This technology (exemplified by Dynamo, CodeMorphing, and JITs) has the potential to optimise away the speed penalties inherent in modular software, by discovering stable software configurations at runtime (f.ex inlining library code, removing indirection in COM method calls, specialiasing common cases).
(*) Of course asymptotic inefficiency is never warranted, but a constant factor slowdown may be. Of course there will always be tight loops to be programmed in assembly/C but 95% of the time, investing the resources to upgrade the client hardware is a better idea.
Benchmark the Itanium on a 64bit OS w/ 64bit code (Score:5)
Why oh why are they testing IA32 code on the Itanium? That is hardly likely to show the performance of the processor in a good light. It's like running an Amiga emulator on x86 and complaining that the copper tricks don't work as quickly.
The Itanium is supposed to be the first in a new line, so I wouldn't be surprised if its IA32 bit convertor was a bolt-on solution for those who can't release themselves from 32bit (I hesistate to mention that 64 bit Windows apps may be a little short on the ground for a while yet ...).
The other aspect of benchmarking a system is to have equivalent compilers - different compilers can produce code varying in speed by as much as a factor of two on the same architecture and other factors such as optimizer flags can have a serious impact on the eventual speed.
The obvious set up to compare the Itanium against the competition (which really should include the Alpha, Ultra Sparc and the 64 bit POWER chips, not just x86 architectures) and pick an OS which runs on all of these. Not let me think ... Then use GCC in unoptimized mode and compare code length and execution speed, and then optimize progressively.
That the Itanium can't hold a candle to a Pentium I 100MHz on some 32 bit code is amusing, but not a real indicator of speed. That said, I still feel that the Itanium is a weak competitor against the assembled 64 bit processors already on the market, but Intel probably has sufficient clout to carve itself a niche.
Cheers,
Toby Haynes
Remember the transition to the Power Mac? (Score:4)
I haven't heard anyone compare this to the transition to the Power Mac that Apple pulled off a few years ago. They did an amazing job with their 68K emulator, to the extent that the first 60 MHz PowerPC 601 chips could execute 68K code at about the same speed as a 40 MHz 68040. I think that's amazing performance! In fact, 90% of the software was still 68K code for the first couple of years.
It was extremely significant that the Power Mac emulated 68K code so well, because it meant that a bunch of old drivers and extensions written in assembly language didn't need to be rewritten. In fact, they ran so fast that many of them didn't get rewritten for years! Mac OS 8.0 still had lots of 68K code in it! (I think it's pretty much gone in Mac OS 9.0, but who knows?)
The fact is that there are a lot of programs that will never get recompiled for the Itanium. So if it can't execute all of those programs with any sort of speed, people will be discouraged from switching.
Why the 32 bit emu sucks (Score:3)
Intel *deliberately* makes the 32 bit code grudgingly work *just* good enough that stupid people will be able to read their propaganda, buy the chip, and then not be disappointed by its performance because they don't know better.
Then, after enough people have bought in on it, app manufacturers are all going to write 64 bit code (which DOES go a hell of a lot faster). Why would they write programs for a deminishing base of 32 bit users, when the performance on any new processor will be abysmal? Besides, "64 bit" sounds so much better in marketing literature.
Pretty soon, you can only get Windows in a 64-bit version...
And pretty soon, AMD is left out in the cold. How tragic.
Embrace, extend, extinguish.
--Kai
--slashsuckATvegaDOTfurDOTcom
Re:64bit = 32bit*2? (Score:5)
> Uh, shouldn't it be at least capable of blowing the P4 out of the water at a quarter of the clockspeed?
It should be neither, really. Some 32 bit instructions can be executed 2 at a time with a 64 bit register but some can't. You also have the overhead of condensing 2 32-bit instructions into one 64-bit and vice-versa. If execution were absolutely linear, IA-64 wouldn't even be twice as fast as IA-32. It's not, so results will vary.
We should compare running 64-bit math on an Itanium and 64-bit math on a P4. Running legacy code is as illogical as running 16-bit code on a Pentium so I also question Intel's hardware emulation decision.
Flavio