Re: Threads and memory management

2009-04-30 Thread Don Stewart
marlowsd: > On 28/04/2009 17:25, Johannes Waldmann wrote: >> Thanks for your comments. >> >> >>> Check whether it is GC-bound by using +RTS -sstderr. >> >> Well yes, it does a lot of GC (there's no way for the compiler >> to optimize away the list of primes) because that was the point >> of the e

Re: Threads and memory management

2009-04-30 Thread Simon Marlow
On 28/04/2009 17:25, Johannes Waldmann wrote: Thanks for your comments. Check whether it is GC-bound by using +RTS -sstderr. Well yes, it does a lot of GC (there's no way for the compiler to optimize away the list of primes) because that was the point of the example: to confirm (or disprov

Re: Threads and memory management

2009-04-28 Thread Johannes Waldmann
Thanks for your comments. > Check whether it is GC-bound by using +RTS -sstderr. Well yes, it does a lot of GC (there's no way for the compiler to optimize away the list of primes) because that was the point of the example: to confirm (or disprove) that GC hurts parallelism (at the moment).

Re: Threads and memory management

2009-04-28 Thread Simon Marlow
On 27/04/2009 11:29, Bulat Ziganshin wrote: Hello Simon, Monday, April 27, 2009, 2:13:26 PM, you wrote: This is a very strange result: the user time should not *decrease*, but rather should stay the same or increase a bit when adding cores. If ability to run two threads simultaneous may inc

Re: Threads and memory management

2009-04-27 Thread Don Stewart
I've added more notes to this page: http://haskell.org/haskellwiki/Performance/Parallel berthold: > >> Message: 8 >> Date: Fri, 24 Apr 2009 19:20:46 +0200 >> From: Johannes Waldmann >> Subject: Threads and memory management >> To: "glasgow-haskel

Re[2]: Threads and memory management

2009-04-27 Thread Bulat Ziganshin
Hello Simon, Monday, April 27, 2009, 2:13:26 PM, you wrote: > This is a very strange result: the user time should not *decrease*, but > rather should stay the same or increase a bit when adding cores. If ability to run two threads simultaneous may increase performance in some scenarios. one ex

Re: Threads and memory management

2009-04-27 Thread Simon Marlow
On 25/04/2009 13:31, j.waldmann wrote: Here is some more data. It seems the behaviour depends on 32/64 bit arch? ### waldm...@master:~/tmp$ uname -a Linux master 2.6.18-6-amd64 #1 SMP Fri Dec 12 05:49:32 UTC 2008 x86_64 GNU/Linux waldm...@mas

Re: Threads and memory management

2009-04-27 Thread Jost Berthold
Message: 8 Date: Fri, 24 Apr 2009 19:20:46 +0200 From: Johannes Waldmann Subject: Threads and memory management To: "glasgow-haskell-users@haskell.org" Message-ID: <49f1f4ee.8070...@imn.htwk-leipzig.de> Content-Type: text/plain; charset="iso-8859-1" Dear all

Re: Threads and memory management

2009-04-25 Thread j.waldmann
context: http://www.nabble.com/Threads-and-memory-management-tp23221239p23231596.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://w

Threads and memory management

2009-04-24 Thread Johannes Waldmann
Dear all, I was wondering what is the current status of the ghc RTS with respect to threading. Is it true that the allocator and deallocator (garbage collector) are still single-threaded? I made this example: import Control.Concurrent import Control.Concurrent.QSemN primes1 = sieve [ 2 .. ] pr