4 ms·

> To this day it has the best implementation of parallelism; one can achieve a 7x speedup on 8 cores by adding a handful of lines to a program. Eh, you can ach

by adwn 6y ago

> To this day it has the best implementation of parallelism; one can achieve a 7x speedup on 8 cores by adding a handful of lines to a program. Eh, you can achieve the same in Rust using rayon, this isn't exclusive to Haskell or FP. Do you have an example in Haskell, where you get an effortless speedup which wouldn't be easy in another language?

jgilias 6y ago
Yeah, but Rust isn't exactly a counter example, I think. It's heavily inspired by Haskell, its type system, as well as FP in general. So, it sort of inherits (pun not intended) its parallelization capabilities from that.
- darksaints 6y ago
  Heavily? It's actually heavily inspired by ML (SML/OCaml), not Haskell. Most of its functional programming attributes originated in SML, and has avoided most of the things that make Haskell unique. Really it is just type classes that came from Haskell.
  - pjmlp 6y ago
    Type classes are just a way of doing module interfaces or Objective-C protocols/categories, as prior art before Haskell or Miranda came into being.
  - centimeter 6y ago
    I was around in the very early days of rust, and it was explicitly stated in many places in the docs that the trait system, ADTs, etc. were all inspired by Haskell experience. I don't think we ever mentioned OCaml or SML. The trait system in Rust has nothing whatsoever to do with SML or OCaml and everything to do with Haskell's typeclass system. So between that and ADTs, on what grounds do you think it was "heavily inspired by ML"?
    - jgilias 6y ago
      After reading some of these comments I went around searching for info and found that in the Rust book it does feature SML and OCaml prominently as influences[0]. However, the things mentioned: algebraic data types, type inference, pattern matching could also easily be seen as influences from Haskell or FP languages in general. At the end of the day though, it's not like this matters. I'm just happy that such flow of ideas happens, irrespective of where exactly each particular concept comes from. [0] https://doc.rust-lang.org/reference/influences.html https://doc.rust-lang.org/reference/influences.html
    - sideeffffect 6y ago
      > I don't think we ever mentioned OCaml How could you have not mentioned OCaml? The original Rust compiler was implemented in it. By this, Rust has a very clear (OCa)ML heritage. It's meaningless to argue, whether Rust got ADTs from Haskell or OCaml, because the author (Graydon Hoare) had been clearly familiar with both and both got ADTs from ML, which is much older than either of them. On the other hand, traits are a different story, those just Type classes with a different name, and that is a Haskell thing.
    - darksaints 6y ago
      I too was around in the very early days ...at least early enough that there wasn't a rust "team", but rather just Graydon. And to wit the only mentions I read about Haskell as an influence were a) the trait system, and b) to criticize and explicitly refute the Haskell approach to a given problem. There was a reason Graydon wrote the compiler on OCaml and not Haskell. He was very critical of a lot of the ideas that Haskell brought. In particular, he hated how Haskell took mutability from "not the default" to "practically impossible". He hated the effect system and how overly intrusive it was (although he was open to the idea of a fine grained effect system that was not tied to some all powerful Monad typeclass). He hated lazy evaluation. He hated the syntax...even the convention toward snake-case vs camel-case is an homage to OCaml. He didn't even care much for typeclasses, preferring the more strict encapsulation of modules, and only bringing them in after a lot of contributors pushed for them. Basically, apart from typeclasses (which werent really unique to Haskell, as they had been known as interfaces within OOP for a few years), Graydon viewed Haskell quite a bit like an old atheistic refrain about religion: that which is good about it is not unique, and that which is unique about it is not good. BTW, Rust's ADTs as well as Haskell's ADT's came from ML. They've been around since 1973, 13 year before Miranda, and 17 years before Haskell's first release. You don't get to claim that Rust got it's ADTs from Haskell any more than you get to say that Java got it's Optionals from Scala. EDIT: see this comment from Graydon himself, made about a year ago on the rust subreddit: > That said: back then Rust was much more OCaml-y. We did not start with traits / typeclasses; we started with modules (for a while: first-class, though quite badly broken due to my lack of knowhow). I was and am unapologetically more of an OCaml fan than a Haskell fan. This opinion is not made from a lack of information about either, and I am not especially interested in having a Haskell-vs-OCaml argument here. I don't even think of them as being especially different languages from a family-lineage perspective. But insofar as I think eager is a better default evaluation strategy than lazy, and modules are a better abstraction mechanism than typeclasses, I am more in the OCaml camp. Other folks later in Rust's development argued for (and eventually won) the typeclasses / traits thing, against my earlier preferences.
