4 ms·

I find it really interesting that the idiomatic Haskell implementations (basically math) are the best-performing, while the Rust-like Haskell implementation (us

by runeks 9y ago

I find it really interesting that the idiomatic Haskell implementations (basically math) are the best-performing, while the Rust-like Haskell implementation (using an IORef) is orders of magnitude slower. This is exactly what I want: describe the logic of the operation, and leave the compiler to optimize for the hardware (in this case a CPU which mutates registers). The Rust implementation makes assumptions about the underlying hardware (has registers we can mutate), and is only about 15% faster than the Haskell implementation which makes no such assumptions. In essence, this is why I love Haskell, and choose it over Rust: it allows me to write my application logic directly, without having to think about it in terms of mutation, and have the generated code be pretty fast. If GHC becomes well-optimized enough it can render Rust obsolete, since "no runtime overhead" becomes pretty meaningless if it's actually slower than Haskell (e.g. using LinearTypes, which removes need for GC). Rust can't render Haskell obsolete, however, since Haskell's goal is basically allowing you to write logic directly, using types as propositions and values as proofs. So Haskell's goal is a qualitative one (execute logic) while Rust's is a quantitative one (performance/no runtime overhead), which results in Haskell being able to take the place of Rust if GHC gains sufficiently in performance.

pjmlp 9y ago
Not having issues with using a GC language is also a huge win. I can grasp Haskell without major issues, follow C++14 and C++17 meta-programming tricks, yet I still don't understand quite well how to deal with the borrow checker on Rust. Still haven't given up on it, but it shows the learning curve is a bit high, or then it is me that cannot wrap my head around it.
- runeks 9y ago
  I'm not that familiar with Rust but, as far as I can see, it makes sense to say that Rust's borrow checker is an interface to a O(1) garbage collector (as fast as no GC at all), that the programmer has to implement at compile-time for all values. All the borrow checker-code is compiled into a no-runtime-overhead garbage collector, that is embedded into the resulting generated code. In the world of Haskell, the -> arrow embeds a GC (with runtime overhead) into the genrated code. A similar interface to Rust's borrow checker in Haskell (no runtime overhead) would be the ⊸ arrow from LinearTypes (in a future where GHC's GC is able to take advantage of this). It looks, to me, like the arrow (⊸) notation is a lot simpler inteface to a no-runtime-overhead garbage collector -- or the absense of a traditional GC, in other words -- than Rust's borrow checker. But I'm looking forward to seeing how it plays out (it will probably take years before it becomes reality).
  - littlestymaar 9y ago
    > I'm not that familiar with Rust but, as far as I can see, it makes sense to say that Rust's borrow checker is an interface to a O(1) garbage collector (as fast as no GC at all), that the programmer has to implement at compile-time for all values. All the borrow checker-code is compiled into a no-runtime-overhead garbage collector, that is embedded into the resulting generated code. Not really : the borrow checker is just a compile-time analysis tool which checks that you respect some conventions with pointers : - each value has only one owner - each pointer to a value must leave less time than the target value - you must only have one mutable pointer to a value - you can have as many immutable pointer to a value as you want as long as there is no mutable pointer to the same value (think of a statically-checked version of a RW-lock) The borrow-checker isn't responsible for freeing memory at all. Freeing memory is done by RAII like in C++, but the conventions enforced by the borrow checker ensure that the deallocation of memory is safe.
    - pjmlp 9y ago
      The problem I was hinting is that it looks simple on paper and when following the book exercises, but then one picks up a random GUI library, needs to map callbacks and event handlers, it starts to get a bit harder to understand if one needs a lifetime annotation (which one), (A)Rc, RefCell, and starts to jungle them around until it compiles. Again, maybe it is just me and need to spend more time learning it.
      - kirillkh 9y ago
        You're right, that's the difficult part about Rust. Every novice has to go through these hoops to acquire the intuition. I'm midway through and feel comfortable working with Rusty libraries, but interfacing with C libraries that widely employ shared state is a major pain. Fortunately, more and more libraries get rewritten in Rust or acquire sane Rust wrappers.
      - littlestymaar 9y ago
        > Again, maybe it is just me and need to spend more time learning it. I had the exact same experience : after my first reading of the Rust book, I though I understood what's going on but once I tried to actually write something I was totally lost. I stopped using Rust for several months and when I came back, I read the book again and this time I had no troubles writing stuff and the concepts of ownership and lifetime became really clear. I think the concepts behind the borrow-checker are really straightforward[] once you've internalized them, yet they are really unintuitive to the beginner. It's quite paradoxical. [] except when the borrowck is not yet smart enough : http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-lexical-lifetimes-introduction/ http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-...
