Re: [m-users.] Grade for profiling
Julien Fischer <[email protected]>
| Newsgroups | gmane.comp.lang.mercury.general |
|---|---|
| Message-ID | <[email protected]> |
Hi Zoltan, On Tue, 21 Mar 2023, Zoltan Somogyi wrote: > 2023-03-21 19:19 GMT+11:00 "Peter Wang" <[email protected]>: >>> 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. _______________________________________________ users mailing list [email protected] https://lists.mercurylang.org/listinfo/users