I have a Win32 console application which is doing some computations, compiled in Compaq Visual Fortran (which probably doesn't matter).
我有一个Win32控制台应用程序正在进行一些计算,在Compaq Visual Fortran中编译(可能无关紧要)。
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.
在XP中,它们一起占用大约90-100%的CPU,工作速度非常快。在Vista中,无论我运行多少个,它们的CPU(一起)不超过10%,并且工作速度非常慢。
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...
有相当多的控制台输出正在进行,但现在非常多。我可以最小化所有窗口,它没有帮助。 CPU基本上什么都不做......
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
不,这些是不同的机器,但它们运行相同的硬件。 2.没有使用线程,这是一个非常老的(20岁)普通的DOS应用程序,在win32中编译。它应该计算迭代直到它们相遇,消耗它所拥有的全部。我的印象 - VISTA只是没有给它更多的CPU
6 个解决方案
#1
2
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:
如果你真的不关心输出,可以通过重定向到nul来丢弃它。例如:
c:\temp> dir > nul
#2
2
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."
Vista中有一个已知的“功能”,它将某些控制台应用程序限制为32MB RAM。我不知道Compaq Visual Fortran编译的那些是否会受到这个“功能”的影响。
This article appears to have been updated as recently as October 2008, so the problem still exists.
本文似乎最近在2008年10月更新,因此问题依然存在。
#3
1
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.
要阐述Daok的帖子 - 你的XP机器可能是这个过程的CPU绑定,而vista机器受到其他资源的约束。
To clarify: output to stdout (or other) can be slowing down the processing. (as can context switching or file access, etc)
澄清一下:输出到stdout(或其他)可能会减慢处理速度。 (可以上下文切换或文件访问等)
#4
1
As Tim hinted, console output (stdout) is EXTREMELY expensive.
正如蒂姆暗示的那样,控制台输出(stdout)非常昂贵。
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.
但我要看的主要区域是你的代码在两个操作系统环境中的编译方式是否存在显着差异 - 我想知道你的Fortran代码在Vista上运行时是否会产生某种特殊的惩罚,例如兼容性模式。看看Vista的支持程度以及是否可以专门针对Vista进行编译。还要查找报告类似问题的任何人,例如错误报告,功能请求等。
#5
1
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.
你的循环显然不是简单的计算。那里有一个阻塞系统调用。仅仅因为它在XP上运行并不意味着该应用程序没有错误。
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.
由于您可以最小化控制台窗口并且看不到任何改进,我不会认为这是一个问题。根据我的经验,控制台输出只有在控制台窗口绘制文本时才会减慢程序,而不是在最小化时。
#6
0
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?
它是Vista和XP上的相同机器硬件吗?它可能只使用Vista的10%,因为它不需要更多。你在使用Thread吗?我认为它需要有关您的项目的更多信息才能有更好的主意。您是否尝试使用分析器查看发生了什么?
#1
2
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:
如果你真的不关心输出,可以通过重定向到nul来丢弃它。例如:
c:\temp> dir > nul
#2
2
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."
Vista中有一个已知的“功能”,它将某些控制台应用程序限制为32MB RAM。我不知道Compaq Visual Fortran编译的那些是否会受到这个“功能”的影响。
This article appears to have been updated as recently as October 2008, so the problem still exists.
本文似乎最近在2008年10月更新,因此问题依然存在。
#3
1
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.
要阐述Daok的帖子 - 你的XP机器可能是这个过程的CPU绑定,而vista机器受到其他资源的约束。
To clarify: output to stdout (or other) can be slowing down the processing. (as can context switching or file access, etc)
澄清一下:输出到stdout(或其他)可能会减慢处理速度。 (可以上下文切换或文件访问等)
#4
1
As Tim hinted, console output (stdout) is EXTREMELY expensive.
正如蒂姆暗示的那样,控制台输出(stdout)非常昂贵。
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.
但我要看的主要区域是你的代码在两个操作系统环境中的编译方式是否存在显着差异 - 我想知道你的Fortran代码在Vista上运行时是否会产生某种特殊的惩罚,例如兼容性模式。看看Vista的支持程度以及是否可以专门针对Vista进行编译。还要查找报告类似问题的任何人,例如错误报告,功能请求等。
#5
1
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.
你的循环显然不是简单的计算。那里有一个阻塞系统调用。仅仅因为它在XP上运行并不意味着该应用程序没有错误。
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.
由于您可以最小化控制台窗口并且看不到任何改进,我不会认为这是一个问题。根据我的经验,控制台输出只有在控制台窗口绘制文本时才会减慢程序,而不是在最小化时。
#6
0
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?
它是Vista和XP上的相同机器硬件吗?它可能只使用Vista的10%,因为它不需要更多。你在使用Thread吗?我认为它需要有关您的项目的更多信息才能有更好的主意。您是否尝试使用分析器查看发生了什么?