Single or multi-core?

[Alain Dekker]

If we have an industrial application (only one process the user needs to
interact with) that is extremally CPU-hungry (doing very high speed
numerical analysis of images) which machine would we be better off
standardising on:

* Intel single core Pentium 4 @ 3.60 GHz
* Intel Core 2 Duo @ 2.40GHz

?

Any comments appreciated. We can set the process priority for our
application high to try and force the thread scheduler to give our app more
CPU time, if thats a helpful comment.

Thanks,
Alain

 

[Thee Chicago Wolf [MVP]]

If we have an industrial application (only one process the user needs to

interact with) that is extremally CPU-hungry (doing very high speed
numerical analysis of images) which machine would we be better off
standardising on:

* Intel single core Pentium 4 @ 3.60 GHz
* Intel Core 2 Duo @ 2.40GHz

?

Any comments appreciated. We can set the process priority for our
application high to try and force the thread scheduler to give our app more
CPU time, if thats a helpful comment.

Thanks,
Alain

Core 2 Duo for sure. Far more advanced chip than P4 even at 3.6GHz.
Core 2 Duo would also give you some future-proofing.

- Thee Chicago Wolf [MVP]

 

[Alain Dekker]

Thanks for that comment. That was our initial feeling too, but something
worries me slightly: when I'm simulating loads of images through the
application and check Windows Task Manager (which shows a graph for both
CPUs) I note that one CPU (which is running our process) is close to maxxed
out, but the other is hardly moving (sitting aroud 2% or less).

Our process has about 12 threads running, and I'm not sure the Thread
Scheduler on the CPUs is able to tell one thread from the process to run on
CPU 1 and another to run CPU 2. As I understand it, the scheduler just tells
a process to run on CPU 1 or 2. All threadws from that process must then run
on that CPU. Am I correct on that?

Given that our process is the only thing the user needs to see, wouldn't
running 100% of 2.4GHz, even on a more advanced processor, be worse than
running 100% at 3.6GHz (but having to share a slightly higher share of CPU
time compared with the Duo Core with some Windows stuff)?

Thanks again for the comments!
Alain

 

[John John - MVP]

If the application is not written to take advantage of multiple cores
then it won't run any faster on a multi-core processor. As for the
processor speed (2.4Gz compared to 3.6Gz) that is not a reliable spec to
use when comparing processors from different families, other factors
have a play in the overall performance of the processor, not the least
being the length of the processor pipeline. AMD processors for example
have almost always run at a lower CPU cycle speed yet when compared to
competing Intel processors in the same class the Intels running at a
faster cycle are usually not any faster than the AMD processors, the
reason is that the pipeline on AMD processors has always been shorter.
Will a car going 100MPH (processor speed) on a 100 mile trip (pipeline)
arrive to destination before one going 60MPH on a 60 mile trip? That
being said you should still opt for the newer processor.

John

 

[Alain Dekker]

You guessed right, we haven't (yet) written our code to take advantage of
multiple cores. This is something we'll have to look at.

Thanks for the comments. I take your point about the AMD / Intel difference,
bus speeds, etc. I also know that processors differ in terms of their
floating point calculation speeds, multimedia processing, etc even when all
else is equal. Until we properly support multiple cores in the code, we'll
need to test the options carefully, with a strong bias towards the dual core
if the results from the 3.6 GHz are not spectacular.

Thanks,
Alain

 

[Alain Dekker]

If our app is not written to take advantage of multiple cores, is there
anything that can be done to speed it up on a multi-core machine? For
example, Task Manager allows you to set an "Affinity". Could this be used to
set our process affinity to CORE 1 (or 2) and all other processes to the
other CORE?

Thanks,
Alain

 

[Thee Chicago Wolf [MVP]]

If our app is not written to take advantage of multiple cores, is there

anything that can be done to speed it up on a multi-core machine? For
example, Task Manager allows you to set an "Affinity". Could this be used to
set our process affinity to CORE 1 (or 2) and all other processes to the
other CORE?

Thanks,
Alain

The only thing that would speed it up is a fast model CPU. Do you know
for certain what the highest model CPU your system is able to use?
There are variances in Core 2 Duo models such as more cache, FSB, etc.

- Thee Chicago Wolf [MVP]

 

[Bert Hyman]

In John John - MVP

If the application is not written to take advantage of multiple cores
then it won't run any faster on a multi-core processor.

I'm not sure what that means.

Any Windows application will have many threads, even if the application
developer doesn't explicitly create and dispatch threads in his own
code.

The OP says that his application is compute intensive but also has user
interaction, presumably through a GUI of some sort.

The Windows scheduler should be able to efficiently dispatch threads on
a multi-core (or multi-processor) platform.

 

[John John - MVP]

In John John - MVP


I'm not sure what that means.

Any Windows application will have many threads, even if the application
developer doesn't explicitly create and dispatch threads in his own
code.

The OP says that his application is compute intensive but also has user
interaction, presumably through a GUI of some sort.

