Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15303] rvmroot/branches/RVM-658-Quarantine/rvm/src

View: New views
9 Messages — Rating Filter:   Alert me  

Parent Message unknown Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15303] rvmroot/branches/RVM-658-Quarantine/rvm/src

by David P Grove :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Doesn't this cause us to bias basic if-then-else blocks as if they were loops? I'd suggest rather than playing with the static prediction here it would make more sense to tune the thresholds for cmov conversion.

--dave


captain5050@... wrote on 01/29/2009 09:16:59 AM:

>
> Log Message:
> -----------
> Make static branch prediction values configurable. Change static
> prediction of forward bracnhes value to 10% rather than 50% thereby
> preventing such branches becoming conditional moves.
>
> Modified Paths:
> --------------
>     rvmroot/branches/RVM-658-Quarantine/rvm/src/org/jikesrvm/
> compilers/opt/bc2ir/GenerationContext.java
>     rvmroot/branches/RVM-658-Quarantine/rvm/src-generated/options/
> ValueOptions.opt.dat
>
> Modified: rvmroot/branches/RVM-658-Quarantine/rvm/src/org/jikesrvm/
> compilers/opt/bc2ir/GenerationContext.java
> ===================================================================
> --- rvmroot/branches/RVM-658-Quarantine/rvm/src/org/jikesrvm/
> compilers/opt/bc2ir/GenerationContext.java   2009-01-29 13:29:47 UTC
> (rev 15302)
> +++ rvmroot/branches/RVM-658-Quarantine/rvm/src/org/jikesrvm/
> compilers/opt/bc2ir/GenerationContext.java   2009-01-29 14:16:59 UTC
> (rev 15303)
> @@ -616,9 +616,9 @@
>        BranchProfile bp = branchProfiles.getEntry(bcIndex);
>        prob = ((ConditionalBranchProfile) bp).getTakenProbability();
>      } else if (backwards) {
> -      prob = 0.9f;
> +      prob = options.PROFILE_BACKWARD_BRANCH_PROB;
>      } else {
> -      prob = 0.5f;
> +      prob = options.PROFILE_FORWARD_BRANCH_PROB;
>      }
>      // experimental option: flip the probablity to see how bad
> things would be if
>      // we were completely wrong.
>
> Modified: rvmroot/branches/RVM-658-Quarantine/rvm/src-generated/
> options/ValueOptions.opt.dat
> ===================================================================
> --- rvmroot/branches/RVM-658-Quarantine/rvm/src-generated/options/
> ValueOptions.opt.dat   2009-01-29 13:29:47 UTC (rev 15302)
> +++ rvmroot/branches/RVM-658-Quarantine/rvm/src-generated/options/
> ValueOptions.opt.dat   2009-01-29 14:16:59 UTC (rev 15303)
> @@ -45,6 +45,14 @@
>  Threshold at which a conditional branch is considered to be skewed
>  
>  
> +V PROFILE_FORWARD_BRANCH_PROB float 0.1f
> +Static probability an unknown forward branch will be taken
> +
> +
> +V PROFILE_BACKWARD_BRANCH_PROB float 0.9f
> +Static probability an unknown backward branch will be taken
> +
> +
>  V ESCAPE_MAX_ARRAY_SIZE int 5
>  Maximum size of array to replaced with registers by simple escape analysis
>  
>
>
> This was sent by the SourceForge.net collaborative development
> platform, the world's largest Open Source development site.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Jikesrvm-commits mailing list
> Jikesrvm-commits@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-commits

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core


Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15303] rvmroot/branches/RVM-658-Quarantine/rvm/src

by Ian Rogers (nabble) :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

2009/1/29 David P Grove <groved@...>:
> Doesn't this cause us to bias basic if-then-else blocks as if they were
> loops? I'd suggest rather than playing with the static prediction here it
> would make more sense to tune the thresholds for cmov conversion.
>
> --dave

I'd like to see what the change to performance is. Currently we
statically predict that backward branches are taken 90% of the time
and forward branches 50% of the time. We want to use cmovs when the
probability is about 50% (currently 33% to 66% - 1% to 99% in 3.0.1)
according to Intel's optimization guide. This change predicts forward
branches are less likely (10%) and therefore means we don't create
cmovs for unprofiled branches. Predicting forward branches aren't
taken is common in hardware. I can't find any reference for Java. For
C there are some simple heuristics based on negative values in a
compare usually implying errors (and therefore that forward branches
should be predicted taken), that in Java would be less likely to hold
due to the use of exceptions.

