You might get a kick out of this toy model I made to demonstrate how a mesh (or "cloud") of minimal "hardware actors" can work together to compute. It's the latest in a series of explorations of the "particle / field" concept...
http://cs.pdx.edu/~orhai/mesh-sort I think there's a lot that can be done with fine-grained homogeneous self-contained hardware in quantity, and I may get around to building a "poor man's Connection Machine" out of a bucketful of microcontrollers one of these days. The AVR is quite a capable machine for < $5 apiece! -- Max On Sun, Jun 5, 2011 at 6:44 PM, David Pennell <pennell.da...@gmail.com>wrote: > Note that you can "create" new "HW" in a cloud environment. > > >> On Sun, Jun 5, 2011 at 8:13 PM, Casey Ransberger < >> casey.obrie...@gmail.com> wrote: >> >>> Thank you for your reply, comments inline. >>> >>> On Jun 5, 2011, at 4:25 PM, Dale Schumacher <dale.schumac...@gmail.com> >>> wrote: >>> >>> > On Sun, Jun 5, 2011 at 5:23 PM, Casey Ransberger >>> > <casey.obrie...@gmail.com> wrote: >>> >> >>> >> Has anyone taken the actor model down to the metal? >>> > >>> > If someone has, I would sure like to hear about it! There was the >>> > Apiary machine, but I don't think that was ever physically built, only >>> > simulated. >>> >>> Googling... >>> >>> > >>> (snip) >>> >>> > The SEND and BECOME primitives seem fairly straight-forward to >>> > translate to hardware. It is the CREATE primitive that I struggle >>> > with. >>> >>> > Since we can't actually "create" new hardware elements >>> >>> (snip) >>> >>> Oh, yeah. That makes sense. >>> >>> > Maybe there would be some way to activate latent nodes of processing >>> > power, injecting them with their initial behavior as a way of >>> > breathing life into them. >>> >>> I really like this idea. >>> >>> > It could be just a matter of "allocating" >>> > new actors the way we allocate memory. Each hardware node could have >>> > a capacity of available actors who only need a script to become alive. >>> >>> This is not far off from what I was already daydreaming about. When I >>> started I thought those guys looked like a kind of regular "object animator" >>> that would light up when something was bound. I'd likely have to cache the >>> ones that didn't fit on the chip somewhere. >>> >>> Maybe to deal with concurrency I should really start thinking of them as >>> "actor animators". >>> >>> I'm sure there's a way to pull this off. Even if it's by having a lot of >>> FPGAs on the logic board so that I can compensate for reconfiguration >>> latency by switching between them, but I don't think that idea fits any goal >>> around a parsimonious architecture, which is one thing that I'm after. The >>> synchronization problems I'd expect also seem awful, unless someone out >>> there has thought a bunch about doing a low-level TeaTime (or what have >>> you.) >>> >>> So I'm really hoping I can find a general thing that I can just place >>> many identical copies of in the "die" or whatever it is we use now... ahem. >>> I am such a noob! And then just swap them out to main memory or a local >>> cache when I run out. >>> >>> > I would love to explore this idea further and hear how you would >>> > consider approaching the problem. >>> >>> I will definitely CC you if I think I've gotten somewhere with it. Feel >>> free to send me a note if you have any big aha-moments, because I have a >>> tiny slab of time to run at that fence before I'm going to have to get back >>> to work, and any/all help that I can get will be much appreciated. >>> >>> If I made it, I'd likely build a couple of boxes and try to pass them off >>> as art (like what one buys for the wall,) but my plan is to make everything >>> you need ("IP cores" appears to be the term of industry) to do it yourself >>> available under the MIT license if and when I've made some actual progress. >>> >>> I reckon I have a better shot at getting to actually use it if I just >>> give it away! >>> _______________________________________________ >>> fonc mailing list >>> fonc@vpri.org >>> http://vpri.org/mailman/listinfo/fonc >>> >> >> > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
