Suppose you have micro-operations A and B that take t(A) and t(B) to
run. Running repeat(n, A+B) can take n*(t(a) + t(b)), or n*max(t(a),
t(b)), or n*(t(a) + t(b) + huge_delta), or something else.
Sometimes the CPU can completely parallelize A and B so running them in
parallel takes no extra time compared to just one. Sometimes running
them in sequence causes one of the caches to overflow and efficiency
decreases dramatically. And sometimes running both can undo some quirk
and you end up with them taking less time.
Summary: CPUs are complicated.
On 24/03/2019 10.11, Francesco Nigro wrote:
Hi folks,
while reading the awesome
https://shipilev.net/blog/2014/nanotrusting-nanotime/
<https://shipilev.net/blog/2014/nanotrusting-nanotime/> I have some
questions on the "Building Performance Models" part.
Specifically, when you want to compare 2 operations (ie A,B) and you
want to emulate the same behaviour of a real application you need to
amortize the cost of such operations:
in JMH this is achieved with BlackHole.consumeCPU(int tokens), but any
microbenchmark tool (if not on the JVM) could/should provide something
similar.
Said that, now the code to measure is not just A or B but is composed
by 2 operations: amortization; A() (or B);
For JMH that means:
@Benchmark
int a() {
BlackHole.consumeCPU(tokens);
//suppose that rawA() return an int and rawA() is the original call re A
return rawA();
}
in JMH is up to the tool to avoid Dead Code Elimination when you
return a value from a benchmarked method.
The point of the article seems to be that given that "performance is
not composable" if you want to compare A and B cost (with
amortization) you cannot create a third benchmark:
@Benchmark
int amortization() {
BlackHole.consumeCPU(tokens);
}
And use the benchmark results (eg throughput of calls) to be
subtracted from the results of a() (or b()) to compare A and B costs.
I don't understand the meaning of "performance is not composable" and
I would appreciate your opinion on that, given that many people
of this list have experience with benchmarking.
Thanks,
Franz
--
You received this message because you are subscribed to the Google
Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