NB. the change was prompted by seeing the read barrier in x86 code in
Steve/Tony's barriers friend or foe paper. Instead of testing the
overhead for the branch predictor the work tests the overhead of cmov.
Not only is the generated x86 code an inefficient implementation of
the cmov, almost certainly read barriers should be proper compare and
branch sequences.

Regards,
Ian

> captain5050@... wrote on 01/29/2009 09:16:59 AM:
>
>>
>> Log Message:
>> -----------
>> Make static branch prediction values configurable. Change static
>> prediction of forward bracnhes value to 10% rather than 50% thereby
>> preventing such branches becoming conditional moves.
>>
>> Modified Paths:
>> --------------
>>     rvmroot/branches/RVM-658-Quarantine/rvm/src/org/jikesrvm/
>> compilers/opt/bc2ir/GenerationContext.java
>>     rvmroot/branches/RVM-658-Quarantine/rvm/src-generated/options/
>> ValueOptions.opt.dat
>>
>> Modified: rvmroot/branches/RVM-658-Quarantine/rvm/src/org/jikesrvm/
>> compilers/opt/bc2ir/GenerationContext.java
>> ===================================================================
>> --- rvmroot/branches/RVM-658-Quarantine/rvm/src/org/jikesrvm/
>> compilers/opt/bc2ir/GenerationContext.java   2009-01-29 13:29:47 UTC
>> (rev 15302)
>> +++ rvmroot/branches/RVM-658-Quarantine/rvm/src/org/jikesrvm/
>> compilers/opt/bc2ir/GenerationContext.java   2009-01-29 14:16:59 UTC
>> (rev 15303)
>> @@ -616,9 +616,9 @@
>>        BranchProfile bp = branchProfiles.getEntry(bcIndex);
>>        prob = ((ConditionalBranchProfile) bp).getTakenProbability();
>>      } else if (backwards) {
>> -      prob = 0.9f;
>> +      prob = options.PROFILE_BACKWARD_BRANCH_PROB;
>>      } else {
>> -      prob = 0.5f;
>> +      prob = options.PROFILE_FORWARD_BRANCH_PROB;
>>      }
>>      // experimental option: flip the probablity to see how bad
>> things would be if
>>      // we were completely wrong.
>>
>> Modified: rvmroot/branches/RVM-658-Quarantine/rvm/src-generated/
>> options/ValueOptions.opt.dat
>> ===================================================================
>> --- rvmroot/branches/RVM-658-Quarantine/rvm/src-generated/options/
>> ValueOptions.opt.dat   2009-01-29 13:29:47 UTC (rev 15302)
>> +++ rvmroot/branches/RVM-658-Quarantine/rvm/src-generated/options/
>> ValueOptions.opt.dat   2009-01-29 14:16:59 UTC (rev 15303)
>> @@ -45,6 +45,14 @@
>>  Threshold at which a conditional branch is considered to be skewed
>>
>>
>> +V PROFILE_FORWARD_BRANCH_PROB float 0.1f
>> +Static probability an unknown forward branch will be taken
>> +
>> +
>> +V PROFILE_BACKWARD_BRANCH_PROB float 0.9f
>> +Static probability an unknown backward branch will be taken
>> +
>> +
>>  V ESCAPE_MAX_ARRAY_SIZE int 5
>>  Maximum size of array to replaced with registers by simple escape
>> analysis
>>
>>
>>
>> This was sent by the SourceForge.net collaborative development
>> platform, the world's largest Open Source development site.
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> Jikesrvm-commits mailing list
>> Jikesrvm-commits@...
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-commits
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>
>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15303] rvmroot/branches/RVM-658-Quarantine/rvm/src

by David P Grove :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

That's all fine, but I think you may not have got my point. Any if-then-else at the Java source level will contain 1 forward branch. I don't see why we should be statically biasing the branch profiles for these in general, which is what this change is implicitly doing (by saying the forward branch is taken 10% of the time, you are saying the fall through is taken 90% of the time).

--dave


Ian Rogers <ian.rogers@...> wrote on 01/29/2009 10:05:09 AM:

