9 ms·

> The result is that I find myself doing more and more things in Haskell, which lets me write high-level code with decent performance (still slower than what I

> The result is that I find myself doing more and more things in Haskell, which lets me write high-level code with decent performance (still slower than what I get if I go all the way down to C++, but with very good libraries). This strikes me as an odd conclusion to come to if speed was the main motivator.

thinkpad20 9y ago
How so? Haskell has a very high performance ceiling.
- gameswithgo 9y ago
  it does have a high perf ceiling, but the code isn't easy to write when you approach it. Things like C#, F#, Java, Kotlin, Nim, Lua would be more natural things to turn to when you want something "Easy" like python but faster, I think.
  - nightski 9y ago
    I think you could replace "isn't easy" with "isn't familiar". Haskell is very likely to be the first language a developer encounters which is lazy by default instead of strict by default (for many good reasons). So no, it's not easy in a similar fashion that pointers or double pointers in C/C++ are not easy. Or understanding call by value vs. call by reference semantics are not easy. The list goes on. It's probably the largest barrier to learning the language. But once you get a handle on the evaluation model it becomes a lot more natural. At least that was my experience, maybe it is not typical.
  - gaius 9y ago
    I use OCaml when I need something like a fast, type-safe Python
- banachtarski 9y ago
  It really doesn't... I think it's "better" but I definitely wouldn't classify it as high.
bringtheaction 9y ago
Me too. I have heard from someone that used Haskell in production that lazy evaluation caused trouble in terms of achieving predictable performance.
- nightski 9y ago
  Yes, naive use of lazy evaluation can cause performance problems. So can naive use of strict evaluation. It's important to have a solid understanding of your languages evaluation model. This is probably the largest barrier to writing highly performant Haskell. Not because it is vastly more difficult or anything, but it is very different than pretty much any other widely used language.
zwerdlds 9y ago
Not saying you're wrong - you definitely don't get great performance easily in Haskell, but it seems to have better benchmarks than python, by a lot.
- ohyes 9y ago
  “Lies, damn lies and benchmarks” I think is the saying. Python itself is a slow language but it has a lot of fast packages, so it shows poorly when you actually write your benchmark in python. Haskell is a faster language but because it is high level there are more pitfalls you’ll get into if you don’t know the ins and outs of getting fast code out of the compiler. The guys who write fast benchmark code aren’t ‘average’ developers. So in Haskell it’s “the code is slow and I don’t know why” vs python “the code is slow because python is slow, import fast package someone wrote to speed it up.” All that said, I think Haskell is the better language but you have to put in more effort to get experienced in it before you see returns on the investment. Python has a shallower learning curve and an easy way to get “good enough” performance (a bit slower than C). The best criticism in the article is of the multi-core deficiency of python’s interpreter. But that’s only briefly touched on. It isn’t a friendly environment to write complicated multi core code.
  - acqq 9y ago
    > Python has a shallower learning curve and an easy way to get “good enough” performance (a bit slower than C). The article we all reply to exactly claims that as soon as you don't use e.g. NumPy, it's not "good enough" anymore, and I agree with that. The article also argues that e.g. JavaScript isn't more in the same category with Python, but much faster, even if it's not less dynamic. I think the reason for JavaScript's speed vs. Python's slowness is obvious: there were wealthy companies involved, which were, due to competition pressures, motivated to speed up their own JavaScript engines. To get to the point where Python has similar speeds somebody would have to be motivated enough to invest heavily, and then it could happen. As far as I know, there aren't technical limitations against that.
    - pjmlp 9y ago
eksemplar 9y ago
I read it as a compromise. I don’t think the author is primarily a programmer, but mainly uses high-level “easy” languages to do data science. C++ would probably increases his development time significantly compared to Haskell.
willtim 9y ago
GHC Haskell is an advanced optimising compiler, which can get very near the speed of C and C++. However, to write fast programs, one must use the right data structures and algorithms. Often this means array-based strings and streaming IO, unfortunately many Haskell textbooks don't tend to cover this.
- luispedrocoelho 9y ago
  Yep, my Haskell usage is "conduit all the way down". I even wrote up a few utilities to make use of multiple threads while working at a high level: https://hackage.haskell.org/package/conduit-algorithms-0.0.7.1/docs/Data-Conduit-Algorithms-Async.html https://hackage.haskell.org/package/conduit-algorithms-0.0.7...
- bjoli 9y ago
  All comparisons of Haskell and C I have seen where Haskell has been near the performance of C(++) has always compared a highly optimised Haskell program to a moderately fast c program. I have found that most managed languages generally come within 2-5 times slower than C and C++. Which is good enough for me.
  - imtringued 9y ago
    The JVM is fast enough for me but for some reason any JVM project requires hundreds of megabytes of RAM even for the simplest things. cpp webserver + sqlite database + cygwin overhead? 9MB RAM lua worker + websocket client? 4MB RAM JVM server + static html page + websocket relay + kurento api? 500MB RAM With the exception of the cpp webserver none of these tasks are CPU or memory intensive yet the JVM is still off by orders of magnitude. It's ok if it's the only application running on a server with multiple users but there is just a single user and that's me.
    - willtim 9y ago
      Have you tried specifying a smaller maximum heap size? The biggest memory issue IMHO, is that Java and the JVM do not specialise any "generic" code and so there can be a lot of unnecessary boxing going on.
luispedrocoelho 9y ago
OP here. Speed is the main motivation, but total time is TimeToWriteCode + TimeToRunCode. Python has the lowest TimeToWriteCode, but very high TimeToRunCode. C++ has lowest TimeToRunCode, but high TimeTowWriteCode. Haskell is often a good compromise for me. Also, with Haskell, it can be very easy to take advantage of 20 CPU cores, while I don't have as much familiarity with high-level C++ threading libraries.
- pletnes 9y ago
  That’s easy with python, too, in a lot of number crunching cases. Numpy with MKL will use all your cores, as will e.g dask and other libraries built on numpy. Farming out embarassingly parallel work to threads or processes is also easy.
  - luispedrocoelho 9y ago
    If I can fit the code into numpy-like structure, then Python is typically fine. The issue is when I cannot.
    - fxmc 9y ago
      Have you given dask a try? It gives you out-of-core arrays with numpy semantics and distributed computing.
      - VHRanger 9y ago
        Dask doesn't solve that problem since it's a wrapper around pandas functions. If you can't make the core pandas code decently fast, dask won't save you.
        kiriliponi 9y ago
        dask.dataframe might not help but dask.distributed could in that case. I've had success using it on non vanilla stuff (i.e. code that could not get converted to play natively with numpy/pandas structures) As a bonus, the nice profiling tools (built within dask) have also helped me improve the performance of the code. See https://distributed.readthedocs.io/en/latest/ https://distributed.readthedocs.io/en/latest/

thinkpad20 9y ago

How so? Haskell has a very high performance ceiling.

gameswithgo 9y ago
it does have a high perf ceiling, but the code isn't easy to write when you approach it. Things like C#, F#, Java, Kotlin, Nim, Lua would be more natural things to turn to when you want something "Easy" like python but faster, I think.
- nightski 9y ago
  I think you could replace "isn't easy" with "isn't familiar". Haskell is very likely to be the first language a developer encounters which is lazy by default instead of strict by default (for many good reasons). So no, it's not easy in a similar fashion that pointers or double pointers in C/C++ are not easy. Or understanding call by value vs. call by reference semantics are not easy. The list goes on. It's probably the largest barrier to learning the language. But once you get a handle on the evaluation model it becomes a lot more natural. At least that was my experience, maybe it is not typical.
- gaius 9y ago
  I use OCaml when I need something like a fast, type-safe Python
banachtarski 9y ago
It really doesn't... I think it's "better" but I definitely wouldn't classify it as high.

bringtheaction 9y ago

Me too. I have heard from someone that used Haskell in production that lazy evaluation caused trouble in terms of achieving predictable performance.

nightski 9y ago
Yes, naive use of lazy evaluation can cause performance problems. So can naive use of strict evaluation. It's important to have a solid understanding of your languages evaluation model. This is probably the largest barrier to writing highly performant Haskell. Not because it is vastly more difficult or anything, but it is very different than pretty much any other widely used language.

zwerdlds 9y ago

Not saying you're wrong - you definitely don't get great performance easily in Haskell, but it seems to have better benchmarks than python, by a lot.

ohyes 9y ago
“Lies, damn lies and benchmarks” I think is the saying. Python itself is a slow language but it has a lot of fast packages, so it shows poorly when you actually write your benchmark in python. Haskell is a faster language but because it is high level there are more pitfalls you’ll get into if you don’t know the ins and outs of getting fast code out of the compiler. The guys who write fast benchmark code aren’t ‘average’ developers. So in Haskell it’s “the code is slow and I don’t know why” vs python “the code is slow because python is slow, import fast package someone wrote to speed it up.” All that said, I think Haskell is the better language but you have to put in more effort to get experienced in it before you see returns on the investment. Python has a shallower learning curve and an easy way to get “good enough” performance (a bit slower than C). The best criticism in the article is of the multi-core deficiency of python’s interpreter. But that’s only briefly touched on. It isn’t a friendly environment to write complicated multi core code.
- acqq 9y ago
  > Python has a shallower learning curve and an easy way to get “good enough” performance (a bit slower than C). The article we all reply to exactly claims that as soon as you don't use e.g. NumPy, it's not "good enough" anymore, and I agree with that. The article also argues that e.g. JavaScript isn't more in the same category with Python, but much faster, even if it's not less dynamic. I think the reason for JavaScript's speed vs. Python's slowness is obvious: there were wealthy companies involved, which were, due to competition pressures, motivated to speed up their own JavaScript engines. To get to the point where Python has similar speeds somebody would have to be motivated enough to invest heavily, and then it could happen. As far as I know, there aren't technical limitations against that.
  - pjmlp 9y ago

eksemplar 9y ago

I read it as a compromise. I don’t think the author is primarily a programmer, but mainly uses high-level “easy” languages to do data science. C++ would probably increases his development time significantly compared to Haskell.

willtim 9y ago

GHC Haskell is an advanced optimising compiler, which can get very near the speed of C and C++. However, to write fast programs, one must use the right data structures and algorithms. Often this means array-based strings and streaming IO, unfortunately many Haskell textbooks don't tend to cover this.

luispedrocoelho 9y ago
Yep, my Haskell usage is "conduit all the way down". I even wrote up a few utilities to make use of multiple threads while working at a high level: https://hackage.haskell.org/package/conduit-algorithms-0.0.7.1/docs/Data-Conduit-Algorithms-Async.html https://hackage.haskell.org/package/conduit-algorithms-0.0.7...
bjoli 9y ago
All comparisons of Haskell and C I have seen where Haskell has been near the performance of C(++) has always compared a highly optimised Haskell program to a moderately fast c program. I have found that most managed languages generally come within 2-5 times slower than C and C++. Which is good enough for me.
- imtringued 9y ago
  The JVM is fast enough for me but for some reason any JVM project requires hundreds of megabytes of RAM even for the simplest things. cpp webserver + sqlite database + cygwin overhead? 9MB RAM lua worker + websocket client? 4MB RAM JVM server + static html page + websocket relay + kurento api? 500MB RAM With the exception of the cpp webserver none of these tasks are CPU or memory intensive yet the JVM is still off by orders of magnitude. It's ok if it's the only application running on a server with multiple users but there is just a single user and that's me.
  - willtim 9y ago
    Have you tried specifying a smaller maximum heap size? The biggest memory issue IMHO, is that Java and the JVM do not specialise any "generic" code and so there can be a lot of unnecessary boxing going on.

luispedrocoelho 9y ago

OP here. Speed is the main motivation, but total time is TimeToWriteCode + TimeToRunCode. Python has the lowest TimeToWriteCode, but very high TimeToRunCode. C++ has lowest TimeToRunCode, but high TimeTowWriteCode. Haskell is often a good compromise for me. Also, with Haskell, it can be very easy to take advantage of 20 CPU cores, while I don't have as much familiarity with high-level C++ threading libraries.

pletnes 9y ago
That’s easy with python, too, in a lot of number crunching cases. Numpy with MKL will use all your cores, as will e.g dask and other libraries built on numpy. Farming out embarassingly parallel work to threads or processes is also easy.
- luispedrocoelho 9y ago
  If I can fit the code into numpy-like structure, then Python is typically fine. The issue is when I cannot.
  - fxmc 9y ago
    Have you given dask a try? It gives you out-of-core arrays with numpy semantics and distributed computing.
    - VHRanger 9y ago
      Dask doesn't solve that problem since it's a wrapper around pandas functions. If you can't make the core pandas code decently fast, dask won't save you.
      - kiriliponi 9y ago
        dask.dataframe might not help but dask.distributed could in that case. I've had success using it on non vanilla stuff (i.e. code that could not get converted to play natively with numpy/pandas structures) As a bonus, the nice profiling tools (built within dask) have also helped me improve the performance of the code. See https://distributed.readthedocs.io/en/latest/ https://distributed.readthedocs.io/en/latest/