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
separate executables and have them communicate via the OS (pipe or port). But that shouldn't be! (the OS being better than Haskell) Is there was a way of partitioning the memory (managed by the ghc RTS) in totally independent parts that each have their stand-alone memory management. Of cour

memory management

2001-10-01 Thread S.D.Mechveliani
. And I tried to switch out the new garbage collector by +RTS -c100 -RTS, and this does not help. On the other hand, this looks like a trouble with memory management: -M100k - all right, -M300k - Heap exhausted. -