[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-dev
Subject:    Re: Branch Prediction?
From:       Vitaly Davidovich <vitalyd () gmail ! com>
Date:       2014-11-20 15:43:15
Message-ID: CAHjP37H3VN1c7vjfTn1YXsWuzpaF58W1ZL7Yh62vG+tTYk=wEA () mail ! gmail ! com
[Download RAW message or body]

I'm guessing the "problem" will be tagging sufficiently enough of the
existing code to make a dent in performance benchmarks.  Is it feasible to,
say, modify the scavenging collector with places you guys know are
hot/cold, and then run one of the standard GC perf benchmarks that you have
(or a spec bench that's used a performance proxy for GC testing)?

Also, as Erik mentioned in the initial post, there's some nice
documentation aspect to these macros in that it tells the reader how
control usually flows through the functions.  At the end, it's just like
comments -- if they're not maintained, they can cause more harm than good.
But the likely/unlikely macros are frequently used in performance sensitive
projects that I've seen (just empirically).

On Thu, Nov 20, 2014 at 10:38 AM, Mikael Gerdin <mikael.gerdin@oracle.com>
wrote:

>
> On 2014-11-20 16:04, Andrew Haley wrote:
>
>> On 11/20/2014 02:28 PM, Paul Hohensee wrote:
>>
>>> If it were me (and it's not :) ), I'd want to see some generated code
>>> examples that would benefit.  Perhaps quantify the benefit by getting a
>>> libjvm profile, look at the code for the top 10 or 20 methods, reorganize
>>> it via a proof-of-concept implementation and measure the result.  I'd
>>> also
>>> take into consideration that future hardware improvements (e.g., larger
>>> icache line size) might negate any current improvement, so it'd have to
>>> be
>>> a 'big' benefit.  Again if it were me (and it's not :) ), it would take
>>> maybe a per-instance 10% improvement before I'd accept the intellectual
>>> overhead cost of a permanent implementation. I worry a lot about long
>>> term
>>> source code maintainability, hence I have a sort of automatic skepticism
>>> about features than complicate it. :)
>>>
>>
>> I agree, but:
>>
>> The problem with the "benchamrk and see" approach is that a fast
>> system is made up of many very small optimizations, each one of which
>> may be lost in the noise.
>>
>
> +1
>
> I, personally, would be fine with adding these kinds of hints to the hot
> paths of the scavenging collectors, for example.
> But someone needs to do the actual performance measurements to show that
> it at least gives something.
>
> /Mikael
>
>
>> Andrew.
>>
>>
[prev in list] [next in list] [prev in thread] [next in thread]