Intel Dual Core: Multi-Tasking Benchmarking

A place to give your thoughts on our reviews!
teqguy
Legit Enthusiast
Legit Enthusiast
Posts: 42
Joined: Thu Apr 07, 2005 11:19 pm

Post by teqguy »

I understand... but there just seems to be a very discerning pattern among all of the more popular review sites. The reviews seem to either cover the SMP aspects of the processor, or they treat it just like a regular processor and compare it with every former latest and greatest kid on the block.

As the article over at Overclockers.com (here) tries to licit, new methods for accurately measuring dual core performance are neccessary. I believe at this time, that the most accurate and appropriate method of measurement would be to include benchmarks from SMP enabled software and multitasking through manual thread allocation.

Granted, neither will provide an indication of how a multithreaded application fares, but what it will do is provide a comparative response to more expensive dual processor systems based on the Xeon or Opteron.

Keep in mind, I'm not trying to discredit the article or step on toes here. I'm simply giving a written explanation for what the dual core processors are expressing at this point... something that neither Intel, nor AMD has yet to give a public reference to.


Longhorn will feature a layer that automatically appropriates threads based on resource usage, and could even possibly work to multithread single threaded applications through a quanta prefetch algorithm.

When it's released, the average joe will have his cake and eat it too.

However, until then, it would benefit everyone to gather all viable information, regardless of whether or not it's applicable to a marginal demographic.
User avatar
Illuminati
Site Admin
Site Admin
Posts: 2378
Joined: Mon Oct 06, 2003 8:48 am
Location: Wright City, Missouri, USA
Contact:

Post by Illuminati »

I found it interesting that you made reference to comparing these dual core processors to Dual Processor Xeon or Opteron server/workstation setups. I think the manual thread management does fit much better in this category.

However, you may want to wait a month or two for AMD to release their dual core Opterons for that comparison... and the sites which review servers/workstations should definitely have that comparison for you. For now, we only have desktop systems to compare the dual core processor to... and unfortunately, I personally don't see the demand for manual thread management on desktop systems.
Justin West
Server Admin & Forum Moderator
Follow me on Twitter | Find us on Facebook
accord1999
Legit Little One
Legit Little One
Posts: 4
Joined: Wed Apr 13, 2005 3:19 pm

Post by accord1999 »

For tests such as the simultaneous Norton scan, F@H and D3 test, can you provide the scores for all 3 applications. The problem here that I can see is that there are three CPU intensive applications, with HT disabled, there are only two cores for the OS to schedule to. Therefore, either the Norton on F@H thread is not actually executing. With HT enabled, with 4 logical cores to schedule to, all three threads now are being executed, resulting in reduced performance for a single thread, but an increase in total combined throughput.
teqguy
Legit Enthusiast
Legit Enthusiast
Posts: 42
Joined: Thu Apr 07, 2005 11:19 pm

Post by teqguy »

I believe all of the threads were executed on the primary core, and that the secondary core wasn't even considered in any of the tests.

Windows XP has no scope when it comes to thread management, so while it may support as many logical processors as available, it doesn't have a clue what to do with them.

Keep in mind that Hyperthreading is not an entire logical processor, but rather a set of architectural exploits and instructions, and that Windows XP was never originally designed for Hyperthreading. Microsoft's patch might've done more harm than good.

There's a technical explanation of Hyperthreading here:
http://www.intel.com/technology/itj/200 ... _intro.htm

Furthermore, the Smithfield features a few architectural enhancements over the 6 series, such as lower latency 1MB SRAM, opposed to the higher latency 2MB SRAM in the 6 series.

This could easily attribute to the performance difference demonstrated in the benchmarks.
accord1999
Legit Little One
Legit Little One
Posts: 4
Joined: Wed Apr 13, 2005 3:19 pm

Post by accord1999 »

Windows XP does understand logical processors, it's one of the reasons HT works better on XP than on 2000. It is smart enough to realize the difference between a physical and a logical processor, and will try to schedule threads to a idle physical processor before using the second logical processor of an already busy processor.

