Simon Marlow ([EMAIL PROTECTED]) wrote:
Please test. We'd especially like to hear from Win98/WinME users. Also
try installing under a directory path with spaces in if you can.
Here is the result of attempting to build ghc-6.2.1 with the 6.2.1rc binaries:
[...]
==fptools== make boot -
The particular problem that you are encountering seems to be some
complicated interaction between Win98 and the GHC build system. We
can't reproduce it, not having a Win98 box, and supporting building from
source on Win98 isn't a major goal. It would have been great if the new
RC fixed it, but
Sébastien Pierre [EMAIL PROTECTED] writes:
I am currently evaluating different languages for implementing an
application which will have to manipulate large graphs representing
the structure of programs and their evolution.
Speed is in fact a crucial criterium for the language choice.
In my
I would recommend Haskell for speed of
development and correctness of implementation, but (probably) C for
speed. You can of course combine the two with the FFI, but I don't
know how trivial it is to pass Haskell graph structures to C and
back.
If you use a C library for speed, you want to
| I am currently evaluating different languages for implementing an
| application which will have to manipulate large graphs representing
| the structure of programs and their evolution.
|
| Speed is in fact a crucial criterium for the language choice.
A wise man once warned about the danger
Hi all,
Thanks for all your answers :)
I am still unsure of whether Haskell would be a good competitor against
other languages in my case, but it seems like if it does the best option
would be to reuse C++ graph libraries and carefully write a wrapper
around them to minimize passing values
Hi Sébastien!
On Thu, Mar 18, 2004 at 11:30:26AM +0100, Sébastien Pierre wrote:
In fact, I would like to know how Haskell compares in performance to
other languages because if I refer to the page I mentioned
(http://www.bagley.org/~doug/shootout/craps.shtml) it does not even
compete with
How can you take the results of a comparison like that seriously:
For example the reverse file test, here is the Haskell actually used:
main = interact $ unlines . reverse . lines
and here is the C:
/* -*- mode: c -*-
* $Id: reversefile.gcc,v 1.10 2001/07/20 17:20:32 doug Exp $
*
Simon Peyton-Jones wrote:
A wise man once warned about the danger of premature optimisation. I often
spend ages labouring over efficiency aspects of my code (GHC, for example)
that turn out to be nowhere near the critical path. Language choice is
another example.
My biased impression is
Simon Peyton-Jones [EMAIL PROTECTED] writes:
| I am currently evaluating different languages for implementing an
| application which will have to manipulate large graphs representing
| the structure of programs and their evolution.
|
| Speed is in fact a crucial criterium for the
On Thu, 18 Mar 2004, Carsten Schultz wrote:
Hi Sébastien!
On Thu, Mar 18, 2004 at 11:30:26AM +0100, Sébastien Pierre wrote:
In fact, I would like to know how Haskell compares in performance to
other languages because if I refer to the page I mentioned
Hi again,
Well, it seems like my little question raised an interesting thread, and
brought me some valuable information.
I am pleased to see that the Haskell community is particularily aware of
the fact that being a fast language is far from being the most important
criterium in most languages
Josef Svenningsson [EMAIL PROTECTED] writes:
[Doug Bagley's Language Shootout]
You should look at the individual examples and see how relevant their
results are for you.
Well, I think this shows that one should be very careful when reading
these kinds of benchmarks.
And don't forget
Hello,
Is there any way to find out what C compiler and preprocessor are used by
ghc?
I've run into problems with a windows user, since the ghc distribution
apparently uses a different compiler than the one that my configure script
finds, and so the configure script indicates that a certain
ghc -v Foo.hs
will show you what C compiler GHC invokes
S
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of David Roundy
| Sent: 18 March 2004 14:05
| To: [EMAIL PROTECTED]
| Subject: finding C compiler and preprocessor?
|
|
For now, I assume that Haskell is very expressive, but has
the speed of most interpreted language,
GHC is a *lot* faster than most interpreted languages :-P
Usual caveats, and large handfuls of salt apply.
Simon's cheat sheet for getting fast Haskell code:
Rule 1: don't use String I/O.
MR K P SCHUPKE [EMAIL PROTECTED] writes:
To do the equivalent of the C you could use:
http://www.haskell.org/~simonmar/io/System.IO.html
Is this documented anywhere? How do I use this?
The Haddoc documentation is a bit sparse.
This seems quite different from the System.IO module
installed
MR K P SCHUPKE [EMAIL PROTECTED] writes:
To do the equivalent of the C you could use:
http://www.haskell.org/~simonmar/io/System.IO.html
Is this documented anywhere? How do I use this?
The Haddoc documentation is a bit sparse.
This seems quite different from the System.IO module
Simon Marlow [EMAIL PROTECTED] writes:
http://www.haskell.org/~simonmar/io/System.IO.html
The difference is that the System.IO that comes with GHC is actually
implemented, rather than just documented :-)
Ah. Drat. You know, it really looks good, and I really could use
efficient file
Okay. What's really bothering me is that I can't find any good
indication of what to do to get IO faster. Do I need to FFI the whole
thing and have a C library give me large chunks? Or can I get by with
hGet/PutArray? If so, what sizes should they be? Should I use memory
mapped files?
On Thu, Mar 18, 2004 at 03:43:21PM +0100, Ketil Malde wrote:
Okay. What's really bothering me is that I can't find any good
indication of what to do to get IO faster. Do I need to FFI the whole
thing and have a C library give me large chunks? Or can I get by with
hGet/PutArray? If so, what
Memory mapped files (mmap) should be even quicker.
But then you'll have
to use peek co from Foreign to access the bytes.
Just a thought: couldn't they be mapped to unboxed
arrays?
Cheers,
JP.
__
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage,
Simon Peyton-Jones ([EMAIL PROTECTED]) wrote:
The particular problem that you are encountering seems to be some
complicated interaction between Win98 and the GHC build system. We
can't reproduce it, not having a Win98 box, and supporting building from
source on Win98 isn't a major goal. It
On Thu, 18 Mar 2004, Simon Peyton-Jones wrote:
Date: Thu, 18 Mar 2004 10:28:54 -
From: Simon Peyton-Jones [EMAIL PROTECTED]
To: Ketil Malde [EMAIL PROTECTED],
[iso-8859-1] Sébastien Pierre [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Haskell performance
| I am currently
Hi,
looking at `The Great Computer Language Shootout' mentioned in another
thread, I wanted to try if Data.HashTable gives better results than
Data.FiniteMap for the spell checker test
http://www.bagley.org/~doug/shootout/bench/spellcheck/
I came up with the attached program. With data files
Hello S\'ebastien,
I am a Haskell newbie, but have been interested in Haskell (and
generally speaking ML-derivates) for some time. I am currently
evaluating different languages for implementing an application which
will have to manipulate large graphs representing the structure of
programs
G'day all.
Quoting Sébastien Pierre [EMAIL PROTECTED]:
I am still unsure of whether Haskell would be a good competitor against
other languages in my case, but it seems like if it does the best option
would be to reuse C++ graph libraries and carefully write a wrapper
around them to minimize
27 matches
Mail list logo
