[CC stripped a bit]
On Thu, Mar 01, 2001 at 07:58:26AM +0100, Ketil Malde wrote:
> Jan-Willem Maessen <[EMAIL PROTECTED]> writes:
> > Absolutely. Good high-level thread support trumps anything provided
> > by the operating system.
> Unless you have more than one CPU...
No, even then, some hig
I implemented the programs for hash1 and hash2, but I had to
make a lot of changes to FiniteMap to get them to work:
- I changed foldl to foldl' (as defined in Hugs).
- I made foldFM strict (like foldl').
- I made the datatype FiniteMap strict (put !'s everywhere).
I put the programs below, maybe
> Reducing the 46M reported on the shootout without changing the
> program would be interesting. An easy way for improvement
> would be to share characters and small integers like is done in Hugs.
> This would mean the initial list of characters would be reduced from
> 40M to 24M, so the total sho
Reducing the 46M reported on the shootout without changing the
program would be interesting. An easy way for improvement
would be to share characters and small integers like is done in Hugs.
This would mean the initial list of characters would be reduced from
40M to 24M, so the total should go do
A feature I have always wanted in ghc was the ability to compile a
program with NO heap allocator/ GC whatsoever. basically I want the
program to grab large chunks of memory from the OS with 'sbrk (or
mmap or whatever) and just give out pieces of it as they are requested.
no GC, no keeping track o
Simon Peyton-Jones wrote:
>
> A String is a [Char] and a Char is a heap object. So
> a file represented as a string takes a massive 20 bytes/char
> (12 for the cons cell, 8 for the Char cell). Then it's all sucked
> through several functions.
>
> It's entirely possible, though, that the biggest
I/O itself. We'd be happy if anyone wanted to invesigate
and improve.
Simon
| -Original Message-
| From: John Atwood [mailto:[EMAIL PROTECTED]]
| Sent: 02 March 2001 01:12
| To: Josef Svenningsson
| Cc: [EMAIL PROTECTED]
| Subject: Bagley shootout. Was: Lightningspeed haskell
|
|
I notice that the reverse file program, while concise, is quite slow.
The program in its entirety is:
main = interact $ unlines . reverse . lines
Any thoughts on why its time is 5.68 seconds, vs 3.56 for tcl, 2 for
perl, 0.19 for gcc, 0.18 for ocaml; and how it might be sped up? Is the
l
Jan-Willem Maessen <[EMAIL PROTECTED]> writes:
> Absolutely. Good high-level thread support trumps anything provided
> by the operating system.
Unless you have more than one CPU...
> Similar dramatic performance disparities have cropped up in the Java
> community. There are Java benchmarks wh
Josef Svenningsson <[EMAIL PROTECTED]> wrote:
> One benchmark turned out to give pretty remarkable results. It's the
> producer/consumer benchmark. I suggest you all take a look at it. The
> haskell version is six (SIX!!!) times faster than the c version. Hey,
> what's going on here? I would reall
On Wed, 28 Feb 2001, Simon Marlow wrote:
> > It should be noted that synchronisation is achieved by using
> > slightly different kinds of primitives. But still... six times...
>
> And it's about to get faster still, because CVars can now be implemented
> with a single MVar instead of two. The re
> It should be noted that synchronisation is achieved by using
> slightly different kinds of primitives. But still... six times...
And it's about to get faster still, because CVars can now be implemented
with a single MVar instead of two. The reason is that putMVar now
blocks on a full MVar rath
Cool! Thanks for doing this.
I guess GHC is fast because it's implementing lightweight
threads inside a single OS thread.
Simon
| -Original Message-
| From: Josef Svenningsson [mailto:[EMAIL PROTECTED]]
| Sent: 28 February 2001 09:47
| To: [EMAIL PROTECTED]
| Subject: Lightning
Hi all.
Some days ago someone posted this url:
http://www.bagley.org/~doug/shootout/
which is a page benchmarking a number of different languages and
compilers where ghc is one of them. Some benchmarks lacked a haskell
versions (and some still do) and so I decided to fill in some of the gaps.
O
14 matches
Mail list logo