The point I'm making is that in the case of the benchmark utilizing three CPU intensive apps, with HT disabled, there are only two cores that are visible. Therefore only two apps can be executing simultaneously. With F@H likely at idle priority, it is very likely that Doom 3 executes on one core, receiving 100% of the core's execution time, while Norton executes on the other core, receiving 100% of the 2nd core's execution time. F@H meanwhile starves and does virtually no work.

With HT enabled, now there are 4 visible "cores", in which case F@H, even with an idle priority, will still be scheduled to execute simultaneously. Depending on the XP scheduler, F@H may end up running on the logical processor of the 1st core, causing Doom 3 and F@H to split execution resources, but the total throughput is higher.

This is similar to comparing a single P4 with HT vs a system without HT. Run Doom 3 and F@H at idle priority at the same time. The non-HT system will see virtually no loss in framerate in Doom 3, but F@H will do no work at the same time. However, for the HT system, Doom 3 framerates will drop, maybe to 60-65% of the original framerate. However, F@H will still be working, maybe at 60-65% of the output of what it can acheive by itself. If you change the priority of F@H to normal, there won't be any change in the HT system, but the non-HT system, each application will run at 50% of the single threaded performance, so your combined throughput is still only 100%.
teqguy
Legit Enthusiast
Legit Enthusiast
Posts: 42
Joined: Thu Apr 07, 2005 11:19 pm

Post by teqguy »

I think you have more faith in XP than even Microsoft itself.

Parallel scheduling doesn't exist on XP, period. It relies on software that supports SMP to manage that.

Applications that demand quanta recieve it based on the execution priority of the application, not what XP deems appropriate for the situation.

If XP did feature thread management, it would inhibit the more native thread management of applications that support SMP.
accord1999
Legit Little One
Legit Little One
Posts: 4
Joined: Wed Apr 13, 2005 3:19 pm

Post by accord1999 »

What are you talking about? What is parallel scheduling. In the test, we have 3 essentially single-threaded applications. The XP kernel controls which processor they run on. With HT disabled, there are only two visible processors, and only two applications can execute. With HT enabled, all 3 applications are scheduled simultantenously and execute simultaneously.
teqguy
Legit Enthusiast
Legit Enthusiast
Posts: 42
Joined: Thu Apr 07, 2005 11:19 pm

Post by teqguy »

XP's microkernel has a serial thread scheduler, not a parallel thread scheduler, meaning that threads are not given an affinity mask when executed.

The microkernel doesn't deviate from that when handling DPCs, so only the primary logical processor is considered, unless specified by the application.

Furthermore, XP has very soft CPU affinity, so most of the time applications will execute on the last processor ran, rather than on the ideal processor.
accord1999
Legit Little One
Legit Little One
Posts: 4
Joined: Wed Apr 13, 2005 3:19 pm

Post by accord1999 »

So, all these are only factors that the scheduler takes into account when determing which CPU an application thread runs in. The ultimate decision remains with the scheduler. If what you say is true, then a Windows OS should show no performance benefit for running two single-threaded application simultaneously on a dual-processor system and this is not the case.
teqguy
Legit Enthusiast
Legit Enthusiast
Posts: 42
Joined: Thu Apr 07, 2005 11:19 pm

Post by teqguy »

It's exactly the case.

As stated by the article I posted earlier, Window XP's thread management is practically non-existent. It doesn't load balance like it's supposed to.

The slight performance improvements come from architectural enhancements, not from the presence of another logical processor.

If the secondary logical processor was actually kicking in, you would see no difference between the benchmarks with HT enabled and with it disabled.
User avatar
infinitevalence
Legit Extremist
Legit Extremist
Posts: 2841
Joined: Sat Apr 24, 2004 12:40 pm
Location: Nashville, TN
Contact:

Post by infinitevalence »

next time you open up the task manager select a process and you will find out that XP does infact set affinity for a particular core. Also your right there is no parallel tasking and luckly there is very little software that is parallel. All the programs running were all serial single thread apps.

