On Wed, Jul 30, 2008 at 4:35 AM, <[EMAIL PROTECTED]> wrote: > On Tue, Jul 29, 2008 at 12:12:05PM -0700, Bakul Shah wrote: > > > > It is slightly depressing to think that the situation has not really > > changed since EWD wrote this in 1975. It will take some young > > whippersnapper of a Dijkstra or Hoare or Strachey or Iverson or Backus > > to find the critical insight that will make reasoning about parallel > > algorithm no more difficult than sequential ones. > > Is the human thought process parallel? For _my capacities_, I have the > impression that I'm more multitask than parallel. And context switch is > expensive because there is not only explicit data, but also implicit and > I'm not able, if I'm really doing something involved, to restore the > previous state without much ado. > > CSP is (for me) the best answer to problem involving blocking/waiting on > input. But this is not parallelism.
It's not pure parallelism, no, but CSP arranged tasks may execute in parallel :-) Imagine if you had a CSP-style process that grabs data in chunks from a network, and then passes a message to another helper which does some filtering. The filtering process could be scheduled on another core/CPU, while the other task it getting I/O from the network and massaging it in other ways. It's not exactly CSP, but I wrote a prime sieve using communication channels in Haskell (typed STM based channels) and I got a pretty good boost by telling the scheduler there was more than one CPU. http://hpaste.org/7766 (was my first try with this kind of haskell, so it's probably not that pretty). > > > And for processing, finally threads are also called in some > implementations: LWP, that is simply something that could have been > solved with Processes, if it was not so costly. > I have the impression that LWP is just a solution to poor process > creation and to poor IPC tools (threads are the solution not for > parallelism by itself, but because there is need to share resources > between processes and that it is simplest to put them in the same > address space). > > The most efficient is to have tools that match the way our brains work > (or not...). I'm not convinced our brains are "parallel" (at least mines > are not). What Joe Armstrong (of Erlang) would tell you (I think) is that we operate concurrently, and we communicate with each other via message passing, and that we manage to get work done in parallel this way, so why not manage parallel applications in this same system model? If you have lots of cores, and you wrote your application in a concurrent manner, in theory, many of them *could* run in parallel, but obviously this makes it sound more like art than science :-) One must know when a given process depends on the results of others to show where things are really not in parallel but just compositions of serial operations. > > -- > Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com> > http://www.kergis.com/ > Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C > >
