4 ms·

I'm not convinced that parallelism is something that needs support at the language level. The only languages that do this are Go and Erlang (off the top of my

by j_baker 16y ago

I'm not convinced that parallelism is something that needs support at the language level. The only languages that do this are Go and Erlang (off the top of my head). Others like Clojure and Scala have more support at the standard library level.

X9 16y ago
It might not need language level support, but anything to make it easier to leverage is a plus in my book. If the programmer doesn't have to concern themselves with extra parallelism-specific library calls and is still able to write a binary that can take advantage of multiple cores, that seems like a good idea to me.
swannodette 16y ago
? Clojure has deep language support for concurrency - from syntactical constructs to it's core performant immutable data structures.
- lukev 16y ago
  But the beauty is that because it's a Lisp, it's all implemented in terms of macros - Clojure's complete set of concurrency tools could be written as a library. The only exception is the deref reader macro "@", since Clojure doesn't allow user-defined reader macros by default.
  - kanak 16y ago
    > it's all implemented in terms of macros This is not true at present. The core data structures, and the STM machinery are implemented in java, not as macros.
- plinkplonk 16y ago
  He probably meant "distributed". Erlang has a better "distributed" story than Clojure.
jerf 16y ago
Erlang gets a lot of good mileage out of it, though. You start to really miss the OTP system when you try to write actually-important code in any other language. And there are some aspects that are hard to get right at a later time when it's not in the language from day one, cross-process messaging in particular, which is a primitive used to build a lot of other features. I do not know where Clojure or Scala have a generic cross-process messaging ability, and I'm not saying it's impossible by any means, but it's much easier if you start from scratch with that in mind.
- j_baker 16y ago
  "I do not know where Clojure or Scala have a generic cross-process messaging ability, and I'm not saying it's impossible by any means, but it's much easier if you start from scratch with that in mind." I don't understand how. The only difference I see is whether the interprocess communication parts are coded into the language itself or whether they're coded into a library. It could theoretically make the problem more difficult to put it in the language itself. Instead of only affecting the programs that use that library, now your concurrency features could potentially affect any program written in your language. Could you give me an example of a concurrency feature that really, truly benefits from being in the language and not the standard library? I simply can't think of any examples.
  - Silhouette 16y ago
    > Could you give me an example of a concurrency feature that really, truly benefits from being in the language and not the standard library? Isn't that a bit of a loaded question? In some academic sense, an ideal programming system might have a kernel language that is probably rather small and certainly clean, flexible and extensible in its feature set, and then almost everything else built on top of that kernel in libraries. In practical programming systems, the perfect kernel has proven rather elusive, though. It's rather like the question of whether a standard library should be small, clean and extensible or comprehensive with a good-enough version of everything. Many of us might be inclined toward the former approach from an academic/theoretical/intuitive point of view, but in practice, just about every widely used programming language from the past two decades has come with a batteries-included library. While those libraries are often criticised for various technical weaknesses, and many of those weaknesses are never addressed because it's too much work, these systems are still good enough for most users out of the box.
tophercyll 16y ago
True, the nice things about libraries is that they can compete and make your ecosystem stronger. But the nice thing about building it into the language is that it becomes a common layer of compatibility. We've gotten comfortable enough with our concurrency model, that we felt it deserved to be in the language. As an aside, some features that benefit parallelism can be tricky to add retroactively, although possible (like an N:M threading model).
- 10ren 16y ago
  I believe race conditions can still occur in pure message-passing languages, like Erlang (Joe Armstrong says so in Programming Erlang, p.173). This doesn't get much press, perhaps because it's much easier to get right than shared-memory, and because not that many people are actually doing it yet. Does Spin address this issue?
  - tophercyll 16y ago
    You can build message passing code that suffers from race conditions. In practice, though, it's almost always obvious if you're about to do something dangerous. On p.173 Joe writes: When we say things such as this: Pid = register(...), on_exit(Pid, fun(X) -> ..), there is a possibility the process dies in the gap between these two statements. Regarding process death, we allow multiple inter-process relationships to be specified at spawn time. Hence any number of processes may be configured to observe a newly-spawned process before it has even started. Additionally, all children are linked to (die with) their parent, which both eliminates the risk of orphaned processes and has other benefits. So in Spin you wouldn't be tempted to write something like above (probably not Erlang either?).
scott_s 16y ago
See the paper by Hans Boehm from PLDI 2005, "Threads Cannot Be Implemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf A bit further discussion: http://news.ycombinator.com/item?id=939364 http://news.ycombinator.com/item?id=939364
jacquesm 16y ago
Occam. And a whole pile of others. Did you use a parallel programming language?
alec 16y ago
Fortress makes a convincing argument that it must be supported at the language level. It has a smart work splitting algorithm that does for managing parallelism granularity what garbage collection did for managing memory allocation. It works much better when it's baked into the core and is available from the ground up.
- kanak 16y ago
  > a smart work splitting algorithm Not to detract from anything you said (which I agree with), but when Guy Steele gave a guest lecture at my university on Fortress a few months ago, he said that the work splitting algorithm still needed work, in particular the part that decided the right amount of granularity for the given task (i.e. when to stop splitting the task into smaller subtasks).
  - carterschonwald 16y ago
    shouldn't it also be set up so that different algorithms can be swapped in? I think its pretty accepted at this point that different application scenarios perform better with differently tuned schedulers..

