是什么导致一台 Vista 机器比另一台机器快 10 倍？
我们运行一个已经运行多年的 Fortran 控制台程序。最近，我们为办公室里的每个人购买了相同的新 HP 服务器级机器（4 个处理器、8 GB 内存、4 个硬盘）。我们对它们的配置与我们所知的几乎相同。我们可以在一台机器上编译 Fortran 程序，将可执行文件传递到不同的机器，在两台机器上它执行速度非常慢，而在另外两台机器上它的性能一般（但不如我们从 XP 机器升级之前那么好）。
它几乎不使用控制台输出（大约 40 行），但输出大约 15 兆文件。
我们打开任务管理器查看发生了什么，我们发现在速度较慢的机器上，它的 1 个 CPU 负载率约为 15%。在速度较快的机器上，所有 CPU 的负载率约为 40%（但其中一个似乎比其他 CPU 负载更多）。我记得，在 XP 上它的 CPU 负载达到 99%，并且运行速度更快。
这些机器是员工的通用机器，上面有很多公司的臃肿软件。它们的目录结构可能略有不同。但令我完全困惑的是为什么 Vista 不给他们更多的 CPU 时间。如果 CPU 正在加载，我可能会将性能差异归咎于不同的目录结构，但不加载 CPU 简直让我难以置信。
大卫
We run a Fortran console program we have run for years. Recently we purchased identical new HP server class machines (4 processors, 8 gig ram, 4 hard drives) for everyone in the office. We configured them identically as nearly as we know. We can compile the Fortran program on one machine, pass the executable to the different machines, and on two machines it executes painfully slow, while on two others it has modest performance (but not as good as before we upgraded from XP machines).
It uses almost no console output (about 40 lines) but outputs about 15 megs of files.
We open task manager to see what's going on, and we see that on the slow machines it's loading ONE CPU to about 15%. On the fast machines it's loading ALL CPUs to about 40% (but one of them seems to load more than the others). As I recall, on XP it loaded the CPU to 99%, and ran much faster.
These machines are the employees' general purpose machines, and have lots of company bloatware on them. And there is the possibility they have slightly different directory structures. But what seems totally puzzling to me is why Vista is not giving them more CPU time. If the CPUs were loading up, I might blame the performance variation on different directory structures, but not loading up the CPUs just boggles my mind.
David
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果 IO 存在瓶颈，CPU 的负载就不会那么多，因为它主要是在等待 IO 发生。如果由于等待之间有足够的时间而没有必要启动另一个 CPU，人们甚至可以想象这会导致一个 CPU 与多个 CPU 的问题。如果您拿一个外部硬盘并尝试在不同机器上的硬盘上运行相同的程序是否也会发生差异？
if there's a bottleneck in IO, the CPU wouldn't be loaded as much because it's mostly waiting for the IO to take place. One could even imagine this to cause the one CPU vs many CPUs problem if there's just no point in kicking in another CPU because there's plenty of time between while waiting. What if you take an external HD and try out if the differences also take place if you run the same program on that HD on different machines?
请进入Windows任务管理器，性能/ - 在[查看]中选择选项：[内核时间]并查看程序执行期间条形图上显示的内容。
如果四核+超线程盒上的负载仅为 15%，则基本上说明 OpenMP、MPI（或它使用的任何内容） - 无法正常工作 - 适用于 1/8 => 15%。您可以为您的特定系统运行 MPI-test 命令来检查每个机器上的多处理错误吗？因此，问题是 - 为什么多处理环境不起作用？
问候
rbo
Please go into Windows task manager, Performance / - Select in [View] the option: [Kernel Times] and look what's displayed on the bars during program execution.
If its only 15% load on quad+hyperthreading box, that says basically, OpenMP, MPI (or whatever it uses) - isn't properly working - works on 1/8 => 15%. Can you run the MPI-test command for your specific system in order to check for errors in multiprocessing on each box? Therefore, the question would be - why does the multiprocessing environment not work?
Regards
rbo
SWAG，但是您检查过您的病毒扫描程序配置吗？如果扫描仪未设置为忽略您在慢速计算机上写入的文件类型，则对这些文件的每次写入都可能在写入磁盘之前被拦截和扫描。这可能会导致进程处于 I/O 等待状态并且不能经常得到调度。
SWAG, but have you checked your virus scanner configuration? If the scanner isn't set to ignore the type of file you're writing on the slow machine, then each write to those files might be getting intercepted and scanned before being written to the disk. This could lead to the process sitting in I/O wait and not getting scheduled as often.
Vista有一些无法控制的内存泄漏问题，也许这是你的错误，“膨胀软件”中的一些冲突导致了内存泄漏，所以你的Fortran程序运行得慢得多？
我假设您已经在所有程序结束的情况下对此进行了测试。您的控制台程序似乎不太可能是问题所在。听起来肯定存在内存冲突。
Vista had a problem with some uncontrollably memory leaks, perhaps this is your error, some conflict in the "bloatware" is causing a memory leak and so your Fortran program is running so much slower?
I assume you have tested this with all programs ended. It seems unlikely that your console program is the issue. Sounds like there's definitely a memory conflict going on though.