I don't know Haskell very well, but even I can tell, looking at, for
example, the N-body benchmark, that the Haskell code is probably not
type-safe, and the tricks used in it would not be usable in a larger
program (see below).
The task is essentially a pure computation: take a list of bodies
havi
jhc0033:
> I don't know Haskell very well, but even I can tell, looking at, for
> example, the N-body benchmark, that the Haskell code is probably not
> type-safe, and the tricks used in it would not be usable in a larger
> program (see below).
>
> The task is essentially a pure computation: take
dons:
> jhc0033:
> > I don't know Haskell very well, but even I can tell, looking at, for
> > example, the N-body benchmark, that the Haskell code is probably not
> > type-safe, and the tricks used in it would not be usable in a larger
> > program (see below).
> >
> > The task is essentially a pur
I don't know Haskell very well, but
Paul: "I'm not racist but . . ." :-)
even I can tell, looking at, for
example, the N-body benchmark, that the Haskell code is probably not
type-safe, and the tricks used in it would not be usable in a larger
program (see below).
The task is esse
On Sun, May 11, 2008 at 1:40 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> n-body requires updating a global array of double values to be
I think the array and any side-effects on it can and should be local
to the simulation procedure.
> competitive performance-wise, though we haven't really nail
jhc0033:
> On Sun, May 11, 2008 at 1:40 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
>
> > n-body requires updating a global array of double values to be
>
> I think the array and any side-effects on it can and should be local
> to the simulation procedure.
>
> > competitive performance-wise, thou
--- On Mon, 5/12/08, PR Stanley <[EMAIL PROTECTED]> wrote:
> >I don't know Haskell very well, but
>
>
> Paul: "I'm not racist but . . ." :-)
Relevant Haskell humor:
Humor/Homework - HaskellWiki: see line 3:
http://www.haskell.org/haskellwiki/Humor/Homework
Benjamin L. Russell
J C wrote:
...
If anyone has a version of the N-body benchmark, where the simulation
is a type-safe pure function, I would very much like to see and time
it.
Hello JC, I think you've set yourself a challenge there :) Welcome to
Haskell programming. Taking a Shootout entry and playing with it is
On Mon, May 12, 2008 at 4:38 AM, Richard Kelsall
<[EMAIL PROTECTED]> wrote:
> Hello JC, I think you've set yourself a challenge there :) Welcome to
> Haskell programming. Taking a Shootout entry and playing with it is
> a great way to learn Haskell. The Shootout provides an example in your
> f
On 2008 May 13, at 0:26, J C wrote:
On the other hand, if the experts can't help using malloc, unsafe*,
global mutables and IO, I'll be able to conclude that this is probably
what it takes to make Haskell run fast :-(
Very few of the shootout entries have been revisited since most of the
im
J C wrote:
<[EMAIL PROTECTED]> wrote:
Hello JC, I think you've set yourself a challenge there :) Welcome to
Haskell programming. Taking a Shootout entry and playing with it is
a great way to learn Haskell. The Shootout provides an example in your
favourite previous language for comparison a
Well, it would be meaningful for your own experience in learning Haskell.
Some time ago somebody took a shot at nbodies using pure immutable
structures, and as I recall, got within about 4x the performance of mutable
structures. In 6.6, an STArray based approach was maybe 2x slower, but by
now it m
Bulat Ziganshin wrote:
Hello Richard,
Tuesday, May 13, 2008, 6:10:54 PM, you wrote:
because I was compiling my splitAt with -O2 optimisation as opposed
to the built-in version being compiled with -O. The extra optimisations
in -O2 are a new feature of GHC (and -O2 is slower to compile which is
Bulat Ziganshin wrote:
Hello Richard,
In July 2007 -O2 was documented in GHC as making no difference to
the speed of programs :
http://www.haskell.org/pipermail/haskell-cafe/2007-July/029118.html
it's because ghc is 15 years old and its documentation may be not
updated as things changes :)
Bulat Ziganshin wrote:
Hello Richard,
Yes it was just a plausible guess, but not contradicted by the experts.
And that was using the Windows version of GHC so other versions may
have better optimisation. I don't know how to check, maybe the experts
can illuminate the subject?
note that my let
Hello Richard,
Tuesday, May 13, 2008, 6:10:54 PM, you wrote:
> because I was compiling my splitAt with -O2 optimisation as opposed
> to the built-in version being compiled with -O. The extra optimisations
> in -O2 are a new feature of GHC (and -O2 is slower to compile which is
> why the built-in
Hello Richard,
Tuesday, May 13, 2008, 7:56:36 PM, you wrote:
> In July 2007 -O2 was documented in GHC as making no difference to
> the speed of programs :
> http://www.haskell.org/pipermail/haskell-cafe/2007-July/029118.html
it's because ghc is 15 years old and its documentation may be not
upda
Hello Richard,
Tuesday, May 13, 2008, 8:23:59 PM, you wrote:
> Yes it was just a plausible guess, but not contradicted by the experts.
> And that was using the Windows version of GHC so other versions may
> have better optimisation. I don't know how to check, maybe the experts
> can illuminate th
18 matches
Mail list logo
