4 ms·

The claim that haskell thinks you need separate tools is silly. The fact that the language provides abstractions for parallel computation and for concurrency d

The claim that haskell thinks you need separate tools is silly. The fact that the language provides abstractions for parallel computation and for concurrency does not mean the language or its designers consider them unrelated problems requiring different tools. Haskell is a particularly bad example to support this sort of misleading claim, as the language supports both out of the box without using different tools, and the same page you quoted even says that (http://www.haskell.org/haskellwiki/Parallelism http://www.haskell.org/haskellwiki/Parallelism): >Concurrent threads (forkIO) will run in parallel The simple example being say a webserver. You use forkIO to spawn a green thread per connection. This gets you concurrency. Now if you want parallelism, you simply tell the haskell runtime to multiplex those green threads over more than one OS thread. You don't have to change your code at all. The whole argument and terrible gift analogy seems to rely on redefining parallelism to mean "making sequential code parallel". I think most people are in fact thinking of making concurrent code parallel when they talk about wanting parallelism, like the webserver example.

_yosefk 13y ago
From here: http://www.haskell.org/haskellwiki/Concurrency http://www.haskell.org/haskellwiki/Concurrency "This page contains notes and information about how to write concurrent programs in Haskell. If you're more interested in performance than non-determinism, learn about parallelism first." From here: http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/lang-parallel.html http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/lang-... "GHC implements some major extensions to Haskell to support concurrent and parallel programming. Let us first establish terminology: * Parallelism means running a Haskell program on multiple processors, with the goal of improving performance. Ideally, this should be done invisibly, and with no semantic changes. * Concurrency means implementing a program by using multiple I/O-performing threads. While a concurrent Haskell program can run on a parallel machine, the primary goal of using concurrency is not to gain performance, but rather because that is the simplest and most direct way to write the program. Since the threads perform I/O, the semantics of the program is necessarily non-deterministic. GHC supports both concurrency and parallelism." Finally, the part that I quoted in the article: "Rule of thumb: use Pure Parallelism if you can, Concurrency otherwise." How isn't this "providing different tools for the two and recommending to use them in different situations" I don't know.
- papsosouid 13y ago
  It is almost like you didn't read my post. They provide forkIO as a basic tool to do both. That is explicitly not different tools. They also provide additional abstractions to make different tasks easier. Tasks like parallelising sequential code, which you want to pretend is the only kind of parallelism that exists. Haskell provides different abstractions for lots of things, that doesn't mean those things require different tools. It means convenience matters. >If you're more interested in performance than non-determinism, learn about parallelism first." First, not instead of. >GHC implements some major extensions to Haskell to support concurrent and parallel programming Yep, that really sounds like they require different tools, the way the mention them together as a single topic. >GHC supports both concurrency and parallelism And does so with the same tool: forkIO. Completely contrary to your claim that haskell is evidence that it requires separate tools. This is once again made very clear on a page you link to: >Ordinary single-threaded Haskell programs will not benefit from enabling SMP parallelism alone: you must expose parallelism to the compiler. One way to do so is forking threads using Concurrent Haskell (Section 7.18.1, “Concurrent Haskell”), but the simplest mechanism for extracting parallelism from pure code is to use the par combinator They are literally saying "use a higher level abstraction instead of rolling your own directly with concurrency constructs". This is the same advice that is always given when a higher level abstraction is available. It directly contradicts the claim that parallelism requires a different tool. It explicitly states that you can do it with the same tool.
  - _yosefk 13y ago
    "It is almost like you didn't read my post." Seconded. "They provide forkIO as a basic tool to do both." Computers provide bits to do both and then some. You can call the ensuing distinctions "matters of convenience" and not "requiring different things", of course.
    - papsosouid 13y ago
      >You can call the ensuing distinctions "matters of convenience" and not "requiring different things", of course. Or you can read the code and see that it is quite literally an abstraction layer built on the same tool, not two different tools. That is like saying folds and recursion require different tools, and providing "haskell has both recursion and folds" as proof. Of course it does, but folds are simply an abstraction on top of recursion.

_yosefk 13y ago

From here: http://www.haskell.org/haskellwiki/Concurrency http://www.haskell.org/haskellwiki/Concurrency "This page contains notes and information about how to write concurrent programs in Haskell. If you're more interested in performance than non-determinism, learn about parallelism first." From here: http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/lang-parallel.html http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/lang-... "GHC implements some major extensions to Haskell to support concurrent and parallel programming. Let us first establish terminology: * Parallelism means running a Haskell program on multiple processors, with the goal of improving performance. Ideally, this should be done invisibly, and with no semantic changes. * Concurrency means implementing a program by using multiple I/O-performing threads. While a concurrent Haskell program can run on a parallel machine, the primary goal of using concurrency is not to gain performance, but rather because that is the simplest and most direct way to write the program. Since the threads perform I/O, the semantics of the program is necessarily non-deterministic. GHC supports both concurrency and parallelism." Finally, the part that I quoted in the article: "Rule of thumb: use Pure Parallelism if you can, Concurrency otherwise." How isn't this "providing different tools for the two and recommending to use them in different situations" I don't know.

papsosouid 13y ago
It is almost like you didn't read my post. They provide forkIO as a basic tool to do both. That is explicitly not different tools. They also provide additional abstractions to make different tasks easier. Tasks like parallelising sequential code, which you want to pretend is the only kind of parallelism that exists. Haskell provides different abstractions for lots of things, that doesn't mean those things require different tools. It means convenience matters. >If you're more interested in performance than non-determinism, learn about parallelism first." First, not instead of. >GHC implements some major extensions to Haskell to support concurrent and parallel programming Yep, that really sounds like they require different tools, the way the mention them together as a single topic. >GHC supports both concurrency and parallelism And does so with the same tool: forkIO. Completely contrary to your claim that haskell is evidence that it requires separate tools. This is once again made very clear on a page you link to: >Ordinary single-threaded Haskell programs will not benefit from enabling SMP parallelism alone: you must expose parallelism to the compiler. One way to do so is forking threads using Concurrent Haskell (Section 7.18.1, “Concurrent Haskell”), but the simplest mechanism for extracting parallelism from pure code is to use the par combinator They are literally saying "use a higher level abstraction instead of rolling your own directly with concurrency constructs". This is the same advice that is always given when a higher level abstraction is available. It directly contradicts the claim that parallelism requires a different tool. It explicitly states that you can do it with the same tool.
- _yosefk 13y ago
  "It is almost like you didn't read my post." Seconded. "They provide forkIO as a basic tool to do both." Computers provide bits to do both and then some. You can call the ensuing distinctions "matters of convenience" and not "requiring different things", of course.
  - papsosouid 13y ago
    >You can call the ensuing distinctions "matters of convenience" and not "requiring different things", of course. Or you can read the code and see that it is quite literally an abstraction layer built on the same tool, not two different tools. That is like saying folds and recursion require different tools, and providing "haskell has both recursion and folds" as proof. Of course it does, but folds are simply an abstraction on top of recursion.