- jmcomets 9y ago
  Don't hesitate to check out #rust / #rust-beginners on irc.mozilla.org, I was struggling with BCK for quite a while and asking dumb questions to experienced rustaceans has been very helpful. I've now been using rust for 2 years and am very happy with it.
  - pjmlp 9y ago
    The guys on the forums were very nice, my kudos and appreciation to them. Rust will never be more than an occasional coding exercise for me personally, because doesn't fit the type of work I do (Java/.NET/UWP/Web/Android) where project tooling is dictated by customer IT. However coding exercises in whatever language X helps to open our mind to new ways of solving problems, that we can eventually use in our daily tools. When I give these statements my goal isn't to bash the language, rather give another point of view that might help understanding which areas the design team should focus, or not. After all it is their final call and they need to pay attention to those that are actually using it in production and their real problems, not random dudes like me.
jeffdavis 9y ago
Are you saying there's a way to use haskell without the GC or other runtime overhead? I like rust because it doesn't have much in the way of runtime requirements (almost zero, like C).
- runeks 9y ago
  > Are you saying there's a way to use haskell without the GC or other runtime overhead? There isn't yet, but there will be when, first, the LinearTypes extension arrives (scheduled for GHC 8.4) and, secondly, GHC's garbage collector is modified to take of advantage of the fact that linear types are always consumed exactly once. This will take 1-2 years or so. After this it should be possible to write no-runtime-overhead Haskell functions by using the "lollipop" arrow after an argument, and then consuming that argument exactly once in your function. So you will have to split your functions into small enough functions, that consume their arguments exactly once, and then compose them into something that will not need a garbage collector at runtime. In theory you could write an entire application this way, although in practice you probably wouldn't bother avoiding the GC for the outermost constructions of your program, since this would offer little in performance gains and be a lot more difficult (remember, a no-GC function must consume its arguments exactly once). But time will tell how this will compare to something like Rust's borrow checker.
- evincarofautumn 9y ago
  There’s been some work lately by Tweag I/O on a linear types extension to GHC.[1][2] It would allow us to safely allocate things from malloc memory or a “linear heap” separate from the main GC heap, and that should reduce pause times by reducing GC pressure, but I don’t think we’ll ever be able to avoid the GC entirely. However, we can still expect some nice performance advantages from the fact that linear types can enforce guarantees about inlining & fusion (which are currently somewhat unpredictable) as well as resource lifetimes. [1]: https://github.com/tweag/linear-types https://github.com/tweag/linear-types [2]: https://github.com/tweag/ghc/tree/linear-types https://github.com/tweag/ghc/tree/linear-types
infinity0 9y ago
I can certainly see it's plausible Haskell can beat Rust in the mid-term future on high-level programming away from the bare metal. Less certain that it can beat Rust for system-level programming or low-level library programming, where people using the library don't want to link to a heavy runtime that includes a GC.
adwn 9y ago
> If GHC becomes well-optimized enough it can render Rust obsolete [...] Ah yes, the mythical Sufficiently Smart Compiler (TM), scheduled to arrive any day now. Will it also be able to reliably transform non-trivial functions that are accidentally O(n) in memory consumption due Haskell's laziness, to O(1) versions? The keyword here is reliably. There are many clever but brittle compiler optimizations that aren't used much in the field, because when performance is crucial, you can't rely on the compiler to detect this transformation opportunity in some cases and not in some other cases, so you code it explicitly.
- rtpg 9y ago
  I understand this frustration, but my understanding is that patterns exist to _ensure_ transformations go through exist in Haskell land. Im thinking about stream fusion for example. Lots of "pipe-y" libraries exist to make sure your program consumes input in a streamed manner. So while your O(n) code might sometimes unreliably be turned into O(1), if performance is your game you can use these kind of libraries to endure O(1).
- chongli 9y ago
  reliably transform non-trivial functions that are accidentally O(n) in memory consumption due Haskell's laziness, to O(1) versions? What you're describing is called strictness analysis. [0] I believe that attempting to solve it in general runs up against the halting problem. That being said, GHC does perform some strictness analysis when optimization flags are turned on. [1] The language itself also includes strictness annotations on the fields of data constructors. [2] Experienced Haskell programmers know how to use these to avoid allocating unnecessary thunks. [0] https://en.wikipedia.org/wiki/Strictness_analysis https://en.wikipedia.org/wiki/Strictness_analysis [1] https://wiki.haskell.org/Performance/Strictness#Strictness_analysis https://wiki.haskell.org/Performance/Strictness#Strictness_a... [2] https://wiki.haskell.org/Performance/Data_types#Strict_fields https://wiki.haskell.org/Performance/Data_types#Strict_field...
