Author Topic: Mutation Sims  (Read 35707 times)

Offline Testlund

  • Bot God
  • *****
  • Posts: 1574
    • View Profile
Mutation Sims
« Reply #45 on: October 16, 2006, 12:03:48 PM »
I have a settings file here you can check out to set up your sim. Have fun!   Note it's for version 2.42.8 which is the major evosim program.

You can either let the morphological costs be like they are, which will eventually kill off a bunch of them after awhile, or you can chose to have it all set to 0. I whould recommend you start a bot with at least 13 zeros in the DNA.
The internet is corrupt and controlled by criminally minded people.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Mutation Sims
« Reply #46 on: October 16, 2006, 12:46:32 PM »
FYI, if you use the "No costs applied when population below..." feature, then amazingly, no costs will be applied until you evolve a replicator and the population grows beyond your threshold.  A major reason I added this feature is for null evo sims where you want no selection pressure until you have evolved a first replicator...
Many beers....

Offline Zinc Avenger

  • Bot Builder
  • **
  • Posts: 56
    • View Profile
Mutation Sims
« Reply #47 on: October 17, 2006, 06:43:26 AM »
The comment above about using teleporters to take advantage of multiple processors is pure gold. I did not know I could do that, and it has opened up some great possibilities for me.

The way I've got my setup running at the moment is to run two sims, a standard size one with bots and veggies and high frequency oscillating mutation rates (1 cycle at 16x, 3 cycles at 1/16x, no point mutations) and a large low-mutation one (1 at 16x, 19 at 1/16x, no point mutations) populated only with a fairly high number of veggies. Both have wandering teleporters set up to exchange only bots between the two.

The idea is that the bots evolve in the high-mutation sim and the teleporters occasionally transfer bots to the low-mutation sim. This sets up a stable population in the low-mutation sim, and regularly introduces bots from the high-mutation sim and transfers bots back to the high-mutation sim. If the currently-dominant strain in the high-mutation sim is not competitive against the low-mutation sim strain (in other words if the descendants are not competitive against their own ancestors) then the influx of ancestor-strain bots from the low-mutation sim will take over. If they are not significantly more competitive than their ancestors they won't get a foothold in the low-mutation sim.

The test sims I ran last night (about 7 hours worth) managed to avoid crunched descendants and showed definite evidence of improving fitness (introducing equal numbers of current-strain bots and ancestor-strain bots to a new sim meant that the current-strain bots always wiped out the ancestor-strain bots).

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Mutation Sims
« Reply #48 on: October 17, 2006, 11:35:27 PM »
Quote from: Zinc Avenger
The test sims I ran last night (about 7 hours worth) managed to avoid crunched descendants and showed definite evidence of improving fitness (introducing equal numbers of current-strain bots and ancestor-strain bots to a new sim meant that the current-strain bots always wiped out the ancestor-strain bots).

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).

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Mutation Sims
« Reply #49 on: October 18, 2006, 11:38:04 AM »
Diversity of environments is pretty key I think to providing the selective pressures necessary to evolve greater fitness.    Pressures to evolve can come from both the non-organism environment as well as from direct competition with other organisms.  I.e. an organism will be fitter if it out-competes rivals but also if it evolves a better adaptation to the environment.  Yes the latter almost always results in the former but my point is that a new or changing environment can often proivide directional selection independent of competition whereas a static environment favors stabalizing selection all else being equal.

While DB is pretty limited today in the ability to create different evironments within a single sim (gravity, fluid dynamics, costs etc are uniform throuhout a sim) it dawned me a while back that allowing multiple instances to connect on the same machine would be a cheap way to get greater environmental diversity as well as performance scaling.  The configuration you are using ZA is exactly the kind of thing I had in mind.  I love it.

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.
Many beers....

Offline Testlund

  • Bot God
  • *****
  • Posts: 1574
    • View Profile
Mutation Sims
« Reply #50 on: October 18, 2006, 12:36:36 PM »
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.

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!  
The internet is corrupt and controlled by criminally minded people.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Mutation Sims
« Reply #51 on: October 18, 2006, 01:50:07 PM »
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...
Many beers....

Offline Testlund

  • Bot God
  • *****
  • Posts: 1574
    • View Profile
Mutation Sims
« Reply #52 on: October 18, 2006, 02:18:04 PM »
Here's a sim with allmost 2000 objects in it, mostly veggies.
The internet is corrupt and controlled by criminally minded people.

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Mutation Sims
« Reply #53 on: October 18, 2006, 09:40:39 PM »
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...

Offline Zinc Avenger

  • Bot Builder
  • **
  • Posts: 56
    • View Profile
