Warp wrote:
> appear even in single-core systems which run multiple threads (even though
> no two threads are ever physically run at the same time in parallel).

Just FYI, the general terms you're looking for are "concurrent" but not 
"simultaneous". :-)

> AFAIK the problems are more fundamental
> than the precise CPU design used.

Yep. There's no good way of making larger parts of systems automatically 
concurrent. The body of a loop that is small enough for the compiler to 
analyze? Sure. Two separately compiled procedures, or something running on 
two physically separate machines (where one might fail while the other keeps 
running)?  Not so much.  Not *impossible*, but far from trivial.

I've never seen it done well unless the whole system was broken down into 
parallel operations and then optimized back into larger components. E.g., in 
NIL and Hermes, there were no subroutine calls, just sending a message to an 
independent process (that only existed for however long it took to process) 
and then waiting for the result - easy to parallelize, pretty easy to 
recognise and turn into a subroutine if appropriate. In Erlang, you 
explicitly deal with failures and concurrency, manually making the trade-off 
of where to run a process, how many to run, and the difference between a 
process and a subroutine.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message