Maximum CPU usage

[vectorg]

I have some number-crunching applications that I want to run as fast as possible. I'm running XP with a core-2 duo processor.

When I start an application, the task-manager tells me that the application is using about 50% of the CPU. When I start a second instance of the same application, the task manager tells me that each application is using half the CPU for a total of 100% usage. If I start a third instance of the same application, the task manager shows that the CPU use of the 3 applications totals around 100%.

I get no additional CPU processing power by running more than 2 applications.

Windows performed this same way when I had only a single-core processor. What does it really mean to have a dual, quad, or octa-core processor under Windows?

I've tried multi-threading in the application code, but it ran only slower.

What is the best CPU/Windows setup to run pure number-crunching applications?

Thanks.

 

[hellwig]

Ar you trying to get more than 100%, its a little confusing.

Windows reports CPU usage as a percentage of total CPU power. Since you have a dual core processor, 50% is utilizing one single core 100%. When you start a second instance, and it uses 50%, it is using 100% of the second core. This is as much as your computer can handle, being that it only has 2 cores. Starting more than 2 applications means at least 2 will have to share a core, just like 2 apps running on a single-core CPU.

The reason it slows-down with multi-threading is probably due to innefficient code threading. If one thread constantly has to wait for the other, it would only slow the system down, regardless of how many cores the CPU has.

I had this problem running ffmpeg (I have an Athlon X2, not a Core 2), one instance using 2 threads for a single file was slower than 2 instances running on separate files. When burning DVDs with my Nero software, the software only manages about 70% processor usage (single app, multi-threaded). However, my BeyondTV mpeg-to-divx encoding runs around 95%. Some data just can't be split efficiently enough to use two cores at one time.

Do you want to run one app across multiple cores? If so, the app simply needs to be coded with multi-threading in mind, and coded efficiently. If you instead want to run multiple apps at once, then your computer is currently utilizing the processor to its fullest potential.

Windows is designed more for multi-tasking (multiple applications), than multi-threading (one application, multiple threads). It does a decent job handling multi-threaded apps, and I've heard Vista and 7 should be even better. However, if the machine is only used for number crunching, you are better off using a customized linux, unix, or BSD kernel.

 

[vectorg]

Thanks hellwig, no I know 100% is the limit.

With my Pentium-4 processor, I can run 2 instances of the application, and each gets 50% of the CPU, and each runs at 3GHz. That's good.

Then, what I expected from a dual-core processor is that I would be able to open 4 application instances, each getting 50% of a CPU, and all running at 3GHz. (double the processing power of a single-core processor)

My dual-core processor acts like my single-core CPU.

My goal with this post is to decide if I should get a quad-core or higher Intel processor, and thus be able to run many applications just as if I had many PCs sitting on my desk.

If I get a quad-core, will I still see my app getting 50% of the CPU, then a second app getting the other 50%... just like a single-core?

Thanks.

 

[maxchirag]

Hello,

I have similar problem with my application,

I am developing an application in QT, C++ on WindowsXp.

My problem is i have module which compiles my DOM Document, applies some more logic on that and writes different binary files. but when i have big DOM document the CPU usage goes maximum (50% in my core 2 Due processor). and the tool performance is very bad

I m trying to improve the performance of the application by trying to utilize both cores for processing and writing files in parallel.

my impression before reading this thread was like , "windows allows one process to execute on only one core and restricts its instructions to go on other core just to save the CPU for other processes and windows itself."

to solve that problem i have decided to fork the child processes from main process and handle file generation in child processes. (to achive multi-core utilization).

but as i read here, multi-threading can utilize both the cores too. is that really true? if i have multiple threads (all doing diff task) at the same time in on process, will then windows let my process (threads) utilize both the cores? the reason i m asking this is, if this solves the problem i can easily change my program to go for multi-threading, but in case of multi-tasking i have implement IPC and its lots of headache too.

another question is, is there any performance diff in case of multi-threading and multi-tasking? if yes, then approximately how much? because performance is important to me rather then writing code headache.

one more question, does forking child processes and handling IPC also add overhead to my task?

thanks!, waiting for reply

 

[hellwig]

vectorg: sorry, must not have turned on email notifications for this thread, I hope you went with the quad-core anyway, you couldn't really go wrong.

maxchirag: As far as I know, threads CAN span across cores.

The overhead with processes is that each has its own address space, this means each has its own copy of the parent processes memory, and runs separately from the parent process. This means the OS has to swap between the two processes, though with enough memory and multiple cores, you eliminate most (or all) of this swapping (you still have to worry about other processes running in the system, but this is always a concern).

With threads, they share the same address space, and execute AS the "parent" thread. There's no swapping between processes. However, with multiple cores, the OS must ensure that each core's cache contains the correct version of memory. If one thread writes to the shared memory space, this must be propagated to the other core. Modern OSes and processors are optimized to mitigate most negative effects of this propagation, there shouldn't be too noticeable a penalty.

As for IPC overhead, the only difference is shared memory access. With threads, this is "built-in", you just have to manage the access with semaphores or mutexs. With processes, you'll have to use some special API or library to enable shared memory, which could be more difficult to setup (I have limited experience with this). If you use semaphores or sockets for IPC, there really shouldn't be any difference between threads or processes.

Personally, I would use threads, I can't think of any advantages processes have over threads, except that a forked process can survive if the parent or sibling process dies (with threads, there is only one process total). However, if you have issues with processes dying, you should just solve those. To prevent one thread from affecting the other, you should use event handlers to capture and contain faults, its just good programming practice.