Optimizations for mutable structures?
Talk of uniqueness and so forth on the various Haskell mailing lists
causes me to wonder: with so much imperative code being written in
Haskell these days, to what extent is / should GHC perform standard
imperative optimizations? A few things come to mind:
- Fetch elimination for imperative reads:
writeIORef r e >> acts >> readIORef r === writeIORef r e >> acts
>> return e
readIORef r >>= \e -> acts >> readIORef r ===
readIORef r >>= \e -> acts >> return e
And that sort of thing, generalized for other imperative monadic
types...
My feeling is this doesn't come up much in code as written on
the page,
but might well be relevant after inlining.
- Some way to turn the following idiom into memcpy (for any array
type):
do a <- newArray
writeArray a 0 e0
writeArray a 1 e1
writeArray a 2 e2
...etc...
What say others? Is there a need yet? (I don't honestly know the
answer!)
-Jan-Willem Maessen
Jan-Willem Maessen <jmaessen@alum.mit.edu> writes:
- Fetch elimination for imperative reads: writeIORef r e >> acts >> readIORef r === writeIORef r e >> acts >> return e
This transformation is valid only on single-threaded systems. If there is any possibility of an IORef being shared across threads, you are out of luck. Regards, Malcolm
On Wed, Dec 07, 2005 at 08:30:36AM -0500, Jan-Willem Maessen wrote:
What say others? Is there a need yet? (I don't honestly know the answer!)
Although I don't think impertive optimizations at this high of a level will benefit much for how much they cost, after the code has been processed and is in cmm form or about to be I think there is a lot of room for improvement. even a few basic optimizations there can help. ideally we would rely on gcc, but it seems to fall down on a lot of code that ghc generates. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (3)
-
Jan-Willem Maessen -
John Meacham -
Malcolm Wallace