Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your feedback on a survey! Each completed response supports our community and gives you a chance to win a $25 Amazon gift card!


A New Approach to Simulation: 10,000 Actors, 10,000 Threads, 10,000 Spaceships


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 pronpu   Members   -  Reputation: 139

Like
0Likes
Like

Posted 16 October 2013 - 09:56 AM

We heard you!

 

Following the previous discussion, we've re-written the simulation to use actors running on top of true lightweight threads. No more callbacks!

Read about the new spaceships simulation here.



Sponsor:

#2 wodinoneeye   Members   -  Reputation: 879

Like
0Likes
Like

Posted 01 November 2013 - 09:20 AM

You may now find your database to be your chokepoint on performance.

 

All the updates flow in while queries for adjacency data is also being pulled.

 

How you database mechanism interlocks between writes and reads may be making the system run at a fraction of what an optimized solution might do.

 

The read/write transactions have to be queued (and that queue interlocked).  The record updates need to block concurrent  read attempts for the adjacency queries

 

--

 

Is it possible to maintain 2 database images - one for the current turn to read (read-only, having been written the previous 'turn')

and a second to receive the object updates (write-only, to be used the next turn for reads).    ((NOTE- this also prevents an object arbitrarily reacting/being one turn ahead in its actions.))

 

The two databases simply flip flop between the two uses (you have to make sure every record is written to the new write DB for every active object and wipe/mark all the just-dead objects)

 

This scheme eliminates multitude of read/write locks for individual records inside the DB

 

The update transactions and query results  goingto/from the DB process still have to queue/dequeue, but you might  manage in/out lockless ringbuffers to dodge alot of wasteful  locking overhead.  Multiple threads (cores)might do the queries if they are sufficient percentage of the processing.

 

The entire simulation works in lockstep with your multiple worker cores each  working an assigned object lists -- no pulling from a shared list if possible - as thats another resource interlock to avoid  (have minor reassignments for load leveling would be done between the different core's work lists).

 

There still might be a point in the 'turn' processing where complex results (effects from multiple objects must be summed  and arbitrated) but if the game mechanics can allow the locked in situation data from the previous turn to compound with results posted to the next turns situation state, it just becomes another phase which can also be processes with locks on individual object datat.


Edited by wodinoneeye, 05 November 2013 - 11:03 PM.

--------------------------------------------Ratings are Opinion, not Fact




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS