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
Anand Lal Shimpi - Friday, December 30, 2005 - link
I had some serious power/overclocking issues with the pre-production board Intel sent for this review. I could overclock the chip and the frequency would go up, but the performance would go down significantly - and the chip wasn't throttling. Intel has a new board on the way to me now, and I'm hoping to be able to do a quick overclocking and power consumption piece before I leave for CES next week.Take care,
Anand
Betwon - Friday, December 30, 2005 - link
We find that it isn't scientific. Anandtech is wrong.
You should give the end time of the last completed task, but not the sum of each task's time.
For expamle: task1 and task2 work at the same time
System A only spend 51s to complete the task1 and task2.
task1 -- 50s
task2 -- 51s
System B spend 61s to complete the task1 and task2.
task1 -- 20s
task2 -- 61s
It is correct: System A(51s) is faster than System B(61s)
It is wrong: System A(51s+50s=101s) is slower than System B(20s+61s=81s)
tygrus - Tuesday, January 3, 2006 - link
The problem is they don't all finish at the same time and the ambiguous work of a FPS task running.You could start them all and measure the time taken for all tasks to finish. That's a workload but it can be susceptible to the slowest task being limited by its single thread performance (once all other tasks are finished, SMP underutilised).
Another way is for tasks that take longer and run at a measurable and consistent speed.
Is it possible to:
* loop the tests with a big enough working set (that insures repeatable runs);
* Determine average speed of each sub-test (or runs per hour) while other tasks are running and being monitored;
* Specify a workload based on how many runs, MB, Frames etc. processed by each;
* Calculate the equivalent time to do a theoretical workload (be careful of the method).
Sub-tasks time/speed can be compared to when they were run by themselves (single thread, single active task). This is complicated by HyperThreading and also multi-threaded apps under test. You can work out the efficiency/scaling of running multiple tasks versus one task at a time.
You could probably rejig the process priorities to get better 'Splinter Cell' performance.
Viditor - Saturday, December 31, 2005 - link
Scoring needs to be done on a focused window...By doing multiple runs with all of the programs running simultaneously, it's possible to extract a speed value for each of the programs in turn, under those conditions. The cumulative number isn't representative of how long it actually took, but it's more of a "score" on the performance under a given set of conditions.
Betwon - Saturday, December 31, 2005 - link
NO! It is the time(spend time) ,not the speed value.You see:
24.8s + 13.7s = 38.5s
42.8s + 42.2s + 46.6s + 65.9s = 197.5s
Anandtech's way is wrong.
Viditor - Saturday, December 31, 2005 - link
It's a score value...whether it's stated in time or even an arbitrary number scale matters very little. The values are still justified...
Betwon - Saturday, December 31, 2005 - link
You don't know how to test.But you still say it correct.
We all need the explains from anandtech.
Viditor - Saturday, December 31, 2005 - link
Then I better get rid of these pesky Diplomas, eh?
I'll go tear them up right now...:)
Betwon - Saturday, December 31, 2005 - link
I mean: You don't know how the anandtech go on the tests.The way of test.
What is the data.
We only need the explain from anandtech, but not from your guess.
Because you do not know it!
you are not anandtech!
Viditor - Saturday, December 31, 2005 - link
Thank you for the clarification (does anyone have any sticky tape I could borrow? :)What we do know is:
1. All of the tests were started simultaneously..."To find out, we put together a couple of multitasking scenarios aided by a tool that Intel provided us to help all of the applications start at the exact same time"
2. The 2 ways to measure are: finding out individual times in a multitasking environment (what I think they have done), or producing a batch job (which is what I think you're asking for) and getting a completion time.
Personally, I think that the former gives us far more usefull information...
However, neither scenario is more scientifically correct than the other.