From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain Date: Wed, 4 Mar 2009 08:29:52 -0800 From: Roman V Shaposhnik In-reply-to: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: <1236184192.16176.100.camel@work> References: Subject: Re: [9fans] threads vs forks Topicbox-Message-UUID: b0fe47f4-ead4-11e9-9d60-3106f5b1d025 On Tue, 2009-03-03 at 23:24 -0600, blstuart@bellsouth.net wrote: > > 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. Our running joke circa '05 was that the industry was suffering from the "transistor overproduction crisis". One only needs to look at other "overproduction crisis" (especially the food industry) to appreciate the similarities. > 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... One could argue that transactional memory model is supposed to be exactly that. Thanks, Roman.