- platinumrad 6y ago
  What? No. Rust has some influence from Haskell in terms of traits and such, but Rust's parallelization capabilities comes from its tracking of mutability. (No, Haskell did not invent caring about mutability.) Also, succinct expression of parallel algorithms isn't a particularly unique feature. Like half of the named algorithms in the C++ standard library can be parallelized by adding a single parameter.
  - jolux 6y ago
    That’s because the parallelization in the STL is encapsulated. In Haskell and Rust it’s explicit, it’s not just about adding a parameter to an existing function, it’s a general mechanism.
    - platinumrad 6y ago
      Rayon literally works on iterators just like the C++ algorithm library.
      - jolux 6y ago
        Well in that case neither of them is really comparable to what Haskell can do here. But Rust’s capabilities go far beyond Rayon as I’m sure you know.
jeffreygoesto 6y ago
Isn't the speedup a direct result of immutable data more than a specific language?
WJW 6y ago
From the article at https://medium.com/@s.nawaz/optimizing-ray-tracing-in-haskell-3dc412fff20a https://medium.com/@s.nawaz/optimizing-ray-tracing-in-haskel...: > let colors = fmap computeColor coordinates to > let colors = fmap computeColor coordinates `using` parListChunk 32 rseq So half a line added to parallelize the mapping a pure computation including using a sensible threadpool implementation. How impressive you find this depends on how you define "easy in another language". Rayon comes pretty close but you can encode some properties about your computation in the Haskell type system that Rust does not yet support and so the safety of some computations can be statically proven in Haskell but not in Rust.
- CJefferson 6y ago
  I think this reasoning goes the other way (as I understand), Rust can express threadsafe mutability, as you can only have one mutable reference to any object, so if I can mutate, I know I have the only reference.
- twic 6y ago
  Meh. var colours = coordinates.stream().map(this::computeColour).collect(toList()); var colours = coordinates.stream().parallel().map(this::computeColour).collect(toList()); Java doesn't do as much (well, anything) to help you make sure the implementation of computeColour is suitable for parallelisation, but that comes with the territory. On the other hand, it will automatically split the stream up appropriately for the number of cores you have.
  - przemo_li 6y ago
    You have just started that Java isn't as good but since it isn't, it shouldn't be judged so hardly and thus concluded that Java is as good as any (when using softer requirements just for Java) I also think that explicit threadpool isn't the same thing as implicit one. But that's very minor issue here easily solvable by different api for parallel method
    - AnimalMuppet 6y ago

by adwn 6y ago

jgilias 6y ago

Yeah, but Rust isn't exactly a counter example, I think. It's heavily inspired by Haskell, its type system, as well as FP in general. So, it sort of inherits (pun not intended) its parallelization capabilities from that.

darksaints 6y ago
Heavily? It's actually heavily inspired by ML (SML/OCaml), not Haskell. Most of its functional programming attributes originated in SML, and has avoided most of the things that make Haskell unique. Really it is just type classes that came from Haskell.
- pjmlp 6y ago
  Type classes are just a way of doing module interfaces or Objective-C protocols/categories, as prior art before Haskell or Miranda came into being.
