Slashdot Mirror
Double-Whammy Look At The Pentium 4
SystemLogicNet writes: "We at SystemLogic.net have just taken a technical look at the Pentium 4 architecture. In the article we go over all the basics that all the other sites cover like the double pumped ALUs, iSSE2, the longer pipeline, etc, but in addition we have some discussion about how different program structurings have an impact upon the design, and performance of the Pentium 4. One of the major areas where this comes into play is how complex data structures interact with the underlying philosophy that the Pentium 4 is built upon -- extreme bandwidth. This Pentium 4 technical background can be read over here. At the same time, we've done a rigorous analysis, including benchmark description and discussion regarding the Pentium 4's performance, and this can be read over this way."
Wrong! Branching is predicting the outcome of a dice roll. If you predict the outcome of 10 rolls and get a correct prediction 90% of the time and have the next instructions calculated on the outcome, you are way ahead of the game. The old way is wait for the roll then act on the outcome. Having most of the likely outcomes predicted, and the next instructions lined up in the pipeline puts you way ahead in time when an outcome becomes known. That is the advantage of prediction. To predict all possible outcomes to all chance paths is not 100% acheivable. The unlikely outcomes are not predicted. For example, predicting the next keystroke from a user can be 90% that it is a single keypress and all instructions on that can be pipelined. However predicting that the next keystroke is going to be Ctrl-tab-F7 is a waste of time and would be part of the 10% not predicted. Don't expect 100% prediction.
The truth shall set you free!
Umm... This isn't a very good analogy. Imagine instead:
STOP . AMERICA . NOW
What goes through the mind of vendors who assume that customers will, of course, run out and replace all their software to take advantage of a new chip.
This sounds all too much like the music industry who thinks we'll run out and buy new copies of stuff we already own in order to enjoy some new technological advance.
I'm sure the P4 will be great... in a couple of years.
CUR ALLOC 20195.....5804M
Which end of the middle would that be?
The way you describe it doesn't seem to fit with how the words are usually used.
Usually in sales & marketing, the term is mid _range_, mid _end_ is simply rediculous as even if the middle had an end, it's not descriptive as to what the end of a middle is, or which end assuming if there is one, or where that end is if there was only one.
Personally, I don't agree with the Brute Force methodology by Intel; I prefer simpler, cleaner and more elegant solutions. It is difficult to deny, however, that the brute force method has worked so far. Yes, yes, I know that the "x86 suxx0rs" crowd is now going to come out of the woodwork. Let me just say this: It may not be the best architecture, and it may be kludged for backwards compatability, but... it works, and it's cheap. With any luck, the 64-bit processors will be able to buck the trend of backwards compatability (has anyone heard anything about this with regards to Itanium and/or AMD's 64-bit chip?).
"To hope's end I rode and to heart's breaking: Now for wrath, now for ruin and a red nightfall!"
You're absolutely right. But like you say about the Pentium Pro - It SUCKED when it came out.
The Pentium 4 is an inferior chip right now, so it's a poor purchase choice, again, now - and for more reasons than are made evident in this comparison.
It is a little early to begin reviewing the Pentium IV. Intel released it early due to market pressure from AMD.
When the
Bush's education improvements were
Benchmarks show that programs compiled with intels compiler using P4 optimisations
That's predictable. A code recompile is needed with every one of the Pentium processor generations in order to make any significant performance gains. I'm not saying that's good or bad, there are downsides and upsides to that. For one, we'd get faster code but that means that the compilers have been re-tweaked and all our software is re-compiled, but then that usually means waiting for the next revision, and buying new software.
The link claimed that the optimizations available in modern compilers aren't much beyond Pentium.
Tom's Hardware Guide or AnandTech
Sorry, but comparing a 1.1gig/200Mhz FSB Athlon to a 1.7gig P4 is laughable at best. What hardware review site uses a processor that's over a year old (Athlon 1.1gig/200FSB) in a comparison to one of the latest processors from the competition?
also, note that the 1.7 ghz p4 has a 600 mhz advantage over the 1.1 ghz athlon and usually the performance difference was only 10-40%. the p4 has over 50% more processor mhz than the athlon. what an unfair comparison, especially when the 1.33 ghz athlon is out and available for purchase. processor mhz for processor mhz, the athlon beat the p4.
The point of the extremely long (20-stage) pipeline of the Pentium 4 is the ability to reach extremely high clock speeds - much higher than the Athlon could ever reach. Of course, Mhz-for-Mhz, the Athlon is going to beat the Pentium 4 performance-wise, but it wouldn't tell us anything except the obvious differences in the two's design philosophies.
Light a fire for a man and he'll be warm for a day. Light a man on fire and he'll be warm for the rest of his life.
That is a much better explanantion, and now in respone to the original comment: it is nearly impossible to criticize that "miss rate" without actually going through the design process.
Something like Patterson & Hennessy would explain the classic tradeoff well. If you make a lower miss rate (imagine 9.5 out of 10 are hits), the time for hits goes up slightly. Now the main question becomes, what is the "common case".
The most important thing before you whine about some processor is to know the design process. Is missing 1 out of 20 times (but hit-time taking twice as long) better? Is missing 1 out of 7 times (but having a lightning-fast hit-time and tolerable miss-time) better? As a /.er there's really no room to say "thats so bad" unless you actually sat at Intel/AMD, went through the design process, and there was a better option for your mix of instructions.
Using the new process of W.attage H.alting R.esistance E.ngineering, Intel can reduce pent-up system tension at an even lower cost.
Also, the WHORE system is fully compatible with the C.omposite R.ecursive A.lgorithm C.reation K.it used for extreme overclocking.
"The CRACK/WHORE combination should be a killer setup for many of our users, and we have already had several U.S. senators make inquiries" says John Thompson, head of engineering at Intel. "We even allow for massive clustering with the P.arallel I.nsulating M.ultipartite P.olymer, or PIMP management process.
Thompson also spoke of project BITCHSLAP for correcting wayward systems, but could not elaborate on it...
Did you just cut and paste a press release onto the front page of Slashdot?
I sure hope you Slashdot isn't selling Front Page space to any little company that pays...
While I agree that as technology moves forward the traditional ways of X86 programming will have to expand along with the technology, and in some areas change completely, I'd just like to share something about upcoming AMD technology in this regard.
The next-generation chips from AMD are being designed with programming optimizations done at the firmware level. For example, a FORTH interpreter is being ingrained into the preprocessing area on the chip die itself. This makes it easier not only to add firmware-level software like BIOS, bootloaders, etc more easily, without resorting to running the code through a compiler into X86 instructions and machine code, but it will also make it much easier to write more optimized C compilers (and other compilers for that matter). If you combine this with the improved instruction technology that AMD will be incorporating, it makes for a very powerful new platform for all programmers.Dwain Snyders
Research and Development, AMD
2DUP * ;
the graphs are not done fairly. they almost never started at 0 to a result slightly higher than the higher result of the two processors, they were always done so that the intel bar was much longer (and therefore appeared to do much better) than the athlon when the actual results were that the two processors were pretty close.
also, note that the 1.7 ghz p4 has a 600 mhz advantage over the 1.1 ghz athlon and usually the performance difference was only 10-40%. the p4 has over 50% more processor mhz than the athlon. what an unfair comparison, especially when the 1.33 ghz athlon is out and available for purchase. processor mhz for processor mhz, the athlon beat the p4.
The 1.4 ghz athlon has been out for a couple months now... the 1.1 ghz athlon has been out for at least 10 months.
Here is a june 6 pcworld review where an amd 1.4-GHz system is "the fastest system yet tested by PCWorld.com" beating out 5 systems based on the 1.7 ghz p4.
Here is a tech report review of an amd 1.33 vs intel 1.7 where they conclude: "Intel's new entry, the 1.7GHz Pentium 4, performs about like a 1.2GHz Athlon in most situations."
You cant get duel processing power from a pentium 4 like you can with an athlon.
We have the best government that money can buy.
1.1 Ghz 200fsb Athlon -vs- 1.7 Ghz P4????
The 1.7 was released april 23.
The 1.333 Ghz 266 fsb athlon was released april 1.
The MSI KT7 Turbo is at best a middle of the pack Motherboard. It does not use DDR.
The intel 850 is the best platform available for the p4
This is sort of like saying the ford mustang (P4) is faster than the chevy camero (1.1;200,KT133), therefore it is faster than the corvette(1.333;266AMD760). WRONG
BAD BIASED ARTICLE NO COOKIE! LOOSER INTEL SUCK UP PAID FOR JOURNALISM.
or a fan boy, therefore unpaid suckup double looser stoolie.
-1 flamebait
If voting were effective, it would be illegal by now.
I was shocked by this review site. Most all the graphs are misleading. Most magnify the area of differenc between the two processors to make the margin look larger. For example, in the benchmark "Content Creation Winstone" (http://www.systemlogic.net/reviews/hardware/proce ssors/intel/p41700/i/c7.gif), the difference is only 3.6 points, yet the scale is nearly 1/3. That's nearly 3x magnification.
Some only differ by a few percent, the lowest about -4.5% of P4 score, yet the distance represented on the graph would suggest nearly a 60% difference or more.
This review site needs to get a clue about statictics and start using proper graphing according to real differences, not magnified margins.
"I'll just chip in a bit for RedHat: I actually have that installed on my university machine." - Linus, '95
The review was pretty interesting. Essentially it comes down to this:
1. The P4 1.7G is a faster processor than the Athlon 1.1G (and probably the 1.4G but they really can't say).
2. It costs a few hundred bucks more.
3. Just wait till next year's model, which will be even better.
It seems to me that the people who want the highest performance will pick up the P4, and those who want to save money will pick up a Celeron. Who would buy the Athlon? People who want to compromise between price and performance.
As for the temperature slowdown switch, I'm all for it. Why fry my processor unnecessarily?
144l. ph34r my 133t l3g4l 5k1lz!
On the other hand, the Athlon and its offspring seem to be better no matter which way you cut it. You'd think they'd keep intel on its toes...
it's sad that Intel feels the need to optimize for an untested and foreign program structure (XP) when they haven't even gotten imperative programming optimizations done right. oh, and that failing-branch-10%-of-the-time might knock the wind out of the P4's sails (sales) too. i'll stick to the Open Source support of the Athlon.
Cretin - a powerful and flexible CD reencoder
I think you misunderstand branch prediction. Now I don't claim to be an expert on cpu architecture or branch prediction. But from my understanding, it is kinda silly to compare opening files etc to branch prediction. If a cpu encounters a failed branch prediction the user would never notice this. It merely means that the failed instruction would have to be rerun through the cpu. This would slow things down for the cpu, but for the end user this wouldn't be noticeable at all. Considering that a cpu has millions of instructions runnning through it at all times, a few missed ones aren't going to be noticed. Of course 100 % branch prediction would be nice, but so would an internal combustion engine with 100 % efficiency.
S.t.e.v.e.
As an end user in the market for a new box based on p4 or athlon tech, I appreciate why he thinks the P4 sucks but I tend to think of two things that bias his judgement.
1) He's writting in assembly.
Any change that doesn't rely on x86 basics he's grown to love will likely be considered by him as bad. Eg. "... and even went so far as to expect developers to rewrite their applications to make use of the Pentium 4." The assembly language programming paradyne that he has embraced is not as conducive to rewritting so it's a chore. If he was writting in C and using asm for the most preformance intensive functions as is now standard practice for the non lazy (who know their target platform and optimize for it)it would not be such a chore. Perhaps if he used an Intel compiler plugin that optimizes for the P4 he would not be complaining. Should he have to do so? Nope, but it seems to be the way everything is heading whether you look at AMD or Intel. Also with AMD embracing functionality of SSE2 on their newest processors this is not going away.
I love asm, but most people would not try to write a modern office suite in it. It's a shame but it's the way things are. I wish more programmers of commercial applications coded better but I don't think this is going to get resolved anytime soon, unless we move more to an appliance architechure where resources are both well defined and limited or go opensource. I'm not holding my breath.
2) It sounds like as an early adopter he got burned on price. There was a time (11 months ago?)where the p4+rdram was about 3.5 times the cost of an athlon+sdram. If you look at the present it's more like 2.1 times the cost for a p4+rdram vs an athlon+ddr memory. That is still a sizeable chunk but remeber the cpu and memory just part of the equation. There's still case,ps,motherboard,storage and yes the OS and productivity license which despite being in a Windows dominated world is likely to be the first thing cut to save costs. It's already happened on the low end and the highend, and I think it's only a matter of time before it happens on the mid end.
As a side note it's interesting to once again hear the arguments for and against thermal protection. I think the arguments both have their points, but I think it would be better to have it, but also be able to turn it off from the BIOS. AMD's new chips will have the integrated thermal diode so really the issue is will endusers be to easily configure it manually.
The Pentium 4 is, by Intel, considered to have "Hyper pipelined technology."
I can see the ads now..... "The Pentium 4 - Because our Pipline is bigger than theirs!
S.t.e.v.e.
Intel's biggest problem is that they are losing inovative engineers. Anyone with any real talent has left Intel already. Management is running the scene and they need to pull their heads out of the ground to see what is going on. A good example of this would be with the Rambus fiasco. It was the managers that made the decision to use Rambus, not the engineers. Another example would be the web tablet. This product has been in development for a long time. In fact, if people at the last CES didn't show much excitement for it, the Web Tablet would have been scratched already. By the way, 80% of the webtablet group have been either laid-off or re-deployed to other groups. What does that tell you?
I agree that the P4 is not the best CPU at this time. However, Intel has designed this new architecture looking out 10 years or so. Many of these choices are dictated by the laws of physics, and all other processors will be heading this direction over time.
The fundamental problem is that propagation speed of a signal on a chip is essentially fixed (that's why the minor improvement from a special trick like copper wiring was a big deal). As you speed up the transistors, the signal propagation delay becomes more of a bottleneck.
To avoid this, you have to break the logic steps into smaller pieces that live in a smaller portion of the chip. The standard way to do this in synchronous logic is to pipeline the work into more stages. The total signal propagation delay to do one instruction remains about the same, but at least you can pipeline alot of instructions to try to get more work done.
This processor is not very competetive today, but in 5 years there won't be any other way to make forward progress. By that time, Intel will have worked out the kinks (problems with branch prediction, memory interface snafus, etc.), and this core will probably be as wildly successful as the Pentium Pro/PII/PIII/Celeron core was.
BTW, remember how sucky the Pentium Pro was when it came out? It was a piece of crap on 16-bit code and it would generate huge pipeline bubbles for no good reason. Over time, they fixed these problems and made countless $billions in the process. Watch for a repeat with this new architecture.
The 64-bit AMD processor will be fully backward compatible.
Kjella
Live today, because you never know what tomorrow brings
Actually, it's not exactly "hard" stuff from an implementation point of view. Cycle times are short so you want a predict equation that you can do quickly and in one cycle. In fact, you can get pretty good results with a simple 4 state strongly not taken (00) - weakly not taken (01) - weakly taken (10) - strongly taken (11) saturating counter that updates when a branch is confirmed to be taken or not taken. If your BHT (branch history table) is sufficiently large, you can get decent results. Sprinkle in some voodoo magic by adding a GHR (global history register) which hashes the opcode address based on the state of the last n taken branches and you can get a couple of extra percentage points. I've seen upwards of 95%-97% prediction rates with such implementations but that's in a RISC environment which also provides fairly accurate branch hints in the opcode itself (much like the Itanium does). (The compiler knows what the code should do and what the semantics of a branch are: an "if", "for", "switch" construct, etc.)
Where things probably get weird for Intel is that their BHT probably suffers a bit of address aliasing/underutilization due to the fact that x86 opcodes are variable length. With RISC architectures (fixed length opcodes), you can chop off the last couple of address bits since the 0,1,2,3 cases don't matter == less address aliasing over a greater range of addresses.
Mispredict bypass buffers are another nicety that help back out of branch mispredicts because you don't have to go running back to the I$ and wait two cycles. In fact, while you're going down the codestream for the "predicted taken" path, you can also load up the "not predicted taken" path into a line buffer from an alternate cache such as a BTB (branch target buffer: if the data is available, a TLB entry exists, etc) and bypass the 2 cycle hit on the I$ on the mispredict. Two cycles are two cycles...
Engineers have a very big bag of tricks to work from..but they do have to know when to cut the apron strings and say "out with the old, in with the new." I think the key to major ramp-ups in speed for the x86 architecture is going to be when Intel proclaims "The Great Simplification" (a la "A Canticle for Leibowitz") and deprecates a whole slew of ancient modes (e.g., 286 type stuff) such that they must be emulated through an OS trap. By that time, DOS based OSs like W9x will be about as common as Win311 is now so it won't even matter. About the only people who I can see complaining then are VMWare, Netraverse, Plex86, and the WineHQ Team.
If he was writting in C and using asm for the most preformance intensive functions as is now standard practice for the non lazy (who know their target platform and optimize for it)it would not be such a chore.
;-)
Damn... that's the first time I've seen someone who programs in C/C++ tell someone who programs in ASM that he's lazy. What balls, man! Way to go!
"And like that
Its not quite this simple.
;) ) actually solves this problem with a bunch of silicon real-estate - they compute both parts of the branch at once, and throw away the part that terms out to be incorrect once the comparison finishes. Apart from doing that, all you can do is predict which path you're going to take, and start loading the pipeline with the predicted path, and if it fails, flush it. Flushing and restarting the pipeline 10% of the time actually is far more than a 10% slowdown. I'd expect at least 50%.
:P Unless they have a reason...
You see, a 90% prediction rate is incredibly bad (I don't even know how they managed to get that low, if the parent was correct with their numbers). Having to stop executing while waiting for a comparison is exceedingly bad - depending on the comparison, it may even have to do a memory read (!), and in all likelyhood, at least a cache read; neglecting the time for the comparison itself, which is usually a subtract and a bit check. Merced (I refuse to call it "Itanium"
I really hope that 90% number is incorrect - that's a pathetic number for a college CPU design course to get, let alone for Intel to get..
-= rei =-
*Kid Rock runs for Senate* Democrats: We must run Kid Scissors.
There are liars, damned liars, and statisticians. Then someone in marketing gets the graphs....