Question

我写了一个宏来报告运行给定操作所需的时间。它运行了很多次，并以纳秒为单位打印出每次运行的时间。第一次运行总是比后续运行花费更多的时间。为什么会这样？

以下是10 x 10次运行的结果，时间Thread.yield()：

> (dotimes [x 10] (prn (times 10 (Thread/yield))))

[55395 1659 622 561 591 702 795 719 742 624]
[3255 772 884 677 787 634 605 664 629 657]
[3431 789 965 671 774 767 627 627 521 717]
[2653 780 619 632 616 614 606 602 629 667]
[2373 759 700 676 557 639 659 654 659 676]
[2884 929 627 604 689 614 614 666 588 596]
[2796 749 672 769 667 852 629 589 627 802]
[1308 514 395 321 352 345 411 339 436 315]
[1390 363 328 337 330 321 324 347 333 342]
[1461 416 410 320 414 381 380 388 388 396]

第一批的第一次运行非常慢，我想这是由于JIT第一次看到代码 - 足够公平。但是，所有后续批次中的第一次运行也明显慢于后续运行。为什么呢？

times宏的代码：

(defmacro time
  [expr]
  `(let [t1# (System/nanoTime)]
     ~expr 
     (- (System/nanoTime) t1#)))

(defmacro times
  [reps expr]
  `(loop [reps# ~reps times# []]
     (if (zero? reps#) 
       times#
       (recur (dec reps#) (conj times# (time ~expr))))))

Decompiling产生以下内容，因此System.nanoTime()似乎在Thread.yield()之前和之后直接调用，如预期所示：

> (decompile (dotimes [x 10] (prn (times 10 (Thread/yield)))))

...

public Object invoke() {
    long reps__1952__auto__2355 = 10L;
    Object times__1953__auto__2356 = PersistentVector.EMPTY;
    while (reps__1952__auto__2355 != 0L) {
        final long dec = Numbers.dec(reps__1952__auto__2355);
        final IFn fn = (IFn)const__3.getRawRoot();
        final Object o = times__1953__auto__2356;
        times__1953__auto__2356 = null;
        final long t1__1946__auto__2354 = System.nanoTime();
        Thread.yield();
        times__1953__auto__2356 = fn.invoke(o, Numbers.num(Numbers.minus(System.nanoTime(), t1__1946__auto__2354)));
        reps__1952__auto__2355 = dec;
    }
    final Object o2 = times__1953__auto__2356;
    times__1953__auto__2356 = null;
    return o2;
}

Answer 1

第一次运行总是比后续运行花费更多时间。为什么会这样？

您的基准测试结果还有另一个棘手的依赖因素：I / O.尝试一些返回时间向量而不是打印的测试运行，你会发现结果更符合这个：

installArm8Release

如果您在基准测试中使用(for [_ (range 10)] (times 10 (Thread/yield))) => ([32674 1539 1068 1063 1027 1026 1025 1031 1034 1035] [1335 1048 1030 1036 1043 1037 1036 1031 1034 1047] [1088 1043 1029 1035 1045 1035 1036 1035 1045 1047] [1051 1037 1032 1031 1048 1045 1039 1045 1042 1037] [1054 1048 1032 1036 1046 1029 1038 1038 1039 1051] [1050 1051 1039 1037 1038 1035 1030 1030 1045 1031] [1054 1045 1034 1034 1045 1037 1037 1035 1046 1044] [1051 1041 1032 1050 1061 1039 1045 1041 1057 1034] [1052 1042 1034 1032 1035 1045 1043 1038 1052 1052] [1053 1053 1041 1043 1053 1044 1039 1042 1051 1038])而不是System.out.println，则应该看到相同的减速行为，但更不夸张：

prn

Answer 2

即使使用比(Thread/yield)更低成本且更少IO限制的操作，您也可以看到此效果，例如常量表达式5：

user=> (doall (for [_ (range 10)] (times 10 5)))
[[390 132 134 132 109 86 94 109 115 112]
 [115 117 114 112 112 89 112 112 115 89]
 [117 106 109 109 109 86 109 109 111 109]
 [121 106 103 103 109 86 106 106 129 109]
 [117 109 106 109 112 95 111 112 109 89]
 [112 112 111 111 114 92 109 112 109 114]
 [118 111 112 111 115 88 112 109 115 92]
 [112 108 108 111 109 92 109 109 118 89]
 [115 106 112 115 112 89 112 109 114 89]
 [117 109 112 112 114 89 114 112 111 91]]

非常有趣，不是吗？第一个表达式总是最慢的，或者至少非常接近最慢的表达式，奇怪的是第六个和第十个表达式往往是最快的。为什么会这样？

我最好的猜测只是HotSpot的神秘力量。即使在这个非常简短的片段中，也会调用许多动态调度方法。你将conj称为IFn，也许HotSpot建立了一些信心，你的大多数IFn调用都将成为conj，因此它试图让这个用例更快;但是在每次迭代10结束时，还会调用一些其他函数，以附加到更大的结果列表，因此HotSpot会退出其优化，期望您将开始执行其他操作。

或许它根本不是HotSpot，而是与CPU缓存或操作系统的虚拟内存管理器进行一些交互，或者......

当然这个特定场景都是猜测，但重点是即使你编写非常简单的代码，你依赖大量非常复杂的系统来为你运行它，最终的结果基本上是不可知的而不需要投入对所涉及的每个系统进行了大量的研究。

为什么第一次运行总是慢得多？

2 个答案: