4 ms·

I think one has to be careful about performance claims. Of course you can tweak things to be fast in hakell, but to be able to actually program haskell in such

by platz 13y ago

I think one has to be careful about performance claims. Of course you can tweak things to be fast in hakell, but to be able to actually program haskell in such a way to, beat other languages in performance, is not a trivial skill. There are numerous stackoverflow and r/haskell posts "Why is my haskell code 10x times slower than language X?" Or observe this set of web framework benchmarks: http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/

thinkpad20 13y ago
That good performance is not trivial to achieve is not really here nor there. Haskell is a difficult language and many people come into it with assumptions that come from imperative or strict languages and don't hold up in a lazy functional language. That there are programmers who are using the language in a non-optimal way, and coming away with reduced performance, is not a mark against the language itself. To the extent that the benchmarks prove anything, they prove that you can write Haskell code to be competitive with or any other language, at least in regards to those specific problems. Of course, it certainly doesn't prove that there are no areas in which Haskell - as a language, not in regards to specific uses - is not in the upper level of performance. As to the web frameworks benchmarks, I can't speak to them, as I don't know whether they were written expertly or with the latest available libraries. Maybe they aren't as fast. Regardless, it's clear that it's more than possible to write very performant code in Haskell, so ruling it out on those grounds makes little sense.
- platz 13y ago
  I don't think I made a mark against the language itself, or tried to rule it out, or tried to indicate it cannot attain the highest levels of performance - Yes, my point was just that there are programmers using Haskell in a non-optimal way. Beginners seem to be surprised when their Haskell code isn't automatically in the upper level. I'm not really a great fan of benchmarks, or this particular benchmark, but at least the source of every test is available: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/wai/bench/wai.hs https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/snap/bench/src/Main.hs https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/yesod/bench/src/yesod.hs https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...
  - igouy 13y ago
    > at least the source of every test is available Also true of the benchmarks game. (Also the command line used to compile and run the program, etc)
    - platz 13y ago
      Except the code used in the benchmarks game is hardly idiomatic
      - igouy 13y ago
        According to who's idea of what is or isn't idiomatic? Yours? Don Stewart's? http://www.willamette.edu/~fruehr/haskell/evolution.html http://www.willamette.edu/~fruehr/haskell/evolution.html Is this "idiomatic": http://benchmarksgame.alioth.debian.org/u64q/program.php?test=meteor&lang=ghc&id=4 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... "One can, with sufficient effort, essentially write C code in Haskell using various unsafe primitives. We would argue that this is not true to the spirit and goals of Haskell, and we have attempted in this paper to remain within the space of “reasonably idiomatic” Haskell. However, we have made abundant use of strictness annotations, explicit strictness, and unboxed vectors. We have, more controversially perhaps, used unsafe array subscripting in places. Are our choices reasonable?" "Measuring the Haskell Gap" http://www.leafpetersen.com/leaf/publications/ifl2013/haskell-gap.pdf http://www.leafpetersen.com/leaf/publications/ifl2013/haskel...
        platz 13y ago
        The meteor example isn't bad at all, no.
        igouy 13y ago
        Is this idiomatic? http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=ghc&id=2 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
username223 13y ago
> Of course you can tweak things to be fast in hakell, but to be able to actually program haskell in such a way to, beat other languages in performance, is not a trivial skill. No kidding: http://benchmarksgame.alioth.debian.org/u64/program.php?test=regexdna&lang=ghc&id=2 It's mostly a matter of knowing C, then knowing how to torture GHC into doing what the C would do.
- copergi 13y ago
  Linking to the benchmark game as if it means something should be a bannable offense. When you look at something that encourages speed at all costs, that is what you will see. People do low level optimizations like that to gain 0.5% better performance. That does not mean you need to do anything like that to get good performance.
  - igouy 13y ago
    > That does not mean you need to do anything like that to get good performance. Please contribute your Haskell regex-dna program that does not do anything like that and get's "good" performance. Here's the task description: http://benchmarksgame.alioth.debian.org/u64/performance.php?test=regexdna#about http://benchmarksgame.alioth.debian.org/u64/performance.php?... Here's "How to contribute programs": http://benchmarksgame.alioth.debian.org/play.php#contribute http://benchmarksgame.alioth.debian.org/play.php#contribute GHC 7.8.2 installed, cabal 1.2 stuff available as-needed.
    - copergi 13y ago
      >Please contribute your Haskell regex-dna program No. I stopped bothering with that cluster fuck like a decade ago. It is a complete waste of time.
      - igouy 13y ago
        We can stop bothering about your -- "That does not mean you need to do anything like that to get good performance."
chongli 13y ago
Of course you can tweak things to be fast in hakell, but to be able to actually program haskell in such a way to, beat other languages in performance, is not a trivial skill. It actually is trivial in a lot of cases. It's often as simple as swapping out lists for vectors and inserting a few strictness annotations into your types.
- danieldk 13y ago
  ...and using the ST monad. In the end it pretty much ends up looking like an imperative program. The good news is that it stops at the function boundaries. Your quicksort may be implemented in the ST monad, looking like some bastard child of C, but the function type ends up being qsort :: Ord a => Vector a -> Vector a And that's one of the likeable properties of Haskell: it doesn't deny that real-world programs sometimes require mutability, but allow you to isolate it through the type system. So, even though qsort may use mutable memory for sorting, it is a pure and referentially transparent function.

