3

这是一个相当普遍的问题：

我遇到的问题是，time.clock()现在测量的相同操作比以前需要更长的时间。

虽然我有一些非常相似的测量结果

  • 1954年代
  • 1948年代
  • 1948年代

一种略有不同的测量

  • 1999年代

另一个更不同的

  • 2207秒

它似乎或多或少还可以，但对于另一个我得到

  • 2782秒

现在我正在重复测量，它似乎变得越来越慢。

在四舍五入或进行其他奇怪的操作后，我不会对测量值求和。

您是否知道这是否会受到服务器繁忙程度、时钟速度或任何其他可变参数的影响？我希望使用time.clock()而不是time.time()主要解决这些问题......

操作系统是Ubuntu 18.04.1 LTS.

这些操作在单独的screen会话中运行。

这些操作不涉及硬盘访问。

这些操作大多numpy是非分布式的操作。所以这实际上主要是正在执行的 C 代码。

编辑：这可能是相关的：在任何情况下，测量time.time()和time.clock()非常相似。也就是说，time.time()测量值总是略长于time.clock()。time.clock()因此，如果我没有遗漏任何东西，那么原因几乎与on完全相同time.time()。

编辑：我认为我的问题没有得到回答。我能想到的另一个原因是垃圾收集会增加 CPU 使用率，并且在 RAM 已满或即将满时更频繁地进行。

主要是，我正在寻找一种替代措施，它为完成的相同操作提供相同的数字。操作意味着我的算法以相同的开始状态执行。有没有一种简单的方法来计算 FLOPS 或类似的？

4

2 回答 2

0

由于在不同的“系统状态”下重复运行相同的算法，我总结一下这个问题的答案是：

是的，time.clock()可能会受到系统状态的严重影响。

当然，这更适用于time.time().

一般的原因可能是

  1. 相同的 Python 代码并不总是导致向 CPU 发送相同的命令——也就是说，这些命令不仅取决于代码和启动状态，还取决于系统状态（即垃圾收集）
  2. 系统可能会干扰从 Python 发送的命令，从而导致额外的 CPU 使用（即通过核心切换）仍然被计算在内time.clock()

差异可能非常大，在我的情况下约为50%。

目前尚不清楚哪些是具体原因，也不清楚每个原因对问题的影响有多大。

timeit对于上述部分或全部要点是否有帮助仍有待测试。但是timeit，它用于基准测试，可能不建议在正常处理期间使用。它关闭垃圾收集并且不允许访问定时函数的返回值。

于 2019-09-11T08:12:51.503 回答
0

这个问题似乎与 Python 和 Ubuntu 有关。

尝试以下操作：

  • 检查您是否拥有正在使用的 Python 版本的最新稳定版本Link 1

  • 检查进程列表，还可以查看您的 python 可执行文件在哪个 cpu 内核上运行。

  • 检查 cpu Link 2 , Link 3上的线程优先级状态

笔记：

  • 时间可能会因进程切换、线程和其他操作系统资源管理和应用程序代码执行而有所不同（这是无法控制的）

建议：

  • 这可能是因为您的系统构建，尝试在另一台机器或虚拟机上运行您的代码。

阅读：

祝你好运。

~ 迪恩·范格南

于 2019-09-09T16:10:27.620 回答