- lmm 9y ago
  Will Haskell's compiler ever be 100% reliable? Maybe. Will Haskell's compiler ever be more reliable than the average developer? IME it's already there, and has been for a while: for a given functional requirement and a given level of performance, the cheapest way to achieve it is usually Haskell or similar.

by runeks 9y ago

pjmlp 9y ago

Not having issues with using a GC language is also a huge win. I can grasp Haskell without major issues, follow C++14 and C++17 meta-programming tricks, yet I still don't understand quite well how to deal with the borrow checker on Rust. Still haven't given up on it, but it shows the learning curve is a bit high, or then it is me that cannot wrap my head around it.

runeks 9y ago
I'm not that familiar with Rust but, as far as I can see, it makes sense to say that Rust's borrow checker is an interface to a O(1) garbage collector (as fast as no GC at all), that the programmer has to implement at compile-time for all values. All the borrow checker-code is compiled into a no-runtime-overhead garbage collector, that is embedded into the resulting generated code. In the world of Haskell, the -> arrow embeds a GC (with runtime overhead) into the genrated code. A similar interface to Rust's borrow checker in Haskell (no runtime overhead) would be the ⊸ arrow from LinearTypes (in a future where GHC's GC is able to take advantage of this). It looks, to me, like the arrow (⊸) notation is a lot simpler inteface to a no-runtime-overhead garbage collector -- or the absense of a traditional GC, in other words -- than Rust's borrow checker. But I'm looking forward to seeing how it plays out (it will probably take years before it becomes reality).
- littlestymaar 9y ago
  > I'm not that familiar with Rust but, as far as I can see, it makes sense to say that Rust's borrow checker is an interface to a O(1) garbage collector (as fast as no GC at all), that the programmer has to implement at compile-time for all values. All the borrow checker-code is compiled into a no-runtime-overhead garbage collector, that is embedded into the resulting generated code. Not really : the borrow checker is just a compile-time analysis tool which checks that you respect some conventions with pointers : - each value has only one owner - each pointer to a value must leave less time than the target value - you must only have one mutable pointer to a value - you can have as many immutable pointer to a value as you want as long as there is no mutable pointer to the same value (think of a statically-checked version of a RW-lock) The borrow-checker isn't responsible for freeing memory at all. Freeing memory is done by RAII like in C++, but the conventions enforced by the borrow checker ensure that the deallocation of memory is safe.
  - pjmlp 9y ago
    The problem I was hinting is that it looks simple on paper and when following the book exercises, but then one picks up a random GUI library, needs to map callbacks and event handlers, it starts to get a bit harder to understand if one needs a lifetime annotation (which one), (A)Rc, RefCell, and starts to jungle them around until it compiles. Again, maybe it is just me and need to spend more time learning it.
    - kirillkh 9y ago
      You're right, that's the difficult part about Rust. Every novice has to go through these hoops to acquire the intuition. I'm midway through and feel comfortable working with Rusty libraries, but interfacing with C libraries that widely employ shared state is a major pain. Fortunately, more and more libraries get rewritten in Rust or acquire sane Rust wrappers.
    - littlestymaar 9y ago
      > Again, maybe it is just me and need to spend more time learning it. I had the exact same experience : after my first reading of the Rust book, I though I understood what's going on but once I tried to actually write something I was totally lost. I stopped using Rust for several months and when I came back, I read the book again and this time I had no troubles writing stuff and the concepts of ownership and lifetime became really clear. I think the concepts behind the borrow-checker are really straightforward[] once you've internalized them, yet they are really unintuitive to the beginner. It's quite paradoxical. [] except when the borrowck is not yet smart enough : http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-lexical-lifetimes-introduction/ http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-...
jmcomets 9y ago
Don't hesitate to check out #rust / #rust-beginners on irc.mozilla.org, I was struggling with BCK for quite a while and asking dumb questions to experienced rustaceans has been very helpful. I've now been using rust for 2 years and am very happy with it.
- pjmlp 9y ago
  The guys on the forums were very nice, my kudos and appreciation to them. Rust will never be more than an occasional coding exercise for me personally, because doesn't fit the type of work I do (Java/.NET/UWP/Web/Android) where project tooling is dictated by customer IT. However coding exercises in whatever language X helps to open our mind to new ways of solving problems, that we can eventually use in our daily tools. When I give these statements my goal isn't to bash the language, rather give another point of view that might help understanding which areas the design team should focus, or not. After all it is their final call and they need to pay attention to those that are actually using it in production and their real problems, not random dudes like me.