- centimeter 6y ago
  I was around in the very early days of rust, and it was explicitly stated in many places in the docs that the trait system, ADTs, etc. were all inspired by Haskell experience. I don't think we ever mentioned OCaml or SML. The trait system in Rust has nothing whatsoever to do with SML or OCaml and everything to do with Haskell's typeclass system. So between that and ADTs, on what grounds do you think it was "heavily inspired by ML"?
  - jgilias 6y ago
    After reading some of these comments I went around searching for info and found that in the Rust book it does feature SML and OCaml prominently as influences[0]. However, the things mentioned: algebraic data types, type inference, pattern matching could also easily be seen as influences from Haskell or FP languages in general. At the end of the day though, it's not like this matters. I'm just happy that such flow of ideas happens, irrespective of where exactly each particular concept comes from. [0] https://doc.rust-lang.org/reference/influences.html https://doc.rust-lang.org/reference/influences.html
  - sideeffffect 6y ago
    > I don't think we ever mentioned OCaml How could you have not mentioned OCaml? The original Rust compiler was implemented in it. By this, Rust has a very clear (OCa)ML heritage. It's meaningless to argue, whether Rust got ADTs from Haskell or OCaml, because the author (Graydon Hoare) had been clearly familiar with both and both got ADTs from ML, which is much older than either of them. On the other hand, traits are a different story, those just Type classes with a different name, and that is a Haskell thing.
  - darksaints 6y ago
    I too was around in the very early days ...at least early enough that there wasn't a rust "team", but rather just Graydon. And to wit the only mentions I read about Haskell as an influence were a) the trait system, and b) to criticize and explicitly refute the Haskell approach to a given problem. There was a reason Graydon wrote the compiler on OCaml and not Haskell. He was very critical of a lot of the ideas that Haskell brought. In particular, he hated how Haskell took mutability from "not the default" to "practically impossible". He hated the effect system and how overly intrusive it was (although he was open to the idea of a fine grained effect system that was not tied to some all powerful Monad typeclass). He hated lazy evaluation. He hated the syntax...even the convention toward snake-case vs camel-case is an homage to OCaml. He didn't even care much for typeclasses, preferring the more strict encapsulation of modules, and only bringing them in after a lot of contributors pushed for them. Basically, apart from typeclasses (which werent really unique to Haskell, as they had been known as interfaces within OOP for a few years), Graydon viewed Haskell quite a bit like an old atheistic refrain about religion: that which is good about it is not unique, and that which is unique about it is not good. BTW, Rust's ADTs as well as Haskell's ADT's came from ML. They've been around since 1973, 13 year before Miranda, and 17 years before Haskell's first release. You don't get to claim that Rust got it's ADTs from Haskell any more than you get to say that Java got it's Optionals from Scala. EDIT: see this comment from Graydon himself, made about a year ago on the rust subreddit: > That said: back then Rust was much more OCaml-y. We did not start with traits / typeclasses; we started with modules (for a while: first-class, though quite badly broken due to my lack of knowhow). I was and am unapologetically more of an OCaml fan than a Haskell fan. This opinion is not made from a lack of information about either, and I am not especially interested in having a Haskell-vs-OCaml argument here. I don't even think of them as being especially different languages from a family-lineage perspective. But insofar as I think eager is a better default evaluation strategy than lazy, and modules are a better abstraction mechanism than typeclasses, I am more in the OCaml camp. Other folks later in Rust's development argued for (and eventually won) the typeclasses / traits thing, against my earlier preferences.
platinumrad 6y ago
What? No. Rust has some influence from Haskell in terms of traits and such, but Rust's parallelization capabilities comes from its tracking of mutability. (No, Haskell did not invent caring about mutability.) Also, succinct expression of parallel algorithms isn't a particularly unique feature. Like half of the named algorithms in the C++ standard library can be parallelized by adding a single parameter.
- jolux 6y ago
  That’s because the parallelization in the STL is encapsulated. In Haskell and Rust it’s explicit, it’s not just about adding a parameter to an existing function, it’s a general mechanism.
  - platinumrad 6y ago
    Rayon literally works on iterators just like the C++ algorithm library.
    - jolux 6y ago
      Well in that case neither of them is really comparable to what Haskell can do here. But Rust’s capabilities go far beyond Rayon as I’m sure you know.

jeffreygoesto 6y ago

Isn't the speedup a direct result of immutable data more than a specific language?

WJW 6y ago

From the article at https://medium.com/@s.nawaz/optimizing-ray-tracing-in-haskell-3dc412fff20a https://medium.com/@s.nawaz/optimizing-ray-tracing-in-haskel...: > let colors = fmap computeColor coordinates to > let colors = fmap computeColor coordinates `using` parListChunk 32 rseq So half a line added to parallelize the mapping a pure computation including using a sensible threadpool implementation. How impressive you find this depends on how you define "easy in another language". Rayon comes pretty close but you can encode some properties about your computation in the Haskell type system that Rust does not yet support and so the safety of some computations can be statically proven in Haskell but not in Rust.

CJefferson 6y ago
I think this reasoning goes the other way (as I understand), Rust can express threadsafe mutability, as you can only have one mutable reference to any object, so if I can mutate, I know I have the only reference.
twic 6y ago
Meh. var colours = coordinates.stream().map(this::computeColour).collect(toList()); var colours = coordinates.stream().parallel().map(this::computeColour).collect(toList()); Java doesn't do as much (well, anything) to help you make sure the implementation of computeColour is suitable for parallelisation, but that comes with the territory. On the other hand, it will automatically split the stream up appropriately for the number of cores you have.
- przemo_li 6y ago
  You have just started that Java isn't as good but since it isn't, it shouldn't be judged so hardly and thus concluded that Java is as good as any (when using softer requirements just for Java) I also think that explicit threadpool isn't the same thing as implicit one. But that's very minor issue here easily solvable by different api for parallel method
  - AnimalMuppet 6y ago