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
ich of these is more likely to contain an error. A wrong
> program
> scores infinity on the time scale, so Haskell is infinitely faster than a
> wrong
> C program.
>
> Secondly, The C program is using buffers, the Haskell program could use
> raw IO
> and buffers too. If it did 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 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
is more likely to contain an error. A wrong program
scores infinity on the time scale, so Haskell is infinitely faster than a wrong
C program.
Secondly, The C program is using buffers, the Haskell program could use raw IO
and buffers too. If it did it would ba a lot faster, and use about the same
me
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 all,
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 their evol
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
29 matches
Mail list logo
