Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Mon, 16 Apr 2012 23:29:24 -0500 Message-ID: <4F8CF1A3.202@SPAM.comp-arch.net> Date: Mon, 16 Apr 2012 21:29:23 -0700 From: "Andy (Super) Glew" Reply-To: andy@SPAM.comp-arch.net Organization: comp-arch.net User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 Newsgroups: comp.arch Subject: Re: Indirect Bit References: <4F84FB1E.6CD1FC88@sonic.net> <4F86ECC6.4060405@SPAM.comp-arch.net> <9v14o0F3snU1@mid.individual.net> <3c8ca63b-36d5-4b70-9603-8addf508a4fb@f6g2000vbc.googlegroups.com> <9v3osiFchsU2@mid.individual.net> In-Reply-To: <9v3osiFchsU2@mid.individual.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Lines: 41 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-8bgCSehB2m7vjk78bUoOeMZ+qVfVpCniG5IEgjShPDd03DrCwVRcbzLRUA4apd/1EaFKvp3LDOywuSR!TaZ+uleXJlic1pBgwiczKg4banKRHNdGLv2ELTFHXmQtu3FGTlAIt3E= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 3335 Xref: csiph.com comp.arch:6564 On 4/16/2012 4:38 PM, Andrew Reilly wrote: > On Mon, 16 Apr 2012 08:08:34 -0700, Paul A. Clayton wrote: > >> Rather than seeing this as sending code, one might look at it as sending >> work orders. (If the code size of the work order is small, sending the >> code can be cheaper [no cache/TLB misses] >> than sending a function pointer. Likewise, some data might be more >> cheaply sent directly rather than sending a pointer.) If the data >> processed by the work order is mostly local to a different node, >> transferring the work order can be cheaper than transferring data to the >> originating node. >> >> The classic example of this kind of operation is fetch-and-add, >> where keeping the cache line holding the value in one place can have >> significant benefits (and the additions can even be coalesced in the >> network). > > So instead of having a thread on one node do read-add-write of data from > a remote node, you would have a remote thread that does read-add-write of > local data with a remote coefficient (or perhaps one in the instruction > stream). That sounds like a code structure issue, requiring a higher- > level of compiler optimisation that I think is commonly used. Perhaps a > hardware-based "work-order-sending" strategy could work, but it sounds > more complicated than just optimising the code. Sounds like a fun > compiler project, though. I've often thought that abstracting memory > operations to higher-level code, at a compiler level, could be an > interesting exercise. > > It's the same sort of idea as stored procedures in databases too, isn't > it? Some of my thinking here is inspired by David Dewitt's database class at Wisconsin. One day he asked "Which is better, shipping the code to data or shipping the data to the code?" Now, hardware always ships the data to the code. But Dewitt said that it is a truism, nearly always the case, that in databases one ships the code to the data. Function shipping.