by platz 13y ago

thinkpad20 13y ago

That good performance is not trivial to achieve is not really here nor there. Haskell is a difficult language and many people come into it with assumptions that come from imperative or strict languages and don't hold up in a lazy functional language. That there are programmers who are using the language in a non-optimal way, and coming away with reduced performance, is not a mark against the language itself. To the extent that the benchmarks prove anything, they prove that you can write Haskell code to be competitive with or any other language, at least in regards to those specific problems. Of course, it certainly doesn't prove that there are no areas in which Haskell - as a language, not in regards to specific uses - is not in the upper level of performance. As to the web frameworks benchmarks, I can't speak to them, as I don't know whether they were written expertly or with the latest available libraries. Maybe they aren't as fast. Regardless, it's clear that it's more than possible to write very performant code in Haskell, so ruling it out on those grounds makes little sense.

platz 13y ago
I don't think I made a mark against the language itself, or tried to rule it out, or tried to indicate it cannot attain the highest levels of performance - Yes, my point was just that there are programmers using Haskell in a non-optimal way. Beginners seem to be surprised when their Haskell code isn't automatically in the upper level. I'm not really a great fan of benchmarks, or this particular benchmark, but at least the source of every test is available: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/wai/bench/wai.hs https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/snap/bench/src/Main.hs https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast... https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/yesod/bench/src/yesod.hs https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...
- igouy 13y ago
  > at least the source of every test is available Also true of the benchmarks game. (Also the command line used to compile and run the program, etc)
  - platz 13y ago
    Except the code used in the benchmarks game is hardly idiomatic
    - igouy 13y ago
      According to who's idea of what is or isn't idiomatic? Yours? Don Stewart's? http://www.willamette.edu/~fruehr/haskell/evolution.html http://www.willamette.edu/~fruehr/haskell/evolution.html Is this "idiomatic": http://benchmarksgame.alioth.debian.org/u64q/program.php?test=meteor&lang=ghc&id=4 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... "One can, with sufficient effort, essentially write C code in Haskell using various unsafe primitives. We would argue that this is not true to the spirit and goals of Haskell, and we have attempted in this paper to remain within the space of “reasonably idiomatic” Haskell. However, we have made abundant use of strictness annotations, explicit strictness, and unboxed vectors. We have, more controversially perhaps, used unsafe array subscripting in places. Are our choices reasonable?" "Measuring the Haskell Gap" http://www.leafpetersen.com/leaf/publications/ifl2013/haskell-gap.pdf http://www.leafpetersen.com/leaf/publications/ifl2013/haskel...
      - platz 13y ago
        The meteor example isn't bad at all, no.
        igouy 13y ago
        Is this idiomatic? http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=ghc&id=2 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...

username223 13y ago

> Of course you can tweak things to be fast in hakell, but to be able to actually program haskell in such a way to, beat other languages in performance, is not a trivial skill. No kidding: http://benchmarksgame.alioth.debian.org/u64/program.php?test=regexdna&lang=ghc&id=2 It's mostly a matter of knowing C, then knowing how to torture GHC into doing what the C would do.

copergi 13y ago
Linking to the benchmark game as if it means something should be a bannable offense. When you look at something that encourages speed at all costs, that is what you will see. People do low level optimizations like that to gain 0.5% better performance. That does not mean you need to do anything like that to get good performance.
- igouy 13y ago
  > That does not mean you need to do anything like that to get good performance. Please contribute your Haskell regex-dna program that does not do anything like that and get's "good" performance. Here's the task description: http://benchmarksgame.alioth.debian.org/u64/performance.php?test=regexdna#about http://benchmarksgame.alioth.debian.org/u64/performance.php?... Here's "How to contribute programs": http://benchmarksgame.alioth.debian.org/play.php#contribute http://benchmarksgame.alioth.debian.org/play.php#contribute GHC 7.8.2 installed, cabal 1.2 stuff available as-needed.
  - copergi 13y ago
    >Please contribute your Haskell regex-dna program No. I stopped bothering with that cluster fuck like a decade ago. It is a complete waste of time.
    - igouy 13y ago
      We can stop bothering about your -- "That does not mean you need to do anything like that to get good performance."

chongli 13y ago

Of course you can tweak things to be fast in hakell, but to be able to actually program haskell in such a way to, beat other languages in performance, is not a trivial skill. It actually is trivial in a lot of cases. It's often as simple as swapping out lists for vectors and inserting a few strictness annotations into your types.

danieldk 13y ago
...and using the ST monad. In the end it pretty much ends up looking like an imperative program. The good news is that it stops at the function boundaries. Your quicksort may be implemented in the ST monad, looking like some bastard child of C, but the function type ends up being qsort :: Ord a => Vector a -> Vector a And that's one of the likeable properties of Haskell: it doesn't deny that real-world programs sometimes require mutability, but allow you to isolate it through the type system. So, even though qsort may use mutable memory for sorting, it is a pure and referentially transparent function.