4 ms·

What do you mean by that. Because doing parallelism wrong is easy : do it. Parrallelism mean doing the same thing at the same time. The only way to not do it wr

by di4na 10y ago

What do you mean by that. Because doing parallelism wrong is easy : do it. Parrallelism mean doing the same thing at the same time. The only way to not do it wrong is to not do it.

catnaroek 10y ago
> Parrallelism mean doing the same thing at the same time. Yeah, but how to do it without making the program state go kaboom? > What do you mean by that. “Make it impossible to write to a data structure without (at least temporary) exclusive access to it.” At the risk of oversimplifying, there are basically three ways to do it: (0) Use data structures that are immutable after they are first written to. Pros: very easy to understand and use. Cons: limited to pure parallelism, without concurrency. (1) Clone all data structures when you need to share them. Pros: very easy to understand and use. Cons: not all data structures can be meaningfully cloned, e.g., how do you clone a file descriptor? (2) Use a static analysis (such as type checking) to enforce the precondition that writers must have exclusive access at the time of the writing. Pros: can handle both parallelism and concurrency. Cons: requires the ability to write code that a static analysis tool can understand. Since the last one is by far the most rare approach, let me give an example of it. Quoting the Rust book: > Here’s the rules about borrowing in Rust: > First, any borrow must last for a scope no greater than that of the owner. Second, you may have one or the other of these two kinds of borrows, but not both at the same time: > - one or more references (&T) to a resource, > - exactly one mutable reference (&mut T). https://doc.rust-lang.org/stable/book/references-and-borrowing.html https://doc.rust-lang.org/stable/book/references-and-borrowi...
- di4na 10y ago
  Sure but 1 and 2 end up being the same. Because when you reach the limits you clone. The thing with parallelism is not reading. It is writing. So the best way ... is to have isolated computation then reconnect them at the end... and yes it is hard.. But parallelism has few interest in my view. Concurrency is far more interested.
  - catnaroek 10y ago
    > Sure but 1 and 2 end up being the same. Because when you reach the limits you clone. You mean (0) and (1)? Yes, deep inside, they're the one and the same. (2) is qualitatively different from the other two. > So the best way ... is to have isolated computation then reconnect them at the end... What I'm saying is that Erlang-style complete process isolation is too heavy-handed and imposes unacceptable overhead in many cases. It's better to have fine-grained control over what you isolate and what you share, as in Rust. > and yes it is hard.. It isn't easy, but rejecting large classes of errors automatically helps. > But parallelism has few interest in my view. Concurrency is far more interested. Besides writing correct programs in the face of shared resource usage, another of the main points to concurrency control is to safely parallelize the parts of your program that don't compete with each other for resources.

by di4na 10y ago

What do you mean by that. Because doing parallelism wrong is easy : do it. Parrallelism mean doing the same thing at the same time. The only way to not do it wrong is to not do it.

catnaroek 10y ago

> Parrallelism mean doing the same thing at the same time. Yeah, but how to do it without making the program state go kaboom? > What do you mean by that. “Make it impossible to write to a data structure without (at least temporary) exclusive access to it.” At the risk of oversimplifying, there are basically three ways to do it: (0) Use data structures that are immutable after they are first written to. Pros: very easy to understand and use. Cons: limited to pure parallelism, without concurrency. (1) Clone all data structures when you need to share them. Pros: very easy to understand and use. Cons: not all data structures can be meaningfully cloned, e.g., how do you clone a file descriptor? (2) Use a static analysis (such as type checking) to enforce the precondition that writers must have exclusive access at the time of the writing. Pros: can handle both parallelism and concurrency. Cons: requires the ability to write code that a static analysis tool can understand. Since the last one is by far the most rare approach, let me give an example of it. Quoting the Rust book: > Here’s the rules about borrowing in Rust: > First, any borrow must last for a scope no greater than that of the owner. Second, you may have one or the other of these two kinds of borrows, but not both at the same time: > - one or more references (&T) to a resource, > - exactly one mutable reference (&mut T). https://doc.rust-lang.org/stable/book/references-and-borrowing.html https://doc.rust-lang.org/stable/book/references-and-borrowi...

di4na 10y ago
Sure but 1 and 2 end up being the same. Because when you reach the limits you clone. The thing with parallelism is not reading. It is writing. So the best way ... is to have isolated computation then reconnect them at the end... and yes it is hard.. But parallelism has few interest in my view. Concurrency is far more interested.
- catnaroek 10y ago
  > Sure but 1 and 2 end up being the same. Because when you reach the limits you clone. You mean (0) and (1)? Yes, deep inside, they're the one and the same. (2) is qualitatively different from the other two. > So the best way ... is to have isolated computation then reconnect them at the end... What I'm saying is that Erlang-style complete process isolation is too heavy-handed and imposes unacceptable overhead in many cases. It's better to have fine-grained control over what you isolate and what you share, as in Rust. > and yes it is hard.. It isn't easy, but rejecting large classes of errors automatically helps. > But parallelism has few interest in my view. Concurrency is far more interested. Besides writing correct programs in the face of shared resource usage, another of the main points to concurrency control is to safely parallelize the parts of your program that don't compete with each other for resources.