Call Arity, oneShot or both
Simon Peyton Jones
simonpj at microsoft.com
Mon Oct 27 22:36:13 UTC 2014
| The biggest loser is calendar, which uses scanl. I am not fully sure
| what went wrong here: Either the one-shot annotation on the lambda’s
| variable got lost somewhere in the pipeline, or despite it being there,
| the normal arity analysis did not use it.
| But there is also a winner, fft2, with -1.5% allocations. Here Call
| Arity was not good enough, but oneShot did the jobs.
It's always useful to discover what happens. Why didn't Call Arity do the job? How did the one-shot-ness get lost? I know it takes work to find out these things; but sometimes they show up something that is easy to fix, and which gives improvements across the board.
| best keep the oneShot annotation in the unfoldings: The isOneShotLambda
| flag is currently not stored in the interface. I work around this by
| making sure that the oneShot function is never inlined in unfoldings,
| but maybe it would be better to serialize the isOneShotLambda flag in
| interfaces, which might have other good effects?
Serialising the one-shot lambda info sounds like a good plan to me.
| If we want as much performance as possible, we should simply include
| both approaches. But there might be other things to consider... so not
| sure what the best thing to do is.
I'd be inclined to do both. Call-arity hits programs where the programmer had no idea that there was something to do; or where the lambda isn't *statically* one-shot... it only becomes so when inlined into a particular context. One-shot-lambdas may help in situations where the one-shot-ness is manifestly too hard to spot.
Good work! Keep a wiki page to describe the choices, point to the tickets, etc
More information about the ghc-devs