[m-users.] Grade for profiling

[Julien Fischer]

Hi Zoltan,

On Tue, 21 Mar 2023, Zoltan Somogyi wrote:

> 2023-03-21 19:19 GMT+11:00 "Peter Wang" <novalazy at gmail.com>:
>>> Because there's more going on that just that. Volker's program forks
>>> off separate processes and I suspect the the Prof.* files end up being
>>> inconsistent -- ASLR just complicates matters because the addresses
>>> differ between each of them.
>>
>> That makes sense. The Prof.Decl file would be written when the program
>> starts up, and the Prof.Counts file is probably overwritten by each
>> process when it shuts down. Obviously, you may not get usable profiling
>> information then.
>
> Note that the Mercury profiler mprof was designed and implemented
> years before either
>
> - Mercury got support for parallel programs, or

Right, but in this case we are not talking about parallelism within
Mercury programs, but multiple instances of the program being forked
off. (And fork() definitely existed when mprof was written!)

(We bumped into this issue a few months ago at Opturion; the workaround
we used then was to run each of the child processes in a different
directory. A better solution would be append the process id to the
Prof.* files.)

> - OSs started supporting ASLR.

Having ASLR enabled basically means you cannot merge mprof profiles.
I think the right thing to do here would be to compile with -no-pie
in .prof and .memprof grades; this would disable ASLR in that case.

Julien.