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
