On Wed, May 23, 2012 at 10:52 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote:
Past century? Insults, is it?
Do you fine gentlemen absolutely have to continue this endless, offtopic,
unedifying back-and-forth in public? Please.
___
Haskell-Cafe
Sorry Bryan, there are a couple of comments I should make a final reply to -
I'll ignore the rest.
From: Richard O'Keefe o...@cs.otago.ac.nz
Sent: Wednesday, May 23, 2012 10:52 PM
-snip-
Says who? Is that on your own authority or some other source you can point
us to?
It looks
Oops, forgot to reply-to-all. This was a minor clarification on Wren's
behalf (he can correct me if I'm wrong). But I agree with Bryan that it's
time for the thread to die:
Do bear in mind that Java doesn't optimize ---that's the JIT's job
What are we supposed to make of that?
Why write
Oops, forgot to reply-to-all.
N! You had the right idea the first time. :-)
(Please excuse us while we chide you as humorously as we can into putting this
thread out of its misery.)
Chris
___
Haskell-Cafe mailing list
I understand your concerns about modifying the current ideology, it's fair
enough.
Actually I'm myself more in favor of adding strict couterparts, and export
them conjointly, to support both the mathematical roots and the
performances of the operations that are done most of time (Which kind of
From: Richard O'Keefe o...@cs.otago.ac.nz
Sent: Tuesday, May 22, 2012 7:59 PM
But string processing and text I/O using the java.io.* classes aren't
brilliant.
Wait just a moment - Are you comparing text I/O for C programs that process
bytes against Java programs that process double-byte
From: wren ng thornton w...@freegeek.org
Sent: Tuesday, May 22, 2012 9:30 PM
-snip-
FWIW, that matches my expectations pretty well. Naive/standard Java
performing
slower than Smalltalk; highly tweaked Java using non-standard data types
performing on-par with or somewhat faster than
On 24/05/2012, at 4:39 AM, Isaac Gouy wrote:
From: Richard O'Keefe o...@cs.otago.ac.nz
Sent: Tuesday, May 22, 2012 7:59 PM
But string processing and text I/O using the java.io.* classes aren't
brilliant.
Wait just a moment - Are you comparing text I/O for C programs that process
From: Richard O'Keefe
Sent: Monday, May 21, 2012 6:54 PM
On 22/05/2012, at 4:15 AM, Isaac Gouy wrote:
Actually, I/O bound is *good*.
Why would that be good or bad?
The context here is a UNIX-style topological sorting program.
Being I/O bound means that the program is limited by how
On 23/05/2012, at 4:54 AM, Isaac Gouy wrote:
There may be very little one can do about the I/O part.
Maybe you could say how the Java I/O is being done.
For 50,000 nodes and 8,385,254 edges,
Java (first version) ran out of memory after 89.54 seconds (default heap)
Java (2nd
On 5/21/12 10:51 AM, Yves Parès wrote:
I do think we have the opposite problem, however, in much Haskell code --
people are using the clean, obviously correct, but inefficient code even in
standard library functions that really should be optimized like crazy!
And even before optimizing like
On 5/22/12 12:54 PM, Isaac Gouy wrote:
On 5/21/2012 6:54 PM, Richard O'Keefe wrote:
For 50,000 nodes and 8,385,254 edges,
Java (first version) ran out of memory after 89.54 seconds (default heap)
Java (2nd version) 13.31 seconds -- avoid Integer boxing!
Java (3rd
The unconditional desire for maximum possible object code
performance is usually very stupid, not to mention impossible to reach
with any high level language and any multi-tasking operating system.
Definitely. I don't know if we have a catchy term for kneejerk
optimization or if it falls
Ryan Newton rrnew...@gmail.com wrote:
I do think we have the opposite problem, however, in much Haskell code
-- people are using the clean, obviously correct, but inefficient code
even in standard library functions that really should be optimized
like crazy!
Not necessarily. For example the
I do think we have the opposite problem, however, in much Haskell code --
people are using the clean, obviously correct, but inefficient code even in
standard library functions that really should be optimized like crazy!
And even before optimizing like crazy, I think the functions that are
more
Not necessarily. For example the 'nub' function from Data.List could be
much faster. Unfortunately this would also change its type. O(n²)
complexity is really the best you can get with the Eq constraint.
Why not in that kind of cases provide a second function (named
differently), together
On Mon, May 21, 2012 at 7:53 AM, Yves Parès yves.pa...@gmail.com wrote:
Not necessarily. For example the 'nub' function from Data.List could be
much faster. Unfortunately this would also change its type. O(n²)
complexity is really the best you can get with the Eq constraint.
Why not in
Yes, this seems to be a separate disease. Not just using low-level langs,
per se,
but using them for *everything*. I have worked at places in industry where
teams
automatically use C++ for everything. For example, they use it for building
all
complete GUI applications, which
From: Richard O'Keefe o...@cs.otago.ac.nz
Sent: Sunday, May 20, 2012 3:41 PM
On 19/05/2012, at 5:51 AM, Isaac Gouy wrote:
In the 'tsort' case, it turns out that the Java and Smalltalk
versions are I/O bound with over 90% of the time spent just
reading the data.
My guess is that they could
If you are writing a program or system that has significant performance
requirements, you might just be better off doing the whole thing in C/C++
and living with the annoyance of doing GUIs
I fail to see how the GUI part would suffer from lack of performance if the
rest of the system is fine. I
On 21 May 2012 17:27, Yves Parès yves.pa...@gmail.com wrote:
I fail to see how the GUI part would suffer from lack of performance if the
rest of the system is fine. I would hate to be bold, but to me this case
sounds a little bit like MVC done wrong if the breaking GUI apart from the
rest of
From: Stephen Tetley stephen.tet...@gmail.com
Sent: Monday, May 21, 2012 10:08 AM
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
On 21 May 2012 17:27, Yves Parès yves.pa...@gmail.com wrote:
I fail to see how the GUI part would suffer from lack of performance if the
rest
On 22/05/2012, at 4:15 AM, Isaac Gouy wrote:
Actually, I/O bound is *good*.
Why would that be good or bad?
The context here is a UNIX-style topological sorting program.
Being I/O bound means that the program is limited by how fast
it can read the data. If 90% of the time goes into reading
On 19/05/2012, at 5:51 AM, Isaac Gouy wrote:
In the 'tsort' case, it turns out that the Java and Smalltalk
versions are I/O bound with over 90% of the time spent just
reading the data.
My guess is that they could be written to do better than that - but it's
idiotic of me to say so
How much is hard to port a haskell program to C ?
If it will become harder and harder, (i.e. for parallelizations) than
it's fair to choose haskell for performance, but if it's not, I think
it's hard to think that such a high level language could ever compile
down to something running faster
On 5/16/12 7:43 AM, Yves Parès wrote:
On the one hand, characterizing those who desire the best performance
possible as simple-minded is, at best, a gross over-generalization. Like
you, I work in a field where optimization is king (e.g., in machine
translation, program runtimes are measured in
wren ng thornton w...@freegeek.org wrote:
However, while the logical interpretation of Ertugrul's words may be
that simple-mindedness implies performance-desire, that interpretation
is not the only one available to the standard interpretation of his
words, nor IMO the dominant interpretation.
On 5/16/12 3:57 PM, Bardur Arantsson wrote:
Comparing languages is a highly non-trivial matter involving various
disciplines (including various squidgy ones) and rarely makes sense
without a very specific context for comparison.
Exactly. That's what I was trying to get at re the problems of
On 5/18/12 7:45 AM, Roman Werpachowski wrote:
On Fri, 18 May 2012 15:30:09 +1200, Richard O'Keefeo...@cs.otago.ac.nz
wrote:
The claim was and remains solely that
THE TIME DIFFERENCE BETWEEN *ALGORITHMS*
can be bigger than
THE TIME DIFFERENCE BETWEEN *LANGUAGES*
and is in this particular
On 5/16/12 4:37 PM, Gregg Lebovitz wrote:
1) Outstanding best practices documents that capture this knowledge and
provides useful answers. Organizing this information in an online
document that can be searched by keyword or index would be really
helpful. The hard part will be maintaining it. As
Hello,
I would like to add questions to yours. I'm not sure that C++ programs
are same performance as C actually, so I can have a bad logic.
How much is hard to port a haskell program to C ?
If it will become harder and harder, (i.e. for parallelizations) than
it's fair to choose haskell for
Date: Sat, 19 May 2012 08:57:38 +0200
From: Ertugrul S?ylemez e...@ertes.de
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
To: haskell-cafe@haskell.org
Message-ID: 20120519085738.37548...@tritium.streitmacht.eu
Content-Type: text/plain; charset=us-ascii
Haskell delivers
Am 19.05.2012 12:00, schrieb wren ng thornton:
Exactly. That's what I was trying to get at re the problems of comparing
Haskell to C++ (or indeed any pair of dissimilar languages). A
legitimate comparison will involve far more than microbenchmarks, but
then a legitimate comparison must always
From: wren ng thornton w...@freegeek.org
Sent: Saturday, May 19, 2012 12:49 AM
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
-snip-
Fair in what sense? That is, what _exactly_ are you hoping to
compare?
If the goal is to benchmark the implementation of the runtime, VM
Date: Fri, 18 May 2012 15:30:09 +1200
From: Richard O'Keefe o...@cs.otago.ac.nz
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
To: Roman Werpachowski roman.werpachow...@gmail.com
Cc: haskell-cafe@haskell.org
Message-ID: b43b8ce3-9f90-4dc3-8725-d62298397...@cs.otago.ac.nz
Content
- Original Message -
From: Richard O'Keefe o...@cs.otago.ac.nz
Sent: Thursday, May 17, 2012 8:30 PM
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
-snip-
The claim was and remains solely that
THE TIME DIFFERENCE BETWEEN *ALGORITHMS*
can be bigger than
THE TIME
There was and is no claim that method 2 is much harder
to implement in C or C++. In fact both methods *were* implemented
easily in C.
OK, got that now. So Haskell doesn't have a *big* advantage over C w/r
to the ease of implementation of both algorithms?
In the case of these specific
- Original Message -
From: o...@cs.otago.ac.nz o...@cs.otago.ac.nz
Sent: Friday, May 18, 2012 9:38 AM
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
-snip-
and if we want
to compare *languages*, we should use identical algorithms to make the
comparison fair
I've been following the topic in both threads. Very nice discussion.
On 18 May 2012 18:51, Isaac Gouy igo...@yahoo.com wrote:
Moreover, being absolutely sure that the algorithms are in some sense
identical might make comparison pointless - for example, when the same
assembly
is generated by
Date: Wed, 16 May 2012 06:54:08 -0400
From: wren ng thornton w...@freegeek.org
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
To: haskell-cafe@haskell.org
Message-ID: 4fb38750.9060...@freegeek.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
But on the other hand
From: Richard O'Keefe o...@cs.otago.ac.nz
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
To: Haskell Cafe haskell-cafe@haskell.org
Message-ID: 5f6605a2-dfe0-4aea-9987-3b07def34...@cs.otago.ac.nz
Content-Type: text/plain; charset=us-ascii
On 17/05/2012, at 2:04 PM, Gregg Lebovitz
Roman,
I think this question is for Richard. I haven't had a chance to play
with these methods. I will try to do that today.
Gregg
On 5/17/2012 6:07 AM, Roman Werpachowski wrote:
From: Richard O'Keefeo...@cs.otago.ac.nz
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
To: Haskell
Isaac,
I see your point. Probably I shouldn't have made that assertion given my
limited understanding of the benchmarks. I want to thank you for your
kind and gentle way of pointing this out to me. I feel very welcomed and
encourage.
I still plan to work on the performance paper with the
From: Gregg Lebovitz glebov...@gmail.com
Sent: Thursday, May 17, 2012 5:50 AMI look forward to
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
Isaac,
I see your point. Probably I shouldn't have made that assertion given my
limited understanding of the benchmarks. I want
: Thursday, May 17, 2012 5:50 AMI look forward to
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
Isaac,
I see your point. Probably I shouldn't have made that assertion given my
limited understanding of the benchmarks. I want to thank you for your
kind and gentle way of pointing this out
On 17/05/2012, at 10:07 PM, Roman Werpachowski wrote:
No slide deck required. The task is generating alternating permutations.
Method 1: generate permutations using a backtracking search;
when a permutation is generated, check if it is alternating.
Method 2: use the same
On 5/10/12 8:44 PM, Ryan Newton wrote:
through the trouble of writing my algorithms in C/C++, but simple-minded
people often have a desire to get the best performance possible, in
which case you really want to use C, C++, Fortran or whatever high level
assembler language you like.
I think this
On the one hand, characterizing those who desire the best performance
possible as simple-minded is, at best, a gross over-generalization. Like
you, I work in a field where optimization is king (e.g., in machine
translation, program runtimes are measured in days).
You misread the logical
Wren,
I see at least three different issues being discussed here. I think it
is important to delineate them:
1) Does Haskell and its libraries need performance improvements?
Probably yes. Some of the performance issues seem to be related to the
way the language is implemented and others by
Wed May 16 16:40:26 CEST 2012, Gregg Lebovitz wrote:
2) ... I think the problem with current comparisons,
is that they are designed to favor imperative languages.
Please be specific:
- Which current comparisons?
- How do you know what they are designed to favor?
On Wed, May 16, 2012 at 8:40 AM, Gregg Lebovitz glebov...@gmail.com wrote:
1) Does Haskell and its libraries need performance improvements? Probably
yes. Some of the performance issues seem to be related to the way the
language is implemented and others by how it is defined. Developers really
Isaac,
I was looking at the debian coding contest benchmarks referenced by
others in this discussion. All of the benchmarks algorithms, appear to
be short computationally intensive programs with a fairly low level of
abstraction.
In almost all examples, the requirement says: you must
Kevin,
Interesting point.
Over the past few weeks as part of my work, I have interviewed a
large numbers of Haskell developers from many different industries
and have been hearing the same points you are making. Space leaks
that were address by learning how
On 05/16/2012 09:02 PM, Gregg Lebovitz wrote:
Isaac,
I was looking at the debian coding contest benchmarks referenced by
others in this discussion. All of the benchmarks algorithms, appear to
be short computationally intensive programs with a fairly low level of
abstraction.
In almost
On Wed, May 16, 2012 at 1:17 PM, Gregg Lebovitz glebov...@gmail.com wrote:
Also interesting is that in all my interviews, GHC performance was never
raised. No one said I have to drop into C to solve that performance
problem.
That's been my experience too. I've so far been able to get
Kevin Charter kchar...@gmail.com writes:
snip
For example, imagine you're new to the language, and as an exercise decide
to write a program that counts the characters on standard input and writes
the count to standard output. A naive program in, say, Python will probably
use constant space
Ben,
This is precisely the kind of problem I am currently thinking about and
why I asked for pointers to documents on best practices. The current
model for gaining the necessary experience to use Haskell effectively
does not scale well.
Here are some ideas on how to address the knowledge
The profiler is certainly useful (and much better with GHC 7.4)
What are the improvements in that matter? (I just noticed that some GHC
flags wrt profiling have been renamed)
2012/5/16 Ben Gamari bgamari.f...@gmail.com
Kevin Charter kchar...@gmail.com writes:
snip
For example, imagine
Yves Parès yves.pa...@gmail.com writes:
The profiler is certainly useful (and much better with GHC 7.4)
What are the improvements in that matter? (I just noticed that some GHC
flags wrt profiling have been renamed)
The executive summary can be found in the release notes[1]. There was
also a
On 5/16/2012 3:57 PM, Bardur Arantsson wrote:
Comparing languages is a highly non-trivial matter involving various
disciplines (including various squidgy ones) and rarely makes sense
without a very specific context for comparison. So the short answer
is: mu. Discovering the long answer
From: Gregg Lebovitz glebov...@gmail.com
Sent: Wednesday, May 16, 2012 12:02 PM
I was looking at the debian coding contest benchmarks referenced by others in
this discussion.
debian coding contest ?
It's been called many things but, until now, not that.
All of the benchmarks
In a lecture today I presented (for quite other reasons) a simple combinatorial
enumeration problem where the difference between two algorithms was far larger
than any plausible difference between programming languages. If a programming
language makes it easier to explore high level
Richard,
Thank you. This is an example of what I had in mind when I talked about
changing the playing field. Do you have a slide deck for this lecture
that you would be willing to share with me? I am very interested in
learning more.
Gregg
On 5/16/2012 9:13 PM, Richard O'Keefe wrote:
In a
On 17/05/2012, at 2:04 PM, Gregg Lebovitz wrote:
Richard,
Thank you. This is an example of what I had in mind when I talked about
changing the playing field. Do you have a slide deck for this lecture that
you would be willing to share with me? I am very interested in learning more.
No
Yet this resource seems a little outdated:
http://www.haskell.org/haskellwiki/Performance/Strings does not speak about
Text
http://www.haskell.org/haskellwiki/Performance/Arrays about Vector
And what's the status of the Streams IO approach detailed in
On 05/11/2012 07:53 AM, Ertugrul Söylemez wrote:
My point is: If you need C-like performance at a certain spot there is
really no excuse for writing the entire application in C. Haskell has
a working, powerful enough FFI. Also idiomatic Haskell code nowadays
performs close to C. If your code
Dmitry Vyal akam...@gmail.com wrote:
My point is: If you need C-like performance at a certain spot there
is really no excuse for writing the entire application in C.
Haskell has a working, powerful enough FFI. Also idiomatic Haskell
code nowadays performs close to C. If your code doesn't,
Well, if it's in many ways the same as C, then again it's probably not
idiomatic Haskell.
It's just a recursive equation for mandelbrot fractals. I should have been
precise, I didn't mean that the source is literally the *same* as the C
source (i.e. there's no for loop, no mutable
Ryan Newton:
But, anyway, it turns out that my example above is easily transformed from a
bad GHC performance story into a good one. If you'll bear with me, I'll show
how below.
First, Manuel makes a good point about the LLVM backend. My 6X anecdote
was from a while ago and I didn't
Chris,
Thanks you for indulging me. I will eventually get use to the idea that
there is a wiki page for almost every topic :-)
Gregg
On 5/12/2012 1:02 AM, Chris Wong wrote:
On Sat, May 12, 2012 at 12:41 AM, Gregg Lebovitzglebov...@gmail.com wrote:
I would find it useful to pull all this
Gregg Lebovitz glebov...@gmail.com wrote:
Ryan writes:
With a few years of Haskell experience in my backpack I know how to
utilize laziness to get amazing performance for code that most people
would feel must be written with destructively updating loop.
That was me actually. Just a minor
This is an outstanding discussion. I am learning a lot from it.
I would find it useful to pull all this information together into a
single document that discusses all the performance issues in one
place and shares the real life experience is dealing with each
issue.
On Sat, May 12, 2012 at 12:41 AM, Gregg Lebovitz glebov...@gmail.com wrote:
I would find it useful to pull all this information together into a single
document that discusses all the performance issues in one place and shares
the real life experience is dealing with each issue. I see this as a
through the trouble of writing my algorithms in C/C++, but simple-minded
people often have a desire to get the best performance possible, in
which case you really want to use C, C++, Fortran or whatever high level
assembler language you like.
I think this is a bit of an unfair accusation
Ryan Newton:
As a community I think we have to face the fact that writing the hot inner
loop of your application as idiomatic Haskell is not [yet] going to give you
C/Fortran performance off the bat. Though in some cases there's not really
anything stopping us but more backend/codegen work
Ryan Newton rrnew...@gmail.com wrote:
I think this is a bit of an unfair accusation (simple-minded).
Performance is only relevant to certain domains, sure. But program
performance is an entire *industry*. And I'd argue it's of massive
importance to the world at large. Intel has an army of
One thing that baffles me is the comparison Haskell V. Java:
http://shootout.alioth.debian.org/u32/benchmark.php?test=alllang=ghclang2=java
Would've expected always shorter code and better performances on average.
2012/5/8 Silvio Frischknecht silvio.fris...@gmail.com
-BEGIN PGP SIGNED
On 06/05/2012 07:40, Janek S. wrote:
a couple of times I've encountered a statement that Haskell programs
can have performance comparable to programs in C/C++. I've even read
that thanks to functional nature of Haskell, compiler can reason and
make guarantess about the code and use that
On May 8, 2012, at 12:18 PM, Yves Parès wrote:
Would've expected always shorter code
It's not so surprising if you consider that some of the programs are
practically imperative programs in Haskell. To give an example:
2012/5/8 Silvio Frischknecht
Also I challenge anyone to improve one of the haskell programs there. It'd be
cool if we could make haskell get a higher rank. I recently managed to
improve the Fasta algorithm, but not by much. Also I think the benchmarks
don't use llvm flag. It says somewhere
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Can anyone provide a code in Haskell that performs better in terms
of execution speed than a well-written C/C++ program?
http://shootout.alioth.debian.org/ compares a lot of programming
languages on a lot of problems. Haskell is never as fast as
Hi,
a couple of times I've encountered a statement that Haskell programs can have
performance
comparable to programs in C/C++. I've even read that thanks to functional
nature of Haskell,
compiler can reason and make guarantess about the code and use that knowledge
to automatically
On 6 May 2012 16:40, Janek S. fremenz...@poczta.onet.pl wrote:
Hi,
a couple of times I've encountered a statement that Haskell programs can have
performance
comparable to programs in C/C++. I've even read that thanks to functional
nature of Haskell,
compiler can reason and make guarantess
On 06.05.2012 10:44, Ivan Lazar Miljenovic wrote:
On 6 May 2012 16:40, Janek S.fremenz...@poczta.onet.pl wrote:
Hi,
a couple of times I've encountered a statement that Haskell programs can have
performance
comparable to programs in C/C++. I've even read that thanks to functional
nature of
I do not agree: the fib function is tail-recursive, any good C compiler is
able to optimize away the calls and reduce it to a mere loop.
At least that's what I learnt about tail recursion in C with GCC.
2012/5/6 Artur apeka1...@gmail.com
On 06.05.2012 10:44, Ivan Lazar Miljenovic wrote:
On 6
It is not tail-recursive.
* Yves Parès yves.pa...@gmail.com [2012-05-06 10:58:45+0200]
I do not agree: the fib function is tail-recursive, any good C compiler is
able to optimize away the calls and reduce it to a mere loop.
At least that's what I learnt about tail recursion in C with GCC.
Sorry sorry sorry ^^
I read too fast and realized I was wrong before you sent this.
Okay so then it would be nice that somewhere with higher skills tells us
where does Haskell recursive calls stand when compared to C's.
2012/5/6 Roman Cheplyaka r...@ro-che.info
It is not tail-recursive.
*
* Artur apeka1...@gmail.com [2012-05-06 11:41:58+0300]
isn't it that particular Haskell code is outperforming C (22 seconds
vs. 33), just because the author uses recursion in C? I surely love
Haskell, and the way it's code is easy parallelized, but that example
seams not fair.
I think the
In this case it doesn't matter; while it isn't technically tail
recursive, GCC is very capable of transforming it into a direct loop
likely because it knows about the associative/commutative properties
of + so it's able to re-arrange the body as it sees fit since
combined, both calls are in 'tail
Well, I believe that comparison is about solving a task, not writing code
in some particular way. I get your point, but I think that when comparing
language speed, you should use the best techniques each one has to offer,
it makes no sense otherwise.
If there was some kind of comparison made
Roman Cheplyaka:
If you're saying that in C an explicit stack should have been used
instead of recursion, then it would increase the code complexity while
having non-obvious performance benefits.
This is a fragment of a bigger message I won't comment.
But THIS is a little dubious. You may
Janek S. fremenz...@poczta.onet.pl wrote:
a couple of times I've encountered a statement that Haskell programs
can have performance comparable to programs in C/C++. I've even read
that thanks to functional nature of Haskell, compiler can reason and
make guarantess about the code and use that
Roman Cheplyaka r...@ro-che.info wrote:
isn't it that particular Haskell code is outperforming C (22
seconds vs. 33), just because the author uses recursion in C? I
surely love Haskell, and the way it's code is easy parallelized, but
that example seams not fair.
I think the point was
An equivalent parallel version in C++11 would look something like this:
long long fib(long long n) {
if (n 2) {
return 1;
}
std::futurelong long r = std::async(fib, n-2);
long long l = fib(n-1);
return r.get() + l;
}
My bet though is that it would
On 5/6/12 2:40 AM, Janek S. wrote:
Hi,
a couple of times I've encountered a statement that Haskell programs can have
performance
comparable to programs in C/C++. I've even read that thanks to functional
nature of Haskell,
compiler can reason and make guarantess about the code and use that
95 matches
Mail list logo
