Bots and Simulations > Evolution and Internet Sharing Sims
Mutation Sims
Numsgil:
Can't wait to till I can get ahold of some spare computers and set this up
EricL:
--- 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.
--- End quote ---
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
--- End 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...
Numsgil:
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...
--- End quote ---
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
Testlund:
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.
EricL:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version