> [image removed]

>
> Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15303] rvmroot/
> branches/RVM-658-Quarantine/rvm/src

>
> Ian Rogers

>
> to:

>
> Discussion of day-to-day development and design among JikesRVM core
> team members

>
> 01/29/2009 10:10 AM

>
> Please respond to Discussion of day-to-day development and design
> among JikesRVM core team members

>
> 2009/1/29 David P Grove <groved@...>:
> > Doesn't this cause us to bias basic if-then-else blocks as if they were
> > loops? I'd suggest rather than playing with the static prediction here it
> > would make more sense to tune the thresholds for cmov conversion.
> >
> > --dave
>
> I'd like to see what the change to performance is. Currently we
> statically predict that backward branches are taken 90% of the time
> and forward branches 50% of the time. We want to use cmovs when the
> probability is about 50% (currently 33% to 66% - 1% to 99% in 3.0.1)
> according to Intel's optimization guide. This change predicts forward
> branches are less likely (10%) and therefore means we don't create
> cmovs for unprofiled branches. Predicting forward branches aren't
> taken is common in hardware. I can't find any reference for Java. For
> C there are some simple heuristics based on negative values in a
> compare usually implying errors (and therefore that forward branches
> should be predicted taken), that in Java would be less likely to hold
> due to the use of exceptions.
>
> NB. the change was prompted by seeing the read barrier in x86 code in
> Steve/Tony's barriers friend or foe paper. Instead of testing the
> overhead for the branch predictor the work tests the overhead of cmov.
> Not only is the generated x86 code an inefficient implementation of
> the cmov, almost certainly read barriers should be proper compare and
> branch sequences.
>
> Regards,
> Ian
>
> > captain5050@... wrote on 01/29/2009 09:16:59 AM:
> >
> >>
> >> Log Message:
> >> -----------
> >> Make static branch prediction values configurable. Change static
> >> prediction of forward bracnhes value to 10% rather than 50% thereby
> >> preventing such branches becoming conditional moves.
> >>
> >> Modified Paths:
> >> --------------
> >>     rvmroot/branches/RVM-658-Quarantine/rvm/src/org/jikesrvm/
> >> compilers/opt/bc2ir/GenerationContext.java
> >>     rvmroot/branches/RVM-658-Quarantine/rvm/src-generated/options/
> >> ValueOptions.opt.dat
> >>
> >> Modified: rvmroot/branches/RVM-658-Quarantine/rvm/src/org/jikesrvm/
> >> compilers/opt/bc2ir/GenerationContext.java
> >> ===================================================================
> >> --- rvmroot/branches/RVM-658-Quarantine/rvm/src/org/jikesrvm/
> >> compilers/opt/bc2ir/GenerationContext.java   2009-01-29 13:29:47 UTC
> >> (rev 15302)
> >> +++ rvmroot/branches/RVM-658-Quarantine/rvm/src/org/jikesrvm/
> >> compilers/opt/bc2ir/GenerationContext.java   2009-01-29 14:16:59 UTC
> >> (rev 15303)
> >> @@ -616,9 +616,9 @@
> >>        BranchProfile bp = branchProfiles.getEntry(bcIndex);
> >>        prob = ((ConditionalBranchProfile) bp).getTakenProbability();
> >>      } else if (backwards) {
> >> -      prob = 0.9f;
> >> +      prob = options.PROFILE_BACKWARD_BRANCH_PROB;
> >>      } else {
> >> -      prob = 0.5f;
> >> +      prob = options.PROFILE_FORWARD_BRANCH_PROB;
> >>      }
> >>      // experimental option: flip the probablity to see how bad
> >> things would be if
> >>      // we were completely wrong.
> >>
> >> Modified: rvmroot/branches/RVM-658-Quarantine/rvm/src-generated/
> >> options/ValueOptions.opt.dat
> >> ===================================================================
> >> --- rvmroot/branches/RVM-658-Quarantine/rvm/src-generated/options/
> >> ValueOptions.opt.dat   2009-01-29 13:29:47 UTC (rev 15302)
> >> +++ rvmroot/branches/RVM-658-Quarantine/rvm/src-generated/options/
> >> ValueOptions.opt.dat   2009-01-29 14:16:59 UTC (rev 15303)
> >> @@ -45,6 +45,14 @@
> >>  Threshold at which a conditional branch is considered to be skewed
> >>
> >>
> >> +V PROFILE_FORWARD_BRANCH_PROB float 0.1f
> >> +Static probability an unknown forward branch will be taken
> >> +
> >> +
> >> +V PROFILE_BACKWARD_BRANCH_PROB float 0.9f
> >> +Static probability an unknown backward branch will be taken
> >> +
> >> +
> >>  V ESCAPE_MAX_ARRAY_SIZE int 5
> >>  Maximum size of array to replaced with registers by simple escape
> >> analysis
> >>
> >>
> >>
> >> This was sent by the SourceForge.net collaborative development
> >> platform, the world's largest Open Source development site.
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> This SF.net email is sponsored by:
> >> SourcForge Community
> >> SourceForge wants to tell your story.
> >> http://p.sf.net/sfu/sf-spreadtheword
> >> _______________________________________________
> >> Jikesrvm-commits mailing list
> >> Jikesrvm-commits@...
> >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-commits
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by:
> > SourcForge Community
> > SourceForge wants to tell your story.
> > http://p.sf.net/sfu/sf-spreadtheword
> > _______________________________________________
> > Jikesrvm-core mailing list
> > Jikesrvm-core@...
> > https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
> >
> >
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core


Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15303] rvmroot/branches/RVM-658-Quarantine/rvm/src