I think you have done lots of good research and know an lot but i dont think you entierly grasp whats going on. The reason people are looking at this thing as either a single cpu or as SMP is because they are trying to find out who benifits from this technology. If the average user/gammer does not then why look at its SMP ablities it does not help gamming...
"Don't open that! It's an alien planet! Is there air? You don't know!"
teqguy
Legit Enthusiast
Legit Enthusiast
Posts: 42
Joined: Thu Apr 07, 2005 11:19 pm

Post by teqguy »

Dual core processors were not designed to replace SMP, but rather facillitate multithreading on a single processor system.

Symmetric multiprocessing distributes load evenly among processors(otherwise known as load balancing) and allows simultaneous use of more than one processor to execute a single application.

Where this differs from multithreading is in the way the application is executed.

For example, if you were rendering a video in Premiere, CPU0 would execute the application, while CPU1 remains idle. When you start to render, both processors would kick in, but CPU0 would retain the application's affinity.

However, with multithreading, individual parts of the application are individually executed on either processor, while CPU affinity is mutually shared among processors. Each portion of the application retains its own thread pool, which allows multiple threads of the same application to execute entirely seperately.

Games are only going to benefit from multithreading, because intensive portions like physics and the graphical engine can be executed seperately from the rest of the application.
User avatar
Illuminati
Site Admin
Site Admin
Posts: 2378
Joined: Mon Oct 06, 2003 8:48 am
Location: Wright City, Missouri, USA
Contact:

Post by Illuminati »

I've noticed that this discussion has veered slightly over the last few posts... so I want to reiterate something for everyone's benefit...

Just a few posts ago, the subject was on our benchmarking tests of testing the multitasking ability by using 3 single-threaded apps (doom3, norton AV, & F@H)... The last post mentions windows XP's lacking ability to support multithreaded apps, and I'm not sure where the exact transition was... so I want to give everyone a reminder to make sure they are distinguishing the difference between multiple single-threaded apps (multitasking) and single multiple-threaded apps (multithreading). HT was designed for multithreaded apps, while XP can support multiple physical processors effectively in a multitasking environment... I think this was the source of some contraditions and confusion, so I wanted to try and clear this up.
Justin West
Server Admin & Forum Moderator
Follow me on Twitter | Find us on Facebook
weblurker
Legit Little One
Legit Little One
Posts: 1
Joined: Wed Apr 13, 2005 10:37 pm

Post by weblurker »

Illuminati wrote:I've noticed that this discussion has veered slightly over the last few posts... so I want to reiterate something for everyone's benefit...
I may have missed this point in the review, but was the Pentium 640 set up with Hyperthreading enabled during the benchmarks against the Pentium 840?

If HT was turned on in the 640 (as I suspect it was), it might have been interesting to compare the non HT single cpu 640 against the non HT dual core 840.
teqguy
Legit Enthusiast
Legit Enthusiast
Posts: 42
Joined: Thu Apr 07, 2005 11:19 pm

Post by teqguy »

Considering that Hyperthreading hasn't changed between the processors, there might be no need for that.

The 90nm Smithfields are based on two Prescotts, with the only difference being that they went back to using lower latency 1MB cache per core, instead of the higher latency 2MB cache found in the 6xx series.
User avatar
Illuminati
Site Admin
Site Admin
Posts: 2378
Joined: Mon Oct 06, 2003 8:48 am
Location: Wright City, Missouri, USA
Contact:

Post by Illuminati »

weblurker wrote:I may have missed this point in the review, but was the Pentium 640 set up with Hyperthreading enabled during the benchmarks against the Pentium 840?

If HT was turned on in the 640 (as I suspect it was), it might have been interesting to compare the non HT single cpu 640 against the non HT dual core 840.
We did run some tests with HT off on the 640... but the differences were slim to none in most cases... we did notice a similar performance difference when running Folding@Home though... perhaps Apop still has some of those no HT 640 numbers that he can post up here.

So the answer to your question is that in the graphs, HT was turned on for the Intel 640 processor.
Justin West
Server Admin & Forum Moderator
Follow me on Twitter | Find us on Facebook
Post Reply