[Sorry if this turns out to be a dup, it appears that my first send
got lost, while my followup message went through.]
I ran some longer trials, and noticed a further pattern I wish I could
explain:
I'm comparing the enumeration of the roughly 69 billion atomic
lattices on six atoms, on m
On Apr 19, 2009, at 9:59 PM, Tyson Whitehead wrote:
This leave me wondering how do the absolute numbers compare? Could
the extra
overhead due to the various 32bit issues be giving more room for
better
threading performance? What do you get if you use 32bit GHC with
Linux?
Oddly enough,
I ran some longer trials, and noticed a further pattern I wish I could
explain:
I'm comparing the enumeration of the roughly 69 billion atomic
lattices on six atoms, on my four core, 2.4 GHz Q6600 box running OS
X, against an eight core, 2 x 3.16 Ghz Xeon X5460 box at my department
runnin
Simon Marlow wrote:
Peter Hercek wrote:
The proposed meaning for :next
Lets mark dynamic stack size at a breakpoint (at which we issue
:next) as breakStackSize and its selected expression as breakSpan.
Then :next would single step till any of these is true:
1) current dynamic stack size is s
2009/4/20 Neil Mitchell
>
> Hi,
>
> Using one benchmark I have, which doesn't create any threads, I have:
>
> $ benchmark +RTS -Nx
>
> x time (Seconds)
> 1 2
> 2 2
> 3 2
> 4 3
> 5 3
> 6 3
> 7 3
>
Jason Pepas wrote:
Jason Pepas wrote:
Jason Pepas wrote:
/lusr/bin/ghc -#include cutils.h -DSTAGE=1 -package-name ghc-6.10.1
Um, scratch that. I've apparently become confused as to which release
I was actually building.
-jason
So I've run into a (legitimate) issue with building 6.8.3.
Simon Marlow wrote:
I think the problem you're describing never got fixed: see
http://hackage.haskell.org/trac/ghc/ticket/2970
and then we decided to replace readline with editline (bad mistake) and
later decided to adopt haskeline instead. I believe some OSs (e.g.
FreeBSD) that put readli
Peter Hercek wrote:
Hi,
So I wanted to give implementing :next ghci debugger command a shot. It
looked easy and I could use it. Moreover it would give me an easy way to
implement dynamic stack in ghci (using similar approach as used for
trace) ... well if I would feel like that since I was a
Manuel M T Chakravarty wrote:
Dave Bayer:
In that paper, they routinely benchmark N-1 cores on an N core Linux
box, because of a noticeable falloff using the last core, which can do
more harm than good. I had confirmed this on my four core Linux box,
but was puzzled that my two core MacBook sh
Christopher Lane Hinson wrote:
I regret that I don't have a simpler failure case, but I'm just going to
post this and please advise me. I don't see how to get debugging
symbols to work to even look at a core dump.
Usually I get a segfault, but sometimes I get this:
_rsagl_modelview: intern
Hi,
Using one benchmark I have, which doesn't create any threads, I have:
$ benchmark +RTS -Nx
x time (Seconds)
1 2
2 2
3 2
4 3
5 3
6 3
7 3
8 aborted after 2 minutes
This is using
David Waern wrote:
2009/4/2 Simon Marlow :
I just noticed that the new 'ghc-pkg check' feature exposes a silly mistake
in the definition of the rts package that we ship with GHC 6.10.2:
$ ghc-pkg check
There are problems in package rts-1.0:
include-dirs: PAPI_INCLUDE_DIR doesn't exist or isn't
12 matches
Mail list logo
