Re:Google's Introduction to Parallel Programming and MapReduce
by barrkel on Sunday October 23, 2011 @06:43AM
(#3145777)
There's a danger of talking about different levels of abstraction, yes; but if we start bringing in chip-level timing signals, I think we've lost sight of programming language level models, so I ultimately I think that's a red herring.
(I considered linking to that blog post, but decided against it in small part because of this.)
Re:Google's Introduction to Parallel Programming and MapReduce
by nandemo on Sunday October 23, 2011 @07:11AM
(#3145828)
I forgot the link to source:
http://existentialtype.wordpress.com/2011/03/17/parallelism-...
> Concurrency is concerned with nondeterministic composition of programs (or their components). Parallelism is concerned with asymptotic efficiency of programs with deterministic behavior. Concurrency is all about managing the unmanageable: events arrive for reasons beyond our control, and we must respond to them. (...) Parallelism, on the other hand, is all about dependencies among the subcomputations of a deterministic computation
> Now I can hear you object, but isn’t concurrency required to implement parallelism? Well, yes, it is, but concurrency is also required to implement sequentiality too! The timing signal on your processor chip is essentially a synchronization mechanism with which to coordinate the otherwise independent activity of the components of the processor. (...) The point is that concurrency is not relevant to parallelism, even if the engineers who build our parallel computing platforms must deal with concurrency. Another way to say the same thing is that parallelism is a useful abstraction, and abstractions should never be confused with their implementations.