by Ian Rogers (nabble) :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

2009/1/29 David P Grove <groved@...>:
> That's all fine, but I think you may not have got my point. Any if-then-else
> at the Java source level will contain 1 forward branch. I don't see why we
> should be statically biasing the branch profiles for these in general, which
> is what this change is implicitly doing (by saying the forward branch is
> taken 10% of the time, you are saying the fall through is taken 90% of the
> time).
>
> --dave

I agree. Static prediction in hardware is equally as arbitrary. This
code should only happen in the uncommon case that we don't have
profile information. Trying to carry around that a branch prediction
wasn't from a profile would be quite a mess. My understanding is that
for reordering blocks 50% will behave just as 10% as there is no need
to reorder two blocks when the taken and not taken probability are
equal.

Ian

> Ian Rogers <ian.rogers@...> wrote on 01/29/2009 10:05:09 AM:
>
>> [image removed]
>>
>> Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15303] rvmroot/
>> branches/RVM-658-Quarantine/rvm/src
>>
>> Ian Rogers
>>
>> to:
>>
>> Discussion of day-to-day development and design among JikesRVM core
>> team members
>>
>> 01/29/2009 10:10 AM
>>
>> Please respond to Discussion of day-to-day development and design
>> among JikesRVM core team members
>
>>
>> 2009/1/29 David P Grove <groved@...>:
>> > Doesn't this cause us to bias basic if-then-else blocks as if they were
>> > loops? I'd suggest rather than playing with the static prediction here
>> > it
>> > would make more sense to tune the thresholds for cmov conversion.
>> >
>> > --dave
>>
>> I'd like to see what the change to performance is. Currently we
>> statically predict that backward branches are taken 90% of the time
>> and forward branches 50% of the time. We want to use cmovs when the
>> probability is about 50% (currently 33% to 66% - 1% to 99% in 3.0.1)
>> according to Intel's optimization guide. This change predicts forward
>> branches are less likely (10%) and therefore means we don't create
>> cmovs for unprofiled branches. Predicting forward branches aren't
>> taken is common in hardware. I can't find any reference for Java. For
>> C there are some simple heuristics based on negative values in a
>> compare usually implying errors (and therefore that forward branches
>> should be predicted taken), that in Java would be less likely to hold
>> due to the use of exceptions.
>>
>> NB. the change was prompted by seeing the read barrier in x86 code in
>> Steve/Tony's barriers friend or foe paper. Instead of testing the
>> overhead for the branch predictor the work tests the overhead of cmov.
>> Not only is the generated x86 code an inefficient implementation of
>> the cmov, almost certainly read barriers should be proper compare and
>> branch sequences.
>>
>> Regards,
>> Ian
>>
>> > captain5050@... wrote on 01/29/2009 09:16:59 AM:
>> >
>> >>
>> >> Log Message:
>> >> -----------
>> >> Make static branch prediction values configurable. Change static
>> >> prediction of forward bracnhes value to 10% rather than 50% thereby
>> >> preventing such branches becoming conditional moves.
>> >>
>> >> Modified Paths:
>> >> --------------
>> >>     rvmroot/branches/RVM-658-Quarantine/rvm/src/org/jikesrvm/
>> >> compilers/opt/bc2ir/GenerationContext.java
>> >>     rvmroot/branches/RVM-658-Quarantine/rvm/src-generated/options/
>> >> ValueOptions.opt.dat
>> >>
>> >> Modified: rvmroot/branches/RVM-658-Quarantine/rvm/src/org/jikesrvm/
>> >> compilers/opt/bc2ir/GenerationContext.java
>> >> ===================================================================
>> >> --- rvmroot/branches/RVM-658-Quarantine/rvm/src/org/jikesrvm/
>> >> compilers/opt/bc2ir/GenerationContext.java   2009-01-29 13:29:47 UTC
>> >> (rev 15302)
>> >> +++ rvmroot/branches/RVM-658-Quarantine/rvm/src/org/jikesrvm/
>> >> compilers/opt/bc2ir/GenerationContext.java   2009-01-29 14:16:59 UTC
>> >> (rev 15303)
>> >> @@ -616,9 +616,9 @@
>> >>        BranchProfile bp = branchProfiles.getEntry(bcIndex);
>> >>        prob = ((ConditionalBranchProfile) bp).getTakenProbability();
>> >>      } else if (backwards) {
>> >> -      prob = 0.9f;
>> >> +      prob = options.PROFILE_BACKWARD_BRANCH_PROB;
>> >>      } else {
>> >> -      prob = 0.5f;
>> >> +      prob = options.PROFILE_FORWARD_BRANCH_PROB;
>> >>      }
>> >>      // experimental option: flip the probablity to see how bad
>> >> things would be if
>> >>      // we were completely wrong.
>> >>
>> >> Modified: rvmroot/branches/RVM-658-Quarantine/rvm/src-generated/
>> >> options/ValueOptions.opt.dat
>> >> ===================================================================
>> >> --- rvmroot/branches/RVM-658-Quarantine/rvm/src-generated/options/
>> >> ValueOptions.opt.dat   2009-01-29 13:29:47 UTC (rev 15302)
>> >> +++ rvmroot/branches/RVM-658-Quarantine/rvm/src-generated/options/
>> >> ValueOptions.opt.dat   2009-01-29 14:16:59 UTC (rev 15303)
>> >> @@ -45,6 +45,14 @@
>> >>  Threshold at which a conditional branch is considered to be skewed
>> >>
>> >>
>> >> +V PROFILE_FORWARD_BRANCH_PROB float 0.1f
>> >> +Static probability an unknown forward branch will be taken
>> >> +
>> >> +
>> >> +V PROFILE_BACKWARD_BRANCH_PROB float 0.9f
>> >> +Static probability an unknown backward branch will be taken
>> >> +
>> >> +
>> >>  V ESCAPE_MAX_ARRAY_SIZE int 5
>> >>  Maximum size of array to replaced with registers by simple escape
>> >> analysis
>> >>
>> >>
>> >>
>> >> This was sent by the SourceForge.net collaborative development
>> >> platform, the world's largest Open Source development site.
>> >>
>> >>
>> >>
>>
>> ------------------------------------------------------------------------------
>> >> This SF.net email is sponsored by:
>> >> SourcForge Community
>> >> SourceForge wants to tell your story.
>> >> http://p.sf.net/sfu/sf-spreadtheword
>> >> _______________________________________________
>> >> Jikesrvm-commits mailing list
>> >> Jikesrvm-commits@...
>> >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-commits
>> >
>> >
>>
>> ------------------------------------------------------------------------------
>> > This SF.net email is sponsored by:
>> > SourcForge Community
>> > SourceForge wants to tell your story.
>> > http://p.sf.net/sfu/sf-spreadtheword
>> > _______________________________________________
>> > Jikesrvm-core mailing list
>> > Jikesrvm-core@...
>> > https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>> >
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> Jikesrvm-core mailing list
>> Jikesrvm-core@...
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>
>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15303] rvmroot/branches/RVM-658-Quarantine/rvm/src

