Proposal: Add a benchmark section to .cabal files

Hi all, Problem ======= After having used Makefiles to build my benchmark suites for quite some time I'm convinced we need support for building benchmark using Cabal. Make doesn't solve the problem of building a benchmarks particularly well. There are several problems: * Building your library using Cabal and your benchmarks using Make sometimes ends up with different package versions being used for the two separate builds, resulting in compilation errors. * Lots of functionality that's already in Cabal is duplicated in Makefiles (e.g. preprocessor rules). * It's hard to get proper incremental compilation; I always use `make -C benchmarks clean all` to rebuild the benchmarks, just to make sure that everything is up-to-date. Proposal ======== Step 1. Add basic support for building simple benchmark suites e.g. modelled after test suite sections: Name: foo Version: 1.0 License: BSD3 Cabal-Version: >= 1.9.2 Build-Type: Simple Benchmark bench-foo type: stdio-1.0 main-is: bench-foo.hs build-depends: base This doesn't add much on top of normal executable sections, except that it tells Cabal that this isn't an executable it should build by default or install. Step 2. Add a detailed benchmark interface that allows the benchmark to associate a real valued *measure* (optionally with upper and lower bounds) with a benchmark name. Benchmark naming would work like test naming (e.g. group/subgroup/name). This would allow us to track performance over time. Step 2 needs to be fleshed out some more, but I think we can get quite a lot of bang-for-the-buck with step 1. Cheers, Johan

On Mon, 2011-10-03 at 22:59 -0700, Johan Tibell wrote:
Proposal ========
Step 1. Add basic support for building simple benchmark suites e.g. modelled after test suite sections:
Name: foo Version: 1.0 License: BSD3 Cabal-Version: >= 1.9.2 Build-Type: Simple
Benchmark bench-foo type: stdio-1.0 main-is: bench-foo.hs build-depends: base
This doesn't add much on top of normal executable sections, except that it tells Cabal that this isn't an executable it should build by default or install.
Just to point out that the closest workaround at the moment is to add an executable but to mark it as not buildable by default.
Step 2. Add a detailed benchmark interface that allows the benchmark to associate a real valued *measure* (optionally with upper and lower bounds) with a benchmark name. Benchmark naming would work like test naming (e.g. group/subgroup/name). This would allow us to track performance over time.
Step 2 needs to be fleshed out some more, but I think we can get quite a lot of bang-for-the-buck with step 1.
In general, yes I think benchmarking is a sensible follow-on from test suites. We can follow the same approach of specifying a protocol so that we can add more sophisticated interfaces later as we gain experience wit them. Duncan

On Tue, Oct 4, 2011 at 7:57 AM, Duncan Coutts
In general, yes I think benchmarking is a sensible follow-on from test suites. We can follow the same approach of specifying a protocol so that we can add more sophisticated interfaces later as we gain experience wit them.
What do you think about the very basic interface I gave? It basically just makes it possible to create executables that are distinguishable as benchmarks. That seems like a very small step but it solves more or less all of my problems*. Should I go ahead and implement it? * I prefer not to use the workaround as having spurious executables confuses Hackage (which lists them) and users. Cheers, Johan

On Tue, Oct 4, 2011 at 12:49 PM, Johan Tibell
On Tue, Oct 4, 2011 at 7:57 AM, Duncan Coutts
wrote: In general, yes I think benchmarking is a sensible follow-on from test suites. We can follow the same approach of specifying a protocol so that we can add more sophisticated interfaces later as we gain experience wit them.
What do you think about the very basic interface I gave? It basically just makes it possible to create executables that are distinguishable as benchmarks. That seems like a very small step but it solves more or less all of my problems*.
Should I go ahead and implement it?
* I prefer not to use the workaround as having spurious executables confuses Hackage (which lists them) and users.
I've had decent luck with adding a benchmark as a 'test' section, which puts the executable in a predictable place.
Cheers, Johan
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel

Hi, Johan Tibell wrote:
[...] I'm convinced we need support for building benchmark using Cabal. [...]
Could test sections be used for benchmarks, too?
Step 1. Add basic support for building simple benchmark suites e.g. modelled after test suite sections:
This should work immediately.
Step 2. Add a detailed benchmark interface that allows the benchmark to associate a real valued *measure* (optionally with upper and lower bounds) with a benchmark name.
This could be supported by a protocol where a "test" reports a real instead of a boolean value. Test bench-foo type: benchmark-1.0 main-is: bench-foo.hs build-depends: base Except for the more specialized keywords, there seems to be no need to distinguish tests from benchmarks. Tillmann

On Wed, 2011-10-05 at 12:09 +0200, Tillmann Rendel wrote:
Hi,
Johan Tibell wrote:
[...] I'm convinced we need support for building benchmark using Cabal. [...]
Could test sections be used for benchmarks, too?
Step 1. Add basic support for building simple benchmark suites e.g. modelled after test suite sections:
This should work immediately.
Step 2. Add a detailed benchmark interface that allows the benchmark to associate a real valued *measure* (optionally with upper and lower bounds) with a benchmark name.
This could be supported by a protocol where a "test" reports a real instead of a boolean value.
Test bench-foo type: benchmark-1.0 main-is: bench-foo.hs build-depends: base
Except for the more specialized keywords, there seems to be no need to distinguish tests from benchmarks.
Hmm, that's an interesting idea, to just make benchmarks a different testsuite protocol. Certainly we could prototype it like this. Duncan

On Wed, Oct 5, 2011 at 3:43 AM, Duncan Coutts
Hmm, that's an interesting idea, to just make benchmarks a different testsuite protocol. Certainly we could prototype it like this.
We should try to separate concreate .cabal syntax from implementation. We could definitely try to share much of the implementation, I'm not so sure we want to share the concrete syntax. -- Johan
participants (4)
-
Antoine Latter
-
Duncan Coutts
-
Johan Tibell
-
Tillmann Rendel