Slashdot Mirror
Itanium Preview And 32-bit Benchmarks
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."
Those are CPUs where the commercial compilers, such as Sun Workshop (SunPro) and xlc (or Visual Age C or whatever IBM calls it these days), frankly kick the crap out of gcc. Gcc is only a good compiler when you use it to build x86 code, and "maybe" Alpha code. Then again the Itanium might look like a joke once the 21364 Alpha (if it ever comes) and the POWER4 hit the market.
I agree with you about GCC as far as producing the fastest code on UltraSparc and POWER processors. If you think that GCC produces optimal x86 code, you haven't used some of the commercial compilers, such as Intels own proton compiler. Intel gave part of its Pentium II optimisations to GCC (back in 1999 if I remember correctly through Cygnus), but I feel it's lagging again. What I'd really like to see is AMD give some major help to the agcc project in terms of best optimisations, effective 3DNow extension use and efficient floating/integer interleaving. But that is another story.
Back to the main thread. You have to have a common baseline when trying to do comparisons. GCC produces an intermediate code which is then transformed into the machine code for the target processor. This means that before optimisation the actual machine code is fairly similar and therefore is as close as you can get to the ideal comparison. Exploring the various optimisations will then give you an insight into branch prediction, cache handling, etc.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
Hi, I am one of the tweakers.net administrators. You all know "The slashdot effect" I guess :P
Weel it seems that this link causes such an enormous flow of pageviews that our servers can't cope with it at this point. We have just 2 webservers and one database server, which seems to hold qute much, but not this much. Quite a nice test though ;)
Our serveradministrator is on the job and tries as hard as possible to keep the servers up, so don't let this put you off, just try again and hopefully the site will be available.
No comment.
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*.
..don't panic
I like a lot the IA64 assembler, wich has a quite intuitive syntax (sometimes reminds me of a higher level language) and will allow a lot of dirty tricks, as it even has a built-in endian switch, byte shuffles in the registers, and e.g. parallel instructions of 8 bytes in one register, in two registers at a time, (what possibilities for string.h or clipping algorithms!).
Just because I can imagine doing a hippopotamus, doesn't mean I'd like to do it.
Given sufficient memory, any chip can emulate any other.
It's usually not as slow as an Itanium emulating x86, though.. ;-)
And as for this great "Intel engineers" troll-fest.. bah, humbug! I say. It's not the engineers we're mocking, it's the foolish decision (presumably handed down from the adminisphere) to do the emulation in hardware (badly) instead of in software (where even if it was done badly, it can at least be improved in the next version!). Now, if there are any Intel managers reading Slashdot.. well maybe they feel insulted. But I'm sure their salaries and stock options will ease the pain. ;-)
dont judge these things by their x86 emulation, benchmark them against a similarly clocked (or similarly priced) alpha, that is when we can discount this chip.
Well, the only reason that it took Intel more than five years to release this chip is the Alpha.
The first version was withdrawn affter two years because a 800 Mhz. version was about 20% slower than a 21164 at 600 Mhz..
This version is almost as fast as a 21164 with similar clockspeeds.
Only problem is, that Digital/Compaq has the 21264 processor and are working at the 21364 processor.
Both processors are faster and cheaper than the Itanium.
One of the reasons it took so long was that HP didn't put much resources into it.
Their PArisc chips are much faster now than the itanium.
T
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?
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 ;)
Top Most Bizarre/Disturbing Error Messages
I couldn't agree with this more. Why does Slashdot even bother posting these kinds of useless articles. Let's wait for the optimized 64 bit code generated by an Intel compiler, before we piss away our time worrying about 32 bit code. All bets are that it will be a piece of crap and no Sparc. However, let's give them the benefit of the doubt until the relevant facts are in.
Someone you trust is one of us.
That's with 4MB external cache. Cache is expensive. $4k isn't unreasonable for any processor with 4MB.
> 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.
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
well...
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
"I hope I don't make a mistake and manage to remain a virgin." - Britney Spears
It would be more fitting to say "illogical as running 16-bit code on a Pentium Pro." Windows 95 killed that processor (that and the fact that the two chip design made it expensive to produce). Great chip if you had a pure 32 bit operating system. I remember reading that on a Pentium Pro box Windows NT would outperform Windows 95.
As for the emulation thing, I'm guessing the idea is to make people ditch the 32 bit code more quickly than they did 16 bit.
"Homo sum: humani nil a me alienum puto"
(I am a man: nothing human is alien to me)
My only political goal is to see to it that no political party achieves its goals.
Can your Pentium 4 even run 64-bit programs?
If the answer were "no," then why would Nintendo 64 emulators, which emulate a 64-bit MIPS CPU, exist on x86 CPUs? Besides, double-precision floating-point and MMX are already 64-bit (although they may not be executed as 32-bit ops in a particular implementation).
Like Tetris? Like drugs? Ever try combining them?
Will I retire or break 10K?
If you'd like to try out Itanium-based systems for yourself, we happen to have one running Linux in the Compaq Test Drive Program. Check it out and see for yourself just how it performs. Sign up on the Test Drive web site, and we'll give you a free shell account on not only our Linux Itanium system, but also on a wide variety of Alphas, x86's, and even StrongARM's running lots of different operating systems.
People (usually AMD'ers who want to wax rhapsodic about the Sledgehammer) often overlook the fact that the Itanium isn't supposed to be just 'a 64-bit chip.' They're trying out some rather neat stuff in the way of EPIC instructions and scaleability. Once the chip has had some software developed for it (actually using some of these features instead of just looking for an excuse to have 64-bit integers) and has maybe even had a chance to go through some incremental upgrades, then it will be fair to really judge the Itanium against its competitors. Until then, I think Intel at least deserves a nod for trying to actually push processor design technology forward instead of resting on its x86 laurels.
Itanium project
E-Speak
That person was Rajiv Gupta.
Seastead this.
Yes AMD are creating x86-64. The difference is that AMD's 64 bit platform will not be binary compatible with Intel's. This means that any software distributed binary only will have to be compiled for both Intel and AMD. I can see this being a serious stumbling block for AMD if many small windows shop's start selling only Intel based binaries of their products.
>~~~~~~~~~~~~~~~~
>~~~~~~~~~~~~~~~~
Pilchie
As I understand it, the VLIW architecture of the Itanium chip means that brach predictions are stored in the binary so that the processor doesn't have to worry about guessing the right branch outcome.
This means that the branch prediction logic is up to the compiler, hence compilers have to get better for the Itanium architecture to become worthwhile.
However, imagine if the operating system could profile a running binary and actively modify the branch predictions on disk based on common usage?
Yessir, fire up your favorite CPU hogging program under your operating systems IA64 profiling mode and it suddenly speeds up by 50% on subsequent runs.
This is the type of stuff that makes the IA64 architecture so awesome (although I'm betting that nobody will ever take advantage of these possiblities, just like they don't take advantage of the Crusoe's code morphing features).
Then you obviously aren't thinking. If you don't use the same compiler, then how do you know you aren't simply testing how good your Itanium to X86 cross-compiler is and not how good the hardware is.
To put it another way, imagine that we wanted to see if Red Hat Linux or Windows ME was faster on a specific processor. If I did such a test, using the best Windows C complier on the market and, for Linux, using some weak complier I cobbled together in my undergrad compilers class, everyone on Slashdot would be flaming the hell out of me when Windows wiped the floor with Linux because it was such an unfair test.
In my hypothetical test, I would say the results reflected the difference in quality of the compliers, not the operating systems.
For that ammount of money, you could have some serious computing power by running multiple processors. It may be good, but it'll have to drop in price a lot before it becomes an alternative to me.
Sig (appended to the end of comments I post, 54 chars)
Will the Itanium 4 be able to run as fast as an Intel 4004 ?
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) then where does that leave this as a selling point?
And pretty soon, AMD is left out in the cold. How tragic.
Err, AMD are creating a 64-bit chip too y'know. And it will apparently have similar 32-bit perfomance to todays Athlons. Can't be bad...
because that is Alpha, and this is Intel, that's why. It is like "why run Windows when Linux is available and is more stable, has applications, etc". It's the name that counts to the masses.
It's much too soon for making any judgements about Itanium and the IA-64 architecture. These are chips designed for the future, and I appreciate Intel's willingness to move beyond the profitable-but-aging IA-32 chips.
And I don't see the relevance of testing 32-bit apps on a 64-bit platform. The IA-32 architecture has been severely limited by support for legacy code; I hope Intel focuses the IA-64 chips on 64-but applications. If I need to run 32-bit apps, I'll run a 32-bit computer.
Perhaps my only quibble with Intel is in trying to shove more capability into a single-processor model, when multiprocessing is certainly a more productive alternative. I'd rather spend $4000 on four high-end Pentium 4s than the same money on one Itanium. Four processors working simultaneously seems better than having one processor trying to do four things at once... I hope someone (Intel, AMD, or whoever) considers building chips specifically for SMP, as opposed to implementing more "trciks" like multiple pipelines.
--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
All about me
I've been working with Itanium boxes for awhile, and let me tell you they are not slow, and I'm pretty happy with what Intel has shown us. Its my opinion that this chipset with a linux 2.4 kernel will be capable of runing hand in hand with Sun E450s, at a much lower price point.
// EvilJohn
// Java Geek
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.
Less Talk, More Beer.
yes!
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.
I'm not thinking of cross compiling, I'm thinking about standard benchmarks and applications in native mode. Compile it whatever way you can to improve performance.
Actually, if you read the article you'd notice that the Itanium doesn't support RAMBUS, it only works with PC100 and PC1600/DDR memory.
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
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
While folowing the link to the Tahoe Arch. I found this.
don't worry, no goat here, but just some holiday pictures that I don't understand.
Is it a hack or what ?
Update:while checking my link I found what I expected at first.
--
Trolling using another account since 2005.
Which basically means:
YESS! Tweakers.net is broken! We kneel in from of admin Rick hoping this will advance the healing of Tweakers.net. In the mean time some pictures so we don't have to get bored.
So, probably something broke, they already fixed it by the time I'm typing this.
Thimo (Dutch)
--
Avoid the Gates of Hell. Use Linux!
Sadly but ture, the faster and faster processors that we get, the lazier and lazier the coders get
Absolutely. Those are the hacks of the programming world, but there will always be a small subset of people who will create tight efficient code. Many programmers opt to make sloppy, inefficient code because they can get it out quickly without a heck of a lot of theory. Those that do will continue to make mediocre code. But that will be for mundane tasks. There is plenty of mundane code that needs to be written. I, for one, would prefer to have the best of the best programmers working on the tough problems, not relegated to the run-of-the-mill problems because nobody else can produce something workable.
There are plenty of applications that require more computing power than we have commonly available now- like real time image recognition, real time speech (as spoken) recognition, photorealistic image rendering. This type of problem is where our best programmers should be working.
Heck, the advent of Linux showed us that we could still do great things with a 386 when the 486 was all the rage. As we get more computing power, the realm of the possible will continue to expand.
Sounds like an absolute nightmare to me!!
Perhaps they should just get connectix to make a virtual pc for pcs.
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.
I don't see any reason to use the same compiler - it's the end result which matters. If a company spends more money on taking advantage of the chip, they can spend less on chip development/manufacturing and still give the end user a good result.
As for the price tag, $4k isn't that high when comparing to other server chips like Alpha, UltraSparc.
Paraphrased from somewhere: "Never ascribe to malice that which can adequately be explained by incompetence". Not exactly right for this, but close...
I think Intel (and Microsoft, in Whistler-64) are so focused on 64 bit performance that they haven't spent enough time on the 32 bit emulation/translation piece, which will probably be improved in McKinley. Or alternatively, they just don't care about 32 bit performance since IA-64 will largely run on servers, at least initially, and everyone will have produced new server software.
I do think it was hardly worth doing this review with 32 bit tests only - it would have been a lot more useful to put in another hard drive and install Linux IA-64 on that, removing it after the test. At least then they could have compiled some benchmarks from source.
Because x86 compatability is the only thing that matters. Performance is irrelevant. The x86 legacy is what drives the market. If that weren't the case, then Intel would have gone out of business in the late 80s or early-to-mid 90s when they were sooo far behind the state of the art. But they didn't go out of business. They sold crappy chips like hotcakes, while modern chip makers watched their sales stagnate.
Intel seems to have forgotten the very principle that allowed them to survive.
All of Wintel's competitors learned this the hard way, years ago. Now Intel is going to learn it too, when AMD beats the crap out of them with their evolutionary (instead of revolutionary) approach to bringing 64-bit CPUs to Joe x86 user.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
my bad. i was off by 3 months. the pentium 60 was released in march of 1993.
and i had one.
"I hope I don't make a mistake and manage to remain a virgin." - Britney Spears
"I hope I don't make a mistake and manage to remain a virgin." - Britney Spears
MIPS mean nothing. Neither do MFLOPS.
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
>> Early benchmarks with IA-64 code on Itanium systems have shown that the new architecture is certainly capable of blowing the P4 out of the water with half the clockspeed.
> 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