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
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 mini
> | > 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 a
I would add a couple of points; these are implicit in a number of the
responses but I would like to make them explicit.
1. Haskell is extremely sensitive to coding choices. You can hack up a C
program and do a whole lot of things stupidly, and it will run at perhaps
1/2 the speed of a well writt
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 PR
> 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, 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, w
> 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 fil
"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 fil
> 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.
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
installe
> 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.
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
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
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
> > (http://www.bagley.org/~doug
"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 fo
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 i
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 $
* http://
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 wit
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 bet
| > 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 dan
> 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
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.
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 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
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
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 refere
Cc: [EMAIL 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-J
28 matches
Mail list logo
