Intel's Pentium Extreme Edition 955: 65nm, 4 threads and 376M transistors
by Anand Lal Shimpi on December 30, 2005 11:36 AM EST- Posted in
- CPUs
Final Words
The Pentium Extreme Edition 955 finally starts to bring some respectable performance to Intel's high end processors, but there is no clear cut victory. In applications and usage scenarios where the EE's ability to execute four threads simultaneously comes into play, it generally can remain quite competitive with the Athlon 64 X2 4800+. However, looking at older applications, single threaded scenarios and some multithreaded applications that aren't optimized for more than two threads, the EE 955 falls significantly behind.
There are a few other conclusions that we can draw based on what we've seen thus far. For starters, Hyper Threading is quite important to the performance of the Extreme Edition 955. While it isn't always perfect, when under very heavy multitasking loads, the ability to execute more threads translates into better overall performance for the entire system.
We've also been able to take an early look at the state of multithreaded game development, through the latest Call of Duty 2 and Quake 4 patches. Although the performance in CoD2 was terrible in SMP mode, Quake 4 gave us some hope, with performance gains approaching the 50% mark on dual core processors at CPU bound resolutions.
As far as the processor at hand is concerned, Intel has done a reasonable job with the Pentium EE 955, but with Conroe not too far away, we just can't justify recommending it. If you absolutely must upgrade today, the Athlon 64 X2 is still probably going to be a better bang for your buck. However, as we have seen in the benchmarks, there are advantages to being able to execute four threads simultaneously.
It is pretty much a toss-up at this point, but we'd recommend sticking with AMD for now and re-evaluating Intel's offerings when Conroe arrives. If all goes well, we will have a cooler running, faster processor with Conroe that may provide some even tougher competition for AMD's Athlon 64 X2.
While we're not emphatically recommending Intel's latest and greatest, we are impressed with Intel's transition to 65nm thus far. If Intel can use Cedar Mill and Presler to ramp up their 65nm process, hopefully it will be primed and ready for Conroe's introduction later this year. From what we've seen of Yonah, Intel does have their work cut out for them in order to truly regain the performance crown with Conroe, but anything is possible. A successful migration to 65nm would be a definite step in the right direction for Intel.
More than anything, we're hoping not to be disappointed by Conroe. We vividly remember recommending to wait for the original Pentium 4's release and then once more for Prescott's release, and both times being terribly disappointed by Intel's decisions. Let's hope that with the Pentium M team at the helm, Conroe's introduction will be a change of tradition for Intel.
The Pentium Extreme Edition 955 finally starts to bring some respectable performance to Intel's high end processors, but there is no clear cut victory. In applications and usage scenarios where the EE's ability to execute four threads simultaneously comes into play, it generally can remain quite competitive with the Athlon 64 X2 4800+. However, looking at older applications, single threaded scenarios and some multithreaded applications that aren't optimized for more than two threads, the EE 955 falls significantly behind.
There are a few other conclusions that we can draw based on what we've seen thus far. For starters, Hyper Threading is quite important to the performance of the Extreme Edition 955. While it isn't always perfect, when under very heavy multitasking loads, the ability to execute more threads translates into better overall performance for the entire system.
We've also been able to take an early look at the state of multithreaded game development, through the latest Call of Duty 2 and Quake 4 patches. Although the performance in CoD2 was terrible in SMP mode, Quake 4 gave us some hope, with performance gains approaching the 50% mark on dual core processors at CPU bound resolutions.
As far as the processor at hand is concerned, Intel has done a reasonable job with the Pentium EE 955, but with Conroe not too far away, we just can't justify recommending it. If you absolutely must upgrade today, the Athlon 64 X2 is still probably going to be a better bang for your buck. However, as we have seen in the benchmarks, there are advantages to being able to execute four threads simultaneously.
It is pretty much a toss-up at this point, but we'd recommend sticking with AMD for now and re-evaluating Intel's offerings when Conroe arrives. If all goes well, we will have a cooler running, faster processor with Conroe that may provide some even tougher competition for AMD's Athlon 64 X2.
While we're not emphatically recommending Intel's latest and greatest, we are impressed with Intel's transition to 65nm thus far. If Intel can use Cedar Mill and Presler to ramp up their 65nm process, hopefully it will be primed and ready for Conroe's introduction later this year. From what we've seen of Yonah, Intel does have their work cut out for them in order to truly regain the performance crown with Conroe, but anything is possible. A successful migration to 65nm would be a definite step in the right direction for Intel.
More than anything, we're hoping not to be disappointed by Conroe. We vividly remember recommending to wait for the original Pentium 4's release and then once more for Prescott's release, and both times being terribly disappointed by Intel's decisions. Let's hope that with the Pentium M team at the helm, Conroe's introduction will be a change of tradition for Intel.
Facebook
Twitter
RSS
84 Comments
View All Comments
Betwon - Saturday, December 31, 2005 - link
NO, 2. is wrong.We need to know the end time of all tasks.
The sum of each task's time will mislead.
Because it can not show the real time spend to complete those tasks. (Time is overlayed)
Viditor - Saturday, December 31, 2005 - link
That's what I thought you meant...it's not misleading to me (nor to most of the other readers I gather, since nobody else has come forward). If you want to know the time to complete all tasks, then just take the largest time number of what ever test you wish.
The reason that the setup they used appeals to me is that it helps me understand how an individual application is affected under those conditions, and the totals give me a relative picture of each of the apps as a whole. They haven't said that the time listed in the "Total" is actually how long things took in reality, they said it was the total of the times.
I understand that the difference in those two phrases is perhaps a difficulty that many have when understanding a foriegn language...
In the future, you might want to be less confrontational about your questions...
Phrases like "There are still many knowledge about CPU that anandtech need to learn" are considered quite inhospitable...
fitten - Saturday, December 31, 2005 - link
No. What is being mentioned here is "Wall Clock Time" vs. summation of execution times. You start a stopwatch at the instant you start your task bundle and when the last task in the bundle is finished, you stop your stopwatch. That's the wall clock time. Measuring CPU utilization time is quite easily seen to be false. with two CPUs, two tasks may take 20s each to finish, but they may start and finish at the same time after 20s of wall clock time... not 20s + 20s = 40s (each task will see 20s of CPU utilization time, but those sets of 20s are simultaneously used... 20s on one CPU and 20s on the other CPU at the same time - for a wall clock finish time of 20s, not 40s).And, you cannot simply take the largest time number. For example, suppose a task that runs for 1s is blocked by a second task which takes 10s, then the first task takes another 1s to finish, while 10s is larger than 2s, the wall clock time for this bundle is actually 12s (1s + 10s + 1s), not 10s or 2s.
bldckstark - Monday, January 2, 2006 - link
Ummmmm, all of the times you are screaming about are listed. You can work it out for yourself. Although, when you look at the concurrent timing for each app, you will find that the AMD posted a better score. Concurrent timing results -AMD 4800+ - 65.9s
955EE No HT - 83.3
955EE With HT - 71.1
Consecutive times of course show a different picture, and most of all, SPCC is a wreck during all of this for AMD.
I have to say, I can't remember when I last opened 4 huge memory and CPU hogging programs at exactly the same time that I tried to play a game. These CPU's may be great at doing this many activities at once, but I can only do one thing at a time. Each of these programs would be started separately, and when they are on their way, I might start gaming. This is a great test, but not realistic.
Betwon - Friday, December 30, 2005 - link
Your test of the SMP game --Quake4Your result is diffirent with the result of the more detail test from FiringSquad.
http://www.firingsquad.com/hardware/quake_4_dual-c...">http://www.firingsquad.com/hardware/qua...-core_pe...
We find that both HT and multi-core will improve the fps. P4 540 HT is about 1x % improvement.
We need your explains. Why you say that HT will not help the in the the SMP game --Quake4?
And we do not find that AthlonX2 have the more excellent improvement than PD, when they work (change from single-core-work to multi-core-work).
Where is the benefits of on-die communication? 101ns latency? why is it slower the lateny of the memory? Is your cache2cache test software wrong?
The test shows that
SMPon/SMPoff PD840 102.9 fps/74.8 fps --> 37.6% improvement
SMPon/SMPoff X2 3800+ 101.1 fps/74.4 fps --> 35.9% improvement
SMPon/SMPoff X2 4800+ 103.2 fps/87.7 fps --> 17.7% improvement
AMD test:
http://www.firingsquad.com/hardware/quake_4_dual-c...">http://www.firingsquad.com/hardware/qua...al-core_...
Intel test:
http://www.firingsquad.com/hardware/quake_4_dual-c...">http://www.firingsquad.com/hardware/qua...-core_pe...
The improvement ratio of PD is better than that of athlonX2.
psychobriggsy - Saturday, December 31, 2005 - link
> SMPon/SMPoff PD840 102.9 fps/74.8 fps --> 37.6% improvement> SMPon/SMPoff X2 3800+ 101.1 fps/74.4 fps --> 35.9% improvement
> SMPon/SMPoff X2 4800+ 103.2 fps/87.7 fps --> 17.7% improvement
Looks like the issue is an upper performance limit around the 103 fps mark that probably isn't caused by the CPU - e.g., GPU or something else.
If it is a memory bandwidth issue (which should be easy to test for by using faster memory and running the tests again) then there isn't much that can be done. Then again, the Intel processor uses DDR2 so ...
If the 4800+ improved by 36% like the 3800+ then it would achieve around 120fps.
In the end it just shows that the lower-priced dual-cores are still a better deal ... especially as they can be overclocked quite nicely.
Viditor - Friday, December 30, 2005 - link
I would hope so, since the patch was partially written by Intel...
http://firingsquad.com/hardware/quake_4_dual-core_...">http://firingsquad.com/hardware/quake_4_dual-core_...
Betwon - Saturday, December 31, 2005 - link
PD840 139.1fps/83fps --> 67.6%PD840 are 67.6 percent faster at 800x600 with threading enabled.
67.6% > 63%
Patch was partially written by Intel...?
But the patch is very excellent!
This patch is the most improvement game patch for SMP CPU.
We can not find that another SMP game patch can improvement the game performent so much.
Good quality of the codes!
Betwon - Saturday, December 31, 2005 - link
PD840 139.1fps/83fps --> 67.6%PD840 are 67.6 percent faster at 800x600 with threading enabled.
67.6% > 63%
Patch was partially written by Intel...?
But the patch is very excellent!
This patch is the most improvement game patch for SMP CPU.
We can not find that another SMP game patch can improvement the game performent so much.
Good quality of the codes!
Viditor - Saturday, December 31, 2005 - link
Possibly, but Intel is well known for creating an imbalance in performance for their processors using software (e.g. the Intel Compiler). Most likely, future versions of the patch will correct for this. Either way, it really says less about the CPU than it does the patch...