jeffdavis 9y ago

Are you saying there's a way to use haskell without the GC or other runtime overhead? I like rust because it doesn't have much in the way of runtime requirements (almost zero, like C).

runeks 9y ago
> Are you saying there's a way to use haskell without the GC or other runtime overhead? There isn't yet, but there will be when, first, the LinearTypes extension arrives (scheduled for GHC 8.4) and, secondly, GHC's garbage collector is modified to take of advantage of the fact that linear types are always consumed exactly once. This will take 1-2 years or so. After this it should be possible to write no-runtime-overhead Haskell functions by using the "lollipop" arrow after an argument, and then consuming that argument exactly once in your function. So you will have to split your functions into small enough functions, that consume their arguments exactly once, and then compose them into something that will not need a garbage collector at runtime. In theory you could write an entire application this way, although in practice you probably wouldn't bother avoiding the GC for the outermost constructions of your program, since this would offer little in performance gains and be a lot more difficult (remember, a no-GC function must consume its arguments exactly once). But time will tell how this will compare to something like Rust's borrow checker.
evincarofautumn 9y ago
There’s been some work lately by Tweag I/O on a linear types extension to GHC.[1][2] It would allow us to safely allocate things from malloc memory or a “linear heap” separate from the main GC heap, and that should reduce pause times by reducing GC pressure, but I don’t think we’ll ever be able to avoid the GC entirely. However, we can still expect some nice performance advantages from the fact that linear types can enforce guarantees about inlining & fusion (which are currently somewhat unpredictable) as well as resource lifetimes. [1]: https://github.com/tweag/linear-types https://github.com/tweag/linear-types [2]: https://github.com/tweag/ghc/tree/linear-types https://github.com/tweag/ghc/tree/linear-types

infinity0 9y ago

I can certainly see it's plausible Haskell can beat Rust in the mid-term future on high-level programming away from the bare metal. Less certain that it can beat Rust for system-level programming or low-level library programming, where people using the library don't want to link to a heavy runtime that includes a GC.

adwn 9y ago

> If GHC becomes well-optimized enough it can render Rust obsolete [...] Ah yes, the mythical Sufficiently Smart Compiler (TM), scheduled to arrive any day now. Will it also be able to reliably transform non-trivial functions that are accidentally O(n) in memory consumption due Haskell's laziness, to O(1) versions? The keyword here is reliably. There are many clever but brittle compiler optimizations that aren't used much in the field, because when performance is crucial, you can't rely on the compiler to detect this transformation opportunity in some cases and not in some other cases, so you code it explicitly.

rtpg 9y ago
I understand this frustration, but my understanding is that patterns exist to _ensure_ transformations go through exist in Haskell land. Im thinking about stream fusion for example. Lots of "pipe-y" libraries exist to make sure your program consumes input in a streamed manner. So while your O(n) code might sometimes unreliably be turned into O(1), if performance is your game you can use these kind of libraries to endure O(1).
chongli 9y ago
reliably transform non-trivial functions that are accidentally O(n) in memory consumption due Haskell's laziness, to O(1) versions? What you're describing is called strictness analysis. [0] I believe that attempting to solve it in general runs up against the halting problem. That being said, GHC does perform some strictness analysis when optimization flags are turned on. [1] The language itself also includes strictness annotations on the fields of data constructors. [2] Experienced Haskell programmers know how to use these to avoid allocating unnecessary thunks. [0] https://en.wikipedia.org/wiki/Strictness_analysis https://en.wikipedia.org/wiki/Strictness_analysis [1] https://wiki.haskell.org/Performance/Strictness#Strictness_analysis https://wiki.haskell.org/Performance/Strictness#Strictness_a... [2] https://wiki.haskell.org/Performance/Data_types#Strict_fields https://wiki.haskell.org/Performance/Data_types#Strict_field...
lmm 9y ago
Will Haskell's compiler ever be 100% reliable? Maybe. Will Haskell's compiler ever be more reliable than the average developer? IME it's already there, and has been for a while: for a given functional requirement and a given level of performance, the cheapest way to achieve it is usually Haskell or similar.