Re: [Haskell-cafe] Can Haskell outperform 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 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 increasingly as though there is no point in this discussion. Is there ANY conceivable criticism of Java that will not elicit ad hominem attacks from you? It isn't an ad hominem attack to ask you who's the authority that made some recommendation. -snip- Wait just a moment - you wrote I didn't _think_ I'd omitted anything important and now it turns out that the measurements were made using your personal Smalltalk implementation! You have got to be joking. Why? Because you omitted basic information about the measurements you presented. -snip- imo It would be better to show how much better programs using other data structures and algorithms perform those specific tasks than brandish anecdotes from a past century. Past century? Insults, is it? No, it's an echo of the words you used - ...insanely difficult in Fortran 77. This century's Fortran is of course another matter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
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 unicode? -snip- Using System.in directly takes the time down from 15.07 seconds to 11.11 seconds. -snip- With both of these changes, we are moving away from recommended good practice; the faster code is the kind of code people are not supposed to write any more. Says who? Is that on your own authority or some other source you can point us to? -snip- As for Smalltalk, you must be thinking of free Smalltalk systems that lacked a JIT. Commercial Smalltalks have excellent JITs (many HotSpot ideas were copied from them) ... As for Smalltalk, I earned my crust with commercial Smalltalks for a decade. These particular measurements were made using my own Smalltalk compiler which is an oddity amongst Smalltalks: a whole program compiler that compiles via C. Yes, most of the good ideas came from INRIA, although ST/X does something not entirely dissimilar. Wait just a moment - you wrote I didn't _think_ I'd omitted anything important and now it turns out that the measurements were made using your personal Smalltalk implementation! You have got to be joking. fwiw my expectation is that should be possible to make the Java program considerably faster. -snip- Any reasonable person would expect ... I'm happy to hear what *you* would expect. -snip- And it's not INTERESTING, and it's not about LANGUAGES. There is NOTHING about the Java language that makes code like this necessarily slow. It's the LIBRARY. The java.io library was designed for flexibility, not speed. That's why there is a java.nio library. Here's the gorilla in the room question - So why doesn't your program use java.nio? And that's the point I was making with this example. Why does Smalltalk come out in the middle of the Java results? A balance between a language penalty (tagged integer arithmetic is a lot slower than native integer arithmetic) and a library bonus (a leaner meaner I/O design where there are wrappers if you want them but you very seldom need them). It's the great advantage of using libraries rather than syntax: libraries can be changed. No, that doesn't seem to be the case - if I'm misunderstanding what you've done then please correct me, but it seems that Smalltalk comes out in the middle of the Java results because you chose to use a Java library designed for flexibility, not speed and you chose to use that library in a way that slows the program down. -snip- Neither. I am making the point that many benchmarks benchmark library code rather than languages or compilers per se, and that the concept of same algorithm is as a result very fuzzy. Thank you, for stating your point clearly. -snip- How is I have seen a lot of code construed as just speculating? You seem to be generalizing from what you recollect without any way to control for the particularities of the situations you observed, or the particularities of your recollection. You don't seem to have data - just memories. -snip- My evidence may be anecdotal, but it is better than arguing with NO evidence. imo It would be better to show how much better programs using other data structures and algorithms perform those specific tasks than brandish anecdotes from a past century. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
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 Smalltalk. I have no difficulty believing that if you are talking about a 1996 Java reference implementation and a 1996 Smalltalk JIT VM. I could believe that if you are comparing a naive Java program with a highly tweaked Smalltalk program. That C is 7x faster is a bit on the high end, but for something like tsort I could imagine it'd be possible. It's possible because it's possible to write a Java program to be slower than it need be :-) 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 that and not -- Do bear in mind that Smalltalk doesn't optimize that's the JIT's job -- or -- Do bear in mind that C doesn't optimize that's the compiler's job. -snip- But even still, in my experience of using Smalltalk, the standard data structures are much better done and so they will be on-par with what you'd get from hand-tuning for Java. I've spent a lot of time trying to get decent performance out of Java, not so much with Smalltalk; but the performance with Smalltalk was sufficient that it wasn't needed so badly. Do you have a specific example that you can share? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
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 fast it can read the data. If 90% of the time goes into reading the data, that means that the *algorithmic* part is fast enough. 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. I didn't _think_ I'd omitted anything important. Oh well. -snip- 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 version) 15.07 seconds Smalltalk 14.52 seconds C 2.36 seconds fwiw my expectation is that Java would not be that much slower than C, and would be considerably faster than Smalltalk. fwiw my expectation is that should be possible to make the Java program considerably faster. Of course, what I expect and what happens are often very different ;-) Of course, to some degree, user defined hash functions remedy that specific problem. While creating other, and perhaps worse, ones. For example, in the Smalltalk code, if you use a Dictionary of Strings, you're getting Robert Jenkin's hash function in optimised C. If you supply your own, you're getting a very probably worse hash function and it's going to run rather slower. And above all, the stuff you are benchmarking is no longer code that people are actually likely to write. I think you're being a touch quarrelsome :-) That upset me. I'm sorry that gentle comment upset you. All I was saying is that surely the only *point* of talking about the performance of *languages* is to get some idea of how well programs are likely to do, and not any old specially crafted code, but the kind of code that is likely to be written for purposes other than benchmarking. So the more you bash on a particular example to get the time down, the less representative it is of the kind of code people are likely to write *for purposes other than benchmarking*. Certainly less representative of the kind of code students are likely to write for course credits, and the kind of code people are likely to write to complete some project task before they hand it off to someone else, and the kind of code people are likely to write until their program is actually put into use and suddenly they are working the weekend to make their program faster. A more positive way to think of - code written for purposes of benchmarking - is that it's like code written to address a performance hot spot. Just today I marked a student program where their program took 15 minutes and my model answer took a touch under 4 milliseconds. I explained to them _that_ their program was spectacularly slow. They already knew _why_ it was. I also explained the one trick (lazy initialisation) that could have hugely improved the time. I also told them that they had made the right decision, to optimise *their* time, not the computer's, in their particular context. The whole point is carried by your final assertion. Here's another anecdote - in my first week on site, I overheard a group of engineers arguing that Smalltalk should be abandoned because calculation times were incredibly slow. I peeked at the code, saw that it was littered with unnecessary numeric conversions (plus unnecessary arbitrary precision arithmetic), fixed and timed a sample, and left them with a lot of rework to do all across their library code. The kind of code people are likely to write is sometimes best described as bad. That can have consequences which spiral out of proportion -- an engineer writes some bad Smalltalk, an app performs so slowly the business group loses money, the manager of the business group notices and is shown that the slow app is the problem (and it really is the problem), the manager now knows that Smalltalk is slow, the manager moves the business group away from Smalltalk, the manager is promoted and moves the whole organization away from Smalltalk. That's also an anecdote. *That* function, no. *Some* hash function as a primitive (meaning optimised C), well, I don't have every Smalltalk, but the ones I do have, I've checked, and yes they do. Maybe I misunderstood the thrust of your original comment - Were you trying to make a point about writing in C and calling that code from Smalltalk as a user written primitive; or were you trying to make a point about the importance of using a better hash function? Have you researched what code people are actually likely to write, or are you just speculating? ;-) I'm in my 6th decade. I've seen a lot of code in a lot of languages. So just
Re: [Haskell-cafe] Can Haskell outperform C++?
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 be written to do better than that - but it's idiotic of me to say so without understanding the specifics, please forgive me ;-) Actually, I/O bound is *good*. Why would that be good or bad? I suppose you're just suggesting that, in this case, the performance characteristics of the Java and Smalltalk programs are similar to the C program; but, for whatever reason, you're leaving us guessing about the timings for those other programs. -snip- Of course, to some degree, user defined hash functions remedy that specific problem. While creating other, and perhaps worse, ones. For example, in the Smalltalk code, if you use a Dictionary of Strings, you're getting Robert Jenkin's hash function in optimised C. If you supply your own, you're getting a very probably worse hash function and it's going to run rather slower. And above all, the stuff you are benchmarking is no longer code that people are actually likely to write. I think you're being a touch quarrelsome :-) Do *all* Smalltalk language implementations provide that same hash function in optimised C? Have Smalltalk language implementations *always* provided that same hash function in optimised C? How might that hash function be used when the (not necessarily Smalltalk) language implementation does not provide it? Have you researched what code people are actually likely to write, or are you just speculating? ;-) -snip- But we're still going to ask - Will my program be faster if I write it in language X? - and we're still going to wish for a simpler answer than - It depends how you write it! Here's another little example. I had a use for the Singular Value Decomposition in a Java program. Should I use pure Java or native C? Pure Java taken straight off the CD-ROM that came with a large book of numerical algorithms in Java: T seconds. After noticing that the code was just warmed over Fortran, and was varying the leftmost subscript fastest (which is good for Fortran, bad for most other languages) and swapping all the matrix dimensions: T/2 seconds. After rewriting in C: T/4 seconds. After rewriting the C code to call the appropriate BLAS and thereby using tuned code for the hardware, T/7 seconds. Since this was going to take hundreds of seconds per run, the answer was easy. Maybe the more interesting question was - Should I use a scripting language + BLAS. It depends is the second best answer we can get. The best answer is one that says _what_ it depends on. That may be the best answer to some other question - but for the stated question I think were looking for a Yes or a No :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
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 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 really that impossible. A few years ago one of the architects at Adobe published some slides on the software engineering aspects of PhotoShop, unfortunately I couldn't find them on the web when I tried recently but I believe it stated the codebase was well over 1 million lines of C++ and the GUI (including Adobe's own frameworks) accounted for more than half of that... GUI's often *are* the program rather than a way in to use it. What about a more recent code base, this is from a 2008 presentation on Adobe Lightroom 2: - 63% of the main Lightroom-team authored code is Lua - 16% C++ - 12% ObjC - 9% C http://www.troygaul.com/LrExposedC4.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
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, or built-in types, then requiring the same algorithm makes sense--- because the algorithm is irrelevant other than to provide a bunch of calls to the runtime/vm/etc. However, benchmarking a language's implementation in this way is rarely that helpful. It's great for comparing CPython to PyPy (or any other in-language cross-compiler comparison), but what would it tell you about Haskell vs C++? The PyPy crowd won't like it if you take programs written for CPython and measure how they run with PyPy - that's not fair. But it might take a couple of years before they contribute programs optimised for PyPy :-( (You already said what it would tell you, but questioned how helpful that would be.) If the goal is to compare, say, production costs for a given level of performance, then fixing the algorithm is not at all fair. The fact of the matter is that different languages make different algorithms easier to (a) implement, and (b) discover/identify/generalize. Thus, when it comes to real-world software, the language that makes it easy to implement good algorithms has a major advantage--- an advantage which is being specifically ignored by fixing the algorithm aforehand. Let's just say that's true - Is it useful? What would we need to do to make the comparison? We could do something like - Plat_Forms: Is there a single best web development technology? A professional programming contest http://page.mi.fu-berlin.de/prechelt/Biblio/platforms07-cacm-2010.pdf But that was just once, with very few teams, and only one problem -- seems like it would need to be repeated more often than is affordable, and with more teams than can be persuaded to donate their time. Maybe your point is true but practically useless? :-( In order for fair to have any meaning whatsoever, we must first specify what is being compared, so that we know what it is that things are supposed to be fair with regard to. 'What does not fair mean? (A fable)' http://stackoverflow.com/a/6380299 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
- 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 DIFFERENCE BETWEEN *LANGUAGES* and is in this particular case. That seems like a modest and uncontentious claim. There is also a second claim, which I thought was uncontentious: the relative difficulty of tasks varies with language. That doesn't seem unlikely; but I think you'd have to spell out just what you mean by language, and it also doesn't seem unlikely that for the same task the relative difficulty might flip when other details change (the people doing the task, the language implementation, the libraries available for the language implementation...) It all seems so very particular ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
- 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. In the permutation generation example, I was talking about four programs: Language X Language Y Method 1 Program X1 Program Y1 -- identical algorithms Method 2 Program X2 Program Y2 -- identical algorithms However, identical isn't clearly defined. 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 a C program and gnat from an Ada program. -snip- 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 without understanding the specifics, please forgive me ;-) They have I/O libraries with very different structures, so what does identical algorithms mean? If you are using dictionaries/hashmaps, and the two languages have implementations that compute different hash functions for strings, is _that_ using the same implementation? Of course, to some degree, user defined hash functions remedy that specific problem. I agree with the thrust of your comments - even programming languages (and implementations) that seem similar, are often so different (when we get down to specifics) that comparison between programs written in different languages is a matter of making the best of a bad job. But we're still going to ask - Will my program be faster if I write it in language X? - and we're still going to wish for a simpler answer than - It depends how you write it! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
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 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 help of others on this list. I look forward to your support and constructive feedback. Gregg Gregg, You wrote that you were looking at the benchmarks and then made a definite assertion about what was shown on the website. Unsuspecting readers would assume that you were truthfully reporting what you saw on the website. I cannot explain to them why you made an assertion which could be seen not to be true, simply by looking at the benchmarks game website. best wishes, Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Can Haskell outperform C++?
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? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
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 algorithms, appear to be short computationally intensive programs with a fairly low level of abstraction. Tiny tiny toy programs - more or less 100 lines - not quite small enough to be microbenchmarks. Why might that be? Well, not IO bound. Do people usually mean IO performance when they compare programming languages? (I guess you must have excluded meteor-contest from your consideration. It's a coding contest and so doesn't specify an algorithm.) In almost all examples, the requirement says: you must implement the X functions as implemented in Java, or C#, or C++. binary-trees - No, it doesn't say that. thread-ring - No. chameneos-redux - No. pidigits - No. regex-dna - No. k-nucleotide - No. mandelbrot - No. reverse-complement - No. spectral-norm - Each program must implement 4 separate functions / procedures / methods like the C# program. (The point being cross function calling so don't amalgamate 4 functions into a single function.) fasta-redux - No. fasta - No. meteor-contest - No. fannkuch-redux - defined by programs in Performing Lisp Analysis of the FANNKUCH Benchmark n-body - Each program should model the orbits of Jovian planets, using the same simple symplectic-integrator - see the Java program. The k-nucleotide even specifies a requirement to use an update a hash-table. Probably not too onerous a requirement for a test of hash table lookup :-) Some people like hash tables, go figure. http://gregorycollins.net/posts/2011/06/11/announcing-hashtables -snip- Interesting that you would focus on this one comment in my post and not comment on one on countering the benchmarks with a new criteria for comparing languages. Too obvious to be interesting. Interesting that you haven't said how you know they are designed to favor imperative languages ;-) On 5/16/2012 12:59 PM, Isaac Gouy wrote: 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? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Can Haskell outperform C++?
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 that they don't measure llvm because they don't have time. But I think they are refering to clang. So maybe someone should tell them to turn on the llvm flag since it makes a lot of haskell programs faster. Several GHC versions have come and gone since the Haskell benchmarks game programs were written, so perhaps it is time that a dozen new programs were written to replace those old programs - new programs that take advantage of GHC 7.4.1 and -llvm. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] fyi GHC 7.2.1 release on the benchmarks game
1) Some of the GHC programs contributed to the benchmarks game have problems with recent GHC releases - meteor-contest #5 - Ambiguous occurrence `permutations' http://shootout.alioth.debian.org/u64q/program.php?test=meteorlang=ghcid=5#log - regex-dna #2 - Precedence parsing error http://shootout.alioth.debian.org/u64q/program.php?test=regexdnalang=ghcid=2#log - reverse-complement #2 - parse error on input `-' http://shootout.alioth.debian.org/u64q/program.php?test=revcomplang=ghcid=2#log - reverse-complement #3 - Could not find module `Monad' http://shootout.alioth.debian.org/u64q/program.php?test=revcomplang=ghcid=3#log 2) I noticed `-fvia-C` has now gone away and there were half-a-dozen programs that had been written to use `-fvia-C` so how might that effect performance of those programs? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fyi GHC 7.2.1 release on the benchmarks game
--- On Fri, 8/12/11, austin seipp a...@hacks.yi.org wrote: Thanks, I do like easy fixes :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with threading?
--- On Thu, 6/10/10, Louis Wasserman wasserman.lo...@gmail.com wrote: Date: Thursday, June 10, 2010, 1:32 AM Yeah, Control.Parallel would be nice to have. Heck, ideally I could get the whole Haskell Platform, which would be a reasonable comparison to the huge Java and C++ libraries accessible to those languages. And having the whole Haskell Platform still isn't enough to compile those regex-dna programs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with threading?
--- On Wed, 6/9/10, Don Stewart d...@galois.com wrote: -snip- Now how do we get those regex-dna and binary-trees programs to compile? http://shootout.alioth.debian.org/u32/measurements.php?lang=ghc binary-trees: Could not find module `Control.Parallel.Strategies': -- cabal install parallel regex-dna: cannot satisfy -package regex-posix -- cabal install regex-posix parallel, regex-posix, regex-pcre are now installed and the current compile errors are caused by the programs not the absence of required libraries - http://shootout.alioth.debian.org/u64q/program.php?test=binarytreeslang=ghcid=2#log http://shootout.alioth.debian.org/u64q/program.php?test=binarytreeslang=ghcid=3#log http://shootout.alioth.debian.org/u64q/program.php?test=regexdnalang=ghcid=4#log http://shootout.alioth.debian.org/u64q/program.php?test=regexdnalang=ghcid=1#log ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with threading?
--- On Thu, 6/10/10, Louis Wasserman wasserman.lo...@gmail.com wrote: Date: Thursday, June 10, 2010, 1:32 AM Yeah, Control.Parallel would be nice to have. Heck, ideally I could get the whole Haskell Platform, which would be a reasonable comparison to the huge Java and C++ libraries accessible to those languages. Out of curiosity, though, Haskell's thread-ring implementation just tumbled down the rankings http://shootout.alioth.debian.org /u64q/program.php?test=threadringlang=ghcid=3. Previously, it'd been doing most of its work on a single core, now it's spread out. Any ideas for fixin' it? (I'm going to to try using forkOnIO.) There are 4 sets of rankings so - http://shootout.alioth.debian.org/u64/program.php?test=threadringlang=ghcid=3 I have been wondering what approach is recommended when one part of a program would be a lot faster with -threaded but other parts of the program would be a lot faster without -threaded. I can see that the C++ and Fortran and ... programmers would just wrap part of their program source code with a pragma. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with threading?
--- On Thu, 6/10/10, Louis Wasserman wasserman.lo...@gmail.com wrote: Date: Thursday, June 10, 2010, 11:25 AM There are 4 sets of rankings so - http://shootout.alioth.debian.org/u64/program.php?test=threadringlang=ghcid=3 Yes, but Haskell used to be doing much better specifically on the u64q, which was why I was surprised. I tend not to believe used to be doing much better comments until I'm shown the numbers ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with threading?
--- On Thu, 6/10/10, Don Stewart d...@galois.com wrote: From: Don Stewart d...@galois.com Subject: Re: [Haskell-cafe] Problems with threading? To: Louis Wasserman wasserman.lo...@gmail.com Cc: igo...@yahoo.com, Haskell Café List haskell-cafe@haskell.org Date: Thursday, June 10, 2010, 11:36 AM wasserman.louis: There are 4 sets of rankings so - http://shootout.alioth.debian.org/u64/program.php?test=threadring〈=ghc; id=3 Yes, but Haskell used to be doing much better specifically on the u64q, which was why I was surprised. Oh, indeed, http://shootout.alioth.debian.org/u64q/performance.php?test=threadring Something broke. Simon Marlow described how best to parallelize this problem extensively in: http://www.haskell.org/~simonmar/bib/multicore-ghc-09_abstract.html So I'd suggest doing what he says. In particular, use thread pinning to improve locality. -qw -qm ? How's that going to work out when applied to the other Haskell programs? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with threading?
--- On Thu, 6/10/10, Don Stewart d...@galois.com wrote: From: Don Stewart d...@galois.com Subject: Re: [Haskell-cafe] Problems with threading? To: Isaac Gouy igo...@yahoo.com Cc: Louis Wasserman wasserman.lo...@gmail.com, Haskell Café List haskell-cafe@haskell.org Date: Thursday, June 10, 2010, 12:54 PM igouy2: Simon Marlow described how best to parallelize this problem extensively in: http://www.haskell.org/~simonmar/bib/multicore-ghc-09_abstract.html So I'd suggest doing what he says. In particular, use thread pinning to improve locality. -qw -qm ? How's that going to work out when applied to the other Haskell programs? I'm sure it does bad things to them. Yep, earlier in the week I measured the programs using +RTS -N4 -qw -qm which is why I wonder how you would approach programs that have a mix of performance characteristics? Maybe there aren't large Haskell programs like that? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with threading?
--- On Mon, 6/7/10, Don Stewart d...@galois.com wrote: From: Don Stewart d...@galois.com Subject: Re: [Haskell-cafe] Problems with threading? To: Isaac Gouy igo...@yahoo.com Cc: Louis Wasserman wasserman.lo...@gmail.com, Haskell Café List haskell-cafe@haskell.org Date: Monday, June 7, 2010, 4:43 PM igouy2: As Louis has already mentioned this to me, I'll take the opportunity to sketch out a simple approach - 1) GHC programs compiled without -threaded and run without +RTS -N are already shown for x86 and x64 http://shootout.alioth.debian.org/u32/compare.php?lang=ghc http://shootout.alioth.debian.org/u64/compare.php?lang=ghc 2) For quad-core, the GHC programs will all be compiled with -threaded and all run with +RTS -N4 3) That seems to match the approach taken with Erlang, where all the programs on quad-core run with smp built into the vm, and all the programs on one core run without smp built into the vm. Yep, that's fine. All the GHC programs have been re-measured. http://shootout.alioth.debian.org/u64q/compare.php?lang=ghc http://shootout.alioth.debian.org/u32/compare.php?lang=ghc Now how do we get those regex-dna and binary-trees programs to compile? http://shootout.alioth.debian.org/u32/measurements.php?lang=ghc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with threading?
--- On Mon, 6/7/10, Don Stewart d...@galois.com wrote: From: Don Stewart d...@galois.com Subject: Re: [Haskell-cafe] Problems with threading? To: Louis Wasserman wasserman.lo...@gmail.com Cc: Haskell Café List haskell-cafe@haskell.org Date: Monday, June 7, 2010, 2:50 PM wasserman.louis: While working on the Shootout, I noticed the following benchmarks: http://shootout.alioth.debian.org/u64/program.php?test=chameneosredux〈=ghc; id=3 http://shootout.alioth.debian.org/u64q/program.php?test=chameneosredux〈= ghcid=3 The same program becomes almost 4 times slower when compiled with --threaded and run with +RTS -N5 -- even though the multi-core benchmark really only ever uses one processor. Using -N5 sounds suspicious. There are only 4 cores on the machine. -N5 is likely to have been your orsuggestion for getting the most out of ghc 6.10.* :-) -snip- I wanted to throw this out for people to discuss, because I'd like to see it improved. As Louis has already mentioned this to me, I'll take the opportunity to sketch out a simple approach - 1) GHC programs compiled without -threaded and run without +RTS -N are already shown for x86 and x64 http://shootout.alioth.debian.org/u32/compare.php?lang=ghc http://shootout.alioth.debian.org/u64/compare.php?lang=ghc 2) For quad-core, the GHC programs will all be compiled with -threaded and all run with +RTS -N4 3) That seems to match the approach taken with Erlang, where all the programs on quad-core run with smp built into the vm, and all the programs on one core run without smp built into the vm. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Language Shootout reverse-complement benchmark
On Tue, Jun 1, 2010 at 10:25 AM, David Leimbach leimy2k at gmail.com wrote: I'm still trying to figure out what the point of the shootout really is. From one point of view - http://shootout.alioth.debian.org/help.php#why If there's no dedicated folks working with a language there, trying to make things run faster, a language will come out looking inefficient potentially. If there isn't even one effective programmer willing to contribute tiny programs ... There's a lot of compile flags and optimizations that can make a difference in probably all of the languages listed on that page. The compile flags and optimizations used are shown below the program source code. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Benchmarks game updated to ghc 6.12.2
Ketil Malde ketil at malde.org writes: As for code size, the programs are heavily tuned for speed. iirc there was a community effort 2 or 3 years ago, but now ghc has changed enough that the compiler and runtime parameters seem to need re-tuning. Is it an idea to go back a few steps to more idiomatic code? Perhaps as a separate track? There's always room for 2 or 3 Haskell programs per task - not necessarily The Good, the Bad and the Ugly - but you'll already find the cliched example of a faster more convoluted Haskell program and a more concise but slower Haskell program. (Idiomatic code? Aren't there idioms for writing fast Haskell too?) I also worry a bit that source code optimization for a specific compiler makes it more difficult to take advantage of compiler optimization improvements. These are tiny tiny programs - when those compiler optimization improvements arrive re-write the programs to take advantage of them ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Shootout update
On Mar 30, 1:26 am, Simon Marlow marlo...@gmail.com wrote: The shootout (sorry, Computer Language Benchmarks Game) ... In a different time, in a different place, the shootout meant a football once again flying over the cross bar or harmlessly into the arms of the keeper and England once more exiting an international competition. Here in the west it has meant slaughter - back in 2004 crossed-pistols were suggested as the website image. Wading through Google search results comprised of porn sites and college mass murder just wasn't a bright happy start to the day for me - so after Virginia Tech I changed the name. I should probably have moved everything to a new project (a new URL). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The Computer Language Benchmarks Game: pidigits
On Mon May 25 16:18:29 EDT 2009, Arnaud Payement wrote: ... I thought it is better to show Haskell as one would naturally write it. One would naturally first write it in C ? :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc
--- On Fri, 2/20/09, Bulat Ziganshin bulat.zigans...@gmail.com wrote: -snip- You need look no further than the debian language shootout that things really aren't as bad as you're making out √ Haskell comes in in general less than 3x slower than gcc compiled C. you should look inside these tests, as i done :) When did you look - six months ago? a year ago? 3 years ago? most of these tests depends on libraries speed Most? 2 of 12 strongly depend on libraries because PCRE and GMP are explicitly allowed. in one test, PHP is 1st I don't believe that has ever been true - which test? from 2 or 3 tests that depends on compiler speed, one was fooled by adding special function readInt to ghc libs and the rest are written in low-level haskell code - look the sources Please note that sum-file is not included in the current tests. Please note that sum-file has not been included since autumn 2008. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[4]: [Haskell-cafe] Re: speed: ghc vs gcc
--- On Fri, 2/20/09, Bulat Ziganshin bulat.zigans...@gmail.com wrote: From: Bulat Ziganshin bulat.zigans...@gmail.com Subject: Re[4]: [Haskell-cafe] Re: speed: ghc vs gcc To: Isaac Gouy igo...@yahoo.com Cc: haskell-cafe@haskell.org Date: Friday, February 20, 2009, 4:43 PM Hello Isaac, Saturday, February 21, 2009, 3:28:31 AM, you wrote: When did you look - six months ago? a year ago? 3 years ago? ah, again this argument. two weeks ago Don said that ghc changed a lot in 2 years, now when we see that there is no difference, he says that those loop optimizer is somewhere noone know where. now i should look into new set of tests just because everyone else believe that ghc is shiny. please look yourself, i will continue to say about testset i have seen when 6.6 arrived If you're going to continue talking about a testset you saw in 2006 then tell people you are talking about 2006. most of these tests depends on libraries speed Most? 2 of 12 strongly depend on libraries because PCRE and GMP are explicitly allowed. *were* depending on libs speed. in particular, haskell's triumph - multithreading tests, chameneos or so Most? If you add those 2, that makes 4 out of 12 (4 out of 17 in the old data). in one test, PHP is 1st I don't believe that has ever been true - which test? large regexps one PHP is not 1st in regex-dna. PHP is not even 1st in regex-dna in the old data. PHP is not even in the first 15 in regex-dna in the old data. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Climbing up the shootout...
--- Simon Brenner [EMAIL PROTECTED] wrote: On Mon, Sep 22, 2008 at 2:07 PM, Bulat Ziganshin [EMAIL PROTECTED] wrote: this overall test is uselles for speed comparison. afair, there are only 2-3 programs whose speed isn't heavily depend on libraries. in DNA test, for example, Tcl (or PHP?) was leader just because it has better regexp library On the regex-dna benchmark, I'll have to agree. It's unfortunate to have a benchmark so dependent on the set of libraries included in the distribution, and e.g. Text.Regex.PCRE kicks Text.Regex.Posix's behind in this benchmark - but we probably can't use it only because one's bundled and the other isn't. Maybe we could roll our own regexp engine for this specific benchmark though (for example, Text.Regex.TDFA is within 10% or something of PCRE and AFAIK pure Haskell - a customized and downsized version of that could probably be made quite competitive). You could always suggest use of Text.Regex.PCRE, provide a program and instructions on how to install Text.Regex.PCRE on Ubuntu. -snip- With bytestrings, unboxed arrays, light-weight threads and other tricks, we can usually replace all those ugly low-level programs with nice high-level haskell ones ... Go do! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[6]: [Haskell-cafe] Climbing up the shootout...
--- Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello Graham, i don't think that these 3 libs allows to write high-level high-performance code in *most* cases. just for example, try to write wc without using words. To a newbie, that's a cryptic statement. Are you saying that these libs aren't needed to make a high-performance wc, and that the Prelude functions are sufficient? (I note too that there is Data.ByteString.Char8.words, but I assume you are talking about the Prelude function.) i mean that naive haskell code is very slow and 3 or 5 or twelve libs can't solve the problem of ghc generating slow code Is there something particularly fascinating about naive code written in any language? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Speed Myth
--- Don Stewart [EMAIL PROTECTED] wrote: -snip How should the benchmarks game approach multicore? Well, there's a famous paper, Algorithm + Strategy = Parallelism I'd imagine we use the benchmark game's algorithms, but let submitters determine the strategy. Then the results would show a) how well you utilize the cores, and b) overall wall clock results. otoh I see the attraction of showing parallelised versions alongside existing programs; otoh that adds yet another layer of confusion about why the measurements differ (and another level of quarreling about whether even vaguely the same thing is being measured); otoh some existing programs already use more cores when they can ... The Scala threadring program shows 524s cpu but 157s elapsed: http://shootout.alioth.debian.org/u64q/benchmark.php?test=threadringlang=all I'm keen to get going on this, if only because I think we can turn out parallelised versions of many of the existing programs, fairly cheaply. I'm always delighted that you're keen to get going on things like this! The benchmarks game always seems to demand somewhat unnatural acts and here's another - is there an effective way to /prevent/ ghc using multiple cores when multiple cores are available? Can we force ghc to only use one core on the quadcore machine? (Moreover can we do the same trick for other languages?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Speed Myth
dons: (Where I note GHC is currently in second place, though we've not submitted any parallel programs yet). We might call that the thread-ring effect :-) Also CC'd Isaac, Mr. Shootout. Isaac, is the quad core shootout open for business? Should we rally the troops? iirc there was some discussion after the last GHC release about cleaning up the programs to make them less low-level given the improved capabilities of the compiler - I don't think that ever happened, and low level seems to be a common complaint against the Haskell programs shown in the benchmarks game. As Simon Peyton-Jones suggested we're certainly open for suggestions: http://groups.google.com/group/fa.haskell/browse_thread/thread/7eb82c689de8688/4f3c47b976394666?lnk=stq=alioth+shootout#4f3c47b976394666 However, we're operating new measurement scripts on both u64q (published) and gp4 (unpublished), and my focus is still on catching up to where we were with measurements from the old scripts, and installing third-party libraries on u64q. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Speed Myth
--- Don Stewart [EMAIL PROTECTED] wrote: -snip- So still consolidating the system. Pretty much. Do I understand though, that if we submit, say, a quad-core version of binary-trees, for example, using `par` and -N4, it'll go live on the benchmark page? That's an open question - should it? How should the benchmarks game approach multicore? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] shootout using 6.6?
--- Don Stewart [EMAIL PROTECTED] wrote: igouy2: Duncan Coutts wrote Note that ghc-6.8.2 is in gentoo now and has been for a few weeks. There's no reason not to use it. Cool! It shall be done! Great. Do let us know when its available. A couple of benchmarks will need to be tweaked in light of library changes. I'm also hoping to see good speedups for constructor-matching heavy programs like binary-trees. Yes that was a good speed up :-) otoh there are several failing programs... http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=ghclang2=ghc Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] shootout using 6.6?
Duncan Coutts wrote Note that ghc-6.8.2 is in gentoo now and has been for a few weeks. There's no reason not to use it. Cool! It shall be done! Mea culpa - when I was considering building ghc from source I seem to have unmerged ghc, so ghc-6.8.2 didn't show up in the portage updates. Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why can't Haskell be faster?
Ketil Malde wrote: [LOC vs gz as a program complexity metric] Do either of those make sense as a program /complexity/ metric? Seems to me that's reading a lot more into those measurements than we should. It's slightly interesting that, while we're happily opining about LOCs and gz, no one has even tried to show that switching from LOCs to gz made a big difference in those program bulk rankings, or even provided a specific example that they feel shows how gz is misrepresentative - all opinion, no data. (Incidentally LOC measures source code shape as much as anything else - programs in statement heavy languages tend to be longer and thinner, and expression heavy languages tend to be shorter and wider.) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why can't Haskell be faster?
--- Jon Harrop [EMAIL PROTECTED] wrote: On Friday 02 November 2007 19:03, Isaac Gouy wrote: It's slightly interesting that, while we're happily opining about LOCs and gz, no one has even tried to show that switching from LOCs to gz made a big difference in those program bulk rankings, or even provided a specific example that they feel shows how gz is misrepresentative - all opinion, no data. Why gzip and not run-length encoding, Huffman coding, arithmetic coding, block sorting, PPM etc.? Choosing gzip is completely subjective and there is no logical reason to think that gzipped byte count reflects anything of interest. Why waste any time studying results in such an insanely stupid metric? Best case you'll end up concluding that the added complexity had no adverse effect on the results. In contrast, LOC has obvious objective merits: it reflects the amount of code the developer wrote and the amount of code the developer can see whilst reading code. How strange that you've snipped out the source code shape comment that would undermine what you say - obviously LOC doesn't tell you anything about how much stuff is on each line, so it doesn't tell you about the amount of code that was written or the amount of code the developer can see whilst reading code. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why can't Haskell be faster?
--- Sebastian Sylvan [EMAIL PROTECTED] wrote: -snip- It still tells you how much content you can see on a given amount of vertical space. And why would we care about that? :-) I think the point, however, is that while LOC is not perfect, gzip is worse. How do you know? Best case you'll end up concluding that the added complexity had no adverse effect on the results. Best case would be seeing that the results were corrected against bias in favour of long-lines, and ranked programs in a way that looks-right when we look at the program source code side-by-side. It's completely arbitrary and favours languages wich requires you to write tons of book keeping (semantic noise) as it will compress down all that redundancy quite a bit (while the programmer would still has to write it, and maintain it). So gzip is even less useful than LOC, as it actively *hides* the very thing you're trying to meassure! You might as well remove it alltogether. I don't think you've looked at any of the gz rankings, or compared the source code for any of the programs :-) Or, as has been suggested, count the number of words in the program. Again, not perfect (it's possible in some languages to write things which has no whitespace, but is still lots of tokens). Wouldn't that be completely arbitrary? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why can't Haskell be faster?
--- Greg Fitzgerald [EMAIL PROTECTED] wrote: while LOC is not perfect, gzip is worse. the gzip change didn't significantly alter the rankings Currently the gzip ratio of C++ to Python is 2.0, which at a glance, wouldn't sell me on a less code argument. a) you're looking at an average, instead try http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=pythonlang2=gpp b) we're not trying to sell you on a less code argument - it's whatever it is Although the rank stayed the same, did the change reduce the magnitude of the victory? c) that will have varied program to program, and do you care which way the magnitude of victory moved or do you care that where it moved to makes more sense? For fun, 2 meteor-contest programs, ratios to the python-2 program LOC GZ WC ghc-3 0.981.401.51 gpp-4 3.764.144.22 Look at the python-2 and ghc-3 source and tell us if LOC gave a reasonable indication of relative program size - is ghc-3 really the smaller program? :-) http://shootout.alioth.debian.org/gp4/benchmark.php?test=meteorlang=allsort=gz __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Great language shootout: reloaded
Donald Bruce Stewart wrote: -snip- I agree. Breaking the rules was mainly the reason for the drop. Entries like chameneos and fasta. Also, the other language teams kept improving things. Yes, I missed that opportunity for listing things in threes ;-) Over the year improved programs were contributed for other languages. In contrast to the last focussed effort by the Haskell community, many of the other programs are contributed by individuals working alone, over many weeks. Other language (perl, iirc) were affected far worse by the gzipping. gzip is an interesting measurement, and it doesn't hurt Haskell too much either way -- short Haskell programs stay short when compressed. As a result, rewriting verbose entries to ByteString will probably be much more useful :) Btw, Isaac, are we going to have any new parallelism benchmarks? I'd love to try out the SMP runtime ;) If we were to have a 'which is the silliest comparison on the computer language shootout' competition, I think chameneos and cheap-concurrency would be joint first - there are so many really really different approaches. Ideas for unicode text processing would be more welcome. Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Great language shootout: reloaded
On 11/10/06, Henk-Jan van Tuyl hjgtuyl at chello.nl wrote: Haskell suddenly dropped several places in the overall socre, when the size measurement changed from line-count to number-of-bytes after gzipping. Maybe it's worth it, to study why this is; Haskell programs are often much more compact then programs in other languages, but after gzipping, other languages do much better. One reason I can think of, is that for very short programs, the import statements weigh heavily. Before this gets out-of-hand, my memory is certainly fallible but as I recall Haskell /did not/ drop several places because size measurement changed from line-count to gzip byte-count. 1) Check the webpage that Don Stewart cached and note the values for the memory use and code-lines multipliers, and note the values for the benchmark weights http://www.cse.unsw.edu.au/~dons/data/haskell_1.html Now go to the computer language shootout website and note the multipliers and benchmark weights. 2) Some Haskell programs were pushed into 'interesting alternative implementations' because they'd strayed so far from the spirit of the benchmark. (It takes a while for people to notice and complain, but eventually they do.) Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Known Unknowns
--- Ketil Malde [EMAIL PROTECTED] wrote: Isaac Gouy [EMAIL PROTECTED] writes: Programmer skill and effort really does matter ;-) Yes, more so, than any inherent language disadvantage, perhaps, which happens to be the general lesson from the ICFP contests as well. Any idea if other languages have seen similar efforts? FreePascal and Smart Effiel, somewhat - and there have been excellent individual efforts with Lua and Tcl and ... imo the Haskell Cafe discussions and wiki have been a more open and shared learning experience than we usually see, and maybe some of the success stems from that collaboration and competition. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Number 1, at least for now
--- Sebastian Sylvan [EMAIL PROTECTED] wrote: It seems to be number 2 at the moment. It looks like it, all of a sudden, has one missing benchmark. Did something break? Previously the GHC program was shown incorrectly as completing regex-dna within the timeout - now it's shown correctly. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Known Unknowns
--- Chris Kuklewicz [EMAIL PROTECTED] wrote: -snip,snip- It is 3rd fastest. Looking at Just Memory Use, Haskell is 8th Looking at Just Lines Of Code, Haskell is 1st Lookat at the 1:1:1 even balance Haskell is 1st Programmer skill and effort really does matter ;-) Congratulations. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shootout favouring C
--- Brent Fulgham [EMAIL PROTECTED] wrote: As expected, GHC makes quite a good showing, moving to 4th position behind ... Rather than look at rank position look at the relative performance (and remember that Bigloo tops ackermann on The Sandbox). http://shootout.alioth.debian.org/sandbox/fulldata.php?test=ackermannp1=clean-0p2=gnat-0p3=bigloo-0p4=ghc-3 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shootout favouring C
Shootout favouring C On 1/16/06, Daniel Fischer wrote: Is it only my machime, or can you confirm that for the Ackermann benchmark, it's very good for C that they chose 9 and not a larger value? Sebastian Sylvan [EMAIL PROTECTED] wrote: This is interesting. Hopefully it's not intentional, Pardon my rudeness but this really is getting a bit much! Please keep to the true spirit of fictional crime writing and provide a motive for these evil characters who will stop at nothing to make Haskell seem some worse than C. but it's quite obvious that for benchmarks where the fastest time is only a few fractions of a second, languages with more complex runtime systems will be unfairly slow due to the startup cost. Sebastian perhaps you'd like to provide something more substantive than quite obvious. Only last week I was sent some rude email based on the claim that there was a strong correlation between how well the Java programs compared to the C programs, and the time taken by the Java programs. I haven't heard from the author since I noted that he had mistakenly made a correlation with the time taken by the C programs, and there wasn't any correlation between how well the Java programs compared and the time taken by the Java programs. There is already a startup benchmark in there Yes and if we make the huge assumption that it means anything at all, then we are being unfair to Haskell by 0.002s on every test - we only show measurements to 0.01s! In other words I'd prefer if all benchmarks are reconfigured to target an execution time of at least a few seconds for the fastest benchmarks. We run the Haskell regex-dna programs for 2500s - isn't that long enough? Let me join Simon Marlow in congratulating those who are using the Shootout to advertise what Haskell can do, by the straightforward approach of contributing faster, smaller, more elegant programs. best wishes, Isaac __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Shootout favouring C
--- Brent Fulgham [EMAIL PROTECTED] wrote: it's not such a big deal to extend the timeout (as we have done for spectralnorm and others), and I think it would be good to do so for the Ackermann test. For ackermann, the constraint is stack-space not run-time. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shootout favouring C
--- Daniel Fischer [EMAIL PROTECTED] wrote: the Ackermann benchmark, it's very good for C that they chose 9 and not a larger value? For 10, we are significantly faster and for 11,12,13, we can run rings around the C-programme homepage: understand that the faster program may become the slower program when the workload changes Maybe when there's a working version of this, it'll turn out to be the faster program http://shootout.alioth.debian.org/debian/benchmark.php?test=ackermannlang=ghcid=0 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shootout favouring C
--- Benjamin Franksen [EMAIL PROTECTED] wrote: What is the reason the debian/amd page lists different program versions than gentoo/intel page? On the former, ghc fails two tests (downgrading it to rank 4), whereas on the latter, it does not and thus has rank 2. 1) Both test machines take programs from the same CVS repository. They are updated at different times, and at different frequencies - so they don't always show the same set of programs. 2) On gentoo/intel we should be showing that the regex-dna programs have Error - check the output from each program. (That's a bug in the shootout scripts on the gentoo/intel machine.) 3) afaict nbody on debian may have the program args mixed-up- Brent? nbody.ghc-2.ghc_run %A $MB_GHCRTS (on debian) nbody.ghc-2.ghc_run $MB_GHCRTS %A (on gentoo) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shootout favouring C
--- Daniel Fischer [EMAIL PROTECTED] wrote: motive Jealousy? I've never used C or C++ so I probably don't mix with enough of those guys to say, but the impression I got was of, shall we say, 'assertive confidence'. -snip- and I dare say Java does suffer from that even more than GHC -snip- then we are being unfair to Haskell by 0.002s on every test - we only show measurements to 0.01s! And you take the average of how many runs? See the FAQ How did you measure ? http://shootout.alioth.debian.org/faq.php#measure -snip- So I don't consider timings of such short tasks very reliable So look at the tasks where the fastest program takes seconds and needs more than 5 lines of code :-) -snip- And though I've no reason to suppose it would help Haskell, for the same reasons, I'd like the fannkuch benchmark changed to Pfannkuchen(10). That's been shown for Gentoo/Intel since at least December http://shootout.alioth.debian.org/gp4/fulldata.php?test=fannkuchp1=gcc-0p2=ghc-2p3=gcc-0p4=ghc-2 -snip- Unfortunately, often the desire for speed wrecks elegance Contribute elegant slower programs and maybe we'll show them - we're currently showing two C++ sum-file programs, one's ~25x faster than the other. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shootout rankings
Haskell now ranked 2nd overall, only a point or so behind C: It was always obvious that the Write the program as-if lines of code were not being measured clause relied too heavily on contributors willingness to co-operate. http://shootout.alioth.debian.org/gp4/faq.php#implementlist Maybe we finally have enough motivation to move to some other measurement of program volume :-) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shootout rankings
--- Donald Bruce Stewart [EMAIL PROTECTED] wrote: -snip- Ah! Just as I thought, SML really was trying very hard ;) Quite possibly so, but no reason to follow down that slippery slope ;) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] powerful type checking false expectations that a program is correct
Programmers who use languages without static type checking sometimes claim that static type checking gives folk the false impression that once the program passes type checking the program is correct. That always seemed silly to me, but I'm starting to wonder ;-) Of course, the shootout programs are a silly entertainment; but after taking the time to optimise and write the programs, I'm a little surprised that there have been Haskell contributions which just don't give 'the correct answer' in a way that visual inspection with the expected answer would detect. For example ackermann Haskell GHC program regex-dna (new) Haskell GHC #2 program Oh well, they are just easy to fix formating bugs :-) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Chameneos
--- Aaron Denney [EMAIL PROTECTED] wrote: Are we off-topic for this mailing-list? I'd just like to respond to this: Anyways, your shootout, your hard work, your rules, but having rulings on what's acceptable be easier to find would be nice. People here have made the effort to develop programs for the shootout - I appreciate /their/ hard work. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Chameneos
--- Aaron Denney [EMAIL PROTECTED] wrote: On 2006-01-11, Chris Kuklewicz [EMAIL PROTECTED] wrote: Aaron Denney wrote: The old version with the meeting place thread has been disqualified (along with Erlang submissions). Is this reasoning explained and clarified anywhere, or did they just move both to the interesting alternatives? The forums there seem to be useless, and the mailing list does not appear to be used anymore. The forums there seem to be useless because...? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Chameneos
--- Aaron Denney [EMAIL PROTECTED] wrote: The forums there seem to be useless because...? Because I can't find anything relevant (and I did look). I can't even tell where such an announcement would have been made. Ah! Useful for finding an announcement - maybe not. otoh the forums do allow QA without subscription. In this case, there was no announcement - just a notification to Einar Karttunen - but if you look at the programs on the website you'll find this note: http://shootout.alioth.debian.org/gp4/benchmark.php?test=chameneoslang=ghcid=2#about And that was already commented on by folk on this mailing-list. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] In for a penny, in for a pound.
--- Chris Kuklewicz [EMAIL PROTECTED] wrote: I have two strong suggestions: * whoever does submit them should diff the output with a previously accepted version. -snip- Simply diff program output with the example output file (there's now an output file link in each problem description). Of course, that won't guarantee the program is correct but it'll catch simple formating problems. There's a simple formating problem with the regex-dna program http://shootout.alioth.debian.org/gp4/benchmark.php?test=regexdnalang=ghcid=2#log __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Shootout favoring imperative code
I sent a private email and the response to it has appeared on this mailing-list, so let me just correct some of the interpretations that have been made. You can say that again! Ah..sarcasm, I know that one. No, it was emphatic agreement (the ordinary usage of that phrase). Is a persecution complex required for Haskell programming :-) This one is sarcasm. Hi Sebastian :-) I'm waiting for the complaints that binary-trees was designed to favour functional programming languages ;-) ;-) == sarcasm Actually no - binary-trees was written with functional programming languages very much in mind. best wishes, Isaac __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help with shootout
--- Chris Kuklewicz [EMAIL PROTECTED] wrote: -snip- which is the wrong kind of CPU anyway -- they test on an AMD system What machine are you running the programs on? http://shootout.alioth.debian.org/gp4/faq.php#machine __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell Speed
Simon Marlow wrote: Also, I would like to draw your attention to the fact that GHC wipes the floor with nearly everyone in the concurrency benchmark SmartEiffel is so much faster that I'm still trying to figure out if it's doing something different :-) Be interesting to see GHC on the other concurrency benchmark... http://shootout.alioth.debian.org/benchmark.php?test=chameneoslang=all Seriously, it's very difficult to draw any meaningful conclusions from these benchmarks. Is it any easier to draw meaningful conclusions about the relative performance of programming languages from some other benchmarks? __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell Speed
Jared Updike wrote: What that means is the results are completely subject to (1) how good the submission for that tests was Contribute faster more-elegant programs http://shootout.alioth.debian.org/gp4/faq.php#contribute (2) the choice of tests in the first place Suggest better tests http://shootout.alioth.debian.org/gp4/faq.php#newbench (3) startup times for loading the binaries into memory (GHC makes big binaries that are arguably much faster if you do things in daemon mode, for example). Is that just speculation? (Erlang is an application server starting-up and that really is noticeable.) -snip- it is pretty much a game created to make C win---it already wins! Which C do you mean - gcc, Intel C, Tiny C? And, no! It is not a game created to make C win (although it is a game). And, no! C does not already win all the games - astonishingly it doesn't even win the basic loop and array test nsieve. __ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell Speed
Branimir Maksimovic wrote: Of course, first example uses [String] instead of Data.HashTable as other languages do. Imagine C program does not use hash,rather list, how it will perform:) And the author comments his program -- This is a purely functional solution to the problem. -- An alternative which keeps a mutable table of occurences would -- be faster. We'll be happy to also show a Haskell program that uses Data.HashTable - first, someone needs to contribute that program. I didn't look further after that. Ideal - you may criticize without the risk that others will criticize what you do. __ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
