个人中心
文章发布
退出
作者热门文章
- Java 双重比较
- java - 比较器与 Apache BeanComparator
- Objective-C 完成 block 导致额外的方法调用？
- database - RESTful URI 是否应该公开数据库主键？
24
4
我偶然发现了一个非常不稳定的性能配置文件实例，该实例是对原始数组进行的非常简单的 map/reduce 操作。这是我的 jmh 基准代码:
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@BenchmarkMode(Mode.AverageTime)
@OperationsPerInvocation(Measure.ARRAY_SIZE)
@Warmup(iterations = 300, time = 200, timeUnit=MILLISECONDS)
@Measurement(iterations = 1, time = 1000, timeUnit=MILLISECONDS)
@State(Scope.Thread)
@Threads(1)
@Fork(1)
public class Measure
{
static final int ARRAY_SIZE = 1<<20;
final int[] ds = new int[ARRAY_SIZE];
private IntUnaryOperator mapper;
@Setup public void setup() {
setAll(ds, i->(int)(Math.random()*(1<<7)));
final int multiplier = (int)(Math.random()*10);
mapper = d -> multiplier*d;
}
@Benchmark public double multiply() {
return Arrays.stream(ds).map(mapper).sum();
}
}
这是典型输出的片段:
# VM invoker: /Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/jre/bin/java
# VM options: <none>
# Warmup: 300 iterations, 200 ms each
# Measurement: 1 iterations, 1000 ms each
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Average time, time/op
# Benchmark: org.sample.Measure.multiply
# Run progress: 0,00% complete, ETA 00:01:01
# Fork: 1 of 1
# Warmup Iteration 1: 0,779 ns/op
# Warmup Iteration 2: 0,684 ns/op
# Warmup Iteration 3: 0,608 ns/op
# Warmup Iteration 4: 0,619 ns/op
# Warmup Iteration 5: 0,642 ns/op
# Warmup Iteration 6: 0,638 ns/op
# Warmup Iteration 7: 0,660 ns/op
# Warmup Iteration 8: 0,611 ns/op
# Warmup Iteration 9: 0,636 ns/op
# Warmup Iteration 10: 0,692 ns/op
# Warmup Iteration 11: 0,632 ns/op
# Warmup Iteration 12: 0,612 ns/op
# Warmup Iteration 13: 1,280 ns/op
# Warmup Iteration 14: 7,261 ns/op
# Warmup Iteration 15: 7,379 ns/op
# Warmup Iteration 16: 7,376 ns/op
# Warmup Iteration 17: 7,379 ns/op
# Warmup Iteration 18: 7,195 ns/op
# Warmup Iteration 19: 7,351 ns/op
# Warmup Iteration 20: 7,761 ns/op
....
....
....
# Warmup Iteration 100: 7,300 ns/op
# Warmup Iteration 101: 7,384 ns/op
# Warmup Iteration 102: 7,132 ns/op
# Warmup Iteration 103: 7,278 ns/op
# Warmup Iteration 104: 7,331 ns/op
# Warmup Iteration 105: 7,335 ns/op
# Warmup Iteration 106: 7,450 ns/op
# Warmup Iteration 107: 7,346 ns/op
# Warmup Iteration 108: 7,826 ns/op
# Warmup Iteration 109: 7,221 ns/op
# Warmup Iteration 110: 8,017 ns/op
# Warmup Iteration 111: 7,611 ns/op
# Warmup Iteration 112: 7,376 ns/op
# Warmup Iteration 113: 0,707 ns/op
# Warmup Iteration 114: 0,828 ns/op
# Warmup Iteration 115: 0,608 ns/op
# Warmup Iteration 116: 0,634 ns/op
# Warmup Iteration 117: 0,633 ns/op
# Warmup Iteration 118: 0,660 ns/op
# Warmup Iteration 119: 0,635 ns/op
# Warmup Iteration 120: 0,566 ns/op
关键时刻发生在第 13 次和第 113 次迭代:首先性能下降十倍，然后恢复。相应的时间是测试运行的 2.5 秒和 22.5 秒。这些事件的时间对阵列大小非常敏感，顺便说一句。
什么可以解释这种行为？ JIT 编译器可能在第一次迭代中完成了它的工作；没有 GC 操作可言(由 VisualVM 确认)...我完全不知道任何解释。
我的 Java 版本 (OS X):
$ java -version
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)
最佳答案
JIT 将首先编译迭代和操作(映射/归约)数组元素的热循环。这很早就发生了，因为数组包含 220 个元素。
稍后在 JIT 上编译管道，很可能内联在已编译的基准方法中，并且由于内联限制无法将其全部编译到一个方法中。碰巧在热循环中达到了内联限制，并且未内联对 map 或 sum 的调用，因此热循环无意中“去优化”。
在运行基准测试时使用选项 -XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation -XX:+PrintInlining，您应该会看到如下输出:
1202 487 % 4 java.util.Spliterators$IntArraySpliterator::forEachRemaining @ 49 (68 bytes)
@ 53 java.util.stream.IntPipeline$3$1::accept (23 bytes) inline (hot)
\-> TypeProfile (1186714/1186714 counts) = java/util/stream/IntPipeline$3$1
@ 12 test.Measure$$Lambda$2/1745776415::applyAsInt (9 bytes) inline (hot)
\-> TypeProfile (1048107/1048107 counts) = test/Measure$$Lambda$2
@ 5 test.Measure::lambda$setup$1 (4 bytes) inline (hot)
@ 17 java.util.stream.ReduceOps$5ReducingSink::accept (19 bytes) inline (hot)
\-> TypeProfile (1048107/1048107 counts) = java/util/stream/ReduceOps$5ReducingSink
@ 10 java.util.stream.IntPipeline$$Lambda$3/1779653790::applyAsInt (6 bytes) inline (hot)
\-> TypeProfile (1048064/1048064 counts) = java/util/stream/IntPipeline$$Lambda$3
@ 2 java.lang.Integer::sum (4 bytes) inline (hot)
那是正在编译的热循环。 (% 表示它在堆栈上被替换，或 OSR'ed)
稍后会进一步编译流管道(我怀疑基准方法迭代了约 10,000 次，但我尚未验证):
@ 16 java.util.stream.IntPipeline::sum (11 bytes) inline (hot)
\-> TypeProfile (5120/5120 counts) = java/util/stream/IntPipeline$3
@ 2 java.lang.invoke.LambdaForm$MH/1279902262::linkToTargetMethod (8 bytes) force inline by annotation
@ 4 java.lang.invoke.LambdaForm$MH/1847865997::identity (18 bytes) force inline by annotation
@ 14 java.lang.invoke.LambdaForm$DMH/2024969684::invokeStatic_L_L (14 bytes) force inline by annotation
@ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) force inline by annotation
@ 10 sun.invoke.util.ValueConversions::identity (2 bytes) inline (hot)
@ 7 java.util.stream.IntPipeline::reduce (16 bytes) inline (hot)
@ 3 java.util.stream.ReduceOps::makeInt (18 bytes) inline (hot)
@ 1 java.util.Objects::requireNonNull (14 bytes) inline (hot)
@ 14 java.util.stream.ReduceOps$5::<init> (16 bytes) inline (hot)
@ 12 java.util.stream.ReduceOps$ReduceOp::<init> (10 bytes) inline (hot)
@ 1 java.lang.Object::<init> (1 bytes) inline (hot)
@ 6 java.util.stream.AbstractPipeline::evaluate (94 bytes) inline (hot)
@ 50 java.util.stream.AbstractPipeline::isParallel (8 bytes) inline (hot)
@ 80 java.util.stream.TerminalOp::getOpFlags (2 bytes) inline (hot)
\-> TypeProfile (5122/5122 counts) = java/util/stream/ReduceOps$5
@ 85 java.util.stream.AbstractPipeline::sourceSpliterator (163 bytes) inline (hot)
@ 79 java.util.stream.AbstractPipeline::isParallel (8 bytes) inline (hot)
@ 88 java.util.stream.ReduceOps$ReduceOp::evaluateSequential (18 bytes) inline (hot)
@ 2 java.util.stream.ReduceOps$5::makeSink (5 bytes) inline (hot)
@ 1 java.util.stream.ReduceOps$5::makeSink (16 bytes) inline (hot)
@ 12 java.util.stream.ReduceOps$5ReducingSink::<init> (15 bytes) inline (hot)
@ 11 java.lang.Object::<init> (1 bytes) inline (hot)
@ 6 java.util.stream.AbstractPipeline::wrapAndCopyInto (18 bytes) inline (hot)
@ 3 java.util.Objects::requireNonNull (14 bytes) inline (hot)
@ 9 java.util.stream.AbstractPipeline::wrapSink (37 bytes) inline (hot)
@ 1 java.util.Objects::requireNonNull (14 bytes) inline (hot)
@ 23 java.util.stream.IntPipeline$3::opWrapSink (10 bytes) inline (hot)
\-> TypeProfile (4868/4868 counts) = java/util/stream/IntPipeline$3
@ 6 java.util.stream.IntPipeline$3$1::<init> (11 bytes) inline (hot)
@ 7 java.util.stream.Sink$ChainedInt::<init> (16 bytes) inline (hot)
@ 1 java.lang.Object::<init> (1 bytes) inline (hot)
@ 6 java.util.Objects::requireNonNull (14 bytes) inline (hot)
@ 13 java.util.stream.AbstractPipeline::copyInto (53 bytes) inline (hot)
@ 1 java.util.Objects::requireNonNull (14 bytes) inline (hot)
@ 9 java.util.stream.AbstractPipeline::getStreamAndOpFlags (5 bytes) accessor
@ 12 java.util.stream.StreamOpFlag::isKnown (19 bytes) inline (hot)
@ 20 java.util.Spliterator::getExactSizeIfKnown (25 bytes) inline (hot)
\-> TypeProfile (4870/4870 counts) = java/util/Spliterators$IntArraySpliterator
@ 1 java.util.Spliterators$IntArraySpliterator::characteristics (5 bytes) accessor
@ 19 java.util.Spliterators$IntArraySpliterator::estimateSize (11 bytes) inline (hot)
@ 25 java.util.stream.Sink$ChainedInt::begin (11 bytes) inline (hot)
\-> TypeProfile (4870/4870 counts) = java/util/stream/IntPipeline$3$1
@ 5 java.util.stream.ReduceOps$5ReducingSink::begin (9 bytes) inline (hot)
\-> TypeProfile (4871/4871 counts) = java/util/stream/ReduceOps$5ReducingSink
@ 32 java.util.Spliterator$OfInt::forEachRemaining (53 bytes) inline (hot)
@ 12 java.util.Spliterators$IntArraySpliterator::forEachRemaining (68 bytes) inline (hot)
@ 53 java.util.stream.IntPipeline$3$1::accept (23 bytes) inline (hot)
@ 12 test.Measure$$Lambda$2/1745776415::applyAsInt (9 bytes) inline (hot)
\-> TypeProfile (1048107/1048107 counts) = test/Measure$$Lambda$2
@ 5 test.Measure::lambda$setup$1 (4 bytes) inlining too deep
@ 17 java.util.stream.ReduceOps$5ReducingSink::accept (19 bytes) inline (hot)
\-> TypeProfile (1048107/1048107 counts) = java/util/stream/ReduceOps$5ReducingSink
@ 10 java.util.stream.IntPipeline$$Lambda$3/1779653790::applyAsInt (6 bytes) inlining too deep
\-> TypeProfile (1048064/1048064 counts) = java/util/stream/IntPipeline$$Lambda$3
@ 53 java.util.stream.IntPipeline$3$1::accept (23 bytes) inline (hot)
@ 12 test.Measure$$Lambda$2/1745776415::applyAsInt (9 bytes) inline (hot)
\-> TypeProfile (1048107/1048107 counts) = test/Measure$$Lambda$2
@ 5 test.Measure::lambda$setup$1 (4 bytes) inlining too deep
@ 17 java.util.stream.ReduceOps$5ReducingSink::accept (19 bytes) inline (hot)
\-> TypeProfile (1048107/1048107 counts) = java/util/stream/ReduceOps$5ReducingSink
@ 10 java.util.stream.IntPipeline$$Lambda$3/1779653790::applyAsInt (6 bytes) inlining too deep
\-> TypeProfile (1048064/1048064 counts) = java/util/stream/IntPipeline$$Lambda$3
@ 38 java.util.stream.Sink$ChainedInt::end (10 bytes) inline (hot)
@ 4 java.util.stream.Sink::end (1 bytes) inline (hot)
\-> TypeProfile (5120/5120 counts) = java/util/stream/ReduceOps$5ReducingSink
@ 12 java.util.stream.ReduceOps$5ReducingSink::get (5 bytes) inline (hot)
@ 1 java.util.stream.ReduceOps$5ReducingSink::get (8 bytes) inline (hot)
@ 4 java.lang.Integer::valueOf (32 bytes) inline (hot)
@ 28 java.lang.Integer::<init> (10 bytes) inline (hot)
@ 1 java.lang.Number::<init> (5 bytes) inline (hot)
@ 1 java.lang.Object::<init> (1 bytes) inline (hot)
@ 12 java.lang.Integer::intValue (5 bytes) accessor
注意热循环中方法发生的“内联太深”。
甚至稍后编译生成的 JMH 测量循环:
26857 685 3 test.generated.Measure_multiply::multiply_avgt_jmhLoop (55 bytes)
@ 7 java.lang.System::nanoTime (0 bytes) intrinsic
@ 16 test.Measure::multiply (23 bytes)
@ 4 java.util.Arrays::stream (8 bytes)
@ 4 java.util.Arrays::stream (11 bytes)
@ 3 java.util.Arrays::spliterator (10 bytes)
@ 6 java.util.Spliterators::spliterator (25 bytes) callee is too large
@ 7 java.util.stream.StreamSupport::intStream (14 bytes)
@ 6 java.util.stream.StreamOpFlag::fromCharacteristics (37 bytes) callee is too large
@ 10 java.util.stream.IntPipeline$Head::<init> (8 bytes)
@ 4 java.util.stream.IntPipeline::<init> (8 bytes)
@ 4 java.util.stream.AbstractPipeline::<init> (55 bytes) callee is too large
@ 11 java.util.stream.IntPipeline::map (26 bytes)
@ 1 java.util.Objects::requireNonNull (14 bytes)
@ 8 java.lang.NullPointerException::<init> (5 bytes) don't inline Throwable constructors
@ 22 java.util.stream.IntPipeline$3::<init> (20 bytes)
@ 16 java.util.stream.IntPipeline$StatelessOp::<init> (29 bytes) callee is too large
@ 16 java.util.stream.IntPipeline::sum (11 bytes)
@ 2 java.lang.invoke.LambdaForm$MH/1279902262::linkToTargetMethod (8 bytes) force inline by annotation
@ 4 java.lang.invoke.LambdaForm$MH/1847865997::identity (18 bytes) force inline by annotation
@ 14 java.lang.invoke.LambdaForm$DMH/2024969684::invokeStatic_L_L (14 bytes) force inline by annotation
@ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) force inline by annotation
@ 10 sun.invoke.util.ValueConversions::identity (2 bytes)
@ 7 java.util.stream.IntPipeline::reduce (16 bytes)
@ 3 java.util.stream.ReduceOps::makeInt (18 bytes)
@ 1 java.util.Objects::requireNonNull (14 bytes)
@ 14 java.util.stream.ReduceOps$5::<init> (16 bytes)
@ 12 java.util.stream.ReduceOps$ReduceOp::<init> (10 bytes)
@ 1 java.lang.Object::<init> (1 bytes)
@ 6 java.util.stream.AbstractPipeline::evaluate (94 bytes) callee is too large
@ 12 java.lang.Integer::intValue (5 bytes)
请注意，没有尝试内联整个流管道，它在到达热循环之前就停止了，参见“callee is too large”，从而重新优化热循环。
可以增加内联限制以避免此类行为，例如 -XX:MaxInlineLevel=12。
关于java - Arrays.stream().map().sum() 的不稳定性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32476864/
24
4
0
我有这个示例代码: #include #include int main() { Eigen::MatrixXf M = Eigen::MatrixXf::Random(1000, 1000)
我有一个像这样的数据框: +-----+--------+ |count| country| +-----+--------+ | 12| Ireland| | 5|Thailand| +-
我想要 SUM(tot_bill_1+tot_bill_2) AS 总计，但这不起作用 SELECT *, IF(SUM(bill_1) IS NULL, '99', SUM(bill_1)) AS
如果我们有两个矩阵 X 和 Y，都是二维的，现在在数学上我们可以说:sum(X-Y)=sum(X)-总和(Y). Matlab 哪个效率更高？哪个更快？ 最佳答案 在我的机器上，sum(x-y) 对于
我正在运行 Hive 1.1.0 并看到对于两个 bigint 列，active_users 和 inactive_users，SUM(active_users + inactive_users) <
是否可以在一个选择查询中求和？ 类似这样的事情: SELECT id, SUM(current_price - bought_price)*amount AS profit FROM purchase
这是一个相当奇怪的结果。我希望这些具有相同的产量。 下面还有从数据库中提取的 excel 链接。 https://twentius.opendrive.com/files?89038281_muoyg
我必须对 2 个字段求和，然后再求和。从性能的角度来看，先添加字段还是在对列求和之后添加字段有什么区别？ 方法 1 = SELECT SUM(columnA + columnB) 方法 2 = SEL
这是一个经典问题，但我很好奇是否有可能在这些条件下做得更好。 问题:假设我们有一个长度为4*N的排序数组，即每个元素重复4次。请注意，N 可以是任何自然数。此外，数组中的每个元素都受制于 0 A. 执
我正在编写一个 Pig 程序，该程序加载一个用制表符分隔整个文件的文件 例如:名称 TAB 年份 TAB 计数 TAB... file = LOAD 'file.csv' USING PigStora
我有一个包含以下字段的表: EmpID, Code, Amount, TransDate, CM, CMDate 我想要进入数据网格的是 SUM所有的Amount具有相同的 Code和 SUM CM具
我有两个单独的查询用于提取报告信息。一年效果很好。但是，如果一个月超过 1 年，则不会显示正确的响应。 这是我的两个查询: select SUM(rpt_complete.total) total,
我想查询一个团队的积分。通过在列上执行 SUM + 来自具有相同团队 ID 的另一个表的 SUM 来添加这些点。我试着这样写: SELECT k.id, s.fylke, s.
这个问题在这里已经有了答案: How to deal with floating point number precision in JavaScript? (47 个回答) Unexpected
关闭。这个问题不符合Stack Overflow guidelines .它目前不接受答案。 这个问题似乎与 help center 中定义的范围内的编程无关。 . 关闭 5 年前。 Improve
我已经找了一段时间，但找不到这个问题的答案(也许我没有搜索正确的术语或其他东西)。基本上，我有一个数据库，每个日期有任意数量的条目。我需要取包含条目的最后 X 天的总和(忽略没有条目的天数)。我知道如
我正在尝试获取 B 行中包含 A 行中某个值的所有值中的一些值。我猜这个问题很简单。 这是我的查询: =QUERY('Sheet1'!$A$16:D, "Select sum(D) Where C c
我正在尝试运行以下查询，但出现以下错误: You have an error in your SQL syntax; check the manual that corresponds to your
我有一个 tableA，其中包含以下结构 我将此结构修改为如下所示的tableB，以减少行数，并且类别是固定长度的 假设我在 tableA 中修改为新结构后有 210 万条数据，tableB 仅包含
我的表在 Postgres 中的数据: id user_id sell_amount sell_currency_id buy_amount buy_currency_id type
我是一名优秀的程序员,十分优秀！