by David P Grove :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Ian Rogers <ian.rogers@...> wrote on 01/29/2009 10:35:22 AM:

> I agree. Static prediction in hardware is equally as arbitrary. This
> code should only happen in the uncommon case that we don't have
> profile information. Trying to carry around that a branch prediction
> wasn't from a profile would be quite a mess. My understanding is that
> for reordering blocks 50% will behave just as 10% as there is no need
> to reorder two blocks when the taken and not taken probability are
> equal.

I don't think this is accurate.  Especially once you start nesting if-then-else blocks by spliting weight 90%/10% instead of 50%/50% you will change the output of the code reordering phase and will also cause some blocks to be marked as infrequent that weren't before (while the 90% "on" half of the if-then-else we know nothing about won't be marked as infrequent).

If the problem is not having profile data for read/write/alloc sequences in MMTk, I'd suggest the fix for that is to include branch profiling of a baseline image in the multi-stage build for a top performance production image.  

--dave

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core


Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15303] rvmroot/branches/RVM-658-Quarantine/rvm/src

by Ian Rogers (nabble) :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

2009/1/29 David P Grove <groved@...>:

> Ian Rogers <ian.rogers@...> wrote on 01/29/2009 10:35:22 AM:
>
>> I agree. Static prediction in hardware is equally as arbitrary. This
>> code should only happen in the uncommon case that we don't have
>> profile information. Trying to carry around that a branch prediction
>> wasn't from a profile would be quite a mess. My understanding is that
>> for reordering blocks 50% will behave just as 10% as there is no need
>> to reorder two blocks when the taken and not taken probability are
>> equal.
>
> I don't think this is accurate.  Especially once you start nesting
> if-then-else blocks by spliting weight 90%/10% instead of 50%/50% you will
> change the output of the code reordering phase and will also cause some
> blocks to be marked as infrequent that weren't before (while the 90% "on"
> half of the if-then-else we know nothing about won't be marked as
> infrequent).
>
> If the problem is not having profile data for read/write/alloc sequences in
> MMTk, I'd suggest the fix for that is to include branch profiling of a
> baseline image in the multi-stage build for a top performance production
> image.
>
> --dave

