Re: [9fans] threads vs forks

[john@csplan9.rit.edu]

>> it's interesting that parallel wasn't cool when chips were getting
>> noticably faster rapidly.  perhaps the focus on parallelization
>> is a sign there aren't any other ideas.
>
> Gotta do something will all the extra transistors.  After all, Moore's
> law hasn't been repealed.  And pipelines and traditional caches
> are pretty good examples of dimishing returns.  So multiple cores
> seems a pretty straightforward approach.
>
> Now there is another use that would at least be intellectually interesting
> and possible useful in practice.  Use the transistors for a really big
> memory running at cache speed.  But instead of it being a hardware
> cache, manage it explicitly.  In effect, we have a very high speed
> main memory, and the traditional main memory is backing store.
> It'd give a use for all those paging algorithms that aren't particularly
> justified at the main memory-disk boundary any more.  And you
> can fit a lot of Plan 9 executable images in a 64MB on-chip memory
> space.  Obviously, it wouldn't be a good fit for severely memory-hungry
> apps, and it might be a dead end overall, but it'd at least be something
> different...
>
> BLS

64 MB is enough to run a lot of Plan 9 apps and the kernel
simultaneously, sure.  But you can't fit Windows or Firefox in there,
so it's probably not going to happen--if you can't fit either of the
world's two most-used consumer apps, I don't think Intel will bother.
Besides that, doing such a thing would involve departing from the
hallowed CPU-cache-memory-swap-disk architecture we've held so dear
since dinosaurs roamed the earth.

Better off to just beef up the caches; there are big benefits and
cash prizes to be had from higher L1 hit rates.


John Floren