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

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.

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

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.

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

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

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.

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.