[m-dev.] Proposing a new grade component.

[Julien Fischer]

On Thu, 3 Nov 2011, Paul Bone wrote:

> Currently the analysis for automatic parallelism is attached to the deep
> profiler.  This means that a deep profiling grade is required, such as
> asm_fast.gc.profdeep, and coverage profiling is also mandatory.
>
> The following options are also relevant:
>
>    --coverage-profiling
>        This enables coverage profiling, which is normally disabled.  We could
>        enable this by default but it's not useful by itself.
>
>    --profile-optimized
>        Deep profiling normally disables some optimizations, such as inlining,
>        this is done so that the profile looks more like the code that the
>        programmer wrote.  However, when using feedback analysis we want a
>        profile that is closer to the compiled code rather than the source
>        code.  This switch re-enables these disabled optimizations.  This
>        option makes it a lot more likely that auto parallelization will
>        succeed, because the feedback data will more-closely match the program
>        being compiled.
>
>    --profile-for-implicit-parallelism
>        This option implies the two options above.
>
> Because coverage profiling is only currently used by feedback analysis it isn't
> useful to turn it out without also turning on --profile-optimized, which makes
> it a lot harder for users to use the deep profiler.  Therefore I propose that
> we introduce a new grade component option (an alternative to the profdeep grade
> component) that also turns on --profile-for-implicit-parallelism.  I'd like to
> call this grade component "profdeep_fb" (fb is short for feedback),
> alternatively it could be called "prof_fb".  This should be a new grade
> component so that it can be installed along side a normal deep profiling grade,
> making it easier for us and our users to use automatic parallelism.

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 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.

Julien.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------