4 ms·

Cython 0.47s less ...ignoring the cdefs, it's just as readable or more, at least for someone used to reading imperative code as opposed to functional code or m

by nnq 13y ago

Cython 0.47s less ...ignoring the cdefs, it's just as readable or more, at least for someone used to reading imperative code as opposed to functional code or mathematical equations. Plus that it takes you 5 minutes to quickly get from a quick and dirty Python hackoff to Cython. And you can stay blissful and ignorant about what "stream fusion" is, focusing on the problem you try to solve and not on the computer science of the tools. Haskell really is far far away from the "don't make me think" philosophy (or "don't make me think of anything else besides the real problem that I'm trying to solve"). No wonder Python and Cython are so loved in the scientific computing field :)

AndreasFrom 13y ago
As you acknowledge yourself, whether Haskell makes you think or not relies on what you're trained to read.
- nnq 13y ago
  Yes, you're right that Haskell is probably easier to read for someone with the mathematical background. But I'm referring to the cognitive overload incurred when you try to optimize it, thinking about list creation costs, then stream fusion to avoid it: most physicists or mathematicians will cringe at the thought of having to think about these "computer sciency optimization stuff". As opposed to this, a crude tool such as Cython or C or even Fortran allows one to just "skip thinking" about these and still have fast enough code. Haskell is great if you want to expand your CS knowledge, but not if your math/physics/engineering problem is already so complicated that it uses up all your available brain cycles and working memory and you just can't squeeze thinking about language-specific optimizations too. I guess this is why it's only used by companies like Galois and such that are already neck deep in advanced CS problems and used to thinking about them all the time.
  - PaulAJ 13y ago
    There is a saying: first make it work, then make it work fast. The problem with doing the second in imperative languages is that you need to pull all your working code apart and rewrite it. Haskell separates the "make it work" from the "make it work fast".
  - nightski 13y ago
    Except that no one actually thinks about that stuff when writing actual vector code. Trust me, I have written several real time 3D reconstruction algorithms (such as SLAM) in Haskell and was not thinking about stream fusion at all.
  - Dewie 13y ago
    > Yes, you're right that Haskell is probably easier to read for someone with the mathematical background. I am quite taken by Haskell, and I have the whopping mathematical background of two introductory courses from my institute of mathematics. > But I'm referring to the cognitive overload incurred when you try to optimize it, thinking about list creation costs, then stream fusion to avoid i The author didn't need to know what stream fusion was; all they did was import a library... it might as well have been called import MagicallyOptimizingPrelude and it would have the same effect.
  - chongli 13y ago
    But I'm referring to the cognitive overload incurred when you try to optimize it, thinking about list creation costs, then stream fusion to avoid it That's not true. This article is about a library that works as a drop-in replacement of the default list processing functions in the Prelude. Eventually, it may be possible that these functions will be put into the Prelude itself. This would allow naive users to get all the performance gains from stream fusion without ever knowing it's happening. All of the "cognitive overload" is taken care of by the researchers who developed this technique and the library authors who implement it.
tel 13y ago
This article was less a practical look into how to write fast Haskell code and more a peel-back-the-curtain look. Practically, you'd just use the vector lib [0] which has massive amounts of stream fusion built into it and exposes only very simple immutable and mutable APIs. [0] http://hackage.haskell.org/package/vector http://hackage.haskell.org/package/vector
curiouslearn 13y ago
I agree. I think the Cython version is eminently readable.
freyrs3 13y ago
I take issue with this benchmark since comparing it to Haskell is not illuminating since the Cython cdef function is straight C and being called as a foreign function. If you do the same in Haskell via the Haskell C FFI it ends up being roughly the same as the C code ( not surprisingly ). Having written quite a bit of Cython, I refuse to touch it anymore given how wildly undefined it's behavior can be with intermingling Python and C semantics.

by nnq 13y ago

AndreasFrom 13y ago

As you acknowledge yourself, whether Haskell makes you think or not relies on what you're trained to read.

nnq 13y ago
Yes, you're right that Haskell is probably easier to read for someone with the mathematical background. But I'm referring to the cognitive overload incurred when you try to optimize it, thinking about list creation costs, then stream fusion to avoid it: most physicists or mathematicians will cringe at the thought of having to think about these "computer sciency optimization stuff". As opposed to this, a crude tool such as Cython or C or even Fortran allows one to just "skip thinking" about these and still have fast enough code. Haskell is great if you want to expand your CS knowledge, but not if your math/physics/engineering problem is already so complicated that it uses up all your available brain cycles and working memory and you just can't squeeze thinking about language-specific optimizations too. I guess this is why it's only used by companies like Galois and such that are already neck deep in advanced CS problems and used to thinking about them all the time.
- PaulAJ 13y ago
  There is a saying: first make it work, then make it work fast. The problem with doing the second in imperative languages is that you need to pull all your working code apart and rewrite it. Haskell separates the "make it work" from the "make it work fast".
- nightski 13y ago
  Except that no one actually thinks about that stuff when writing actual vector code. Trust me, I have written several real time 3D reconstruction algorithms (such as SLAM) in Haskell and was not thinking about stream fusion at all.
- Dewie 13y ago
  > Yes, you're right that Haskell is probably easier to read for someone with the mathematical background. I am quite taken by Haskell, and I have the whopping mathematical background of two introductory courses from my institute of mathematics. > But I'm referring to the cognitive overload incurred when you try to optimize it, thinking about list creation costs, then stream fusion to avoid i The author didn't need to know what stream fusion was; all they did was import a library... it might as well have been called import MagicallyOptimizingPrelude and it would have the same effect.
- chongli 13y ago
  But I'm referring to the cognitive overload incurred when you try to optimize it, thinking about list creation costs, then stream fusion to avoid it That's not true. This article is about a library that works as a drop-in replacement of the default list processing functions in the Prelude. Eventually, it may be possible that these functions will be put into the Prelude itself. This would allow naive users to get all the performance gains from stream fusion without ever knowing it's happening. All of the "cognitive overload" is taken care of by the researchers who developed this technique and the library authors who implement it.

tel 13y ago

This article was less a practical look into how to write fast Haskell code and more a peel-back-the-curtain look. Practically, you'd just use the vector lib [0] which has massive amounts of stream fusion built into it and exposes only very simple immutable and mutable APIs. [0] http://hackage.haskell.org/package/vector http://hackage.haskell.org/package/vector

curiouslearn 13y ago

I agree. I think the Cython version is eminently readable.

freyrs3 13y ago

I take issue with this benchmark since comparing it to Haskell is not illuminating since the Cython cdef function is straight C and being called as a foreign function. If you do the same in Haskell via the Haskell C FFI it ends up being roughly the same as the C code ( not surprisingly ). Having written quite a bit of Cython, I refuse to touch it anymore given how wildly undefined it's behavior can be with intermingling Python and C semantics.