[crossfire] Map cache

[tchize]

Le Vendredi 26 Août 2005 13:40, Brendan Lally a écrit :
>
     
      On 8/26/05, tchize <
      
      tchize at myrealbox.com
      
      > wrote:
     
     >
     
      > Le Vendredi 26 Août 2005 01:45, Brendan Lally a écrit :
     
     >
     
      > >
     
     >
     
      > > An alternitive (which might be easier) would be to have a seperate map
     
     >
     
      > > loading thread at all times, and when a player enters an exit, not
     
     >
     
      > > change their map to the new one, but instead place them in 'limbo' if
     
     >
     
      > > the map isn't loaded (a unique map which is 1x1 and has no objects.
     
     >
     
      > > Then the player object would need to check every tick to see if their
     
     >
     
      > > map is ready. This still poses some problems with what to do with the
     
     >
     
      > > command queue, if a player has hit multiple arrow keys, should they be
     
     >
     
      > > discarded?
     
     >
     
      > 
     
     >
     
      > This isn't as simple, whole server code is thread unsafe, this mean
     
     >
     
      > if you load map in a separate thread you will break about all likned lsits used in
     
     >
     
      > server (objet pool, live objet lists, map lists, shared strings, and static
     
     >
     
      > variables used in some functions).
     
     >
     
     
     >
     
      The way you would get around that would be to have all the required
     
     >
     
      linked lists of items created for the map that is being loaded
     
     >
     
      seperately, then every tick the main thread asks 'are you ready to
     
     >
     
      merge' (checks the value of a variable) and when that is true, it
     
     >
     
      would then call a function in the main thread that took the pointers
     
     >
     
      for the objects in the sub-linked lists and inserted the whole lot
     
     >
     
      into the main list in one go. If done properly, this isn't slower than
     
     >
     
      1 insertion, but is a lot quicker than 2500 (as is the case for the
     
     >
     
      world maps)
     
     
as i said, this is *not* as simple (eg object pool, you have to use it, and it's
access is not thread safe, the file parsing code is also not thread safe, so you
can only load one map / player file at a time). There are not only
linked list related to map, and map loading code does more
than just loading the file (create treasures a.s.o), so lots of server functions 
are called during map load, and nearly 100% of them are not multithreadsafe.


>
     
     
     >
     
      Since the player is in limbo, there can't be any need to use the items
     
     >
     
      in the interim, quite what the result of player->ob->map should be is
     
     >
     
      anyone's guess though. (maybe the old map with a flag IN_LIMBO set?)
     
     >
     
     
     >
     
      > 
     
     >
     
      > There are 30x30 world maps
     
     >
     
      > each of them is 50x50 in size
     
     >
     
      > this makes 2.250.000 objects just for the ground objets
     
     >
     
      > 
     
     >
     
      > 
     
     >
     
      > I see 2 problems.
     
     >
     
      > 
     
     >
     
      > First, each of the objects weighting 0.5k minimum (supposing all pointer in object structure
     
     >
     
      > points to null or common structures) we reach a total of 1098Megs used for background!
     
     >
     
      > (need to hack server to get a real value)
     
     >
     
     
     >
     
      1098MB still sounds a lot today, but 7 years or so ago 300MB would've
     
     >
     
      sounded just as ridiculous, nowadays an application that occupies
     
     >
     
      300MB is bloaty, but not stupidly so. As it is, the entire mapset
     
     >
     
      would probably load into about 3-4 GB, but then servers with that
     
     >
     
      amount of Ram isn't so uncommon anymore.
     
     
point taken, if you except max addressable space on x86 is 2-3G / application :D

>
     
     
     >
     
      > Second, if my memory is still working well, this mean a linked list of 2.250.000 live objects
     
     >
     
      > in server, list which is checked on a regular basis to see if objects have some turns to play.
     
     >
     
      > This will slow down main server loop like hell.
     
     >
     
     
     >
     
      yeah, probably there would need to be a new set of linked list
     
     >
     
      pointers that exclude floor, and the main loop to go through them
     
     >
     
      instead.
     
     >
     
     
     >
     
      In total there are 3888528 occurances of 'arch' in the bigworld maps. (grep)
     
     >
     
     
     >
     
      If we assume on average that every square has one, and only one floor
     
     >
     
      tile, then a little bit of bash and bc gives 2832098 ground squares.
     
     >
     
     
     >
     
      This means there is 'only' about a million squares with relevant items
     
     >
     
      on them, which is still much less. Whether a server could run at full
     
     >
     
      speed with that I don't know.
     
     >
     
     
     
I still think we are addressing the problem from the wrong part.
First as stated in another mail, this is not the big world maps which take time to load but 
maps with lots of objects. Second, we still haven't check which part of map loading is indee taking
this time, responding to those 2 questions will give a better idea of a solution.

>
     
      _______________________________________________
     
     >
     
      crossfire mailing list
     
     >
     
     
      crossfire at metalforge.org
      
      
     >
     
     
      http://mailman.metalforge.org/mailman/listinfo/crossfire
      
      
     >
     
     
     >