Agreed, and that'll bite as we'll switch to minimal BURS and things
like that. Reverted in r15306.

Ian

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15303] rvmroot/branches/RVM-658-Quarantine/rvm/src

by Steve Blackburn :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On 30/01/2009, at 3:09 AM, Ian Rogers wrote:

>> If the problem is not having profile data for read/write/alloc  
>> sequences in
>> MMTk, I'd suggest the fix for that is to include branch profiling  
>> of a
>> baseline image in the multi-stage build for a top performance  
>> production
>> image.
>>
>> --dave
>
> Agreed, and that'll bite as we'll switch to minimal BURS and things
> like that. Reverted in r15306.

I don't follow.

We already have this, right?  (profiled boot images).   I use this for  
all performance work and assumed everyone else did too.   It is just  
the "-p" option on buildit.

--Steve

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15303] rvmroot/branches/RVM-658-Quarantine/rvm/src

by David P Grove :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Steve Blackburn <Steve.Blackburn@...> wrote on 01/29/2009 03:35:43 PM:
> We already have this, right?  (profiled boot images).   I use this for  
> all performance work and assumed everyone else did too.   It is just  
> the "-p" option on buildit.

My bad.  I thought -p build a production image and gathered the dynamic call graph.  

It looks like it builds a baseline image and gathers edge counts.  So it does what we need for this point already (get edge counts).

I think we actually should be doing both (edge counts from a baseline image & call graph from a production image). Or is it doing that too and I missed it?

--dave

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core


Re: [rvm-core] [rvm-commits] SF.net SVN: jikesrvm:[15303] rvmroot/branches/RVM-658-Quarantine/rvm/src

by Steve Blackburn :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On 30/01/2009, at 7:56 AM, David P Grove wrote:

My bad.  I thought -p build a production image and gathered the dynamic call graph.  

It looks like it builds a baseline image and gathers edge counts.  So it does what we need for this point already (get edge counts).

I think we actually should be doing both (edge counts from a baseline image & call graph from a production image). Or is it doing that too and I missed it?

It just does the baseline.   I should know better, but did not think about this distinction when i coded this up.

I can't fix it this moment, but if this is something we need, let's JIRA it.

--Steve

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core