The Windows scheduler should be able to efficiently dispatch threads on
a multi-core (or multi-processor) platform.

It might make the overall computer run faster if it is running multiple
tasks but it won't make a specific application run faster if the
application can't run and use multiple threads, the application must be
able to multi-thread to use multi-cores and many older applications
can't multi-thread, for that matter many of the newer ones still can't
multi-thread!

John

 

[Alain Dekker]

Our application is multi-threaded, does that mean the in-built Windows Task
Scheduler will correctly spread the threads over the cores? To be sure, the
main thread is the most CPU-intensive (doing all the image processing and
then display of the images) and that has not been written to support
multiple cores.

Alain

 

[Paul]

Not always. About 5 years ago, I worked for a company doing heavy-duty
signal processing. There was one algorithm that ran faster on a P4 HT
than a dual-core. (This was with Linux not XP)

And that's why, if you really need to know, you benchmark both solutions,
and see which is better.

At least one person on USENET, distributed a test executable, and
encouraged other people to run it and test it out. That way, he
was able to gather data, without buying a bunch of different processors.
So there are alternatives to buying hardware and running the test.
The test executable doesn't have to be a copy of the
actual application - it just needs to share the same kinds of
programming constructs and code density, and record an
execution time.

Paul

 

[Thee Chicago Wolf [MVP]]

Not always. About 5 years ago, I worked for a company doing heavy-duty
signal processing. There was one algorithm that ran faster on a P4 HT
than a dual-core. (This was with Linux not XP)

Well hold on, was it Core Duo or Core 2 Duo? Athlon dual-core, some
other dual core? What MHz? And comparing Linux to XP, come on. 321-bit
or 64-bit Linux? I've yet to see a benchmark that shows the fastest P4
knock out a Core 2 Duo.

- Thee Chicago Wolf [MVP]

 

[Alain Dekker]

It was a Intel Core 2 Duo 2.40 GHz. I'd like to compare its performance to a
P4 3.60 GHz, both running XP SP2 / 3. From what I've read the P4 could
easily outperform the Core 2 Duo if the main thread of your app was
massively sequential and computationally hungry (as our app is).

It seems that the best way forward, though, is to go with the multi-core
processor and work out a way to split up that hungry sequential processing
into sub-threads that the Windows scheduler can load onto what cores are
idle. This would better future-proof the application. Our application is not
something you use on a desktop while browsing the internet or listening to
music. Its a dedicated PC with a touchscreen used in factories to process
images at high frame rates.

Alain

 

[Thee Chicago Wolf [MVP]]

It was a Intel Core 2 Duo 2.40 GHz. I'd like to compare its performance to a
P4 3.60 GHz, both running XP SP2 / 3. From what I've read the P4 could
easily outperform the Core 2 Duo if the main thread of your app was
massively sequential and computationally hungry (as our app is).

It seems that the best way forward, though, is to go with the multi-core
processor and work out a way to split up that hungry sequential processing
into sub-threads that the Windows scheduler can load onto what cores are
idle. This would better future-proof the application. Our application is not
something you use on a desktop while browsing the internet or listening to
music. Its a dedicated PC with a touchscreen used in factories to process
images at high frame rates.

Here's a direct comparison between a Pentium 4 3.6GHz (and I even gave
it to you as a Prescott, not a Northwood, for the larger 2MB cache)
versus a Core 2 Duo E6600 2.40GHz. Prescotts ran hotter and, most say,
were worse performers than Northwoods.

http://www.tomshardware.com/charts/.../compare,392.html?prod[1262]=on&prod[1289]=on

It TROUNCES the Pentium 4 Prescott.

- Thee Chicago Wolf [MVP]

 

[choro]

And what was the difference between the two sir?

Should I drive the local shops in a battered but still ultra reliable VW
Beetle or in a temperamental Lamborghini? Which do you think will be faster
assuming I don't crash the Lamborghini by driving silly?!

 

[Patok]

It was a Intel Core 2 Duo 2.40 GHz. I'd like to compare its performance to a
P4 3.60 GHz, both running XP SP2 / 3. From what I've read the P4 could
easily outperform the Core 2 Duo if the main thread of your app was
massively sequential and computationally hungry (as our app is).

I can confirm that. One of my scientific programs (highly sequential), when
run on my old trusty 3.06 GHz P4 Northwood laptop, outperforms the 2.40 GHz
Core-2 64-bit workstation at work. Of course I can run 8 of them on the
workstation in parallel, but that's not the point.

It seems that the best way forward, though, is to go with the multi-core
processor and work out a way to split up that hungry sequential processing
into sub-threads that the Windows scheduler can load onto what cores are
idle. This would better future-proof the application. Our application is not
something you use on a desktop while browsing the internet or listening to
music. Its a dedicated PC with a touchscreen used in factories to process
images at high frame rates.

Indeed, I agree that this is the way to go. Especially since image processing
is /usually/ highly parallelizable. Maybe not in your particular case, since I
don't know what exactly you're doing with the images, but I doubt it.