Code center > Bugs and fixes

2.42.7b runs much slower!

(1/4) > >>

Testlund:
I did a comparison between 2.42.7 and 2.42.7b and where the first runs my sim at 5.2 cycles/sec the other one runs the same sim at 1.4 cycles/sec. I wonder what you have added that cause it to run slower.

Numsgil:
How many bots and shots are in the sim?  That's going to be important in finding out if the problem is in a very small percentage of functions or if it's some sort of timing problem or...

EricL:
I would be interested in knowing whether the same slow down is observed in 2.42.7a.

I did make a change between 2.42.7a and 2.42.7b in the management of the shots array size.  It now starts out larger (5000) and grows in jumps of 5000.  I did this because I was hitting some strange crashing bugs when lots and lots of shots get created in a single cycle - more then that previously handled by a single increase in the array size - like when a whole bunch of bots die and their poffs get displayed.  VB was doing something strange that I still don;t understand where the shots array was getting locked.  My thinking is that it will be very rare that more than 5000 shots get created in a single cycle.

The perf impact of this change should be quite minimal, primarily only impacting smaller sims with few or no shots (they will be uncessarily loopoing through a larger shots array).  The impact on larger sims with a "typical" number of shots should be essentially nil - unless I screwed it up of course.

So, the main questions that could help me:

Do you see the slowdown in 2.42.7a?

Does the sim have any shots?  If so, how many typically?

If you turn off poffs, does it change things?

Posting the sim would also be very helpful.

There are some things that have a surprising and unexpected perf impact beyond just total number of shots, bots, ties, shapes, etc..  For example, the exact same sim with the exact same number of bots and shots will run considerably slower if all the bots are close together on the field then if they are spread out.  This is becuase the collision detection routines have to do more work if the bots (or bots and shots) are close enough that a collision is possible that cycle.  If they are far apart, a very fast and simple distance test can rule out a collision.  If they are close, the code has to do a lot more math.  (Thus, if you want null evo sims to run faster, use a big field and turn off planet eaters!)

Testlund:
I haven't tested version 2.42.7a because I was thinking that the only thing you added there was something with day/night cycles that wasn't interesting for me. But it's probably better if you compare it yourself, so here's a sim wich was saved in 2.42.7.

EricL:
I think I may have found this.  Allow me to expound.

Over the course of the last few releases, I have slowly changed the way the shots array works.  Before I came on board, the code tried to keep the shots array small and relatively packed.  That is, if there were 900 shots in the simn, the code would keep the array size just above that, say size 1000, and would try to always use and re-use the lower slots to keep from having to increase the array size.  When a slot empitied becuase a shot got deleted (when it impacts or expires) then the code tried hard to re-use that slot instead of using, say, slot 901.  Each time a new shot was created, it walked the array from the beginning and used the first open slot.  This had the advantage of keeping the array size smaller and thus keeping the shot loop size smaller than it otherwise might be, but had the huge disadvantage that new insertions were very VERY expensive, essentially O(n/2) on average.

The above strategy is okay when insertions and deletions are rare but since shots generally have short lifespans and come and go so frequently, the insertion cost of the above algorithm completely and utterly swamped the benifits of maintaining a tightly packed array.  What I have done is to change the insertion algorhithm so that the probability of using any slot is the same.  When a new shot is created, the code starts looking at a location where the last shot was created.  This has the effect of dramatically lowering insertion costs with a reasonable increase in array size.

In 2.42.7b, I made a bunch of additional changes to allow for > 32000 shots in a sim.  I think I screwed up the code that made the change above as part of that and was setting the pointer back to 1 for each new insertion, essentially going back to the old algorithm, but now with a larger shots array, at least for smaller sims with few shots.  Ooops.  

Try this one.
2.42.7c Buddy Drop Download

Navigation

[0] Message Index

[#] Next page