"Andreas C. Doering" <[EMAIL PROTECTED]> wrote,
> > [1] admittedly not many. Are people using Haskell having problems
> > getting good enough performance? Enough to regret choosing it as a
> > language? (This is not a rhetoric question!)
> No and yes.
> I use Haskell mainly for combinational p
| In that regard, I think the biggest problems remaining are the lack of a
| standard "fast" string type, and some remaining warts in hugs. These are
| maybe easiest to see when you do something like "strace -c" on a hugs
| program and the comparable perl program. So, in my naive version of
| "h
On 21 Mar 2000, Ketil Malde wrote:
> "Jan Brosius" <[EMAIL PROTECTED]> writes:
>
> >> But this example task was chosen as unlucky for Haskell.
> >> In other, average case, I expect the ratio of 6-10.
>
> > This seems that Haskell cannot be considered as a language for real
> > world applicati
> [1] admittedly not many. Are people using Haskell having problems
> getting good enough performance? Enough to regret choosing it as a
> language? (This is not a rhetoric question!)
No and yes.
I use Haskell mainly for combinational problems in research.
I would love to get higher performanc
"Jan Brosius" <[EMAIL PROTECTED]> writes:
>> But this example task was chosen as unlucky for Haskell.
>> In other, average case, I expect the ratio of 6-10.
> This seems that Haskell cannot be considered as a language for real
> world applications but merely as a toy for researchers .
Yeah. L
"D. Tweed" <[EMAIL PROTECTED]> writes:
>> "Ch. A. Herrmann" wrote:
>>> I believe that if as much research were spent on Haskell compilation as
>>> on C compilation, Haskell would outperform C.
> Unless I've got a dramatically distorted view of the amount of research
> that goes on for impera
Hi,
Jan> Haskell code optimised by strictnes annotions in functions or
Jan> in datastructures are ? times slower than C.
Jan> Please correct me where I am wrong and fill in the required
Jan> number for the ? sign above
I cannot give you a number, but I like to report about some
Ok,
So lazy Haskell (GHC 4.0...) is 10 times slower than a same program coded in
C (let forget about Fortran).
imperative functional programs like OCaml (or MLTon (SML 97) are 2.5 times
slower than C , for any sort of program.
Haskell code optimised by strictnes annotions in functions or in
da
> "Ch. A. Herrmann" wrote:
> > I believe that if as much research were spent on Haskell compilation as
> > on C compilation, Haskell would outperform C.
Unless I've got a dramatically distorted view of the amount of research
that goes on for imperative vs functional languages, and C vs haskel
PROTECTED]
Subject: Re: speed of compiled Haskell code.
"Ch. A. Herrmann" wrote:
> I believe that if as much research were spent on Haskell compilation as
> on C compilation, Haskell would outperform C.
I wish I could say I believed that. The big thing you aren't going to be
abl
"Ch. A. Herrmann" wrote:
> I believe that if as much research were spent on Haskell compilation as
> on C compilation, Haskell would outperform C.
I wish I could say I believed that. The big thing you aren't going to be
able to optimise away is laziness, which means you are going to have unev
, March 20, 2000 10:46 AM
To: [EMAIL PROTECTED]
Subject: Re: speed of compiled Haskell code.
Dear Haskellites,
>> My experience with the program of generating permutations on
>> [1..10] showed that the code produced by ghc-4.04 is 22 times
>> slower than certain s
Dear Haskellites,
>> My experience with the program of generating permutations on
>> [1..10] showed that the code produced by ghc-4.04 is 22 times
>> slower than certain specially written C program. Only the C
>> program algorithm was taken very different from Haskell's
>> on
Sergey Mechveliani [EMAIL PROTECTED] wrote:
>> [..]
>> E.g. if one uses GHC to compile Haskell code into native code what
>> speed performance can be expected versus a same program written in
>> C [..]
>My experience with the program of generating permutations on
>[1..10]
>showed that the cod
14 matches
Mail list logo
