Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: Multithreading with Rebol

From: joel:neely:fedex at: 17-Oct-2003 10:08

Hi, Robert, A couple of thoughts on the other side... Robert M. Münch wrote:
> Hi, don't bee fooled by all this multi-threading hype. For example, > have a look at and theire LRWP protocol. This is done > using a cooperative multi-tasking. Very cool and fast, and it can > be coupled with Rebol quite easy. >
I don't know what you mean by "hype", nor what that has to do with speed. I've never thought of parallelism in terms of the speed of a single task, but as a design/expressiveness issue. Remember: it's possible to express *any* computation in terms of only sequence, alternation, and iteration (e.g. block, IF, and WHILE) but few of us choose to restrict ourselves to only those mechanisms. For that matter, most of us would prefer to write (e.g.): foo: func [b [block! n [integer!] ...] [ ... expressions with B and N ... ... final expression with B and N ] ... blort: foo someblock 23 instead of foo-b: foo-n: foo-result: none foo-exprs: [ ... expressions with B and N ... foo-result: ... final expression with B and N ] ... foo-b: someblock foo-n: 23 do foo-exprs blort: foo-result The gain in expressiveness from having functions renders irrelevent the contention that we could find other ways to get the job done without them. There are some problems whose solution can be most naturally expressed in recursive terms. Likewise, there are some problems which can be expressed most clearly as a collection of distinct processes with well-defined collaboration patterns. Consider the popularity of "|" as a means of structuring computations via the *nix shell. Of course, anything that can be done with | can also be done in a single-threaded program, but then the programmer has to concern herself/himself with implementation/algorithm details that are simply irrelevant at the level of the original problem (e.g. buffering, distinguishing push-driven and pull-driven variations of the same algorithm, etc.) Finally, there are cases in which one of a set of collaborating activities should be allowed to "stall" for a time without forcing all others to wait. The fact that we can (sometimes!) deconstruct our code in a scheme to allow this to be managed in a single thread only means that we now have to add the issues of that scheme to the things to consider in doing our design, instead of being able to keep our focus on the top problem. I've recently been involved in several (very hard-core practical) projects where parallelism made significant contribution to the simplicity of the solution, overall performance, or both.
> Remember: multi threading won't solve performance problems just > because it's multi threaded... >
Agreed, but... Remember: single-threading won't solve design problems just because only one thing is happening at a given instant! ;-) -jn- -- ---------------------------------------------------------------------- Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446 Counting lines of code is to software development as counting bricks is to urban development.