Mutation Sims
« Reply #54 on: October 19, 2006, 10:37:52 AM »
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).

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.)
« Last Edit: October 19, 2006, 10:41:51 AM by Zinc Avenger »

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Mutation Sims
« Reply #55 on: October 19, 2006, 11:00:24 AM »
Can't wait to till I can get ahold of some spare computers and set this up

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Mutation Sims
« Reply #56 on: October 19, 2006, 02:10:34 PM »
Quote from: 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.
I am dubious that actual linear scaling can be aheived.   In therory, linear scaling might be achievable for interactions which exhibit topological locality such as ties or collisions or vision.  A grid approach there would allow this, or close to it and it makes much sense to move to this architecture at some point.   I will claim however that the clumping issues can still make things non-linear, though with an exponent hopefully much less than 2.

As the number of nodes go up linearly, the average density will go up and thus the number of edges in the potential local interaction graph for local interactions go will up non-linearly.  If you try to increase the field size and other topological artifacts such as shapes that go with it to maintain average unfiorm density as population increases, then I will claim that you will still have a non-linear component because you will get clumping.  Bots tend to concentrate together around veggies, they are born in physical proximity, they chase one another, etc.  and thus adding the Nth bot will on average result in a slightly higher average desnity (even with a corrospondingly incrementally larger field size) and thus slightly higher number of local interactions needing to be calculated than adding the N-1th bot did.  You will get grid hot spots which will work against the linear aspects of grids and thus I will claim that adding the Nth bot will always take more cycles then adding the n-1th bot did.  Note that this ignores non-local interactions such as planet eaters which do not exhibit locality and are thus essentially O(n^2).  A grid approach won't help that kind of feature (although I suppose you could make it must better than O(n^2) by aggregating the masses of bots within distant grids and calculating the attraction forces for the grid itself as opposed to the bots withion a grid) but it can make the exponent for most interations much less than 2.  Unfortunatly, IMHO I don't think it can ever be 1.

Quote
Can't wait to till I can get ahold of some spare computers and set this up
 

Why not do it on a single computer?  There is no problem running multiple instances on a single cpu.  Multiple machines just adds horsepower.  You can acheive the topological advantages of multiple teleporter connected instances on a single cpu...
« Last Edit: October 19, 2006, 02:19:37 PM by EricL »
Many beers....

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Mutation Sims
« Reply #57 on: October 19, 2006, 09:52:45 PM »
To be honest, I would side with you.  Linear seems like a stretch of a claim, for the same reasons you outlined, but every resource I find indicates a linear relationship.  If I had to guess, I would have said it's probably a very flat O(n log n) curve, since when you add a bot you increase the complexity for a subset of the total population.  Either way, graphs I've seen of the complexity are very, very, flat.

I'd post the resource but I can't find it.

As to the Planet Eaters, I've seen some research from planetary models that use a grid approach to reduce the complexity in the same way you suggest.  The idea is that you absorb a body that is sufficiently far away into a single mass for the purposes of force calculation.  Might be fun to expirement with some time, but it's not really a huge issue since Planet Eaters isn't a standard option.

Quote
Why not do it on a single computer? There is no problem running multiple instances on a single cpu. Multiple machines just adds horsepower. You can acheive the topological advantages of multiple teleporter connected instances on a single cpu...

I basically just need a spare computer.  I tend to use my laptop for programming, etc. and my desktop is currently busy looking for Alien Intelligences in the noise of space

Offline Testlund

  • Bot God
  • *****
  • Posts: 1574
    • View Profile
Mutation Sims
« Reply #58 on: October 20, 2006, 08:27:41 AM »
I'm sorry, I didn't read your post properly before I posted my sim, Eric.  I had no idea running multiple instances could be faster. Maybe running two instances at half the size than a single instance and half the amount of veggies and connect them together whould be much better then. The best thing whould be if DB supported dual core so I could run each sim on each half of the processor. Maybe something to implement in the future?    I have never tried using teleporters. I'll give it a try later.
The internet is corrupt and controlled by criminally minded people.

Offline EricL

  • Administrator
  • Bot God
  • *****
  • Posts: 2266
    • View Profile
Mutation Sims
« Reply #59 on: October 20, 2006, 10:35:52 AM »
First, turn off Planet Eaters.  It's killing your sim perf by a factor of 5.  Yoru sim will run 5 times faster without planet eaters.

Second, let me say that DB *already* supports dual core machines.  All a dual core machine is is a machine with two cpus.  They just happen to be on the same chip.  Windows has supportted multi cpu machines for many years, scheduling processes and threads accross the cpus without any required changes to the programs.  It's not uncommon for big Windows servers to have up to 64 cpus for example and server programs like SQL server are designed to scale as much as they can to leverage such machines.  The XP client handles up to two cpus for XP home and four for XP Pro I beleive and those limits are artificially imposed.   The underlying kernal is bascially the same as that used on the server.  Microsft thottles the desktop to prevent server sales cannabism.

So, DB runs fine on dual core today but since it is VB6 and thus single threaded, it can only take advantage of more than one cpu if you get more than one thread of execution going in parallel and the only way to do that today is to run more than one DB instance.
Many beers....