RE: Haskell profiling and performance
That's unexpected to me at least. We'll investigate. But probably not until after Easter. If you can send a program (smaller the better) that demonstrates this performance difference, we'd make much faster progress. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Ketil Malde | Sent: 07 April 2004 07:33 | To: [EMAIL PROTECTED] | Subject: Haskell profiling and performance | | | Hi, | | Am I doing something wrong, or did profiling performance drop an order | of magnitude with GHC 6.2? When I compile my program with '-prof | -auto-all', it takes about ten times as long to run as it does | without. I use -O2 in both cases, and run without any run-time | profiling options switched on. | | (The reported time, OTOH, seems about right) | | I though that previously profiling-compiling programs would only have | marginal effects, and only running with heap profiling on would really | slow things down. | | If this is a recent 'feature' and not just my brain getting its wires | crossed again, is there any way to alleviate this (downgrade to x.y, | build CVS HEAD, whatever)? | | (GHC 6.2 on Linux, tested with RPM package and Gentoo binary | distribution) | | -kzm | -- | If I haven't seen further, it is by standing in the footprints of giants | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: What means MutVar# ?
Hans Nikolaus Beck wrote:
[...] I've readed tha writeIORef (and readIoRef etc) is used to write directly
to memory places fo implementing variables, as in example in HOpenGL used. Is
this also Haskell standard ?
Huh? I'm not sure what you mean exactly, but with the help of unsafePerformIO
and a pragma for clever compilers you can simulate something like a global
variable in Haskell. Here an excerpt from the GLUT menu handling module:
{-# NOINLINE theMenuTable #-}
theMenuTable :: IORef MenuTable
theMenuTable = unsafePerformIO (newIORef emptyMenuTable)
getMenuTable :: IO MenuTable
getMenuTable = readIORef theMenuTable
modifyMenuTable :: (MenuTable - MenuTable) - IO ()
modifyMenuTable = modifyIORef theMenuTable
Definitely not something to be proud of, but quite handy from time to time. :-)
Alternatives are passing the IORef to every function which needs it (but this
would clutter up the GLUT API in the above case) or using the FFI for holding
global data on the C side. GHC uses a similar hack internally, too, BTW.
Cheers,
S.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unsafePerformIO
Sven Panne wrote:
Huh? I'm not sure what you mean exactly, but with the help of unsafePerformIO
and a pragma for clever compilers you can simulate something like a global
variable in Haskell. Here an excerpt from the GLUT menu handling module:
{-# NOINLINE theMenuTable #-}
theMenuTable :: IORef MenuTable
theMenuTable = unsafePerformIO (newIORef emptyMenuTable)
...
Definitely not something to be proud of, but quite handy from time to time. :-)
Alternatives are passing the IORef to every function which needs it (but this
would clutter up the GLUT API in the above case) or using the FFI for holding
global data on the C side. GHC uses a similar hack internally, too, BTW.
This is not just handy from time to time, but very frequently. I've
just discovered it occurs about 100 times in 100K LOC that I am
responsible for, so often that I have stopped feeling guilty about it.
I don't really know what else I could do. One solution would be to use
implicit parameters to pass a global state variable around, but this would
require me to change the type of huge numbers of functions, since implicit
parameters are still explicit in types.
I don't remember having any actual bugs caused by unsafePerformIO. Well,
only one, before I knew about putting NOINLINE in.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
