为什么矮小的效率不成比例？

Question

我一直在比较numpy和Python列表理解在将随机数数组相乘时的相对效率。(Python3.4/Spyder，Windows和Ubuntu)

正如人们所预期的那样，对于除最小数组之外的所有数组，numpy的性能都比列表理解好，并且对于增加数组长度，您可以得到预期的sigmoid曲线以提高性能。但是乙状结肠远非光滑，我很难理解。

显然，对于较短的阵列长度，存在一定数量的量化噪声，但我得到了意想不到的噪声结果，特别是在Windows环境下。这些数字是各种数组长度的100次运行的平均值，因此应该可以消除任何短暂的影响(我也是这么想的)。

​

​

Numpy and Python list performance comparison

下图显示了使用numpy与列表理解相乘的不同长度数组的比率。

Array Length    Windows     Ubuntu
           1        0.2        0.4
           2        2.0        0.6
           5        1.0        0.5
          10        3.0        1.0
          20        0.3        0.8
          50        3.5        1.9
         100        3.5        1.9
         200       10.0        3.0
         500        4.6        6.0
       1,000       13.6        6.9
       2,000        9.2        8.2
       5,000       14.6       10.4
      10,000       12.1       11.1
      20,000       12.9       11.6
      50,000       13.4       11.4
     100,000       13.4       12.0
     200,000       12.8       12.4
     500,000       13.0       12.3
   1,000,000       13.3       12.4
   2,000,000       13.6       12.0
   5,000,000       13.6       11.9

因此，我想我的问题是，谁能解释为什么结果，特别是在Windows下是如此嘈杂。我已经多次运行测试，但是结果似乎总是完全相同的。

最新消息。在Reblochon的建议下，我已经禁用了葡萄收藏。这在一定程度上降低了Windows的性能，但曲线仍然不稳定。

​

​

Numpy and Python list performance comparison
(Updated to remove garbage collection)

Array Length    Windows     Ubuntu
           1        0.1        0.3
           2        0.6        0.4
           5        0.3        0.4
          10        0.5        0.5
          20        0.6        0.5
          50        0.8        0.7
         100        1.6        1.1
         200        1.3        1.7
         500        3.7        3.2
       1,000        3.9        4.8
       2,000        6.5        6.6
       5,000       11.5        9.2
      10,000       10.8       10.7
      20,000       12.1       11.4
      50,000       13.3       12.4
     100,000       13.5       12.6
     200,000       12.8       12.6
     500,000       12.9       12.3
   1,000,000       13.3       12.3
   2,000,000       13.6       12.0
   5,000,000       13.6       11.8

更新

在@Sid的建议下，我将其限制为在每台机器上运行一个核心。曲线稍微平滑一些(尤其是Linux )，但仍然带有一些不灵活和一些噪音，特别是在Windows环境下。

(这实际上是我最初要发布的不灵活之处，因为它们总是出现在相同的地方。)

Numpy and Python list performance comparison
(Garbage collection disabled and running on 1 CPU)

Array Length    Windows     Ubuntu
           1        0.3        0.3
           2        0.0        0.4
           5        0.5        0.4
          10        0.6        0.5
          20        0.3        0.5
          50        0.9        0.7
         100        1.0        1.1
         200        2.8        1.7
         500        3.7        3.3
       1,000        3.3        4.7
       2,000        6.5        6.7
       5,000       11.0        9.6
      10,000       11.0       11.1
      20,000       12.7       11.8
      50,000       12.9       12.8
     100,000       14.3       13.0
     200,000       12.6       13.1
     500,000       12.6       12.6
   1,000,000       13.0       12.6
   2,000,000       13.4       12.4
   5,000,000       13.6       12.2

​

​

Answer 1

垃圾收集器解释了其中的大部分。其余的可能是基于运行在您的机器上的其他程序的波动。把大部分的东西关掉，运行最小值并进行测试，怎么样？由于您使用的是日期时间(这是所传递的实际时间)，所以它还必须考虑到任何处理器上下文切换。

您也可以尝试在使用unix调用将其附加到处理器上时运行它，这可能有助于进一步平滑它。在Ubuntu上可以这样做：https://askubuntu.com/a/483827

对于windows，处理器关联可以这样设置：http://www.addictivetips.com/windows-tips/how-to-set-processor-affinity-to-an-application-in-windows/

Answer 2

根据我的评论：

通常，垃圾收集会解释bnchmark性能测试中的噪音；禁用它来运行测试是可能的，并且在某些条件下，可以平滑结果。

下面是一个链接，指向如何以及为什么禁用GC：Why disable the garbage collector?

在GC之外，运行基准测试总是很棘手的，因为系统上运行的其他进程可能会影响性能(网络连接、系统备份等)。这可能是自动化的，并在后台悄悄的运行)；也许您可以重新尝试使用一个新的系统启动，以及尽可能少的其他进程来查看它是如何进行的？