【问题标题】:System.nanoTime() returns continuously decreasing times over several runs of QuickSort, how?System.nanoTime() 在 QuickSort 的几次运行中返回连续递减的时间,如何?
【发布时间】:2018-03-02 19:04:42
【问题描述】:

我实现了一个标准的快速排序算法,并在多次运行中对其进行了测试,并将运行时间存储在一个数组中。

int max = 100;
int runs = 1000;
int[] arr = new int[max];
Long[] times = new Long[runs];  

while(n < runs){
        for(int i =0 ; i<max; i++){
        arr[i]=(int)(Math.random()*99);
        //arr[i] = i;  
        }

        Long start = System.nanoTime();
        quicksortsimple(arr,0,max-1);
        Long now = System.nanoTime();

        times[n++] = now-start;
    }

现在发生的情况是,输出的“times”数组以更大的值开始并逐渐减小,在第 100 个索引(快速排序 100 次运行)之后,它变得有点恒定,但这个值小于初始 2 的十分之一-3 值。 n= 1000 返回的平均值在程序的几个 rune 中是相同的。

即使我将数组初始化为已经排序(注释掉的行),同样的事情也会发生,尽管需要更多的平均时间(因为它应该)。

但这不应该为同一个数组上的同一个算法返回如此不同的运行时间。如果有的话,递减模式表示什么?

【问题讨论】:

标签: java performance timestamp quicksort nanotime


【解决方案1】:

(下面的解释并不完全到最后的细节,但足以理解是怎么回事)

一开始,您的 JRE 以解释模式(慢)运行程序,直到它的 Hotspot 引擎检测到排序值得加速并创建一个本地编译的翻译,然后使用它并且运行速度比解释的快得多第一次迭代的代码。

【讨论】:

  • 所以应该有一个“点”或 JRE 改变其模式的一些离散点集。但是,我使用 1000 的 times[] 数组,结果“不断”下降,其间有一些起伏。这是什么意思?您能否详细说明可能发生的情况?这似乎很有趣。
  • Hotspot 编译并不是影响性能的唯一因素,但通常是最突出的因素。优化不一定是一步完成的。例如。除了quicksortsimple() 方法之外,还有Math.random() 经常被调用,还有你的外循环。它们中的每一个都是独立原生编译的候选者,最后 Hotspot 引擎甚至可能将它们全部内联到一个大型原生代码中。当像 Hotspot 这样的后台任务不再消耗 CPU 等等时,处理器的缓存会更频繁地命中......
猜你喜欢
  • 2015-03-29
  • 1970-01-01
  • 2022-11-25
  • 2021-11-09
  • 1970-01-01
  • 2011-10-12
  • 1970-01-01
  • 1970-01-01
  • 2018-06-23
相关资源
最近更新 更多