[REBOL] Re: P2P Q&A
From: dockimbel:free at: 3-Oct-2001 1:25
Hi all,
Maarten Koopmans wrote:
> Ok, this one is gonna be lengthy....
I'm afraid mine too...:)
[...]
> The first thing to realize is that threads are really processes with shared
> memory. (And shared memory is the root of all evil.....) This also implies
> that mutli-threading for performance is only really working on multiple
> processor systems.[...]
I do not agree. Multi-threading works and performs very well on a single processor.
[...]
> Now I am not
> saying that you should write your own OS, it's merely a blunt reminder that
> most things can be done in most environments if you really want to (threading
> at the interpreter level, implemented in REBOL for example).
In Rebol ? I already thought about doing that, but firstly, i see no way to do
it in a premptive mode but only in a cooperative mode (like Win3.1) and secondly,
i'm afraid that it will spend more time switching between your scripts than evaluating
them...:) IMHO, the only viable way is to implement it at least at the interpreter level
(in C).
> Take a look at the rugby console (rugby-console.r) on the REB, for example.
> It runs a server while you can type on the console in Core 2.5
This is just non-blocking I/O ! You're multiplexing between several I/O which spend
most of their time waiting for something to happen on ports ! When something finally
happens on
a port, you have to pray that the event processing won't take much time else you'll block
all other ports...It can work fine if all requests processing take very little time,
but if
any request takes several seconds to complete, all others will...wait !
With a single process server, you can answer only one request at the same time ! You
can
build a high-perf server based on a single thread only if you're spending most of the
time multiplexing I/O events and very few time in request processing. That works very
well for a web server (building a HTTP response doesn't take much time) like Zeus or
MEDUSA, but i'm don't think that an ORB or Application Server can match these criteria.
Apart from that, i'm sure that Rugby works well for simple requests (passing a message
from
a port to another, giving date & time, even performing a small request on a database,...)
provided that the average time between 2 requests is at least the same that a request
processing average time...else watch out for the lag ! :)
> Another example to prove my point: Ruby, a Japanese OO-like language with its
> own light-weight threading system, even on DOS! You could write a
> light-weight threading system if you'd really wanted too in Rebol as well.
Same answer as above. About Ruby, i assume that's a soft-threading model implemented
at the C level.
> Now as for Rugby: you can call functions in other REBOL processes in Rugby
> using the /deferred or /http-deferred refinements. They return immediately
> with a ticket number for your request. You can use this number to check
> regularly if the result is there, and if so fetch it.
Sure ! Multi-processing is way better that single-processing for this kind of server
!
But multi-threading is even better :
- Shared memory (Multitasking heaven, but notoriously difficult to deal with!), so that
a thread could access words from others threads and this way exchange data way faster
and easier than using tcp/ip connections (especially if you have a lot of threads).
Memory management is also more efficient. (for example: data caching)
- Lightweight context-switching : better performance than with multi-processing.
We need multithread to make really serious apps with Rebol, especially for serious server
apps ! IIRC, /Serve use multithreading internally.
[...]
> t: echo/deferred "Who needs threading"
Me and other Rebol developpers who try to find workarounds for their projects and who
could
finally choose drastic solutions like jumping to another langague, in a not-so-distant
future. ;-)
[...]
> So instead of worrying about the features not there you should look to what
> *is* there and how you can cleverly use it to solve your problems. The fact
> that one paradigma is missing doesn't mean that you can't solve it another
> way. In the end it all runs on the same computer.....
Yep, both Win3.1 and BeOS 5 run on my computer, and guess which is running better/faster/cleaner
? ;-)
Best regards,
DocKimbel.
