Bots and Simulations > Evolution and Internet Sharing Sims
Mutation Sims
Testlund:
--- Quote from: EricL ---BTW, I have a LAN at home and have run as many as 10 cooperating instances across 4 machines with a total bot population exceeding 10,000.
--- End quote ---
I don't know how you can possibly manage that without frezzing up the computer. If I get more than 1500 objects in my sim it freezes. I have.... Oh, my...! I just looked at the specifications and it says my dual core processor is only 989 MHz!!! It's supposed to be 2.2 GHz! Something is wrong here!
EricL:
My machines are single proc P4's running between 1.4 and 3Ghz with 512-1Gb of ram. Not dual cores, but not slow pokes either.
Note also that in my setup, any given single DB instance genenerly only contains on average about 1000 bots. The 10,000 number is the total across the 10 connected instances.
Note that many performance elements of DB are non-linear w.r.t. bot population. That is, a sim with 500 bots will run more than twice as fast as the same sim with 1000 bots all else being equal. Said another way, two connected instances with 500 bots each will run faster than a single sim with 1000 bots, all else being equal. The computation necessary for things like vision, bot-bot collision detection and bot-shot collision detection have artifacts that go up polynomially with population, non linearly, especially if there are lots of bots in close proximity.
Even in a given sim with a constant population, the sim will run as much as 2X slower or even more if all the bots are clumped together as opposed to spread out across the sim. This is becuase if two bots or a shot and a bot are close enough to possibly collide or see each other, etc. over the next cycle, then certain performance shortcuts in the code cannot be used and the actual, expensive calculations must be performed. By using multiple instances, no code needs to execute to check for collisions, etc. between bots in differnence instances. Thus, the overall computation load for the total population is less than it would be for a single instance.
My topology between the 10 instances is a ring and generally self regulates, spreading the population out fairly evenly as the field sizes are not large and thus if the population in any single instance goes up, the increased density tends to increase the outbound teleportation rate over time.
If you suspect a performance problem with the program, I would be very interested in taking a look at a sim which exhibits slower performance in recent versions than in prior versions...
Testlund:
Here's a sim with allmost 2000 objects in it, mostly veggies.
Numsgil:
As a performance P.S., the C++ fork uses a uniform grid for the what-can-see-what. The result is that theoretically things scale up linearly as you inrease the number of bots. In actual profilling bot collisions are now more expensive than bot vision. A similar approach with bot collisions means everything should scale linearly with bot population size.
Now if someone would polish and finish that code...
Zinc Avenger:
--- Quote from: Numsgil ---That's an impressive accomplishment! Most ancestor vs. current strain sims that I've done have the ancestor win out (That doesn't necessarily mean that the ancestor is more fit than the predecessor).
--- End quote ---
Yes, the ancestor strain usually does win and that was the idea. The setup I described really raises the bar for mutations to take hold. It created what I tend to think of as a sort of "genetic inertia" (yes I'm aware that I'm just making up descriptive terms! ), so minor improvements and neutral mutations can't oust the ancestor strain in their "home" sim. It takes a genuine and significant improvement for the ancestor strain to be overrun in the low-mutation sim, and all the while if the high-mutation current strain falls below a certain threshold of fitness the low but regular introduction of ancestor strain bots wipes out the feeble descendants and starts the process again from a known competitive point.
I'd think that in some ways the net effect is similar to what you might get if you just vastly scale up the numbers in a single sim, just with lower computing costs.
It automates a lot of the saving and manually injecting test populations I used to have to do in several sims run consecutively. So you can see why I think everyone should be told, loudly and repeatedly, about the new teleporters function!
(Oh, and also perhaps a couple of hints about having to create a dir to use as a swapping area and having a separate dir for each teleporter pair might avoid 15 mins of head scratching like I had.)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version