[Haskell-cafe] ANNOUNCE: StrictBench 0.1 - Benchmarking code
through strict evaluation
Kenneth Hoste
kenneth.hoste at ugent.be
Mon Jun 8 09:29:27 EDT 2009
Hi all,
On Jun 8, 2009, at 15:12 , Magnus Therning wrote:
> On Mon, Jun 8, 2009 at 1:56 PM, Martijn van
> Steenbergen<martijn at van.steenbergen.nl> wrote:
>> Magnus Therning wrote:
>>>
>>> Is there no way to force repeated evaluation of a pure value? (It'd
>>> be nice to be able to perform time measurements on pure code so that
>>> it's possible to compare Haskell implementations of algorithms to
>>> implementations in other languages, without running into confounding
>>> factors.)
>>
>> I'm really curious about this too.
>>
>> My guess is that the answer is "no" because doing so would (among
>> other
>> things) mean a thunk have to be copied first before it is
>> evaluated, to
>> preserve the unevaluated version. And what guarantee is there that
>> values
>> further down the expression haven't been evaluated already?
>> Efficient lazy
>> evaluation is hard; inefficient lazy evalation is even harder. ;-)
>
> Yes, I guessed as much. I was hoping that there might be some way of
> tricking GHC into being more inefficient though, something like a
> rollback in evaluation state.
I've been playing around with MicroBench [1], and I believe there is a
way
to trick GHC (at least the 6.10.2 version) into being inefficient.
Below is a snippet of the code I used to benchmark various
implementations
of a function. The key is partial function application and the IO monad.
Don't ask me why it works, but I believe it does.
-- benchmark a given function by applying it n times to the given value
benchmark :: (a -> b) -> a -> Int -> IO()
benchmark f x n = do
r <- mapM (\y -> return $! f y) (replicate n x)
performGC
return ()
The performGC might not be 100% necessary, but I see it as a part of the
function evaluation (i.e. make the runtime clean up the mess the
function made).
Of course this assumes performGC to be called before using "benchmark".
Note: MicroBench was doing something similar, but was using mapM_
instead,
which no longer seems to fool GHC into evaluating the function n
times. mapM
does seem to work though.
K.
--
Kenneth Hoste
Paris research group - ELIS - Ghent University, Belgium
email: kenneth.hoste at elis.ugent.be
website: http://www.elis.ugent.be/~kehoste
blog: http://boegel.kejo.be
More information about the Haskell-Cafe
mailing list