This is known behaviour of gcc. It doesn't just happen with Haskell
programs.
Could you explain.
Just that gcc -O2 (and higher) isn't guaranteed to produce better code than
gcc -O. I've seen it reported several times, but I couldn't give you any
concrete examples I'm afraid. I know
George Russell wrote:
[snip]
It won't be so hard to
speed up GHC later if that becomes important.
Since this has been disputed, here are three ways I believe you could speed up
GHC without rewriting the whole of it. I would be surprised if you didn't get
at least twice the speed, and you could
(1) (I've suggested this before.) Make GHC access interface
files more
efficiently. If you do top and truss (on a Sun system)
you will find
that GHC has to read in a huge number of interface files,
mainly from
the prelude but also from other places, to get going.
This
On Wed, Nov 24, 1999 at 06:29:24PM -0500, Eduardo Costa wrote:
Dear list members.
In my opinion, a compiler for a functional language should have the following
features:
[snip]
6- The code generated must be small, and use heap sparingly.
I was amazed that an utterly trivial program compiled
Simon Peyton-Jones wrote:
Third, while the things you mention are important, they are not
at the top of the wish-list that Sven maintains for users of
Haskell
(http://marutea.pms.informatik.uni-muenchen.de/wishlist/index.html)
Does that mean that (to borrow from the GHC docs) "smaller,
| Does that mean that (to borrow from the GHC docs) "smaller, faster,
| stingier" are acceptable items for the wishlist? That
| possibility had never occurred to me.
Certainly they are acceptable wishes! Of course, they are wishes we all
have -- who would not want smaller, faster?
However,
| My question is: Why Haskell compiler makers do not try to
| catch with Clean
| team, and surpass them? After all, there are many more people working
| with Haskell than with Clean.
A brief response.
First, Clean is indeed an excellent system, and its implementors
are fearsomely talented. As
I think the GHC developers have got their priorities about right. Yes, GHC is
slow, hard to build, and big. That's because it's a research project.
It's more important now to concentrate on demonstrating that Haskell is a good
language for all sorts of real programming problems. It won't be
On 25-Nov-1999, George Russell [EMAIL PROTECTED] wrote:
I think the GHC developers have got their priorities about right. Yes, GHC
is slow, hard to build, and big. That's because it's a research project.
Making GHC easier to build would make it easier for researchers;
it might well
On 24-Nov-1999, Eduardo Costa [EMAIL PROTECTED] wrote:
2- The compiler must be small. At most, 2 Megabytes.
Why?
--
Fergus Henderson [EMAIL PROTECTED] | "I have always known that the pursuit
WWW: http://www.cs.mu.oz.au/~fjh | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]
10 matches
Mail list logo
