| Are there any concoctions of flags/pragmas/techniques to coax GHC into
| unrolling a function (or rather an IO computation in this case) a
couple
| of iterations. There was another (admittedly also noddy) program that
I
| could get to near gcc, but only by unrolling by hand (though Ian's TH
| st
"Shawn P. Garbett" <[EMAIL PROTECTED]> wrote,
> I redid both programs to make them equivalent in action. The haskell program
> was not actually summing the results, the C program was not checking array
> bounds (Haskell does), the C program did not initialize the array and the C
> program didn'
On Fri, Jun 27, 2003 at 12:10:55PM -0500, Shawn P. Garbett wrote:
> - --
> New Haskell version with Unboxed Array
> Note:it was a simple change of import and type
> - -
> import Data.Array.Unboxed
>
> a :: UArray Int Int
>
> At best case for Haskell, 15.5 times slower. The thing about
> bounds checking,
> in Haskell it's always there. In C, you might have it, you
> might not there is
> no certainty by the language, only by design and
> implementation. So with C,
> one is free to live dangerously.
If you're usi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 26 June 2003 05:46 pm, Lex Stein wrote:
> Great, thanks. Those suggestions narrow the gap from GHC -O being 330x
> slower than GCC -O3 to it being 20x slower. Here are the new results:
>
> gcc -O3 0.54s
> ocamlopt 1.11s
> ghc -O
On Fri, 27 Jun 2003 09:36:36 +0100
"Simon Peyton-Jones" <[EMAIL PROTECTED]> wrote:
> Several comments
>
> 1. In Haskell "mod" is a lot more expensive than "rem", because it
> involves careful jiggery pokery with the sign of the result. That's
> why your boxed version was slower (nothing to do
Several comments
1. In Haskell "mod" is a lot more expensive than "rem", because it
involves careful jiggery pokery with the sign of the result. That's
why your boxed version was slower (nothing to do with boxing).
2. GHC does indeed optimise away the array access if you aren't
careful, and d
On Thu, 26 Jun 2003 17:48:17 -0400 (EDT)
Lex Stein <[EMAIL PROTECTED]> wrote:
>
> Hi, I'm measuring Haskell, Ocaml, and C, small array access
> performance and the results with Haskell (GHC 5.02.2) are so bad that
> I think I must be doing something wrong. Indeed, I am hardly a
> seasoned Haskell
essentially you are being unfare to ghc
> > by making it seq the array element, but not doing the same to GCC. even
> > with -O0, gcc gets rid of the loop body.
> >
> > one solution: add in the assembly to actually read the array (i'm too
> > lazy and busy to do this).
> >
> &
gt;
>
> --
> Hal Daume III | [EMAIL PROTECTED]
> "Arrest this man, he talks in maths." | www.isi.edu/~hdaume
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf
is man, he talks in maths." | www.isi.edu/~hdaume
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Lex Stein
> Sent: Thursday, June 26, 2003 3:46 PM
> To: Sven Panne
> Cc: [EMAIL PROTECTED]
> Subject: Re: haskell array access
Great, thanks. Those suggestions narrow the gap from GHC -O being 330x
slower than GCC -O3 to it being 20x slower. Here are the new results:
gcc -O3 0.54s
ocamlopt 1.11s
ghc -O 10.76s
ocamlc 14.10s
GHC is still pretty slow for native x86 instruction code. Is there any way
to f
Well, part of the answer is definitely that the Haskell program is the
*only* one which really uses the array elements. :-) I guess that the
compilers for the other languages simply remove the array access from
the generated code (gcc definitely does, only an empty loop remains).
Another reason is
Hi, I'm measuring Haskell, Ocaml, and C, small array access performance
and the results with Haskell (GHC 5.02.2) are so bad that I think I must
be doing something wrong. Indeed, I am hardly a seasoned Haskell
programmer. My results are:
ghc -O 61.60s
gcc -O3 0.20s
Ocamlopt 1.11s (t
14 matches
Mail list logo
