Optimizations for mutable structures?
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
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 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
- 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