Allow more convenient use of ghc profiling options -auto and -auto-all

[guest]

Add Setup.(l)hs options that: 1) tells ghc to make a profiling library; 2) tells ghc to make a profiling executable 3) pass on the (a) -auto or (b) -auto-all option 4) Let you do (1)-(2)-(3a) or (1)-(2)-(3b) with a single option, instead of three.

[duncan]

Replying to guest:

Add Setup.(l)hs options that: 1) tells ghc to make a profiling library;

This is covered by the existing configure --enable-library-profiling

2) tells ghc to make a profiling executable

This is covered by the existing configure --enable-executable-profiling

3) pass on the (a) -auto or (b) -auto-all option

This is currently missing.

4) Let you do (1)-(2)-(3a) or (1)-(2)-(3b) with a single option, instead of three.

This is covered by cabal-install since the install command does configure, build and install and it takes the above two options.

So what we're currently missing is any way of handling the -auto or -auto-all options. I'm changing the summary to reflect that.

See also the cabal-devel thread starting with this message:  http://www.haskell.org/pipermail/cabal-devel/2007-January/000379.html

Does anyone have any good suggestion about how to handle -auto or -auto-all ? We cannot make them default for profiling (see above thread) and they are not features that make sense for other haskell implementations.

Currently one can put them in the .cabal file, but it's not really appropriate to do that since they're not static options.

[guest]

I think the best way is to pretend -auto and -caf-all don't exist. They are relatively rarely used, and when they are they can be passed with --ghc-option=, right?

For whether or not to use -auto-all, the portable distinction is whether we are compiling in order to support profiling something else, or to profile this code in particular. How about --enable-library-profiling for -prof -auto-all, and --enable-library-profiling-support for -prof? Better (shorter!) names welcomed; bonus marks if you can make --enable-library-profiling keep its current meaning without sounding too forced.

For other implementations both flags might have the same effect.

Ian Lynagh

[duncan]

Replying to guest:

I think the best way is to pretend -auto and -caf-all don't exist. They are relatively rarely used, and when they are they can be passed with --ghc-option=, right?

Possibly, I've not tried it but I fear that we call ghc for other purposes too and those extra flags might mess things up.

For whether or not to use -auto-all, the portable distinction is whether we are compiling in order to support profiling something else, or to profile this code in particular.

Yes. That is a good portable distinction.

How about --enable-library-profiling for -prof -auto-all, and --enable-library-profiling-support for -prof? Better (shorter!) names welcomed; bonus marks if you can make --enable-library-profiling keep its current meaning without sounding too forced.

Yes, if we can find a decent name and not change the meaning of the existing flag, which is already the right default.

For other implementations both flags might have the same effect.

Right.

[duncan]

This can't be that hard. We just need to figure out what behaviour we want.

[bos]

I'm all for just a single knob to control -auto-all. I've never heard of someone caring about -auto or -caf-all.

[duncan]

So we want something like --enable/disable-profiling-this-package, though with a less silly name. It would modify the meaning of --enable-library-profiling and --enable-executable-profiling to add -auto-all. For libs the default would be disabled and for exes the default would be enabled.

Hmm, if our defaults our different then we'd need different enable/disable flags for libs vs exes.

I agree with bos and Ian that we can basically ignore -auto and -caf-all. On the other hand I think that if we use -auto-all by default for executables then we do need a way to let people not do that for the rare cases (though we don't need to support those cases specifically). The easy way to do that is just to have a corresponding disable flag.

[dolio]

It may be that having annotations on all the libraries one uses is too much information. However, I'd argue that annotations on library calls isn't useful merely for profiling said libraries.

So, my program is slow, and it spends most of the time in function f.

f x = ... includes calls to some libraries ...

What is slow about f? Is it doing some of its own stuff that takes time/memory, or if we unfolded one level, would we find that 90% of f's work is done in the library calls it makes? Now, at some level, I suppose you can get carried away with that (f doesn't do any work, it's all GHC primops :)), but I think that a bit of such information can be useful, to tell me that I need to swap in a different data structure, or contact the library's maintainer and see if anything can be done to speed it up. Maybe you can do some of that with manual SCC annotations, but I've had trouble getting those to work well for me.

At least, it seems to me that there are situations where libraries aren't simply a profiling black hole would be useful when *not* profiling that particular library (even if only to tell you that that library needs to be profiled :)). See the somewhat recent BLAS optimization question on haskell-cafe for a potential example (is it his use of lists and non-fused operations? Is BLAS itself slow? etc.).

It'd be nice if there were a way to turn -auto-all on and off for libraries when compiling an application that uses those libraries. Of course, I don't suspect that's an option at the moment (I suppose you could build two sets of profiling files for each library, and have some way of selecting them, but I imagine that'd be hairy).

Anyhow, just my 2 cents on the issue.

[duncan]

Come on, this is easy to implement. All we need is to agree on the user interface! What command line options should we use?

To be concrete, the proposal is:

For libraries we have:

cabal configure --enable-library-profiling

Keeps its current meaning which is to compile this package to allow dependent packages to be profiled, but not with the intention of profiling this package. For ghc it implies -prof.

cabal configure --enable-library-profiling-this-package-yes-this-one!!!1

This enables profiling but with the intention of profiling this package. For ghc it implies -prof -auto-all. This is where we obviously want a sensible suggestion for the flag name.

For executables we have:

cabal configure --enable-executable-profiling

Which currently, for ghc, builds the exe just with basic profiling. Unlike with libraries, executable have no deps, so generally the only reason to build an exe with profiling support is to profile that exe. The suggestion is that the default be changed to use -auto-all because that is the most common method people use.

However some advanced uses might need to use -prof on it's own with manually annotated SCCs, or with flags -auto or -caf-all.

cabal configure --enable-executable-profiling-but-without-auto-all!!1

Similarly we need a sensible name for this. People would use this in combination with --ghc-option=-caf-all if necessary.

Now it looks like we need different flags to turn on/off the use of -auto-all for libs vs exes. The default values are different for exes vs libs, so having two flags makes things simpler. We could possibly use one flag to toggle both settings away from their defaults. It would mean that for a package like darcs with both a lib an an exe, that we could not build the lib with -auto-all but the exe without.

Having said all that, I'm not sure we can get this into Cabal-1.6.0.2 because it changes the API by changing an exposed type (the type of command line settings which is passed to the user hooks). So perhaps we have to punt for 1.8. That's probably ok as nobody seems to be shouting about this one.

[ganesh]

I suggest cabal configure --profile-this-library to add -auto-all to a library's profiling options, and cabal configure --custom-profiling to remove it from an executable's profiling options.

If the GHC ways system ever supports it, I would also like to be able to build a library both -prof and {{{-prof -auto-all}} for future use. This would then require some interface to select which profiling versions of libraries to use downstream.

[kmcallister]

Patch is attached.

[elga]

*  rio bouygues

[edouard]

A l'image du RIB bancaire, le code RIO est un identifiant unique attribue a la ligne et a un contrat client permettant d'identifier votre demande de portabilite vers un autre operateur.  virgin mobile