Malcolm Wallace wrote:
Had you deprecated the non-threaded RTS, we would probably have no
problems described in ticket #2848 :-/
I think you'll have to deprecate it anyway, because it will be more
and more difficult to maintain two versions of code,
we may conduct small survey on amount of usage of old RTS (i mean ask
this in haskell-cafe)
For the only application I tried, using the threaded RTS imposes a 100%
performance penalty - i.e. computation time doubles, compared to the
non-threaded RTS. This was with ghc-6.8.2, and maybe the overhead has
improved since then?
This is a guess, but I wonder if this program is concurrent, and does a
lot of communication between the main thread and other threads? The
main thread is a bound thread, which means that communication between
the main thread and any other thread is much more expensive than
communication between unbound threads, because it involves full OS-level
context switches.
In a concurrent program, don't use the main thread to do any real work,
do a forkIO and wait for the child to complete.
Certainly a 2x performance overhead for the threaded RTS is not
something we normally see. There will be an overhead for MVars and STM,
but even then I'd consider 2x to be deeply suspicious. For most
programs, the overhead should be close to zero.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
