Slashdot Mirror
Intel to Increase Stages in Prescott
Alizarin Erythrosin writes "Further contributing to the MHz Myth, The Register and ZDNet are reporting that the new P4 core, codenamed Prescott, will have a longer pipeline then Northwood. No official numbers have been released, but The Reg is saying an Intel spokesman said that 30 stages seems to be a reasonable estimate. As most of us know, a longer pipeline can lead to slowdowns in the form of branch mispredictions and pipeline stalls. 'And just as the PIII proved faster than the early P4s in some applications, it's likely that Northwood will similarly prove faster than Prescott, which has clearly been designed for speeds of the order of 4GHz.'"
With all these pipelines you'd think intel was Bush and Prescott was Afghanistan.
--
WHO ATE MY BREAKFAST PANTS?
Northwood was really unsatisfying. I found that for the money, it was too short with too few stages. While gameplay was fine, the lack of stages simply made the cost not worth it for me.
2 stars.
I have been pwned because my
It's not the size of your pipeline that counts... its how you use it.
I work at an engineering firm. The deep pipelines in the current P4 perform so poorly with general number crunching (e.g. matlab) we have almost completely switched to Athlons and are seriously considering Opteron.
-ghostis
Computer Science is all about trying to find the right wrench to bang in the right screw. -T.Cumbo?
I suspect AMD and even Apple are going to shrink Intel's bragging rights in that same time frame unless Intel gets their act together. From AMD's recent earnings report it sure seems somebody is buying Athlon 64's.
Intel blew it when they made the decision to let 32 bits ride for another 2 to 3 years. They look like old fuddy-duddys now. It's AMD and Apple via IBM thats has the cool shit.
I'm kind of tired of the perpetual whining of armchair hardware designers. So the happy few, highly paid architects, 30 years-experience in the industry, hundred-published scientific papers at Intel decide that the next gen chip will have more stages and they have to be called morons ? How do you know better ? Hasn't intel produced the fastest chips on the market with each and every micro-architectural generation ? Long pipelines = costly branch mispredicts, whoooaah, you're so bright why don't YOU have the job leading the prescott team ? branches can be predicted. Long pipelines can improve throughput. Microprocessors are all about trade-offs. Let the pros do the work and go back playing Quake.
When the processor branches, all the partially executed instructions in the pipeline are lost.
They could minimize this by creating two different conditional branch instructions for each condition. One for cases where the programmer expects the branch to occur most of the time, and one for where the branching rarely occurs. They could then optimize the pipeline behavior for each case. If its a 'likely branch' instruction, it could start fetching commands from the branch. If its an 'unlikely branch' instruction, it could prefetch the next instructions after the branch.
This would work well in loops where every time but the last, the processor branches back to the top.
Unknown host pong.
It'll most likely be slower per clock cycle.
What this means, is that it will take a faster clock cycle (4GHZ, for instance) to do the same amount of processing as the Northwood core. However, increasing the pipeline should allow Intel engineers to achieve higher clock speeds, as the longest transistor path will likely be shorter (faster switching times).
In essence, Intel is attempting to increase the speed of their CPU's by focusing on increasing the clock speed (P4), while AMD is focusing on increasing the amount of calculations per clock cycle (Hammer).
Of course, there are a lot of more complex tradeoffs that factor in (ie. branch prediction). I highly recommend reading a computer architecture book if you're at all interested. It's really facinating stuff.
-=Lothsahn=-
Assume for a second that Intels P4 design was really meant to boost GHz numbers easily (to guarantee victory in the GHz war if not the performance war). If so is the Prescott design now due to having to keep up with themselves? Obviously they could design a chip that is "faster" but runs at a lower clock speed than the P4s, but they've pushed the GHz number so much that now they're kind of hamstrung in their design options.
Re-read the register article. Its not the Intel guy who said 30 stages, its the Register who is guessing. They're assuming that since it went from 10 to 20 before it'll go from 20 to 30 now. Its not likely to end up being more than a few extra stages.
Although the Prescott core will have a longer pipeline, it will proboably end up performing a bit better clock-per-clock against Northwood. This is due to a couple reasons. Firsly, Prescoot has 1 MB on-die L2 cache. That's a good bit, and one could see how the P4 was helped by the 2M L3 cache in the P4 "EE". Secondly, the new P4 will have improved hyperthreading. It will also have somewhat improved branch prediction and implements PNI(Prescott New Instruction) which will require a recompile to help things out. All in all, I see the Prescott as being just as fast or faster per clock as Northwood, mostly due to the doubled L2 cache.
So, since Prescott has approximately a 30 stage pipeline, I guess Intel has decided to continue to ignore the low-power consumption market, leaving it open to people like VIA and Transmeta. This is really disappointing to a lot of folks in the embedded markets, who would really like to see Intel ship something with significant horsepower that doesn't require a heatsink with the mass of a black hole to keep running.
Word has it that VIA is readying a new x86 processor to their line that supposedly has P3-class FPU performance while maintaining the same levels of poser consumption as its predecessors. It is expected that this processor may actually have a big win in front of it for DirecTV boxes. With the extra CPU horsepower, it should be exciting to see what nifty features come out of this, especially considering most set-top CPUs generally just act as "traffic cops" for the data moving between ASICs. If they're really making the move to this class of processor, perhaps they've got more in mind.
--JT
I suppose that this makes having a good compiler a little more important. Compiling the same program for a G4 on a compiler other than GCC gave me a 100% speed boost. I don't know if branch mis-prediction came into play, but it had a conditional in its inner loop (it displayed the mandelbrot set).
It sounds like Intel has totally given up on efficiency, and has the Marketing department doing processor requirements now... (has to clock to xGHZ!)
I've been working with Dual Opterons for a few months now, and have been very impressed as to their speed, heat dissapation, and bang for the buck.
A large data transformation job (really doing a scrape of a mainframe report for data) on the order of 1.1GB processed much faster on an IBM E325 Dual Opteron 2.0ghz running 32bit Windows (ack) than my Dual 2.4ghz Xeon (w/HT) running Windows (double ack)....
Yeah- it's not a benchmark, but it is real world performance.
Let me guess - 'Alizarin Erythrosin' is Cupertinus Elvish for 'Mac User', right?
How come your computer takes seconds to multiply two 400 digit #s, but ages to factor them?
[Fuck Beta]
o0t!
Are you most of us?
sic transit gloria mundi
...since my next computer is going to house a G5.
Personally I'm tired of trying to keep up with the gHz war between AMD and Intel. With our current technology, the only areas really pushing processing speeds are gaming and video/image applications(that I'm aware of). My grandmother doesn't need a P5 4gHz to check her email, and neither do I if I simply want to write a paper.
And the masses cried out, "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0!"
In case anyone wants some hard facts:
A. Hartstein and Thomas R. Puzak (IBM): The Optimum Pipeline Depth for a Microprocessor, ISCA 2002.
M.S. Hrishikesh, Norman P. Jouppi, Keith I. Farkas, Doug Burger, Stephen W. Keckler, Premkishore Shivakumar (UT Austin, Compaq): The Optimal Logic Depth Per Pipeline Stage is 6 to 8 FO4 Inverter Delays, ISCA 2002.
Eric Sprangle , Doug Carmean (Intel): Increasing Processor Performance by Implementing Deeper Pipelines, ISCA 2002.
A. Hartstein and Thomas R. Puzak (IBM): Optimum Power/Performance Pipeline Depth, MICRO 2003.
What all these papers have in common is that they find that increasing the pipeline depth past 20 stages increases performance.
Which basically means, Intel can release a CPU with a higher MHZ rating for those that fall for such things.
In reality the CPU will be somewhat faster than current ones due to the higher clock, but much less efficient.
Why not just dump MHZ as a rating altogether? Wouldn't FLOPS-based (Floating Operations Per Sec) or something similar be a better measurement? Maybe how far a simple program can compute PI in a second? We should really be looking at an operational-based measurement rather than a clock-based one.
Programmer time is much more expensive than faster machines.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
Gosh, I'm feeleing really left behind, my G4 400 only has 4 stages in it's plpeline. At least it's build on a .22 micron process as apposed to the Pentium's measly .13 micron process.
Yes, that was a joak
Intel has shown no real interest in joining the 64-bit fray. Indeed, they don't have much choice. To release a 64/32-bit chip at this point would truly create an Itantic out of the Itanium. Microsoft would have more or less wasted it's time producing low volume products such as SQL Server 64 and XP 64 (different than XP 64-bit extended which is as yet to be released). Other consequences for such a shift in strategy would include, a number of people investing in the itanic platform who would be the proud owners of an all but useless, but very expensive hardware platform on their hands.
.NET framework is not 64-bit ready. We can probably expect it's release with VS.NET Whitby, a.k.a. .NET 2.0.
Most real world tests point to AMD chips being faster. The Int and Floating Point Tests still belong to the P4 3.2, but the P4 is having to pass the 1st place troughy to AMD when it comes to games and office productivity.
And then there is price. For $320 you can get $700 worth of Intel performance. Mind you this is the AMD64 running in 32-bit mode.
It would appear that all that is really needed to justify mass market adoption is a consumer OS, that would be Windows XP 64-Bit extended. Currently in Beta. The only delay there is that the
After that - we just need to see some AMD adoption in the mainstream pc builders.
It's much more likely the size of the L2 cache is affecting you (i.e. your working set does not fit into P4's L2 cache but it does in Barton's).
If you don't believe me, try the demo version of Intel Vtune performance analizer on matlab running one of your programs.
How well your caches perform is probably the most important thing for a processor today, as the speed of the main memory is a couple of orders of magnitude under the speed of the processor. It takes a couple of hundred cycles to service an L2 miss, while a long FP operation takes at most 20 cycles.
The Raven
Didn't AMD try to organise this and recently concede it wasn't going to happen?
As long as any metric favours one particular manufacturer, the rest will try to replace it with a new one. The result will be more FUD and ore confused users ("I've finally worked out what GHz are and you tell me I have to look at the number of flops?!?")
</Pessimist>
I say we take-off and slashdot the site from orbit... it's the only way to be sure
I read somewhere that on the P4, when an instruction is already in the L1 cache, the pipeline gets shortened. That's because the L1 instruction cache stores pre-decoded instructions (micro-ops). This means that when the instruction is reached again, the decoding (and branch prediction?) steps are already done, shortening the pipeline. When the instruction is not in cache, there's already a big hit anyway. With that in mind, we'll need to see whether the extra pipeline stages in Prescott will still be there when the instruction is in the L1.
Opus: the Swiss army knife of audio codec
No processor, barring a complete architecture change (in which case its a different processor entirely) will double its performance simply by doubling the clock speed.
It really depends on how you define performance too and what your software is doing. Doing heavy I/O? Processor has little to nothing to do with I/O - it just hands it off to the bus and I/O controllers to take care of and then does something else while waiting for the interrupt.
-
Yes. Hennessy and Patterson (or in reverse, I have Stanford bias :-)) is the bible of computer architecture. They invented the RISC processor independently at Stanford and Berkeley. Their processors evolved into MIPS and SPARC.
Vote for Pedro
Stay away from x86 if you're just starting out...
-
For those into the technical side of this type of stuff and heck of a lot higher S/N ration, check out the Ace's Hardware forum. There's a large thread going on overthere taking about the rumors and what it would actually mean.
More clockspeed = more sales. 95% of computer users (or is it 94%, with recent improvements in public education) believe in the MHz Myth mentioned on the front page.
The MHz myth is the belief that the OneTrue measure of CPU performance is clockspeed. A 2GHz CPU is twice as fast as a 1GHz CPU. A 4GHz CPU is twice as fast as a 2GHz CPU.
While it may not seem common to many of us, if you speak with a large number of average people about computer performance, you will quickly want to kill yourself. Or them. Or both.
This isn't the fault of the general public, as Intel's marketing machine takes advantage of this common belief. Intel Pentium IV processors are some of the highest clocked processors in the world, and they benefit from everyone that thinks this somehow matters.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
"As most of us know, a longer pipeline can lead to slowdowns in the form of branch mispredictions and pipeline stalls
Get off your high horse. Intel architects aren't dummies. Itanium benchmarks are starting to whoop some serious ass and the P4 and Athlon have been neck-and-neck for years. I'm sure Prescott will perform very well.
I can get into all kinds of architecture speak as to why your simplistic notions of mispredictions and pipeline stalls might not be so terrible. Who knows? Maybe Intel will execute both paths of a branch? They've already got partial instruction replay to make squashes much less expensive. With deep speculation, a big instruction window, good bypassing capabilities, and effective non-blocking caches, "pipeline stalls" are not an issue due to branch mispredictions. The bigger issue is memory latency/bandwidth and Intel has always done well with that. A branch misprediction can be easily tolerated...an L2 cache miss can't.
Your EE or ME or ChemE full professor as a grad student could have written a FORTRAN program to compute some stuff and write output to a numeric text file or perhaps draw some plots using a subroutine library. You are probably thinking that anyone who can't sling together C programs using VI to draw graphics straight to X is a luser, but I am talking about pretty technically savy people who don't have time to spend on this stuff and who employ armies of Engineering majors from foreign lands who are not up on this stuff either.
My own take is that if a particular numerical calculation can be easily programmed by some package, it must not be on the cutting edge of research because someone has already done it. Besides, if your software package is really deep, most of the effort goes into the architecture and the data flows and into graphics, and the RAD bit is only simplifying a tiny part of what you are spending your time. A high-power scientific data visualization is really a video game, and how many video games are implemented in Matlab?
But what Perl is to text processing, Python is to collections, and VB is to slinging together a GUI, Matlab is to numerics (what used to be FORTRAN libraries) -- it may not have the best algorithms, but it has a lot of algorithms -- it has a semi-decent scripting language, and it has some facility with producing plots from your computations and other data.
Now that's the thing -- if you are doing matrix operations or using some canned function (most likely C under the hood), Matlab is as fast as fast can be. The minute you start looping in Matlab, it is interpreted and the speeds are in the Python range.
Before you knock it completely, it has very good integration with Java modules -- more seamless than with C modules. While Java may be pokey for its GUI, for tight numeric loops the JIT is almost as fast as C -- no joke, a person should consider writing numeric extensions to Matlab in Java of all things, especially on Windows where they tweaked up Java 1.4.2_03. And how many scripting languages (OK, Jython) have this level of Java integration?
But as a scripting language, Matlab has its shortcomings. It started out as a matrix calculator and has had features grafted on in a hodge-podge Visual Basic 6.0 kind of way. In terms of its data type restrictions and fubar scoping rules and brain-dead object extensions, I don't think, as they say, it scales very well.
My other peeve is that it is proprietary, and while Math Works is not Microsoft, I worry if engineering schools, emphasizing use of "commercial packages students will use in the real world when they graduate" (as opposed to professors dinking around with their homebrew software for use in instruction), are becoming trade schools shilling for the big software houses. I don't have a lot of experience with it, but in place of Matlab we should be using stuff like Python and the Python NumPy extension -- Open Source alternative, comparable performance, C extensions for speed, but much more Turing complete, consistent, and scalable.
And where is Matlab 6.5 using Java internally? Try doing a Files Open to start editing a Matlab script (M-file) with the Matlab editor window. One potato, two potato, three potato, and the window comes up. Now what language has that kind of GUI lag, I wonder what it could be?
" Out here in "Reality World", as I like to call it, it _does_ matter. You see - performance is performance, whether it comes via IPC or high clock speed."
Yes, high clockspeed "speed demon" chips can and often do outperform high-IPC "braniac" chips. Whether the final performance of the fastest Pentium IVs ends up being as high or even higher than the fastest competitor does not change the fact that Intel has made no effort to dispel the MHz myth--and it IS a myth, and have in fact encouraged it.
I said nothing of final performance figures. I was stating that the marketing gimmick is that MHz is an accurate measure of speed, which it is not--even between different revisions of Intel's own Pentium IV core, let alone in comparison to their competitors.
"Until the Athlon64/Opterons AMD had no answer to the P4. They just couldn't quite keep up. And you people harped on the same thing "Ooh, it's a marketing gimmick!"."
Athlons and Pentium IVs have been leapfrogging each-other for years. If you believe that 32-bit Athlons were never competitive with Pentium IVs, you are quite mistaken. I would be happy to help you research the issue.
You want a marketing gimmick? How about selling a 64-bit CPU to people who have like 512M of memory. There's your gimmick.
You may not be aware of this, but it is actually an intelligent idea to fix problems before they become problems.
--LBA-48 was introduces before more than a tiny fraction of people had hard drives that were larger than the 128GB limit. Is it a marketing gimmick that LBA-48 supports multi-petabyte drives? (2^48-1 512 byte sectors).
--Serial ATA, and even ATA100 were introduced long before any hard disk drive could possibly approach 100MB/sec sustained transfer rate. Even today's world's fastest hard drive, the Fujitsu MAS3735, cannot quite reach 80MB/sec. DId you know, however, that the same situation occurred with ATA66, ATA33, ATA16, etc.? Perhaps engineers should have waited until the performance barriers were making drive upgrades pointless before introducing faster means of communication? After all, "no hard drive could possibly even approach 33MB/sec" --1995.
The same applies to 64-bit processors.
The average Dell comes with what, 256MB RAM? Probably 512MB now? That is 1/8 of the "4 GB barrier" of 32-bit pointers. Actually, that barrier is either 1.5GB, 2GB, or 3GB depending on your operating system.
Now, let's think: Have you ever seen the average amount of RAM in a system double? I seem to remember 4MB being "plenty" and 16MB being "wastefull and rediculous". I seem to remember 32MB being the standard, and anything over 128MB was an unwise waste of money.
Do you think that maybe, possibly, that pattern might repeat? Perhaps--since it has happened every few years for decades--the average amount of RAM in a system might increase? Applications might want more than 4GB of address space? Quake 5 may require 6GB RAM minimum (16GB recommended)?
In case you were not aware, the 64-bit mode of the Athlon64 provides real performance benefits, whether software cares about the extra address space or not. Many algorithms, particularly encryption, data management, HL math, high precision math, media en/decoding, and compression can make use of the larger register size.
The fact that there are double the number of GPRs (that stands for "General Purpose Register" Ohhh, ahhh) and that the amount of data that one can fit into those GPRs has quadrupled, helps ALL software that is more than a 20-line assembly language experiment. Hell, even having 16GPRs (twice as many as previous x86 chips), the AMD64 architecture is still considered register-starved. Look at the PowerPC, the IA64, the AXP, the UltraSPARC, and just about any other mainstream high-performance processor architecture.
You may want to look at the reviews from reputable publications showing substantial performance gains from 64-bit Opteron software, including software that could not care less if you have >4GB of memory. Hint: Tom's Hardware is not on that list.
Is a 10%-30% performance boost a gimmick?
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
Before you run off blaming the evil Marketing demons, let me ask you this.....what readily quantifiable measure would you use instead to compare systems for the broad range of users and applications - all other things being the same? (memory, disk, etc.)
... other things might be good. As with any benchmark, there are always caveats and special conditions involved. If one simply averages the scores of many benchmarks things happen such as one candidate doing rediculously well one one (possibly unimportant) part of the benchmark, thus throwing the average way out of kilter.
Imperfect a measure that it may be, it's a hell of a lot easier to relate to and compare than "how many FPS of Quake3 can I get?" or "how quickly can it compile the 2.6 kernel?"
That very question has long been a topic of heated debate. Years ago, AMD launched an initiative to create a nonbiased (so they say), general purpose universal benchmark. It never went anywhere as far as I know.
Overall, Winbench 'XX is a good benchmark because it shows actual performance in real-world applications (albeit somewhat old ones). For games, the only reliable means of benchmarking is to test those individual games, or at least assume similar performance across many games that use the same game engine. The game industry is converging because of the extreme difficulty of developing truly sophisticated 3D graphics engines. I predict that within 5 years, there will be at most 3-5 major game engines used by 90% of high-budget games. A general benchmark of these 3-5 engines (or however many there turn out to be) could be used, either taking their average and giving an overall "gaming score", or predicting the performance of the many games based on each engine based on extensive benchmarking of a few titles using each.
Server benchmarking is not an issue, because those involved in the tests often know what they are doing.
As far as unix benchmarking, well, that is a major pain in the ass. That certainly does not mean that we should rely on clockspeed, or god forbid on BogoMIPS. A standard benchmark based on the compilation time of a certain version of BASh was proposed not too long ago. Because many Unix geeks are developers, this would not be a bad start. As for pure CPU tests, perhaps a mix of BZip2, large-scale encryption, and
Benchmarking is a science, an art, and a rather large pain in the ass.
Your point is well taken though.
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
The Quantium has the following new features:
You have to remember that a garden variety PC is a very unpredictable environment. You have network packets coming in, mouse events, keyboard presses, USB chatter, DMA access, every event generates and interrupt that requires the processor to stop what it's doing, and start the pipeline over again.
It's nothing personal, but articles like this one, as well as posts like this, drive me absolutely batty with the amount of incorrect ideas propagated. It's not that one particular person is misinformed -- it's just that the amount of generally bogus information is silly.
First off, at some point, as far as I can tell, a bunch of people read Maximum PC or somesuch consumer "PC enthusiast" magazines, and read about "The Megahertz Myth". Maybe Ars Technica ran the story that started all this. Heck if I know. All that the original author was trying to do was point out that people shouldn't judge processors strictly by clock speed.
Boy, did they ever create a monster. Somehow, a bunch of folks managed to get the idea that Intel was pulling this as some sort of PR job to deliberately trick people into buying their processors. For Chrissake, this is such an incredibly stupid idea. The OEMs have purchasers that know what they're buying. Not only are they not going to just sit down and look at benchmarks, they're going to have a bunch of test machines built when deciding what to go with. That and business considerations outweight any "MHz rating". The OEM market just plain doesn't care. The only people getting excited about the "MHz Myth" are the "PC enthusiasts", a tiny, tiny sliver of a group when it comes to dollar value. If the sort of "PC enthusiast
riffraff really think that they constitute any kind of a significant market to Intel -- enough for Intel to *redesign their entire processor*, using a longer pipeline and higher clock rate, around getting them to purchase a computer, they are vastly overestimating their own importance in the universe.
When Intel makes the decision about a new processor, it's a pretty safe bet that they don't run out and say "Gee, how would Joe Assmunch in Marketing like us to structure this thing?" They have many, many PhDs in chip and circuit design who have many competing ideas about what the best designs would be. They run many, many simulations before even thinking about deciding on major design decisions.
The "PC enthusiast" folks who think that Intel has taken this path to trick those people that buy from Dell, and that, ho ho ho, *they* are smart enough to see through the trick are ridiculous. If Intel wanted a high clock rate to put on stickers, they could jack the thing through the sky, run at 10GHz, then demux data and only accept data at a lower rate into the various units. Some of the units would move to even more instructions per cycle.
The *current* poster is talking about *keyboard* and *mouse* events? "USB chatter"? Those don't even show up on the *radar*. You roll that mouse, send your 200 Hz interrupts, and you worry about 200 measly mispredictions per second? Just blowing away the page table cache during process switches (which runs at 100 Hz on Linux 2.4 x86 by default) already dwarfs any misprediction performance hit from the said devices, and folks frequently bump it up by an order of magnitude or so and don't see any measurable performance hit -- on Pentium IIs.
As for DMA, the entire point of DMA is so that the processor *isn't* running code from the host. It can continue on in its own happy little world while a co-processor pokes at the memory bus.
You might see significant branch misprediction issues with an inner loop with a branch statement that flicks back and forth just about every loop or so to screw over the branch caching. And "significant" is still pretty minor. The compilers hint to the CPU whether a branch is likely to be taken...it's not as if there's this massive, awful mistake that all the chip designers in the world are making that Joe I-Built-My-Own-Computer-
May we never see th
WTF? Please, just have a look at some IA-64 assembly code! It's NOT pretty, especially if you want it to go fast. You've got to do the whole explicitly parallel thing, manually pack together independent instruction according to what pipelines you want to run them in.
Itanium is NOT a RISC machine like Sparc, not in the least. Sparc is much more closely related to x86 than it is to IA-64. The Itanium is a VLIW chip, or EPIC in Intel-speak. It's a whole different animal altogether.
FWIW, here's a brief article where Intel talks about implementing a bubble-sort in IA-64 assembly vs. the original C. In particular, they start with the code that the Intel C compiler generates and optimizes it. Their final, optimized version of the algorithm is on page 5, and it's anything but easy.