views:

638

answers:

6

I have a Win32 console application which is doing some computations, compiled in Compaq Visual Fortran (which probably doesn't matter).

I need to run a lot of them simultaneously.

In XP, they take around 90-100% CPU together, work very fast. In Vista, no matter how many of them I run, they take no more than 10% of CPU (together), and work very slow respectively.

There is quite a bit of console output going on, but now VERY much. I can minimize all the windows, it does not help. CPU is basically doing nothing...

Any ideas?

Update:

No, these are different machines, but they run relatively the same hardware. 2. Threads are not used, this is a VERY OLD (20 yrs) plain app for DOS, compiled in win32. It is supposed to compute iterations until they meet, consume all it has. My impression - VISTA just does NOT GIVE IT MORE CPU

A: 

Is it the same machine hardware on your Vista and XP? It might use just 10% of the Vista because it doesn't require more. Are you using Thread? I think it requires more information about your project to have a better idea. Have you try to use a profiler to see what's going on?

Daok
1. No, these are different machines, but they run relatively the same hardware.2. Threads are not used, this is a VERY OLD (20 yrs) plain app for DOS, compiled in win32. It is supposed to compute iterations until they meet, consume all it has. My impression - VISTA just does NOT GIVE IT MORE CPU..
badbadboy
Impressions aren't measurement, unfortunately.
Greg D
+1  A: 

To expound on Daok's post - your XP machine might be CPU bound for this process, whereas the vista machine is bound by some other resource.

To clarify: output to stdout (or other) can be slowing down the processing. (as can context switching or file access, etc)

Tim
Posted a comment to Daok's post. About "bound" - is there a way to "bound" VISTA to these processes? The thing is - the processes are running long loops without sleep or anything. So they just don't get more CPU. But the rest - 90% CPU - goes to System idle!.. :)
badbadboy
+2  A: 

Have you tried redirecting the console output to a file? If your applications are being held up writing to the console (this happens sometimes unfortunately) then redirecting the output should help, as it's much quicker to write to a simple file than write to the console.

You do this like so

c:\temp> dir > output.log

If you really don't care about the output at all, you can throw it away, by redirecting to nul. eg:

c:\temp> dir > nul
Orion Edwards
It is amazing that file writes (well, cached, then written) can be faster than console output.
Tim
Amazing, but I'm pretty sure (don't have time to run benchmarks) that it's true :-)
Orion Edwards
+1  A: 

As Tim hinted, console output (stdout) is EXTREMELY expensive.

I suggest rerunning your test while redirecting the console output to a separate log file for each process. If possible, tune down the verbosity of the output in another test run.

Beyond that, there are other obvious possibilities: is the hardware significantly different, are there other major processes running, is there a shared resource that is under contention?

Other than the obvious, look for a nonobvious resource contention such as a shared file.

But the main area where I would look is whether there is a significant difference in how your code is compiled for the two OS environments--I wonder if your Fortran code is incurring some kind of special penalty when running on Vista, such as a compatibility mode. Look to see how well Vista is supported and whether you can target your compile for Vista specifically. Also look for anyone reporting similar issues, such as in bug reports, feature requests, etc.

Rob Williams
Vista is not supported...program created 20 years ago :)...used in narrow scientific surroundings..Thanks for the suggestions.
badbadboy
+2  A: 

There was a known "feature" in Vista that limits certain console applications to 32MB of RAM. I don't know if those compiled by Compaq Visual Fortran are affected by this "feature."

This article appears to have been updated as recently as October 2008, so the problem still exists.

R. Bemrose
+1  A: 

Your loops are obviously not simple computations. There is a blocking system call in there somewhere. Just because it worked on XP doesn't mean the app is bug free.

Since you can minimize the console windows and see no improvement, I would not consider that an issue. In my experience console output slows a program down only if the console window is drawing text, not when it's minimized.