[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 www.xitami.com 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.