On 01/23/2014 01:39 AM, Vitaly Davidovich wrote:
Remi,
Regarding your last point - picking correct data structures and algos
is of course step 1 in any optimization.
No, step 1 is to be sure that your problem is CPU bound.
But, provided that's taken care of, there're plausible reasons to
attempt to cater to hotspot as well (if that's the jvm in use). There
are certainly code shapes that it prefers.
yes, any JITs have preferred code shapes.
The thing is that to know if a new optimization will be included, the
perf tests will be done using benchmarks that usually use dumb codes, as
a logical consequence JITs are trained to recognize dumb codes. That's
why trying to do any micro-optimization using 'smart' code shape usually
result in a code that is slower.
There's a whole slew of inlining heuristics and rules to be aware of.
Those rules change.
There's a set of intrinsics, in some cases covering only a subset of
an API of a class. These things are always subject to change, but
saying "never worth it" isn't right either :).
yes, yo're right it's not right, let say it almost right :)
Rémi
Sent from my phone
On Jan 22, 2014 6:38 PM, "Remi Forax" <fo...@univ-mlv.fr
<mailto:fo...@univ-mlv.fr>> wrote:
On 01/22/2014 11:37 PM, Robert Stupp wrote:
Is there any documentation available which optimizations
Hotspot can perform and what "collecting a garbage" object costs?
I know that these are two completely different areas ;)
I was inspecting whether the following code
for (Object o : someArrayList) { ... }
would be faster than
for (int i=0, l=someArrayList.size(); i<l; i++) { Object
o=someArrayList.get(i); }
for RandomAccessList implementations. The challenge here is
not just to track the CPU time spent creating & using the
iterator vs. size() & get() calls but also track GC effort
(which is at least complicated if not impossible due to the
variety of GC configuration options).
For a long time, using a for with an index (if you are *sure* that
it's an ArrayList) was faster.
With latest jdk8, it's not true anymore.
(and most of the time the iterator object is not created anymore
at least with jdk7+).
For example:
- Does it help Hotspot to declare parameters/variables as
"final" or can Hotspot identify that?
no, it's an urban myth.
You can test it by yourself, if you declare a local variable final
or not the exact same bytecode is produced by javac. The keyword
final for a local variable (or a parameter) is not stored in the
bytecode.
BTW, final was introduced in 1.1 mostly to allow to capture the
value of a variable to be used by an anonymous class, Java 8
doesn't require this kind of variable to be declared final anymore.
- When does Hotspot inline method calls in general and
getters/setters especially?
In general, up to a depth of 10 by default and 1 for a recursive
method.
Roughly, a method call is not inlined either if the call is
virtual and can call too many implementations or if the generated
assembly code will be too big.
I think such a piece of documentation (just what Hotspot can
do in which release) would be really helpful when someone
tries to optimize code - want to say: the question is: "Is
something worth to spend time on or is this special situation
handled by Hotspot?"
It never worth it.
Choose the right algorithms and shape your data to be easily
consumed by your algorithms is enough.
-Robert
Rémi
