Hello Scott,
Wednesday, May 30, 2007, 1:42:22 AM, you wrote:
> I've included your implementation for comparison, as well as a simple
> pure matrix multiplication function, but I'm having trouble tracking
> them down in the profiling. I think all of their cycles are being
> counted under main, but
On Tue, May 29, 2007 at 09:58:38PM -0400, Alec Berryman wrote:
> Simon Marlow on 2007-05-29 16:05:49 +0100:
>
> > Ben Sinclair wrote:
> > >Hello, I've had a problem with GHC.Prim when compiling the darcs HEAD
> > >lately. When I compile it in the normal way with no special options
> > >
> > >>sh b
Simon Marlow on 2007-05-29 16:05:49 +0100:
> Ben Sinclair wrote:
> >Hello, I've had a problem with GHC.Prim when compiling the darcs HEAD
> >lately. When I compile it in the normal way with no special options
> >
> >>sh boot && ./configure && make && make install
> >
>
> It works for me, with last
Hi Maxime,
On Sun, May 27, 2007 at 03:58:47AM +0200, Maxime Henrion wrote:
>
> To be more precise, I want to know how to create the
> ghc-$version-$arch-boot.tar.bz2 file to redistribute to users so
> that they can build GHC easily, and that on a platform that already
> has a working (but older)
You're right. I broke them when experimenting to see where the cycles
were going. I've fixed them, but the other pair of functions, named
gaussElim2, were correct and the issue remains that unsafeRead appears
slower than readArray.
I've included your implementation for comparison, as well as a si
Matthias Kilian wrote:
I'm currently working on updating the GHC port to 6.6.1 for OpenBSD,
and when I run the testsuite (ghc-regress), all test cases for the
way "threaded1", i.e. debug + threaded bail out with an assertion
failure:
Blocks: 132 live + 123 free = 255 total (508 around)
conc010
Ben Sinclair wrote:
Hello, I've had a problem with GHC.Prim when compiling the darcs HEAD
lately. When I compile it in the normal way with no special options
sh boot && ./configure && make && make install
it compiles correctly, but if I attempt to compile
module Main where
import GHC.Prim
instead of (!) (or readArray in stateful code) helped a lot. So then I
went to optimize my gaussian elimination function and found just the
opposite. unsafeRead is slower than readArray. This struck me as very
The functions gaussElimSafe and gaussElimUnsafe are different in their
outputs (*).
That is indeed odd. As I recall unsafeRead doesn't do array-bound checking, and
that ought to be faster, always. I don't have time to look into this myself
(soon, anyway), but
a) if someone does (look at Core!) I'd be interested to know the outcome
b) unless it turns out to be a red herring, wo
