From: archana v. <arc...@ho...> - 2008-05-22 09:28:25
|
Hi, What is the mechanism to generate basic block profiles (actual execution frequencies) while the java program is executed by the JikesRVM compiler? How and where do we add the necessary instrumentation for this purpose? thanks archana _________________________________________________________________ Timely update on all current affairs, sports, events and all thats in News here on MSN videos. http://video.msn.com/?mkt=en-in |
From: Eliot M. <mo...@cs...> - 2008-05-22 10:51:02
|
archana vagish wrote: > Hi, > What is the mechanism to generate basic block profiles (actual execution frequencies) while the java program is executed by the JikesRVM compiler? How and where do we add the necessary instrumentation for this purpose? The Baseline compiler inserts code to increment counters (which it also allocates). The Opt compiler does not generate these profiles. Best wishes -- Eliot Moss |
From: archana v. <arc...@ho...> - 2008-05-22 14:04:58
|
Hi, Can we use OPT_EstimateBlockFrequencies for this purpose? How accurate would that be? thanks archana > Date: Thu, 22 May 2008 06:50:53 -0400 > From: mo...@cs... > To:czzt > Subject: Re: [rvm-research] generating basic block profiles > > archana vagish wrote: > > Hi, > > What is the mechanism to generate basic block profiles (actual execution frequencies) while the java program is executed by the JikesRVM compiler? How and where do we add the necessary instrumentation for this purpose? > > The Baseline compiler inserts code to increment counters (which it also > allocates). The Opt compiler does not generate these profiles. > > Best wishes -- Eliot Moss > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Jikesrvm-researchers mailing list c > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers _________________________________________________________________ No Harvard, No Oxford. We are here. Find out !! http://ss1.richmedia.in/recurl.asp?pid=500 |
From: Ian R. <rog...@gm...> - 2008-05-22 14:13:18
|
archana vagish wrote: > Hi, > Can we use OPT_EstimateBlockFrequencies for this purpose? How accurate would that be? > > thanks > archana > The baseline profiles are a lot better than estimating block frequencies. We recently switched to profiled image runs for the performance regression tests. There should be a JIRA to improve the block frequency estimation code based on the already existing annotated LST code but it still hasn't been transitioned from sourceforge [1]. Please can you list your affiliation when posting from an anonymous source like hotmail. Regards, Ian [1] http://sourceforge.net/tracker/index.php?func=detail&aid=1660744&group_id=128805&atid=712771 >> Date: Thu, 22 May 2008 06:50:53 -0400 >> From: mo...@cs... >> To:czzt >> Subject: Re: [rvm-research] generating basic block profiles >> >> archana vagish wrote: >> >>> Hi, >>> What is the mechanism to generate basic block profiles (actual execution frequencies) while the java program is executed by the JikesRVM compiler? How and where do we add the necessary instrumentation for this purpose? >>> >> The Baseline compiler inserts code to increment counters (which it also >> allocates). The Opt compiler does not generate these profiles. >> >> Best wishes -- Eliot Moss >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Jikesrvm-researchers mailing list >> > c > >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >> > > _________________________________________________________________ > No Harvard, No Oxford. We are here. Find out !! > http://ss1.richmedia.in/recurl.asp?pid=500 > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > |
From: archana v. <arc...@ho...> - 2008-05-22 16:34:52
|
Thank you for the information, archana PhD student, IISc, India ---------------------------------------- > Date: Thu, 22 May 2008 15:12:59 +0100 > From: rog...@gm... > To: jik...@li... > Subject: Re: [rvm-research] generating basic block profiles > > archana vagish wrote: > > Hi, > > Can we use OPT_EstimateBlockFrequencies for this purpose? How accurate would that be? > > > > thanks > > archana > > > > The baseline profiles are a lot better than estimating block > frequencies. We recently switched to profiled image runs for the > performance regression tests. There should be a JIRA to improve the > block frequency estimation code based on the already existing annotated > LST code but it still hasn't been transitioned from sourceforge [1]. > Please can you list your affiliation when posting from an anonymous > source like hotmail. > > Regards, > Ian > > [1] > http://sourceforge.net/tracker/index.php?func=detail&aid=1660744&group_id=128805&atid=712771 > >> Date: Thu, 22 May 2008 06:50:53 -0400 > >> From: mo...@cs... > >> To:czzt > >> Subject: Re: [rvm-research] generating basic block profiles > >> > >> archana vagish wrote: > >> > >>> Hi, > >>> What is the mechanism to generate basic block profiles (actual execution frequencies) while the java program is executed by the JikesRVM compiler? How and where do we add the necessary instrumentation for this purpose? > >>> > >> The Baseline compiler inserts code to increment counters (which it also > >> allocates). The Opt compiler does not generate these profiles. > >> > >> Best wishes -- Eliot Moss > >> > >> ------------------------------------------------------------------------- > >> This SF.net email is sponsored by: Microsoft > >> Defy all challenges. Microsoft(R) Visual Studio 2008. > >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > >> _______________________________________________ > >> Jikesrvm-researchers mailing list > >> > > c > > > >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > >> > > > > _________________________________________________________________ > > No Harvard, No Oxford. We are here. Find out !! > > http://ss1.richmedia.in/recurl.asp?pid=500 > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Jikesrvm-researchers mailing list > > Jik...@li... > > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers _________________________________________________________________ No Harvard, No Oxford. We are here. Find out !! http://ss1.richmedia.in/recurl.asp?pid=500 |
From: Rhodes B. <Rho...@ac...> - 2008-05-22 23:58:32
|
archana vagish wrote: > Can we use OPT_EstimateBlockFrequencies for this purpose? How accurate would that be? Ian Rogers <rog...@gm...> wrote: > The baseline profiles are a lot better than estimating block frequencies. Since my own work also uses block frequencies, I'd just like to be sure I understand these comments. Please correct me if the following seems wrong to any of you. As I understand it, OPT_EstimateBlockFrequencies assigns the frequency values by applying a flow-oriented algorithm based on the available branch profile operands. The computed frequencies need to be termed "estimates" because 1) they are computed indirectly, rather than derived from block counters; 2) they are based on past execution, thus may not reflect future behavior; and 3) they may be inaccurate if some of the branch profile operands are synthetic (i.e. added by a preceding code transformation). However, given these caveats, is there reason to believe that the results of OPT_EstimateBlockFrequencies are grossly inaccurate on for the usual adaptive optimization scheme? I can see that this may be an issue when one forces use of the OPT compiler as the initial compiler (i.e. -X:irc=opt), or during bootstrap compilation when using the OPT compiler. I believe this may be the case that Ian is referring to above. My own inspections revealed that in this case--when there are no previous branch profile operand results--the compiler will use default branch profile "estimates" (see OPT_GenerationContext.getConditionalBranchProfileOperand()). Clearly the block frequency values will be inaccurate in this case. However, my own cursory study revealed that they are "reasonable" in the sense that looping code will still get an f > 1 and will increase exponentially with loop-nest depth. Exception handlers typically get f ~ 0, since there is usually no way to reach them via normal branching. The one major problem lies in the default estimations for methods with branching, but no loops. In this case the default branch profile is set at 0.5 (i.e. no skew). The result is a failure to identify the common path (i.e. the best trace schedule). One might think that this is not an issue--that only looping code is important--but my own profiling studies indicate that (based on the usual baseline, then OPT scheme) more that 3/4 of the "hot" methods from DaCapo and JVM98 are straight (i.e. all block frequencies are computed as <= 1). I imagine that the results are similar for the Jikes code itself, but I have no plans to try to tackle the chicken/egg problem of instrumenting the VM code. However, this observation does provide support for the move to profile-directed generation of the VM. Hope that offers some (correct?) insight. Rhodes Brown PhD Candidate in Computer Science University of Victoria |
From: David P G. <gr...@us...> - 2008-05-23 19:16:49
|
I believe this is all correct. Thanks for taking the time to write up a nice summary. OPT_EstimateBlockFrequencies should compute frequencies that are just as accurate as the input conditional branch probabilities. --dave jik...@li... wrote on 05/22/2008 07:58:30 PM: > [image removed] > > Re: [rvm-research] generating basic block profiles > > Rhodes Brown > > to: > > jikesrvm-researchers > > 05/22/2008 07:59 PM > > Sent by: > > jik...@li... > > Please respond to "General discussion of Jikes RVM design, > implementation, issues, and plans" > > archana vagish wrote: > > Can we use OPT_EstimateBlockFrequencies for this purpose? How > accurate would that be? > > Ian Rogers <rog...@gm...> wrote: > > The baseline profiles are a lot better than estimating block frequencies. > > Since my own work also uses block frequencies, I'd just like to be > sure I understand these comments. Please correct me if the following > seems wrong to any of you. > > As I understand it, OPT_EstimateBlockFrequencies assigns the frequency > values by applying a flow-oriented algorithm based on the available > branch profile operands. The computed frequencies need to be termed > "estimates" because 1) they are computed indirectly, rather than > derived from block counters; 2) they are based on past execution, thus > may not reflect future behavior; and 3) they may be inaccurate if some > of the branch profile operands are synthetic (i.e. added by a > preceding code transformation). However, given these caveats, is there > reason to believe that the results of OPT_EstimateBlockFrequencies are > grossly inaccurate on for the usual adaptive optimization scheme? > > I can see that this may be an issue when one forces use of the OPT > compiler as the initial compiler (i.e. -X:irc=opt), or during > bootstrap compilation when using the OPT compiler. I believe this may > be the case that Ian is referring to above. My own inspections > revealed that in this case--when there are no previous branch profile > operand results--the compiler will use default branch profile > "estimates" (see > OPT_GenerationContext.getConditionalBranchProfileOperand()). Clearly > the block frequency values will be inaccurate in this case. However, > my own cursory study revealed that they are "reasonable" in the sense > that looping code will still get an f > 1 and will increase > exponentially with loop-nest depth. Exception handlers typically get f > ~ 0, since there is usually no way to reach them via normal branching. > The one major problem lies in the default estimations for methods with > branching, but no loops. In this case the default branch profile is > set at 0.5 (i.e. no skew). The result is a failure to identify the > common path (i.e. the best trace schedule). One might think that this > is not an issue--that only looping code is important--but my own > profiling studies indicate that (based on the usual baseline, then OPT > scheme) more that 3/4 of the "hot" methods from DaCapo and JVM98 are > straight (i.e. all block frequencies are computed as <= 1). I imagine > that the results are similar for the Jikes code itself, but I have no > plans to try to tackle the chicken/egg problem of instrumenting the VM > code. However, this observation does provide support for the move to > profile-directed generation of the VM. > > Hope that offers some (correct?) insight. > > Rhodes Brown > PhD Candidate in Computer Science > University of Victoria > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers |
From: Ian R. <rog...@gm...> - 2008-05-24 10:43:11
|
Rhodes Brown wrote: > archana vagish wrote: > >> Can we use OPT_EstimateBlockFrequencies for this purpose? How accurate would that be? >> > > Ian Rogers <rog...@gm...> wrote: > >> The baseline profiles are a lot better than estimating block frequencies. >> > > Since my own work also uses block frequencies, I'd just like to be > sure I understand these comments. Please correct me if the following > seems wrong to any of you. > > As I understand it, OPT_EstimateBlockFrequencies assigns the frequency > values by applying a flow-oriented algorithm based on the available > branch profile operands. The computed frequencies need to be termed > "estimates" because 1) they are computed indirectly, rather than > derived from block counters; 2) they are based on past execution, thus > may not reflect future behavior; and 3) they may be inaccurate if some > of the branch profile operands are synthetic (i.e. added by a > preceding code transformation). However, given these caveats, is there > reason to believe that the results of OPT_EstimateBlockFrequencies are > grossly inaccurate on for the usual adaptive optimization scheme? > I should have been clearer, they are grossly inaccurate in the boot image where we guess profile information (and in other situations where profile information doesn't exist). There are some catch 22s with this, we often guess that a branch is likely to be taken 50% of the time, a branch taken 50% of the time is a good candidate to move into a conditional move, you don't profile conditional moves (and we don't profile opt compiled code anyway) so you can never recover from this change. Generating conditional moves is something Intel's optimization guidelines advise against as it prevents speculatively executing through a branch. We can sometimes sub-optimally generate conditional moves in the opt compiler when cold code gets inlined. There is some specific code to try to prevent this from going too wrong with boot image compiled code (this needs revising to account for when a profiled image is made). In the past, at runtime, I've seen code created with conditional moves in where it would be better that it hadn't - hence being skeptical on the accuracy of the frequency estimation. You are right in its as accurate as it can be given the information its given. Regards, Ian Rogers |