Re[2]: [Haskell-cafe] What's the deal with Clean?
Hello Don, http://shootout.alioth.debian.org/u64q/benchmark.php?test=alllang=ghclang2=cleanbox=1 http://shootout.alioth.debian.org/u64q/benchmark.php?test=alllang=ghclang2=ocamlbox=1 The Haskell compiler isn't the bottleneck. Use it when performance matters. I do. Don, shootout times may be used to measure how many people was contributed solutions for each language, but nothing more. these tests depends mainly on libraries bundled with each compiler and, secondary, on enthusiasts writing low-level code -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] What's the deal with Clean?
Hello Ketil, Wednesday, November 4, 2009, 4:31:20 PM, you wrote: Well, it clearly demonstrates that it is possible to write fast code in Haskell. my measures says that by psending 3x more time than for C you can optimize haskell code to be only 3x slower than C one succinct and correct programs. (Is it possible to have an alternative Haskell track in the shootouts?) even w/o enthusiasts Shootout mainly measure speed of libraries Since this was done, there has been great strides in available libraries and GHC optimizations, and it'd also be interesting to see whether we now are able to optimize ourselves away from much of the overhead. eh, if it was possible, we have seen this. both on shootout and here when people are crying that their code isn't as fast as those ads say. haskell compilation can't yet automatically avoid laziness and convert pure high-level code into equivalent of C one. libraries doesn't change anything - they provide low-level optimized solutions for particular tasks but can't optimize your own code once you started to write it -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] What's the deal with Clean?
I personally don´t care about raw performance. Haskell is in the top of the list of language performance. It has all the ingredients for improving performance in the coming years: A core language, clear execution strategy, analysis and parsing, transformations based on math rules. So my code will improve with each new compiler version at the same or better pace than any other language. Moreover I can not care less about how fast is C, when I simply can not program many things I need in C or C++ or Java and in general any of the language of the performance list that are above... or below, because they lack the necessary type safety, expressiveness, abstraction.etc. Not to mention time. Not to mention the growing community etc. Regards. 2009/11/4 Bulat Ziganshin bulat.zigans...@gmail.com Hello Ketil, Wednesday, November 4, 2009, 4:31:20 PM, you wrote: Well, it clearly demonstrates that it is possible to write fast code in Haskell. my measures says that by psending 3x more time than for C you can optimize haskell code to be only 3x slower than C one succinct and correct programs. (Is it possible to have an alternative Haskell track in the shootouts?) even w/o enthusiasts Shootout mainly measure speed of libraries Since this was done, there has been great strides in available libraries and GHC optimizations, and it'd also be interesting to see whether we now are able to optimize ourselves away from much of the overhead. eh, if it was possible, we have seen this. both on shootout and here when people are crying that their code isn't as fast as those ads say. haskell compilation can't yet automatically avoid laziness and convert pure high-level code into equivalent of C one. libraries doesn't change anything - they provide low-level optimized solutions for particular tasks but can't optimize your own code once you started to write it -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] What's the deal with Clean?
Hello Ketil, Wednesday, November 4, 2009, 7:43:38 PM, you wrote: Right?, the interesting thing is not how fast I can get with N times the effort, but if I can get fast enough with 1/N. it depends entirely on how fast you need. so it's again changing the topic - while i say that haskell is slow compared to other languages, i don't say that it is slow for you or that you need sped at all. why it's repeated again and again? why you don't write to Don what you don't need speed when he wrote that haslkell is fast but wrote this to me? :( when people are crying that their code isn't as fast as those ads say. haskell compilation can't yet automatically avoid laziness and convert pure high-level code into equivalent of C one. Many of those people are making fairly simple mistakes. I think a somewhat seasoned programmer using good libraries can write declarative, concise, and readable code that still is reasonably fast. i don't think that omitting strictness declarations is a mistake :) ?) At least for some approximation of the word. Only one benchmark on the shootout has C at a 3x advantage. oh, can we stop saying about shootout? if you want to see speed of pure haskell code, look at papers about fast arrays/strings - their authors have measured that lazy lists are hundreds times slower than idiomatic C code. is use of lazy lists counted as mistake too and paper authors had too small haskell experience? -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] What's the deal with Clean?
On 05/11/2009, at 04:01, Bulat Ziganshin wrote: oh, can we stop saying about shootout? if you want to see speed of pure haskell code, look at papers about fast arrays/strings - their authors have measured that lazy lists are hundreds times slower than idiomatic C code. is use of lazy lists counted as mistake too and paper authors had too small haskell experience? In the papers I coauthored, I don't think we measured any such thing. What we measured was that in algorithms that are best implemented with (unboxed) arrays, using boxed lists is going to cost you. That's not a very surprising conclusion and it's by no means specific to Haskell. The problem was/is the lack of nice purely declarative array libraries but that changing, albeit slowly. It's a question of using the right data structure for the algorithm, not a C vs. Haskell thing. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
