OK, well I now have so much data sitting in from of me I don't even know
*what* I'm seeing any more. I have made several significant discoveries
though...
Consider the following:
msort [] = []
msort [x] = [x]
msort xs =
let
xs0 = msort (split0 xs)
xs1 = msort (split1 xs)
in
On Apr 20, 2008, at 15:41 , Andrew Coppin wrote:
1. Does running the GC force all threads to stop? I know some GC
designs do this, but I have no idea how the one GHC implements works.
2. Is the GC still single-threaded? (GHC 6.8.2 here.)
Full GC is single-threaded and stops the entire
On Apr 20, 2008, at 15:51 , Brandon S. Allbery KF8NH wrote:
On Apr 20, 2008, at 15:41 , Andrew Coppin wrote:
3. Is there any way for a running Haskell program to find out how
much heap space is currently allocated / used / free? I know you
can find out how much wall time and CPU time you've
Hello Andrew,
Sunday, April 20, 2008, 11:41:52 PM, you wrote:
yes, GC behavior has significant impact on any new language (i mean
java, c#, f# and so on)
1. Does running the GC force all threads to stop? I know some GC designs
do this, but I have no idea how the one GHC implements works.
yes
Bulat Ziganshin wrote:
3. Is there any way for a running Haskell program to find out how much
heap space is currently allocated / used / free?
i think it's possible by asking internal RTS vars. SM once suggested
to add to GHC library that provides official way to ask this info but
no
Bulat Ziganshin wrote:
yes. multi-threaded GC is planned gor next ghc version, afair
To be clear, it'll be a parallel GC, not a concurrent one. The former
still stops all threads, but runs the collector on multiple cores at
once. The latter performs collection while mutator threads are still
OK, so just for fun, I decided to try implementing a parallel merge sort
using the seq and par combinators. My plan was to generate some
psuedo-random data and time how long it takes to sort it. To try to
account for lazy evaluation, what the program actually does is this:
1. Write the input
On Sat, Apr 19, 2008 at 10:56 AM, Andrew Coppin
[EMAIL PROTECTED] wrote:
Can anybody explain any of this behaviour? I have no idea what I'm
benchmarking, but it certainly doesn't appear to be the performance of a
parallel merge sort!
It would be much easier to draw sound conclusions if you
Denis Bueno wrote:
It would be much easier to draw sound conclusions if you would post your code.
Erm... good point.
See attachments.
module Sort where
import Control.Parallel
import Control.Parallel.Strategies
split0 [] = []
split0 (x:xs) = x : split1 xs
split1 [] = []
split1 (x:xs) =
Hello Andrew,
Saturday, April 19, 2008, 6:56:10 PM, you wrote:
OK, so just for fun, I decided to try implementing a parallel merge sort
coincedence - now i'm writing a parallel compression algorithm, very
much like parallel bzip2, but using ghc, of course
Weird thing #1: The first time you
I can't offer definite answers to your questions, but I can suggest a few
issues you should consider:
1. Merge sort doesn't parallelize all that well--when the blocks are
small, the parallelization overhead is large in comparison with the
productive work that is to be done, and when the
On Apr 19, 2008, at 9:56 AM, Andrew Coppin wrote:
Weird thing #3: Adding the -threaded compiler option makes
*everything* run a few percent faster. Even with only 1 OS thread.
I had a similar thing happen to me once.
Hello Andrew,
Saturday, April 19, 2008, 7:50:30 PM, you wrote:
this looks like disk caching effects. if data are read from disj on
first run and from disk cache on the next runs, this only means that
your algorithm works faster than reading its data from disk
Negative. No data is ever
Okay, here are my thoughts:
On Apr 19, 2008, at 9:56 AM, Andrew Coppin wrote:
Weird thing #1: The first time you sort the data, it takes a few
seconds. The other 7 times, it takes a split second - roughly 100x
faster. Wuh?
This looks like standard memoization to me. I know, I know, GHC
On Apr 19, 2008, at 11:50 , Andrew Coppin wrote:
Bulat Ziganshin wrote:
there are plenty of reasons: first, -threaded make i/o overlapped
with calculations.
Not with -N1.
Depending on how it's implemented (I not being a ghc guru), possibly
even with -N1 as long as it's using the
Hello Brandon,
Saturday, April 19, 2008, 8:24:03 PM, you wrote:
contention. (Note that resource locking will be done by the threaded
runtime even with only one thread, so you will see some slowdowns
especially in I/O-related code.)
yes, i forget about this. Simon wrote once that locking
On Apr 19, 2008, at 11:53 , Murray Gross wrote:
2. You need to account for I/O buffering (not only by your OP
system in RAM, but by your disk controller)--after the first set of
I/O operations, your data may be in buffers, so subsequent uses may
retrieve data from buffers rather than from
Bulat Ziganshin wrote:
Hello Brandon,
Saturday, April 19, 2008, 8:24:03 PM, you wrote:
contention. (Note that resource locking will be done by the threaded
runtime even with only one thread, so you will see some slowdowns
especially in I/O-related code.)
yes, i forget about this.
18 matches
Mail list logo
