Hello,
IMO, the conclusion about instant cache misses due to several threads
sharing memory and/or performing large memory consumption is very highly
probable, especially on Intel CPUs with shared L2 cache.
I have several examples, where threading means significant time
consumption increas
Bulat Ziganshin wrote:
Hello Andrew,
Tuesday, March 3, 2009, 9:21:42 PM, you wrote:
I just tried it with GHC 6.10.1. Two capabilities is still slower. (See
attachments. Compiled with -O2 -threaded.)
i don't think so:
Total time4.88s ( 5.14s elapsed)
Total time7.08s (
So, apparently the 6.10.1 code runs amiss of this bug:
http://hackage.haskell.org/trac/ghc/ticket/2747
I'll be upgrading to HEAD now. If no-one else gets around to it first,
I'll probably post some more benchmarks afterwards.
___
Haskell-Cafe mailing lis
Hello Andrew,
Tuesday, March 3, 2009, 9:21:42 PM, you wrote:
> I just tried it with GHC 6.10.1. Two capabilities is still slower. (See
> attachments. Compiled with -O2 -threaded.)
i don't think so:
Total time4.88s ( 5.14s elapsed)
Total time7.08s ( 4.69s elapsed)
so with 1 thr
andrewcoppin:
> Svein Ove Aas wrote:
>> For what it's worth, I tried it myself on 6.10.. details follow, but
>> overall impression is that while you lose some time to overhead, it's
>> still 50% faster than unthreaded.
On a quad core, ghc 6.10 snapshot from today:
Single threaded
whirlpool$
Svein Ove Aas wrote:
For what it's worth, I tried it myself on 6.10.. details follow, but
overall impression is that while you lose some time to overhead, it's
still 50% faster than unthreaded.
Damn. Somebody beat me to it. :-)
While trying to optimize it, I ran "./test +RTS -N2 -H64m -M64
I feel the need to point something out here.
Both for me and Andrew, the program tops out at allocating ~22MB of
memory - in total, over its whole run.
Why, then, is max heap size over a gigabyte?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
h
Brandon S. Allbery KF8NH wrote:
On 2009 Mar 3, at 12:54, mwin...@brocku.ca wrote:
I am using GHC 6.8.3. The -O2 option made both runs faster but the 2
core run
is still much slower that the 1 core version. Will switching to 6.10
make the difference?
If GC contention is the issue, it should.
On Tue, Mar 3, 2009 at 6:54 PM, wrote:
> I am using GHC 6.8.3. The -O2 option made both runs faster but the 2 core run
> is still much slower that the 1 core version. Will switching to 6.10 make the
> difference?
>
There are a lot of improvements; it's certainly worth a try.
For what it's worth
On 2009 Mar 3, at 12:54, mwin...@brocku.ca wrote:
I am using GHC 6.8.3. The -O2 option made both runs faster but the 2
core run
is still much slower that the 1 core version. Will switching to 6.10
make the difference?
If GC contention is the issue, it should.
--
brandon s. allbery [solaris
I am using GHC 6.8.3. The -O2 option made both runs faster but the 2 core run
is still much slower that the 1 core version. Will switching to 6.10 make the
difference?
On 3 Mar 2009 at 18:46, Svein Ove Aas wrote:
> On Tue, Mar 3, 2009 at 6:41 PM, Don Stewart wrote:
> > allbery:
> >> On 2009 Mar
On Tue, Mar 3, 2009 at 6:41 PM, Don Stewart wrote:
> allbery:
>> On 2009 Mar 3, at 12:31, mwin...@brocku.ca wrote:
>>> In both runs the same computations are done (sequentially resp.
>>> parallel), so the gc should be the same. But still using 2 cores is
>>> much slower than using 1 core (same pro
allbery:
> On 2009 Mar 3, at 12:31, mwin...@brocku.ca wrote:
>> In both runs the same computations are done (sequentially resp.
>> parallel), so the gc should be the same. But still using 2 cores is
>> much slower than using 1 core (same program - no communication).
>
> The same GCs are done, but G
mwinter:
> Hi,
>
> I tried a get into concurrent Haskell using multiple cores. The program below
> creates 2 task in different threads, executes them, synchronizes the threads
> using MVar () and calculates the time needed.
>
> import System.CPUTime
> import Control.Concurrent
> import Control.C
Hello mwinter,
Tuesday, March 3, 2009, 8:31:12 PM, you wrote:
not same :) when you perform two computations at the same time,
you have 2x more memory allocated that means that each GC will need
more time. and don't forget that GC is single-threaded
> In both runs the same computations are done
On 2009 Mar 3, at 12:31, mwin...@brocku.ca wrote:
In both runs the same computations are done (sequentially resp.
parallel), so the gc should be the same. But still using 2 cores is
much slower than using 1 core (same program - no communication).
The same GCs are done, but GC has to be done on
It gets a bit faster in general but the problem remains. I have two
threads in both runs, once I use 1 core and then 2 cores. The second
run is much slower.
On 3 Mar 2009 at 17:32, Sebastian Sylvan wrote:
>
>
>
> On Tue, Mar 3, 2009 at 5:31 PM, wrote:
> In both runs the same computations
On Tue, Mar 3, 2009 at 5:31 PM, wrote:
> In both runs the same computations are done (sequentially resp.
> parallel), so the gc should be the same. But still using 2 cores is
> much slower than using 1 core (same program - no communication).
Might there not be contention in the allocator/GC tha
In both runs the same computations are done (sequentially resp.
parallel), so the gc should be the same. But still using 2 cores is
much slower than using 1 core (same program - no communication).
On 3 Mar 2009 at 20:21, Bulat Ziganshin wrote:
> Hello mwinter,
>
> Tuesday, March 3, 2009, 8:09:21
Hello mwinter,
Tuesday, March 3, 2009, 8:09:21 PM, you wrote:
>anybody give me an idea what I am doing wrong?
1. add -O2 to compile command
2. add +RTS -s to run commands
your program execution time may be dominated by GCs
--
Best regards,
Bulatmailto:bulat.z
Hi,
I tried a get into concurrent Haskell using multiple cores. The program below
creates 2 task in different threads, executes them, synchronizes the threads
using MVar () and calculates the time needed.
import System.CPUTime
import Control.Concurrent
import Control.Concurrent.MVar
myTask1 =
21 matches
Mail list logo
