I have a c++ program (compiled with visual studio 2010 for windows x64) which does some mathematical optimization and has no interactive elements (the (single) process is just started via console and ends when the optimization is done). The runtime depends on the given input, and can be for example ca. 4 minutes.

When i run this process on my machine (Dell Latitude E6420, Intel Core i7-2720QM 2,2 Ghz, 8GB RAM, Windows 7 (64bit)) it uses 13% of the whole cpu (that should be correct since it can also use one single core). The problem is, that it runs more than 4 to 8 times slower than on another Dell Latitude E6420 (with exactly the same stats and even mostly same installed software) while using the resources of one core. For example: The process runs 20 minutes on my machine but 4 minutes on the other.

There are no other processes running except for system processes (CPU usage is nearly 0% except for the running c++ process).

Numerical errors or other mathematical problems are out of question, it is verified that the algorithm does exactly the same on both machines, only slower (while having exactly the same processor usage (=13%).

I want to avoid re-installing Windows, so the question is, could there be other reasons, like defect hardware, wrong bios settings etc.? All drivers are up to date.

Any idea what can cause this extreme difference in running time?

  • You need to reinstall Windows to rule out that possability. Once you do that and its still a problem come back and we can attempt to figure it out. Of course without the code thats unlikely to be possible. – Ramhound Jun 12 '12 at 14:26
  • 1
    Do you have SpeedStep and TurboBoost enabled in the BIOS for both machines? You might try CPU-Z and verify that the processors are actually running at the same clockspeed (Bottom left section, "Core Speed"). Also, do they have the same speed memory (CPU-Z -> Memory Tab -> Timings -> DRAM Frequency)? – Darth Android Jun 12 '12 at 14:29
  • Are you running X32 program on X64 system? i had such problem in the past and reason was that compatibility mode in windows is slow. – Maxwell S. Jun 12 '12 at 14:46
  • @Maxwell Actually, I tried both, compiling with x32 and with x64 setting. Both versions are extremely slower than on the other machine. I use 64 bit windows... – Sebastian Jun 12 '12 at 15:00
  • @DarthAndroid Thanks, I will check that and edit the post! – Sebastian Jun 12 '12 at 15:02

You write that both machines are Dell Latitude E6420's. Since both have the same hardware you should be able to swap the harddrives. That way you can detect if the problems in the software without reinstalling.

Other things to check are BIOS settings (same settings and same version of the BIOS).

If neither of the two yields any results check the harddrives. Both the model and the event viewer in windows (read errors will be logged).

Lastly, monitor the CPUs with CPU-Z.

  • Swapping the harddrives was a good idea, it turned out that the process is slow even with the hardware on the other machine! So I think re-installing windows is unavoidable... (BIOS settings and CPU-Z values are the same anyway) – Sebastian Jun 13 '12 at 15:29

It could be a power saving setting that's causing the governor to clock the CPU lower on the slower machine.

  • 2
    I recently spent 3 days with a machine running at 700Mhz because of a BIOS setting related to this :( It was not fun (and I didn't know this was the issue until the 3rd day). – Darth Android Jun 12 '12 at 15:05
  • @DarthAndroid What BIOS setting was that? – Sebastian Jun 12 '12 at 15:29
  • Thanks for the hint, I checked the power settings from windows on both machines, but they are exactly the same, and both notebooks are plugged in all the time. – Sebastian Jun 12 '12 at 15:32
  • @Sebastian I'm still not entirely sure. The system started to SpeedStep properly... after I disabled SpeedStep in the BIOS. Part of me wants to investigate, but the other part of me is just happy to not spend 20+ minutes to do a single build of our software product, and is content to leave things alone :X – Darth Android Jun 12 '12 at 15:43
  • 2
    The CPU may be getting throttled. Is the problem machine running hotter? – Synetech Jun 12 '12 at 20:51

Are you running the program the same way on both machines? You say it's slower on your machine - are you running it from within DevStudio (i.e. Debug->Start Without Debugging, or whatever it's called)? This could slow the process down as it's started in a slightly different context than it would be if it were just run from the command line / shell.

  • No, I run the exact same compiled executable file (which is compiled as release version with no debug information) started from the command line. – Sebastian Jun 12 '12 at 15:26
  • +1 for at least bringing up the fact the VS debug mode is MUCH slower in performance. – Chad Harrison Jun 12 '12 at 21:03

You said that the program is using just one core, but that does not necessarily limit it to 1/N of the processing power. It may be multi-threaded (especially since it is a modern program written in VS2010), so one system may be artificially limiting it.

If a program appears to be stunted and using less of the CPU than it should be (especially when compared to the same program running on another system), check the CPU affinities:

  1. Run the program
    • Press Pause in the console window if necessary (i.e., if it closes too fast)
  2. Open the Task Manager
  3. Right-click the program's process and select Set Affinities
  4. Make sure that all cores/CPUs/threads are selected (i.e., click )
  5. [OK]

The program should now use as much of the processing power as it is capable of using (this depends on the nature of the process).

  • all core affinities are selected, but still, this is a single threaded c++ program and uses only one core (=13%) for the time consuming optimization algorithm. The usage of the processor is not the problem, since it's the same on the other machine. The problem is that both processes use the exact same amount of the same cpu (the complete available amount) but still the other one is extremly slower... – Sebastian Jun 12 '12 at 20:24
  • So if you view the CPU graph for the program on both systems, they both look about the same (i.e., their heights), except that one is ~4x longer? – Synetech Jun 12 '12 at 20:50
  • I did not compare the graphs exactly, only the usage (which was constantly 12-13% while it was running), and yes, one of them is at least 4 times longer though doing exactly the same procedures and memory allocations and producing the same result etc. – Sebastian Jun 12 '12 at 20:59

The reason could be that on the slower machine the advanced debugging was activated (f.e. for a heap corruption debugging). To see the processes for which this debugging is enabled, open "Global Flags" application (Start -> All Programs -> Debugging Tools For Windows (x64)), go to "Image File" tab and type the program name (NOTE! use "Tab" button to refresh) and make sure that no flags are set Global Flags. The other option is to open command line and type "gflags /p", it will show the list of all the programs with advanced debugging (your program should not be there). More on this https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/gflags-overview

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.