> Joe, > > > Regarding efficiency, can someone comment on whether there is any difference > > between the stream and continuation models in the effect on parallelism? > > Parallelism could be ENHANCED by a suitable continuation I/O model, such as the > one I am working on (slowly), since with asynchronous I/O, you can carry on > with calculations after submitting an I/O request (unless you are explicitly > waiting on the result of an I/O operation), and I/O requests themselves > may sometimes be safely carried out in parallel. This applies equally to the request model. Nothing prevents the submission (but not necessarily resolution) of a later I/O request during resolution of an earlier request if those requests are independent (and the request stream is hyper-strict). Overall, I *think* the two systems are equivalent for parallel evaluation, but I'd be interested in any evidence to the contrary (e.g. if the conditions for parallel evaluation are different in either case)... Obviously I/O must be sequential at some level if the necessary dependencies are to be enforced. This may be at the IO controller level rather than the language level, though, and hence some parallelism may be gained even in an apparently sequential program. Parallelism may also be gained by speculation, overlapping "non-conflicting" accesses, or if all IO updates to a location return the same value (this can happen in e.g. a knowledge base -- confluence at a level beyond the functional program!). No matter what the level, the IO "bottleneck" which is a feature of using requests/continuations is highly undesirable in a truly distributed system (for example, a parallel database). Does anyone know how to avoid this, cleanly? Kevin
