[m-dev.] Proposing a new grade component.
pbone at csse.unimelb.edu.au
Mon Nov 7 21:20:26 AEDT 2011
On Mon, Nov 07, 2011 at 04:05:56PM +1100, Julien Fischer wrote:
> I would prefer to avoid adding yet another grade component if possible.
> In this case, provided that the overhead of enabling
> --coverage-profiling is acceptable then we should just enable that by
> default and just use *.gc.profdeep grades for feedback as well as profiling.
> When profiling for feedback, you would need to compile with
> --profile-optimized enabled. While this would only affect your program
> modules, I suspect this is ok since most performance critical
> procedures in the standard library will (should) be opt_imported into
> one of your program modules anyway. Once there, they *can* be compiled
> with it enabled.
I also wish to avoid creating new grades, they're a source of confusion for
Coverage profiling introduces a slowdown of roughly 6% (see my honours thesis).
However, this may have changed since I made coverage data associated with the
dynamic deep profiler structures and not the static structures, that is to say,
now it is collected and stored like the other profiling data.
I agree with your proposal.
> >I would also like to propose renaming the --profile-for-implicit-parallelism
> >option to --profile-for-feedback. This name reflects the more general
> >ability of this grade to be used for any type of profile feedback optimization,
> >not that any other uses for feedback analysis exist at the moment.
> Under my proposal it wouldn't be necessary although you could add it as
> a synonym for --profile-optimized if you wish.
I'll probably do that, I think the synonym is helpful to people are searching
for an option that gets them feedback analysis.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 490 bytes
Desc: Digital signature
More information about the developers