3 ms·

>> Then, the more abstract model of functional programming allows the implementation more freedom when distributing work on the many cores/GPUs, and can make us

by anamax 15y ago

>> Then, the more abstract model of functional programming allows the implementation more freedom when distributing work on the many cores/GPUs, and can make use of this new architecture > It would be great to have some form of programming that maps to parallel architectures without headaches and bug-prone extra work. One of the advantages of age is that you can remember instead of predict. There are three problems - finding enough work that can be done in parallel, controlling the amount of parallel work that you find (yes, you can find too much), and managing the overhead. Functional languages help superficially with the first but the latter two are important as well. One reason why I write "superficially" is that writing in a functional language isn't enough - you have to write programs with the correct dependencies as well. Functional languages merely make it easier for the compiler/run-time to identify the dependencies in the program, which is a very different thing.

Peaker 15y ago
Functional programs encode their dependencies as arguments/return-values. In Haskell, using the par combinator is guaranteed to only affect performance, and not the actual result of the program. This is already a huge boost.
- anamax 15y ago
  > This is already a huge boost. Like I said, I've been to this rodeo before. Heck, I even drank the Kool-aid one of the previous times that functional languages were going to enable parallel execution. Since there's nothing new this time, I think that it's safe to say that the result will be the same. Easy to find and nicely separable dependencies may be necessary, but they aren't anywhere close to sufficient. (BTW - the relevant criteria is not "huge boost" but significant boost, and I don't mean distiguishable from random chance.)
  - Peaker 15y ago
    What functional languages did you see before? Were they pure? Could they guarantee that parallelism did not affect the semantics of their programs like Haskell can? Did you actually see the use of the "par" combinator?
    - anamax 15y ago
      > What functional languages did you see before? If you're going to argue novelty, shouldn't you be the one describing past work? > Were they pure? Could they guarantee that parallelism did not affect the semantics of their programs like Haskell can? Yes. Why is this surprising to you? > Did you actually see the use of the "par" combinator? Do you really think that "do something before it is strictly needed in a lazy language" is new? In other news, your generation didn't invent/discover any sex acts. (Neither did mine.)
      - Peaker 15y ago
        It is surprising because pure functional languages have not been around for a long time, especially not ones with good optimizers. > Do you really think that "do something before it is strictly needed in a lazy language" is new? That's not what the "par" combinator does. "par" along with "pseq" is already used, today, to achieve parallelism in Haskell code, and it already is easier to parallelize than in other environments. Additionally, STM in Haskell is usable in practice, unlike other implementations of software transactional memory, and it also relates to purity (in this case, the ability to distinguish different types of impurity).

by anamax 15y ago

Peaker 15y ago

Functional programs encode their dependencies as arguments/return-values. In Haskell, using the par combinator is guaranteed to only affect performance, and not the actual result of the program. This is already a huge boost.

anamax 15y ago
> This is already a huge boost. Like I said, I've been to this rodeo before. Heck, I even drank the Kool-aid one of the previous times that functional languages were going to enable parallel execution. Since there's nothing new this time, I think that it's safe to say that the result will be the same. Easy to find and nicely separable dependencies may be necessary, but they aren't anywhere close to sufficient. (BTW - the relevant criteria is not "huge boost" but significant boost, and I don't mean distiguishable from random chance.)
- Peaker 15y ago
  What functional languages did you see before? Were they pure? Could they guarantee that parallelism did not affect the semantics of their programs like Haskell can? Did you actually see the use of the "par" combinator?
  - anamax 15y ago
    > What functional languages did you see before? If you're going to argue novelty, shouldn't you be the one describing past work? > Were they pure? Could they guarantee that parallelism did not affect the semantics of their programs like Haskell can? Yes. Why is this surprising to you? > Did you actually see the use of the "par" combinator? Do you really think that "do something before it is strictly needed in a lazy language" is new? In other news, your generation didn't invent/discover any sex acts. (Neither did mine.)
    - Peaker 15y ago
      It is surprising because pure functional languages have not been around for a long time, especially not ones with good optimizers. > Do you really think that "do something before it is strictly needed in a lazy language" is new? That's not what the "par" combinator does. "par" along with "pseq" is already used, today, to achieve parallelism in Haskell code, and it already is easier to parallelize than in other environments. Additionally, STM in Haskell is usable in practice, unlike other implementations of software transactional memory, and it also relates to purity (in this case, the ability to distinguish different types of impurity).