Re: [f-cpu] virtually or physically-addressed cache ?

[Juergen Goeritz <goeritz@oekomm.de>]

On Tue, 5 Mar 2002, Ben Franchuk wrote:
> Christophe wrote:
> 
> > There is a difference between what you can do and what you can
> > efficiently
> > do. In such a scheme if you have say a 48 bit global address space and
> > you
> > are using 32 bit addresses with byte addressing you can efficiently run
> > 65K
> > processes with 2 GB address spaces each, that is not to say you cant run
> > more you will just have to make changes in the global address space and
> > either flush the cache or walk it to invalidate affected cachelines each
> > time a process not on the list is "swapped" in. Would even a hard limit
> > of
> > 65K 4GB address spaces really present any issue for a general purpose OS
> > though? :)
> 
> But really what runs 65K processes at once? In all fairness to the CPU
> really should run 1 process. Need another process ... buy a second ,
> third... A large system while it does have need for large taskes and
> addresses space is really a network of interconnected computers and
> would not the network define what process runs where and addressing.

:-) Yes, this is one way. Optimize a single execution unit
for max performance with limited number of tasks. But you
get a price to pay for communication performance when things
grow bigger. It's always a problem to optimize the data use,
i.e. data exchange between the tasks/processes. And you also
get some restrictions from the max execution performance. I
go for pipelined operation with only few tasks per processor
with my new product. But these tasks get a fully optimized
fast network support in hardware.

BTW this discussion seems to be a continuation of the mainframe
vs. PC discussion that was held some years ago. And the basic
theme beyond is 'have all in one instance' (master concept) or
'divide into many independent instances' (distributed concept).
I believe the distributed concept will beat the master concept
anyway because it is better regarding failsafe of the whole and
further development of the components.

JG

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/