Hi !
[EMAIL PROTECTED] wrote:
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 between C and
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
experiance poor Haskell performance is usually due to not understanding
how the language works (for example head/tail are fast, init/last are slow), or
not using the equivalent techniques in Haskell. To do the equivalent of the C
you could use: http://www.haskell.org/~simonmar/io/System.IO.html
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
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,
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
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
I was thinking about improving array performance, and was wondering
if a transactional model would work well. You would keep a base copy
of the array, and any writes would be written to a delta style transaction
list. A reference to the array would be the list plus the base array.
Different
MR K P SCHUPKE [EMAIL PROTECTED] writes:
I was thinking about improving array performance, and was wondering
if a transactional model would work well.
I would be interested in any comments... I suspect somebody has done this
before, but I havent looked for any papers yet.
O'Neill and
Hi Simon!
On Fri, Feb 27, 2004 at 09:20:40AM -, Simon Peyton-Jones wrote:
There are several things that aren't research issues: notably, faster
copying, fewer intermediate lists, fewer state-monad-induced
intermediate closures. These are things that would move sharply up our
priority
PROTECTED]
| Subject: RE: [Haskell] performance tuning Data.FiniteMap
|
| Is fixing GHC arrays a big research job or is it
| something that someone can straightforwardly
| handle if my site actually gets enough traffic to
| warrant it?
|
| -Alex-
|
| On Thu, 26 Feb 2004, Simon Peyton-Jones wrote
26 matches
Mail list logo
