Slashdot Mirror
Intel Itanium 2 Benchmarks
Pablo writes "Over at VR-Zone we saw some
interesting benchmarks of the upcoming Intel Itanium 2 processor codenamed
McKinley that is on schedule to be launched during second half of this year.
With a faster 3MB on-die L3 cache, 6 instructions/cycle and 6.4GB/s of
bandwidth, it is poised to perform at 1.5-2x of the current Itanium processor.
There is an overview of how the Intel Itanium 2 at 1Ghz clock frequency will
perform against the current Itanium 800Mhz and Sun's Ultra Sparc III RISC
processor."
At least the Itanium is large enough for me to put my coffee cup on to keep it warm. =)
--- I'll have a Bloody Mary, a Steak Sandwich and a uh Steak Sandwich.
This is just a Marketing Piece put out by intel. All the "Benchmarks" are proposed Estimates. And why would a dinky website get a hold of something this "Big"? Dont know just questions.
Mod Me down Please
"All I can tell the "lesser of two evils" folks is that if they keep voting for evil, they'll keep getting evil."-Lp.org
But what's with all the stuff regarding MS urging Intel to use AMD's x86-64? Isn't the future of IA-64 rather bleak right now? Even HP apparently says that "market will decide" whether PA-RISC or IA-64 will be their future Unix platform... Which would not be the case if IA-64 was obviously superior.
Well, this can only mean good for Linux...
Save your wrists today - switch to Dvorak
x86-64 may be more of a desktop migration point, but there are still plenty of IA64 type applications waiting in the wings from Microsoft, IBM and others.
There is always Linux64.
Not to mention the fact that many a beowolf supercomputer would like to be designed on a Itanium 2. There is one at NCSA from IBM with 800 some IA64 chips. They're just waiting for the Itanium2.
As a rock-in-roll Physicist once said, No matter where you go, there you are.
well I'm sorry but all the benchmarks seem to be cache hitters and so run pretty damn fast
real systems are about BANDWIDTH
memory bandwidth/latency is the reason AMD killed the P4 in benchmarks
lets see INTEL go up aganst a SUN on a large oracle DB then I will take notice
really this is where SUN make their money
regards
john jones
It seems that in comparison to finding ways to rev up the clock speed, PC-based innovation in processors has stagnated -- at least as far as those innovations that actually reach the market.
Perhaps I'm just picky.
-- We live in a world where lemonade is artificial and soap has real lemon.
does it make the intraweb go faster?
Have you read the moderator guidelines? Well, have you, PUNK? (and I want a Karma: Gnarly option)
Site is slightly slashdotted, and most of the data is in gifs. Here's a fact or 2:
Intel's claimed specint2000 and specfp2000 are both about 1.75x the 800MHz itanium. And this with only a 25% clock speedup to 1GHz.
They claim specint2000 is 1.3x Sun Ultrasparc3 1050MHz, and specfp is 2x.
Unfortunately, there is no indication of what the frequency headroom/scalability might be. The main point of the pentium4 architecture is to scale to 4+GHz. Can we assume anything similar for the itanium?
I like the part where they said that Itanium 2 has 2x the SPECint performance of the original Itanium, since they never published it!! The SPECint performance for Itanium was so bad that only published SPECfp data!
It's just the same thing that happened when IBM published the SPECint/fp for POWER 4 processors. They only publish the data using 1 processor on the p690, so they run the hole SPEC benchmark suite un the 128MB SRAM cache memory, avoiding using regular DRAM. The easy way to see this is that they never published any SPECrate number, so to avoid showing that they don't scale as all processors start competing for the cache.
Sun USIII 1050MHz is almost 54% faster that USII 750MHz, as anyone can check going to the SPEC page (Sun Blade 1000 Model 1750 against Sun Blade 2050), with a 40% clock speed-up (this 14% increment is due to the compiler). This is exaclty the same processor at a faster clock, while Itanium 2 has more cache and a different architecture that Itanium, so a 1.5x to 2x speedup is less than spectacular, I will said.
For transaction processing, thay don't give any clue to show where they get the info from. While they expect to get the best OLTP number for 4-way systems, I don't think they will be able to surpass the AlphaServer ES45 MoDel 68/1000, which is by far the best 4-way system ever. What's worst, WLIW is know for been a poor performer for OLTP, and a great performer for floating-pont (that's why the only publisehd SPECfp!!). They never published any OLTP benchmark for Itanium (nor SAP, Peoplesoft, ORACLE, or even the raped PTC-C), so you can have an idea of how poor it is...
As of today, Fijutso PrimePower with 128 SPARC processors is the faster OLTP server ever (both SAP and TPC-C numbers!), with IBM p690 a close second for TPC-C and Sun SF15K a close second for SAP SD2-tier. Intel never showed in this kind of performance numbers, and Itanium certainly won't (unless while they keep running Windows).
The first Itanic sank ALREADY?
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
Actually, current compiler technology can probably optimize quite well for a VLIW architecture. The only catch is that for it to work properly, you will need to profile your code. But with that data, a good compiler that can figure out where to optimize shouldn't be that hard to write.
What I really don't get, though, is why no one is focusing on using JITs with these. It strikes me that this is the ideal platform for a JIT, where it can recode parts of the program on-the-fly based on where the bottlenecks are and so forth. I mean, wasn't this the whole point of a just-in-time compiler in the first place? IBM's Java runtime can rival C++ in speed if it is allowed to run for a reasonable length of time, allowing the code to become truly optimized, and since Intel is targeting this thing in a server environment where applications will run for a similarly long length of time I fail to see why they aren't going that route. This has the additional benefit that as our understanding of how to optimize for VLIW improves, the programs do not need to be recompiled, but instead can immediately get the benefit. (I am fully aware that Itanium is supposed to do some of this type of optimization itself, but current specs are utter crap, to put it lightly.)
Interestingly, Sun's MAJC architecture does exactly that, expecting that a JVM or similar virtual machine will run on top. I have no clue what happened to that chip, but it struck me that it had much better potential to kick ass than Intel's Itanium despite having similar designs precisely because it was designed for a JIT to be on top.
Previous McKinleys haven't fared very well.
Ergonomica Auctorita Illico!
It's hard to generate decent code for the IA64 so building a good JIT for it requires a very large investment. Furthermore the JIT compiler would probably be quite slow so it would have to run longer or achieve larger speedups for it to pay off.
... which IA64 doesn't have.
Although a JIT would be able to discover and exploit behavior patterns that didn't show up until runtime (and therefore not exploitable by a static compiler), it's not a panacea. Lots of programs are unpredictable even down to the level of individual loop iterations. Such programs really need small branch penalties and hardware support for instruction reordering
"So it'll actually run even faster than the benchmarks let on once out of beta."
Bullshit. You don't know this, and Intel's history with new processor development suggests otherwise. Maybe this means that they finally have the heat issue under control, and can *finally* reach the clockrates they want to advertise. Maybe it means clock distribution is reducing chip performance to the point that heat isn't an issue. Maybe it means that you work for Intel marketing, and think you are repeating something you heard an Intel engineer saying at a party.
-Paul Komarek