From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <10af1064d3ac35a8d2f62214d5eec485@gmx.de> <78900b59ef46884a6fdc7924188d9760@ladd.quanstro.net> Date: Fri, 15 Oct 2010 15:02:52 -0700 Message-ID: From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0016362837f6f44a810492aefc1a Subject: Re: [9fans] =?iso-8859-7?q?=F0p?= Topicbox-Message-UUID: 677d4f24-ead6-11e9-9d60-3106f5b1d025 --0016362837f6f44a810492aefc1a Content-Type: text/plain; charset=ISO-8859-1 CPUs have big caches to move the code closer to the data (well a copy of the data anyway). Closeness in general is good, the question is what to move and how :-) Dave 2010/10/15 Julius Schmidt > Perhaps I'm getting this all wrong, but to me this seems like an > interesting idea, especially if you consider the impact of being "near > the files" on some classically considered computationally stressy tasks > like compiling (esp. with kencc). So moving the code near the data > definitely seems worth trying. > > aiju > > > > On Fri, 15 Oct 2010, Latchesar Ionkov wrote: > > There are definitely cases when moving the code instead of the data >> makes sense. But that discussion is mostly unrelated to the one on how >> to make the file I/O work better over high-latency links. >> >> 2010/10/15 erik quanstrom : >> >>> On Fri Oct 15 12:33:19 EDT 2010, lucho@ionkov.net wrote: >>> >>>> What if the data your process needs is located on more than one >>>> server? Play ping-pong? >>>> >>> >>> one either plays ping pong with the process or data. one >>> could imagine cases where the former case makes sense. >>> >>> - erik >>> >>> >>> >> --0016362837f6f44a810492aefc1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable CPUs have big caches to move the code closer to the data (well a copy of th= e data anyway).

Closeness in general is good, the questi= on is what to move and how :-)

Dave

2010/10/15 Julius Schmidt <= aiju@phicode.de>
Perhaps I'm getting this all wrong, but to me this seems like an
interesting idea, especially if you consider the impact of being "near=
the files" on some classically considered computationally stressy task= s
like compiling (esp. with kencc). So moving the code near the data
definitely seems worth trying.

aiju



On Fri, 15 Oct 2010, Latchesar Ionkov wrote:

There are definitely cases when moving the code instead of the data
makes sense. But that discussion is mostly unrelated to the one on how
to make the file I/O work better over high-latency links.

2010/10/15 erik quanstrom <quanstro@quanstro.net>:
On Fri Oct 15 12:33:19 EDT 2010, lucho@ionkov.net wrote:
What if the data your process needs is located on more than one
server? Play ping-pong?

one either plays ping pong with the process or data. =A0one
could imagine cases where the former case makes sense.

- erik




--0016362837f6f44a810492aefc1a--