New brainfart for threaded VFS and data passing between threads.
Gary Thorpe
gathorpe79 at yahoo.com
Wed Apr 7 18:17:28 PDT 2004
--- Chris Pressey <cpressey at xxxxxxxxxxxxxxx> wrote: > Gary Thorpe
<gathorpe79 at xxxxxxxxx> wrote:
> > Forth is a stack-based language. I would guess this limits
> > concurrency to 1 in all cases.
>
> [...]
>
> > That link is for a multiprocessor on a chip, it doesn't say what
> > concurrency you can get from _1_ forth program (my guess is 1 since
>
> > colorforth is stack based with 2 stacks for programs+data).
>
> I'm really interested in your reasoning ("guess") here. What is it
> about being stack-based that you think limits concurrency?
>
> -Chris
When your are using a stack to do arithmetic for example, you can only
do one 'equation' at a time (which is the entire sequence) and one
single operation in that equation at any instant. You can only access
what is at the top of the stack at any instant (and this is 1 piece of
data). If you are not using a stack, you could do all operations in
parallel that don't have data dependencies. A stack-based
machine/language is simpler and smaller, but the tradeoff is the time
it takes to do things one at a time.
This is also evident in the x86 floating point moel of execution which
is stack-based. RISC machines at half the clock speed are still getting
better benchmark results than Intel/AMD's latest (and information I
have read suggests it is due the the model that Intel choose to use and
not necessarily just CISC vs RISC and pipelining etc). You can find
information for this specific example that agrees with my opinion that
the stack model limits the performance. I don't agree that my reasoning
is a "guess": even if it is wrong, there is a rational behind it.
______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca
More information about the Kernel
mailing list