by j_baker 16y ago

X9 16y ago

It might not need language level support, but anything to make it easier to leverage is a plus in my book. If the programmer doesn't have to concern themselves with extra parallelism-specific library calls and is still able to write a binary that can take advantage of multiple cores, that seems like a good idea to me.

swannodette 16y ago

? Clojure has deep language support for concurrency - from syntactical constructs to it's core performant immutable data structures.

lukev 16y ago
But the beauty is that because it's a Lisp, it's all implemented in terms of macros - Clojure's complete set of concurrency tools could be written as a library. The only exception is the deref reader macro "@", since Clojure doesn't allow user-defined reader macros by default.
- kanak 16y ago
  > it's all implemented in terms of macros This is not true at present. The core data structures, and the STM machinery are implemented in java, not as macros.
plinkplonk 16y ago
He probably meant "distributed". Erlang has a better "distributed" story than Clojure.

jerf 16y ago

Erlang gets a lot of good mileage out of it, though. You start to really miss the OTP system when you try to write actually-important code in any other language. And there are some aspects that are hard to get right at a later time when it's not in the language from day one, cross-process messaging in particular, which is a primitive used to build a lot of other features. I do not know where Clojure or Scala have a generic cross-process messaging ability, and I'm not saying it's impossible by any means, but it's much easier if you start from scratch with that in mind.

j_baker 16y ago
"I do not know where Clojure or Scala have a generic cross-process messaging ability, and I'm not saying it's impossible by any means, but it's much easier if you start from scratch with that in mind." I don't understand how. The only difference I see is whether the interprocess communication parts are coded into the language itself or whether they're coded into a library. It could theoretically make the problem more difficult to put it in the language itself. Instead of only affecting the programs that use that library, now your concurrency features could potentially affect any program written in your language. Could you give me an example of a concurrency feature that really, truly benefits from being in the language and not the standard library? I simply can't think of any examples.
- Silhouette 16y ago
  > Could you give me an example of a concurrency feature that really, truly benefits from being in the language and not the standard library? Isn't that a bit of a loaded question? In some academic sense, an ideal programming system might have a kernel language that is probably rather small and certainly clean, flexible and extensible in its feature set, and then almost everything else built on top of that kernel in libraries. In practical programming systems, the perfect kernel has proven rather elusive, though. It's rather like the question of whether a standard library should be small, clean and extensible or comprehensive with a good-enough version of everything. Many of us might be inclined toward the former approach from an academic/theoretical/intuitive point of view, but in practice, just about every widely used programming language from the past two decades has come with a batteries-included library. While those libraries are often criticised for various technical weaknesses, and many of those weaknesses are never addressed because it's too much work, these systems are still good enough for most users out of the box.

tophercyll 16y ago

True, the nice things about libraries is that they can compete and make your ecosystem stronger. But the nice thing about building it into the language is that it becomes a common layer of compatibility. We've gotten comfortable enough with our concurrency model, that we felt it deserved to be in the language. As an aside, some features that benefit parallelism can be tricky to add retroactively, although possible (like an N:M threading model).

10ren 16y ago
I believe race conditions can still occur in pure message-passing languages, like Erlang (Joe Armstrong says so in Programming Erlang, p.173). This doesn't get much press, perhaps because it's much easier to get right than shared-memory, and because not that many people are actually doing it yet. Does Spin address this issue?
- tophercyll 16y ago
  You can build message passing code that suffers from race conditions. In practice, though, it's almost always obvious if you're about to do something dangerous. On p.173 Joe writes: When we say things such as this: Pid = register(...), on_exit(Pid, fun(X) -> ..), there is a possibility the process dies in the gap between these two statements. Regarding process death, we allow multiple inter-process relationships to be specified at spawn time. Hence any number of processes may be configured to observe a newly-spawned process before it has even started. Additionally, all children are linked to (die with) their parent, which both eliminates the risk of orphaned processes and has other benefits. So in Spin you wouldn't be tempted to write something like above (probably not Erlang either?).

scott_s 16y ago

See the paper by Hans Boehm from PLDI 2005, "Threads Cannot Be Implemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf A bit further discussion: http://news.ycombinator.com/item?id=939364 http://news.ycombinator.com/item?id=939364

jacquesm 16y ago

Occam. And a whole pile of others. Did you use a parallel programming language?

alec 16y ago

Fortress makes a convincing argument that it must be supported at the language level. It has a smart work splitting algorithm that does for managing parallelism granularity what garbage collection did for managing memory allocation. It works much better when it's baked into the core and is available from the ground up.

kanak 16y ago
> a smart work splitting algorithm Not to detract from anything you said (which I agree with), but when Guy Steele gave a guest lecture at my university on Fortress a few months ago, he said that the work splitting algorithm still needed work, in particular the part that decided the right amount of granularity for the given task (i.e. when to stop splitting the task into smaller subtasks).
- carterschonwald 16y ago
  shouldn't it also be set up so that different algorithms can be swapped in? I think its pretty accepted at this point that different application scenarios perform better with differently tuned schedulers..