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
paralleliz
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 somewhe
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 6 May 2012 16:40, 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
On 06.05.2012 10:44, Ivan Lazar Miljenovic wrote:
On 6 May 2012 16:40, 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 reaso
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
> On 06.05.2012 10:44, Ivan Lazar Miljenovic wrote:
>
>> On 6 May 2012 16:40,
It is not tail-recursive.
* Yves Parès [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.
>
> 2012/5/6 Artur
>
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
> It is not tail-recursive.
>
> * Yves Parès [201
* Artur [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 point was to take
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 recen
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 accus
"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 knowledge to automat
Roman Cheplyaka 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 to take
An equivalent parallel version in C++11 would look something like this:
long long fib(long long n) {
if (n< 2) {
return 1;
}
std::future r = std::async(fib, n-2);
long long l = fib(n-1);
return r.get() + l;
}
My bet though is that it would perform worse t
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 know
-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
One thing that baffles me is the comparison Haskell V. Java:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=ghc&lang2=java
Would've expected always shorter code and better performances on average.
2012/5/8 Silvio Frischknecht
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
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 knowledge
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:
http://shootout.alioth.debian.org/u32/program.php?test=fannkuchredux&lang=gh
>
> 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 accusati
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 w
Ryan Newton 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 "AE"s
> (app
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 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 best
> practice p
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 Lebovitz wrote:
I would find it useful to pull all this information together
Gregg Lebovitz 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 side note that s
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 do
Dmitry Vyal 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, chances a
>
> 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 variab
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 di
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
http://www.haskell.org/haskellwiki/Performance/
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 implic
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
On Wed, May 16, 2012 at 8:40 AM, Gregg Lebovitz 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
> do run into pe
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 impleme
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 al
On Wed, May 16, 2012 at 1:17 PM, Gregg Lebovitz 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 acceptable
performanc
Kevin Charter 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 and be fairly fas
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 iss
> 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
> Kevin Charter writes:
>
> snip
> > For example, imagine you're new to the language, and as an
Yves Parès 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 talk I remember
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 require
> From: Gregg Lebovitz
> 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 algorithms, appear to
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 alternative
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.
> Date: Wed, 16 May 2012 06:54:08 -0400
> From: wren ng thornton
> 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 o
> From: "Richard O'Keefe"
> Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
> To: Haskell Cafe
> 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
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'Keefe"
Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
To: Has
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 hel
> From: Gregg Lebovitz
> 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 benchm
, 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 to me. I feel
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
> Date: Fri, 18 May 2012 15:30:09 +1200
> From: "Richard O'Keefe"
> Subject: Re: [Haskell-cafe] Can Haskell outperform C++?
> To: Roman Werpachowski
> Cc: haskell-cafe@haskell.org
> Message-ID:
> Content-Type: text/plain; charset=us-ascii
>
>
> O
- Original Message -
> From: Richard O'Keefe
> 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 tha
>> 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 spe
- Original Message -
> From: "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
&
I've been following the topic in both threads. Very nice discussion.
On 18 May 2012 18:51, Isaac Gouy 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 gcc from
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 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. It is equal
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 com
On 5/18/12 7:45 AM, Roman Werpachowski wrote:
On Fri, 18 May 2012 15:30:09 +1200, "Richard O'Keefe"
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 case.
Yes, but a
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 s
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 perf
> Date: Sat, 19 May 2012 08:57:38 +0200
> From: Ertugrul S?ylemez
> 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&quo
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 hav
> From: wren ng thornton
> 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
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 s
> 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 fa
>
> 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 fa
Ryan Newton 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 'nub' function
> 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
"mo
> 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 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 that kind of cas
> 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
> 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 be
> 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 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 the software is
> From: Stephen Tetley
> 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 wrote:
>
>> I fail to see how the GUI part would suffer from lack of performance if the
>> rest of the s
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 readin
> 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 limi
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)
>> Jav
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 cr
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 versi
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
numb
> From: Richard O'Keefe
> 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 unicode?
-snip-
> From: wren ng thornton
> 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 Smalltalk.
I ha
On 24/05/2012, at 4:39 AM, Isaac Gouy wrote:
>> From: Richard O'Keefe
>> 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 agains
On Wed, May 23, 2012 at 10:52 PM, Richard O'Keefe 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 mailing list
Haskell-C
Sorry Bryan, there are a couple of comments I should make a final reply to -
I'll ignore the rest.
> From: Richard O'Keefe
> 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 increasingly as t
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 w
> 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
Haskell-Cafe@has
95 matches
Mail list logo
