--- Don Stewart [EMAIL PROTECTED] wrote:
-snip
How should the benchmarks game approach multicore?
Well, there's a famous paper,
Algorithm + Strategy = Parallelism
I'd imagine we use the benchmark game's algorithms, but let
submitters determine the strategy. Then the results
On Aug 29, 2008, at 9:11 AM, Isaac Gouy wrote:
The benchmarks game always seems to demand somewhat unnatural acts and
here's another - is there an effective way to /prevent/ ghc using
multiple cores when multiple cores are available? Can we force ghc to
only use one core on the quadcore
Wow! 3x the performance for a simple change. Frustrating that there
isn't a protable/standard way to express this. Also frustrating that
the threaded version doesn't improve on the situation (utilization is
back at 50%).
GR, retraction, retraction!
I was obviously too tired when I
dons:
(Where I note GHC is currently in second place, though we've not
submitted any parallel programs yet).
We might call that the thread-ring effect :-)
Also CC'd Isaac, Mr. Shootout. Isaac, is the quad core shootout
open for business? Should we rally the troops?
iirc there was some
igouy2:
dons:
(Where I note GHC is currently in second place, though we've not
submitted any parallel programs yet).
We might call that the thread-ring effect :-)
Also CC'd Isaac, Mr. Shootout. Isaac, is the quad core shootout
open for business? Should we rally the troops?
--- Don Stewart [EMAIL PROTECTED] wrote:
-snip-
So still consolidating the system.
Pretty much.
Do I understand though, that if we submit, say, a quad-core version
of
binary-trees, for example, using `par` and -N4, it'll go live on the
benchmark page?
That's an open question - should
igouy2:
--- Don Stewart [EMAIL PROTECTED] wrote:
-snip-
So still consolidating the system.
Pretty much.
Do I understand though, that if we submit, say, a quad-core version
of
binary-trees, for example, using `par` and -N4, it'll go live on the
benchmark page?
That's
On Sun 2008-08-24 11:03, Thomas M. DuBuisson wrote:
Yay, the multicore version pays off when the workload is non-trivial.
CPU utilization is still rather low for the -N2 case (70%). I think the
Haskell threads have an affinity for certain OS threads (and thus a
CPU). Perhaps it results in a
jed:
On Sun 2008-08-24 11:03, Thomas M. DuBuisson wrote:
Yay, the multicore version pays off when the workload is non-trivial.
CPU utilization is still rather low for the -N2 case (70%). I think the
Haskell threads have an affinity for certain OS threads (and thus a
CPU). Perhaps it
dons:
Simon Marlow sez:
The thread-ring benchmark needs careful scheduling to get a speedup
on multiple CPUs. I was only able to get a speedup by explicitly
locking half of the ring onto each CPU. You can do this using
GHC.Conc.forkOnIO in GHC 6.8.x, and you'll also need
thomas.dubuisson:
dons:
Simon Marlow sez:
The thread-ring benchmark needs careful scheduling to get a speedup
on multiple CPUs. I was only able to get a speedup by explicitly
locking half of the ring onto each CPU. You can do this using
GHC.Conc.forkOnIO in GHC 6.8.x,
On 24 Aug 2008, at 01:26, Brandon S. Allbery KF8NH wrote:
On 2008 Aug 23, at 18:34, Krzysztof Skrzętnicki wrote:
Recently I wrote computation intensive program that could easily
utilize both cores. However, there was overhead just from compiling
with -threaded and making some forkIO's. Still,
On 24 Aug 2008, at 06:31, Thomas M. DuBuisson wrote:
That's really interesting -- I just tried this.
Compiling not using -threaded: 1.289 seconds
Compiling using -threaded, but not running with -N2: 3.403 seconds
Compiling using -threaded, and using -N2: 55.072 seconds
I was hoping to
Hmm thanks, that's interesting -- I was think it was probably caused
by OS X, but it appears to happen on Linux too. Could you try running
the old code too, and see if you experience the order of magnitude
slowdown too?
The original program on my Linux 2.6.26 Core2 Duo:
[EMAIL
Lo guys,
I thought you'd like to know about this result. I've been playing
with the debian language shootout programs under OS X, looking at how
fast Haskell code is compared to C on OS X, rather than linux.
Interestingly, Haskell comes out rather better on OS X than it did on
Linux.
2008/8/23 Thomas Davie [EMAIL PROTECTED]:
Finally, that threading example... WOW! 65 times faster, and the code is
*really* simple. The C on the other hand is a massive mess.
I've been wondering about this, but I can't check because I don't have
a multi core cpu. I've heard GHC's single
On 23 Aug 2008, at 20:01, Luke Palmer wrote:
2008/8/23 Thomas Davie [EMAIL PROTECTED]:
Finally, that threading example... WOW! 65 times faster, and the
code is
*really* simple. The C on the other hand is a massive mess.
I've been wondering about this, but I can't check because I don't
On 2008 Aug 23, at 18:34, Krzysztof Skrzętnicki wrote:
Recently I wrote computation intensive program that could easily
utilize both cores. However, there was overhead just from compiling
with -threaded and making some forkIO's. Still, the overhead was not
larger than 50% and with 4 cores I
That's really interesting -- I just tried this.
Compiling not using -threaded: 1.289 seconds
Compiling using -threaded, but not running with -N2: 3.403 seconds
Compiling using -threaded, and using -N2: 55.072 seconds
I was hoping to see a relative improvement when introducting an
19 matches
Mail list logo
