11---
2- layout : multipage- overview
2+ layout : overview-large
33title : 测量性能
44
5- discourse : false
5+ disqus : true
66
77partof : parallel-collections
8- overview-name : Parallel Collections
9-
108num : 8
119language : zh-cn
1210---
1311
14- ## 在JVM上的性能
12+ ### 在JVM上的性能
1513
1614对JVM性能模型的评论常常令人费解，其结论也往往不易理解。由于种种原因，代码也可能不像预期的那样高性能、可扩展。在这里，我们提供了一些示例。
1715
18- 其中一个原因是JVM应用程序的编译过程不同于静态编译语言（见[[ 2]] ）。Java和Scala的编译器将源代码转换为JVM的字节码，做了非常少的优化。大多数现代JVM，运行时，会把字节码转化成相应机器架构的机器代码。这个过程被称为即时编译。由于追求运行速度，所以实时编译的代码优化程度较低。为了避免重新编译，所谓的HotSpot编译器只优化了部分经常被运行的代码。这对于基准程序作者来说，这意味着程序每次运行时的性能都可能不同。在同一个JVM实例中多次执行一段相同的代码（比如一个方法）可能会得到非常不同的性能结果，这取决于这段代码在运行过程中是否被优化。另外，在测量某些代码的执行时间时其中可能包含JIT编译器对代码进行优化的时间，因此可能得到不一致的结果。
16+ 其中一个原因是JVM应用程序的编译过程不同于静态编译语言（见[[ 2] ( http://www.ibm.com/developerworks/library/j-jtp12214/ ) ]
1917
2018另一个在JVM上隐藏执行的是内存自动管理。每隔一段时间，程序的运行就被阻塞并且启动垃圾收集器。如果被进行基准测试的程序分配了任何堆内存（大部分JVM程序都会分配），垃圾收集器将会工作，因此可能会影响测量结果。为了缓冲垃圾收集的影响，被测量的程序应该运行多次以便触发多次垃圾回收。
2119
2220性能恶化的常见原因之一是将原始类型作为参数传递给泛型方法时发生的隐式装箱和拆箱。在运行时，原始类型被转换为封装对象，这样它们就可以作为参数传给有泛型类型参数的方法。这会导致额外的空间分配并且运行速度会更慢，也会在堆中产生额外的垃圾。
2321
2422就并行性能而言，一个常见的问题是存储冲突，因为程序员针对对象的内存分配没有做明确的控制。事实上，由于GC的影响，冲突可以发生在应用程序生命期的最后，在对象被移出内存后。在编写基准测试时这种影响需要被考虑到。
2523
26- ## 微基准测试的例子
24+ ### 微基准测试的例子
2725
2826有几种方法可以在测试中避免上述影响。首先，目标微基准测试必须被执行足够多次来确保实时编译器将程序编译为机器码并被优化过。这就是所谓的预热阶段。
2927
@@ -33,9 +31,43 @@ language: zh-cn
3331
3432最后，为了减少在基准测试中间发生垃圾回收的可能性，理想的垃圾回收周期应该发生在基准测试之前，并尽可能的推迟下一个垃圾回收周期。
3533
36- 正确基准的范例，你可以参考在[ Scala library benchmarks] [ 3 ] 的源代码。
34+ scala.testing.Benchmark trait 是在Scala标准库中被预先定义的，并按前面提到的方式设计。下面是一个用于测试并行算法中映射操作的例子：
35+
36+ import collection.parallel.mutable.ParTrieMap
37+ import collection.parallel.ForkJoinTaskSupport
38+
39+ object Map extends testing.Benchmark {
40+ val length = sys.props("length").toInt
41+ val par = sys.props("par").toInt
42+ val partrie = ParTrieMap((0 until length) zip (0 until length): _*)
43+
44+ partrie.tasksupport = new ForkJoinTaskSupport(new scala.concurrent.forkjoin.ForkJoinPool(par))
45+
46+ def run = {
47+ partrie map {
48+ kv => kv
49+ }
50+ }
51+ }
52+
53+ run方法包含了基准测试代码，重复运行时测量执行时间。上面的Map对象扩展了scala.testing.Benchmark trait，同时，参数par为系统的并行度，length为trie中元素数量的长度。
54+
55+ 在编译上面的程序之后，可以这样运行：
56+
57+ java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=1 -Dlength=300000 Map 10
58+
59+ server参数指定需要使用server类型的虚拟机。cp参数指定了类文件的路径，包含当前文件夹的类文件以及以及scala类库的jar包。参数-Dpar和-Dlength分别对应并行度和元素数量。最后，10意味着基准测试需要在同一个JVM中运行的次数。
60+
61+ 在i7四核超线程处理器上将par的值设置为1、2、4、8并获得对应的执行时间。
3762
38- ## 多大的容器才应该使用并发？
63+ Map$ 126 57 56 57 54 54 54 53 53 53
64+ Map$ 90 99 28 28 26 26 26 26 26 26
65+ Map$ 201 17 17 16 15 15 16 14 18 15
66+ Map$ 182 12 13 17 16 14 14 12 12 12
67+
68+ 我们从上面的结果可以看到运行时间在最初的几次运行中是较高的，但是在代码被优化后时间就缩短了。另外，我们可以看到在这个例子中超线程带来的好处并不明显，从4线程到8线程的结果说明性能只有小幅提升。
69+
70+ ### 多大的容器才应该使用并发？
3971
4072这是一个经常被问到的问题。答案是有些复杂的。
4173
@@ -49,13 +81,101 @@ collection的大小所对应的实际并发消耗取决于很多因素。部分
4981- 副作用。当同时修改内存区域或者在foreach、map等语句中使用同步时，就会发生竞争。
5082- 内存管理。当分配大量对象时垃圾回收机制就会被触发。GC循环会消耗多长时间取决于新对象的引用如何进行传递。
5183
84+ 即使单独的来看，对上面的问题进行推断并给出关于容器应有大小的明确答案也是不容易的。为了粗略的说明容器的应有大小，我们给出了一个无副作用的在i7四核处理器（没有使用超线程）和JDK7上运行的并行矢量减（在这个例子中进行的是求和）处理性能的例子：
85+
86+ import collection.parallel.immutable.ParVector
87+
88+ object Reduce extends testing.Benchmark {
89+ val length = sys.props("length").toInt
90+ val par = sys.props("par").toInt
91+ val parvector = ParVector((0 until length): _*)
92+
93+ parvector.tasksupport = new collection.parallel.ForkJoinTaskSupport(new scala.concurrent.forkjoin.ForkJoinPool(par))
94+
95+ def run = {
96+ parvector reduce {
97+ (a, b) => a + b
98+ }
99+ }
100+ }
101+
102+ object ReduceSeq extends testing.Benchmark {
103+ val length = sys.props("length").toInt
104+ val vector = collection.immutable.Vector((0 until length): _*)
105+
106+ def run = {
107+ vector reduce {
108+ (a, b) => a + b
109+ }
110+ }
111+
112+ }
113+ 首先我们设定在元素数量为250000的情况下运行基准测试，在线程数设置为1、2、4的情况下得到了如下结果：
114+
115+ java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=1 -Dlength=250000 Reduce 10 10
116+ Reduce$ 54 24 18 18 18 19 19 18 19 19
117+ java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=2 -Dlength=250000 Reduce 10 10
118+ Reduce$ 60 19 17 13 13 13 13 14 12 13
119+ java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=4 -Dlength=250000 Reduce 10 10
120+ Reduce$ 62 17 15 14 13 11 11 11 11 9
121+ 然后我们将元素数量降低到120000，使用4个线程来比较序列矢量减运行的时间：
122+
123+ java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=4 -Dlength=120000 Reduce 10 10
124+ Reduce$ 54 10 8 8 8 7 8 7 6 5
125+ java -server -cp .:../../build/pack/lib/scala-library.jar -Dlength=120000 ReduceSeq 10 10
126+ ReduceSeq$ 31 7 8 8 7 7 7 8 7 8
127+ 在这个例子中，元素数量为120000时看起来正处于阈值附近。
128+
129+ 在另一个例子中，我们使用mutable.ParHashMap和map方法（一个转换方法），并在同样的环境中运行下面的测试程序：
130+
131+ import collection.parallel.mutable.ParHashMap
132+
133+ object Map extends testing.Benchmark {
134+ val length = sys.props("length").toInt
135+ val par = sys.props("par").toInt
136+ val phm = ParHashMap((0 until length) zip (0 until length): _*)
137+
138+ phm.tasksupport = new collection.parallel.ForkJoinTaskSupport(new scala.concurrent.forkjoin.ForkJoinPool(par))
139+
140+ def run = {
141+ phm map {
142+ kv => kv
143+ }
144+ }
145+ }
146+
147+ object MapSeq extends testing.Benchmark {
148+ val length = sys.props("length").toInt
149+ val hm = collection.mutable.HashMap((0 until length) zip (0 until length): _*)
150+
151+ def run = {
152+ hm map {
153+ kv => kv
154+ }
155+ }
156+ }
157+ 在元素数量为120000、线程数量从1增加至4的时候，我们得到了如下结果：
158+
159+ java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=1 -Dlength=120000 Map 10 10
160+ Map$ 187 108 97 96 96 95 95 95 96 95
161+ java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=2 -Dlength=120000 Map 10 10
162+ Map$ 138 68 57 56 57 56 56 55 54 55
163+ java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=4 -Dlength=120000 Map 10 10
164+ Map$ 124 54 42 40 38 41 40 40 39 39
165+
166+ 现在，如果我们将元素数量降低到15000来跟序列化哈希映射做比较：
167+
168+ java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=1 -Dlength=15000 Map 10 10
169+ Map$ 41 13 10 10 10 9 9 9 10 9
170+ java -server -cp .:../../build/pack/lib/scala-library.jar -Dpar=2 -Dlength=15000 Map 10 10
171+ Map$ 48 15 9 8 7 7 6 7 8 6
172+ java -server -cp .:../../build/pack/lib/scala-library.jar -Dlength=15000 MapSeq 10 10
173+ MapSeq$ 39 9 9 9 8 9 9 9 9 9
174+
175+ 对这个容器和操作来说，当元素数量大于15000的时候采用并发是有意义的（通常情况下，对于数组和向量来说使用更少的元素来并行处理hashmap和hashset是可行的但不是必须的）。
176+
177+ ** 引用**
178+
179+ 1 . [ Anatomy of a flawed microbenchmark，Brian Goetz] ( http://www.ibm.com/developerworks/java/library/j-jtp02225/index.html )
180+ 2 . [ Dynamic compilation and performance measurement, Brian Goetz] ( http://www.ibm.com/developerworks/library/j-jtp12214/ )
52181
53- ## 引用
54-
55- 1 . [ Anatomy of a flawed microbenchmark, Brian Goetz] [ 1 ]
56- 2 . [ Dynamic compilation and performance measurement, Brian Goetz] [ 2 ]
57- 3 . [ Scala library benchmarks] [ 3 ]
58-
59- [ 1 ] : http://www.ibm.com/developerworks/java/library/j-jtp02225/index.html " flawed-benchmark "
60- [ 2 ] : http://www.ibm.com/developerworks/library/j-jtp12214/ " dynamic-compilation "
61- [ 3 ] : https://github.com/scala/scala/tree/2.12.x/test/benchmarks
0 commit comments