Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
One to add to your list, string edit distance - as its hard, and useful. Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
karczma [EMAIL PROTECTED] writes: I think the Haskell community has just been a bit slower in understanding the importance of strictness :) OK, I admit that I will never understand these complaints about the inefficiency of non-strict computations, since what I *require* in most of my work is laziness. Indeed, I have to agree. I have spent some time fiddling with programs for the Language Shootout which started this conversation, and by far most of the effort was spent in deliberately making code /slower/ by introducing strictness. For instance, the shootout often requires that a task be carried out N times, to make the timings large enough to measure. In all the naive Haskell implementations of these tasks, Haskell wins by a mile. Why? Because the language quite reasonably says that if you multiply a matrix by itself N times, but only use the result of the last multiplication, well it is jolly well not going to bother computing the first (N-1) identical multiplications - what a waste of time! So is it fair to compare the default lazy Haskell solution with all the eager solutions out there that laboriously do all this unnecessary work? Apparently not, so we have gone to all kinds of trouble to slow the Haskell solution down, make it over-strict, do the work N times, and thereby have a fair performance test. Huh. Regards, Malcolm ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
Jerzy Karczmarczuk writes (in the Haskell cafe): OK, I admit that I will never understand these complaints about the inefficiency of non-strict computations, since what I *require* in most of my work is laziness. Had I needed strictness for the sake of efficiency, I would use a different language instead of throwing dirt at Haskell. Sometimes lazy is better, sometimes eager. That's why I want to use both strategies in one language and program. I think complaints about ineffeciency of non-strict computations can be valid. It's nice to write sum = foldl (+) 0 main = print ( sum [1..10]) but if your program runs out of stack you don't want to switch to another language. Clean has not only those ubiquitous !annotations, but has a powerful strickness analyzer, which alleviates their use. Strictness analysis is undecidable in general and there are situations (in real programs) where Clean's strictness analysis falls short. Cheers, Ronny Wichers Schreur ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
n Mon, Oct 11, 2004 at 12:22:13PM +0100, Malcolm Wallace wrote: karczma [EMAIL PROTECTED] writes: I think the Haskell community has just been a bit slower in understanding the importance of strictness :) OK, I admit that I will never understand these complaints about the inefficiency of non-strict computations, since what I *require* in most of my work is laziness. Indeed, I have to agree. I have spent some time fiddling with programs for the Language Shootout which started this conversation, and by far most of the effort was spent in deliberately making code /slower/ by introducing strictness. For instance, the shootout often requires that a task be carried out N times, to make the timings large enough to measure. In all the naive Haskell implementations of these tasks, Haskell wins by a mile. Why? Because the language quite reasonably says that if you multiply a matrix by itself N times, but only use the result of the last multiplication, well it is jolly well not going to bother computing the first (N-1) identical multiplications - what a waste of time! So is it fair to compare the default lazy Haskell solution with all the eager solutions out there that laboriously do all this unnecessary work? Apparently not, so we have gone to all kinds of trouble to slow the Haskell solution down, make it over-strict, do the work N times, and thereby have a fair performance test. Huh. I think the naive way is perfectly fair. If haskell has to live with the disadvantages of lazy evaluation, it only makes sense we should be able to take advantage of the advantages. The fact that haskell doesn't have to compute those intermediate values is a real advantage which should be reflected in the results IMHO. John -- John Meacham - repetae.netjohn ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
On Mon, 11 Oct 2004 14:16:36 -0700, John Meacham [EMAIL PROTECTED] wrote: n Mon, Oct 11, 2004 at 12:22:13PM +0100, Malcolm Wallace wrote: So is it fair to compare the default lazy Haskell solution with all the eager solutions out there that laboriously do all this unnecessary work? Apparently not, so we have gone to all kinds of trouble to slow the Haskell solution down, make it over-strict, do the work N times, and thereby have a fair performance test. Huh. I think the naive way is perfectly fair. If haskell has to live with the disadvantages of lazy evaluation, it only makes sense we should be able to take advantage of the advantages. The fact that haskell doesn't have to compute those intermediate values is a real advantage which should be reflected in the results IMHO. John This seems especially true if you have to add extra lines of code to make the tests fair, because this extra code counts against Haskell in the lines-of-code metric. Personally, I am more impressed by the lines-of-code metrics than I am by the performance metrics. - Brian ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
Malcolm Wallace wrote: For instance, the shootout often requires that a task be carried out N times, to make the timings large enough to measure. In all the naive Haskell implementations of these tasks, Haskell wins by a mile. Why? Because the language quite reasonably says that if you multiply a matrix by itself N times, but only use the result of the last multiplication, well it is jolly well not going to bother computing the first (N-1) identical multiplications - what a waste of time! So is it fair to compare the default lazy Haskell solution with all the eager solutions out there that laboriously do all this unnecessary work? Apparently not, so we have gone to all kinds of trouble to slow the Haskell solution down, make it over-strict, do the work N times, and thereby have a fair performance test. Huh. Well, the shootout appears to have two types of tests. Each individual test is labeled as either being implemented in the Same Way or doing the Same Thing. I agree that the Same Way test are usually too synthetic and too geared toward measuring artifacts of imperative programming which aren't appropriate in Haskell. But there are also the Same Thing tests that are free to be coded in any style at all. And of the Same Thing tests, the largest slowdown in the GHC programs is caused by lazy I/O (I think using better I/O routines would fix Reverse a File and Statistical Moments). To get GHC to come out on top of the CRAPS Scorecard, we need to emphasize the Same Thing tests and downplay the Same Way tests as well as properly weighting lines of code vs. memory consumption and speed. Here's one way to do it... http://makeashorterlink.com/?O5BD42089 What we probably need to do is create some new tests which aren't as phony and convince the powers-that-be to drop some of the synthetic tests or convert them to Same Thing tests (I think the Sum a Column of Integers and Spell Checker would be good candidates to convert). Just for reference, here's a list of the Same Thing tests: Simple TCP/IP Server Matrix Multiplication Statistical Moments Process Instantiation Reverse A File Ring of Messages Count Lines/Words/Chars Word Frequency Greg Buchholz ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
Ketil Malde ([EMAIL PROTECTED]) wrote: As somebody just said, you get to chose between speed and simplicity/clarity of code. I would like both. Me too. Simplicity/calrity of code is, imho, one of the strong point in using Haskell. Couldn't readFile et al. provide the standard interface, but use hGetBuf tricks (e.g. from your 'wc' entry) behind the curtains? That would be nice indeed. It's a pity that Ocaml is getting recommended for a 'real-life' applications instead of Haskell :-( Sincerely, Gour ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
Ketil Malde writes: Couldn't readFile et al. provide the standard interface, but use hGetBuf tricks (e.g. from your 'wc' entry) behind the curtains? No amount of hGetBuf'ing will speed the program up if the problem is the algorithm. I/O comes _sequentially_, and every program that doesn't process the input sequentially will require some form of buffering. Lazy I/O provides a great general-purpose buffering mechanism, but it simply can't be as fast of as efficient as hand-written code. IMHO, a good I/O API forces you to write a stateful callback function (that's how I implemented it in BlockIO), so _if_ you want to buffer something, you can use your state for that. But the I/O driver doesn't buffer, what has been read and processed is gone. Then the I/O part will _always_ be as fast as possible, and the design encourages you to process the data sequentially without looking forward/backward too much. It simply means writing a Char - StateT st IO () -- stream processor or String - StateT st IO () -- line oriented function to handle a _part_ of the input every time, rather than a String - IO () function that handles the entire input at once. Peter ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
Andrew Butterfield [EMAIL PROTECTED] writes: I though clean was always strict, and that was the major difference between clean and haskell (that and the fact clean is a proprietry language) No - Clean is pure and lazy like Haskell, But it uses explicit strictness annotations a lot, and provides strict and/or unboxed versions of various fundamental types (e.g. tuples), with some implicit coercions. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
At 03:32 PM 10/8/2004, Marcin Kowalczyk wrote: Andrew Butterfield [EMAIL PROTECTED] writes: I though clean was always strict, and that was the major difference between clean and haskell (that and the fact clean is a proprietry language) No - Clean is pure and lazy like Haskell, But it uses explicit strictness annotations a lot, and provides strict and/or unboxed versions of various fundamental types (e.g. tuples), with some implicit coercions. It is of course not the language that uses strictness annotations. Clean programs without strictness annotations are perfectly lazy. Clean has a powerful strictness analysis that includes only safe strictness to function arguments. Programmers *can* include strictness annotations, exactly for the reasons that were mentioned in this thread, namely to influence the evaluation strategy in such a way that heap consumption and/or run time decrease. In addition, this can be done light-weight because annotations are added only to function argument types and data types, instead of modifying the code by inserting strict evaluator functions. Regards, Peter Achten N.B. My new email address is : [EMAIL PROTECTED] The University of Nijmegen has changed its name to Radboud University Nijmegen ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
At 03:32 PM 10/8/2004, Marcin Kowalczyk wrote: Andrew Butterfield [EMAIL PROTECTED] writes: I though clean was always strict, and that was the major difference between clean and haskell (that and the fact clean is a proprietry language) No - Clean is pure and lazy like Haskell, But it uses explicit strictness annotations a lot, and provides strict and/or unboxed versions of various fundamental types (e.g. tuples), with some implicit coercions. It is of course not the language that uses strictness annotations. Clean programs without strictness annotations are perfectly lazy. Clean has a powerful strictness analysis that includes only safe strictness to function arguments. Programmers *can* include strictness annotations, exactly for the reasons that were mentioned in this thread, namely to influence the evaluation strategy in such a way that heap consumption and/or run time decrease. In addition, this can be done light-weight because annotations are added only to function argument types and data types, instead of modifying the code by inserting strict evaluator functions. Regards, Peter Achten N.B. My new email address is : [EMAIL PROTECTED] The University of Nijmegen has changed its name to Radboud University Nijmegen ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
On 08-Oct-2004, Andre Pang [EMAIL PROTECTED] wrote: I believe that Marcin wishes to prove the same point that I want to: namely, Clean encourages use of strictness by making it easier to use (via language annotations). At the risk of sounding ignorant and arrogant, I think the Haskell community in general does not understand the importance of syntactic sugar to make such tasks easier. I think the Haskell community understands well the importance of syntactic sugar; witness the use of syntactic sugar for monads, the `infix` operator syntax, the layout rules, etc. I think the Haskell community has just been a bit slower in understanding the importance of strictness :) But that seems to be gradually changing. -- Fergus J. Henderson | I have always known that the pursuit Galois Connections, Inc.| of excellence is a lethal habit Phone: +1 503 626 6616 | -- the last words of T. S. Garp. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
I feel a bit guilty for my ugly wc implementation. At the moment of writing the first version I was thinking only about efficiency, not about elegance. [..] We have already created on this list a version which is fast and quite elegant at the same time, and I feel this one is better for the shootout even if it's slower than the one currently used (but it doesn't use unsafeRead). The good news is that the development GHC 6.3 compiles this to code which is almost as fast as the ugly one. I agree; the code should look reasonable - this will be many people's first sight of Haskell code. Count me as a vote for the better-but-slightly-slower wc. --KW 8-) -- Keith Wansbrough [EMAIL PROTECTED] http://www.cl.cam.ac.uk/users/kw217/ University of Cambridge Computer Laboratory. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
Peter Simons [EMAIL PROTECTED] writes: Keith Wansbrough writes: Count me as a vote for the better-but-slightly-slower wc. How about the attached program? On my machine it faster than Tomasz's version, and I think it's still a fairly clean source code I guess it's possible to submit three different Haskell entries (for GHC, Hugs and NHC). Perhaps we should split up, and aim for performance with GHC, memory with NHC and clarity/brevity with Hugs? (Seriously, it would be very instructive to look at the differences between the three versions.) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
Well, the sootout itself is using GHC, as it lists both language and implementation. There is no entry for NHC or Hugs... So I would say if the GHC specific code is neat and fast put it in... If people hant to see a NHC then there should be a separate implentation of haskell (for example I can see at least 3 schemes in the sootout) Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
Also, its nice to see GHC ahead of Java now in the standard results... Would be nice to beat OCaml Clean though ... Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
looking at ghc's scores... this would seem to be the next candidate for a rework: -- $Id: reversefile.ghc.html,v 1.6 2004/10/03 00:44:58 bfulgham Exp $ -- http://www.bagley.org/~doug/shootout/ -- from Julian Assange main = interact $ unlines . reverse . lines Compare this with the gcc implementation which uses buffers and is 68 lines long! Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
MR K P SCHUPKE [EMAIL PROTECTED] writes: Well, the sootout itself is using GHC, as it lists both language and implementation. There is no entry for NHC or Hugs... Both nhc98 and Hugs have been added in the last few days. Regards, Malcolm ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
Andre Pang writes (in the Haskell cafe): The executive summary of my thoughts is that it seems to be entirely possible to optimise Haskell to be competitive with other, more performance-focused languages, but it's hard... and from his blog: if you need speed, you can get it in Clean much more easily in than Haskell. Perhaps Clean gives your more fine-grained control over the memory and execution behaviour of your program, but this is normally at the expense of clarity and elegance of your program. This is where I think we (FP-ers) stand: We can write elegant programs and we can write efficient programs, but combining these two aspects is still difficult. The Haskell and Clean entries in the Language Shootout clearly demonstrate this. Here are some ideas to better combine elegance and efficiency - decouple data and functions It's often easy to make choices in the data structures with an eye to efficiency, for example sometimes it's better to unbox elements (faster access), sometimes it's better to share the elements (use less memory). The programmer should be able to make these decisions without changing the functions that use the data structure. Overloading can help, but perhaps a good implementation of views will improve it further. - more compiler optimisations Preferably the optimisations should be reasonably predictable for the programmer. - programmer guided transformations, optimisations I don't think we'll ever reach the state where compiler optimisations can completely bridge the gap between elegance and efficiency. I don't mind giving it some help, but I'd like to keep my original program. For example, tell the compiler to unfold a function once, so that the function is strict in more arguments in the recursion. [In Clean] you can, for example, make an unboxed, strict array just by writing [# 1, 2, 3 !] rather than [1, 2, 3] I call [# 1, 2, 3 !] a tail-strict list with unboxed elements (it doesn't have constant time access). Cheers, Ronny Wichers Schreur ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
I though clean was always strict, and that was the major difference between clean and haskell (that and the fact clean is a proprietry language) Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
At 03:08 PM 07/10/2004 +0100, MR K P SCHUPKE wrote: I though clean was always strict, and that was the major difference between clean and haskell (that and the fact clean is a proprietry language) No - Clean is pure and lazy like Haskell, - the key difference is that it uses uniqueness types rather than monads to ensure the I/O is referentially transparent and safe. Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe Dr. Andrew Butterfield (http://www.cs.tcd.ie/Andrew.Butterfield/) Course Director, B.A. (Mod.) Information Communications Technology Dept.of Computer Science, Trinity College, Dublin University Tel: +353-1-608-2517, Fax: +353-1-677-2204 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
Andre, I very much enjoyed reading your blog entry. I would like to make a few comments. First of all I heartly agree with what you call the main problem. I quote: The main problem I see with all this is that its just too hard for an average Haskell programmer to get good performance out of Haskell. This is just so true and something which we need to do something about. What I would like to comment on is why we have this problem and what we can/should do about it. Why is it difficult to write good performance Haskell programs? Well, I'm not going to try and discuss this general question but focus on I/O since that is what this thread is really about. So let's formulate the question to: Why is it difficult to write good performance I/O in Haskell? From your blog entry I take it that you think that there is something wrong with the language Haskell. Maybe I misinterpret you but this is how I read it. I don't quite agree with this. What *is* true is that it is difficult to write good performance I/O in any of the *implementations* that we have. And this is ofcourse a shame. I think this is partly because fast I/O hasn't been that high a priority. I recall an email dating a few years back where Simon PJ was saying that they haven't spent that much time on making I/O blazingly fast. So perhaps bringing the issue on the table and making the implementors aware of it will improve on the situation. Although I do not believe that the Haskell language itself is to blame for why it's difficult to write decent performing I/O, the standard libraries might be a problem. It may be that the functions they provide are difficult to make efficient and that they encourage abuse. One particular function I have in mind is getContents. Maybe we need another set of functions which while still being highlevel are much easier to implement efficiently. Work in this direction has already started with the BlockIO library. I think this is an exciting and promising route to take. Andre, you suggest adding syntax to help the programmer writing faster code. Somehow I don't think that is the right way to go, even if it is only my gut feeling. I think this problem can and should be solved on the library level rather than on the language design level. But I might ofcourse be wrong. Ok, enough preaching for today. For the record, I also recommend O'Caml rather than Haskell to my performance-aware friends. /Josef Andre Pang wrote: On 29/09/2004, at 8:41 AM, Graham Klyne wrote: I can see that this requires the original file to be kept for 3-time scanning, so enough memory for the entire file will be required. Is that *the* problem to which you allude? I can't see any other problem here. And why would this put Haskell at a disadvantage? I've been watching this thread with interest, and posted my own thoughts on this thread and Haskell's performance in general as a blog entry. Rather than repeat it all here, I'll post a link to it: http://www.algorithm.com.au/mt/haskell/haskells_performance.html The executive summary of my thoughts is that it seems to be entirely possible to optimise Haskell to be competitive with other, more performance-focused languages, but it's hard, and you have to be a Haskell expert to do so. One possible solution may be to allow for some extra, syntactically integrated declarations to be inserted by the programmer which enables much better optimisation (e.g. see how to write unboxed strict array example in Clean: much more clear and less work than using IOUArrays). Performance is the one major reason I recommend many existing C programmers try out O'Caml rather than Haskell as their first functional programming language, and it would be really nice if optimisation was made a bit easier. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
MR K P SCHUPKE wrote: I though clean was always strict, and that was the major difference between clean and haskell (that and the fact clean is a proprietry language) Wrong on both accounts. See http://www.cs.ru.nl/~clean/About_Clean/about_clean.html and http://www.cs.ru.nl/~clean/Download/License_Conditions/license_conditions.html. Cheers, Ronny Wichers Schreur ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
On Thursday 07 Oct 2004 3:29 pm, Andrew Butterfield wrote: At 03:08 PM 07/10/2004 +0100, MR K P SCHUPKE wrote: I though clean was always strict, and that was the major difference between clean and haskell (that and the fact clean is a proprietry language) No - Clean is pure and lazy like Haskell, - the key difference is that it uses uniqueness types rather than monads to ensure the I/O is referentially transparent and safe. (At the risk of getting way out of my depth:-) I would say another important difference is that the languages semantics are defined directly in terms of graph re-writing, rather than lambda calculus. Not that I really understand anything about formal semantics, but IMO from a programmers perspective this is good thing because it allows programmers better control of sharing and to distinguish between constants (CAFs) and functions which take no arguments (both concepts being semantically meaningless in lambda calculus AFAIK). Regards -- Adrian Hey ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
what about, quote: N.B. CleanLanguage is only available under a restrictive license. It's LGPL so long as you're not selling anything you write. Otherwise you have to purchase a commercial license. This probably means CleanLanguage will not survive long. Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
Peter Simons [EMAIL PROTECTED] writes: The problem is not Haskell, nor is it the implementation. The problem is that beginners, including yours truly, tend to write awfully inefficient code once you give them a String and tell them: Here, that's the contents of your file. And it's just so *convenient* to use it. Nonetheless, the problem is the inefficient code, not the language. But even a simple, single-pass word-counting using the standard IO is slow, it would be really nice to write this in a straightforward way and still get decent performance. As somebody just said, you get to chose between speed and simplicity/clarity of code. I would like both. Couldn't readFile et al. provide the standard interface, but use hGetBuf tricks (e.g. from your 'wc' entry) behind the curtains? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
I thought that you could use chained buffers to implement the lazy lists, that way the top level interface would still be simple. Also there should be an easy graph-rewrite operation that turns your 3 sequential operations (in the wc example) into 3 parallel ones... put these two together in the compiler and the simple coding should perform near to the complex form. Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
On Wed, Oct 06, 2004 at 01:23:56PM -0400, Andre Pang wrote: I've been watching this thread with interest, and posted my own thoughts on this thread and Haskell's performance in general as a blog entry. Rather than repeat it all here, I'll post a link to it: http://www.algorithm.com.au/mt/haskell/haskells_performance.html I feel a bit guilty for my ugly wc implementation. At the moment of writing the first version I was thinking only about efficiency, not about elegance. I shouldn't have use unsafeRead, because it doesn't give such a big advantage here if you take the danger into account. Secondly, my solution fails to separate file iteration from the algoritm for the problem. We have already created on this list a version which is fast and quite elegant at the same time, and I feel this one is better for the shootout even if it's slower than the one currently used (but it doesn't use unsafeRead). The good news is that the development GHC 6.3 compiles this to code which is almost as fast as the ugly one. Maybe we should vote: which wc implementation should go to the shootout? Best regards, Tom -- .signature: Too many levels of symbolic links ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
