[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[NAUSEA] [task #4868] Make the server parallel

From: Luca Saiu
Subject: [NAUSEA] [task #4868] Make the server parallel
Date: Wed, 26 Oct 2005 23:46:44 +0200
User-agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.8a2) Gecko/20040715


                 Summary: Make the server parallel
                 Project: NAUSEA
            Submitted by: positrone
            Submitted on: Wed 10/26/05 at 23:46
         Should Start On: Wed 10/26/05 at 00:00
   Should be Finished on: Wed 10/26/05 at 00:00
                Category: World Server
                Priority: 1 - Later
                  Status: None
             Assigned to: None
        Percent Complete: 0%
             Open/Closed: Open
              Difficulty: Very hard



We have not seen this happening yet, but I think that for complex worlds the
server workload can become too high. It would be nice to automatically
distribute the workload among several machines, (maybe, but not necessarily,
assuming a very fast connection among them).

I, personally, am definitely *against* explicit user-expressed communications
among server hosts. NAUSEA is an high-level system and I think it should
remain so. Inter-server-hosts communication must happen *automatically* when

This is an extremely complex task. It requires the ability of freezing (part
of) the status of the Scheme interpreter, transfering it into another
machine, and then resuming; all of this *without stopping the simulation*.

Clients should not be able to tell that a load-balancing happened, and just
continue communicating with their interface to the server. This part will be
easy to implement when we have proxies.

Our worlds have a structure which lends itself to data-parallel
parallelization, but until now we have only exploited this structure to
optimize collisions. We can also use it for parallel computation.

I think it's acceptable to make some assumptions about timing. Of course
making the server computation model synchronous would allow us to perfectly
preserve the semantics of the sequential case, but at the cost of totally
killing performance. I think we can afford to make the parallel semantics
just *approximate* the sequential semantics.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]