performance

[jknilinux]

Just wondering, what sort of performance should we expect with DB3? using C#, 3D, extra features, etc... it sounds like it may only run decently on the most recent computers. Perhaps we have to realize that most people are just interested hobbyists and will be running this on a spare pIII PC. Perhaps we can make a less-fully-featured version of DB3?

Will there be any way in the settings to make it very resource-efficient? maybe a hyperspeed mode with almost everything disabled? TY!

[Numsgil]

I'm planning a command line version, if nothing else.  And maybe a way to run a command line version on one computer and hook up a GUI visualizer on another computer.

C# is JIT compiled, so I don't expect significant performance hits from that aspect.  It might run a little memory hungry, though.  Especially any initial versions.

Also, on the subject, any first release will probably run waaaay slower than a final version.  For instance, I'm building on some brute force algorithms for an initial version where some smarter algorithms could significantly reduce the runtime complexity.  With 1000 bots an initial release could easily run a thousand to a million times slower than theoretically possible.

Most of the algorithms I'm playing with are parallizable, as well, so more cores will make life faster.  Maybe some sort of distributed LAN computing network which Darwinbots runs on top of could work...  I'll try to target something like larrabee when they become available.

[jknilinux]

Can it run on 64-bit machines? The extra RAM could prove very helpful

[Numsgil]

It uses XNA, which apparently only has 32 bit versions available.  I think that might cause a "cascade" where the target platform has to be 32 bit.  But there might be a way to build console versions which are 64 bit.  Worst case the memory would grow with the square of the number of bots, so I don't think it would be an issue until you start getting multiple thousands of bots.  And my ultimate goal is to have performance and memory be linearly related to the number of bots, so then that might become moot.

[jknilinux]

ok, great. I think it's like making a man-made closed ecosystem; the more organisms and the larger the space, the more stable it is. So, for a stable, complex ecosystem, I'd imagine we'd need at least a thousand bots. Right?

[Numsgil]

1000 bots at 10 cycles/second average (DB3 will have very bursty performance probably) is my goal for that reason.  Less than that and random population fluctuations can cause extinctions fairly easily.  More bots would be even better, of course.  And once some sort of networking is set up the effective population size could be orders of magnitude larger.

[Shasta]

This is an interesting project I ran upon a while ago: SlimGen, its made by the same people who made SlimDX (C# DirectX wrapper). What it lets you do is use assembly math operations inside of a .net CLR project.

[ikke]

Worst case the memory would grow with the square of the number of bots, so I don't think it would be an issue until you start getting multiple thousands of bots. And my ultimate goal is to have performance and memory be linearly related to the number of bots, so then that might become moot.

How does this relate to DBII where I have pop explosions easily pushing numbers up to 5000?

[jknilinux]

How can we get it to run on a cluster? Also, can this work on early versions of Windows? I'd expect significant performance increases if it runs on Win2k. I want to set up a dedicated computer, so having the latest OS isn't important.

[abyaly]

I think the most important performance optimization right now is getting something running. Others should probably wait for that.

[Numsgil]

This is an interesting project I ran upon a while ago: SlimGen, its made by the same people who made SlimDX (C# DirectX wrapper). What it lets you do is use assembly math operations inside of a .net CLR project.

Yes, I recently found that as well (was talking with Washu on gamedev and found his blog talking about SlimGen).  Not something I'll play with any time soon, but I'll probably dig in to something along those lines to take advantage of vectorization (SSE, SIMD, etc.) in the future.

Worst case the memory would grow with the square of the number of bots, so I don't think it would be an issue until you start getting multiple thousands of bots. And my ultimate goal is to have performance and memory be linearly related to the number of bots, so then that might become moot.

How does this relate to DBII where I have pop explosions easily pushing numbers up to 5000?

DBII should have a memory footprint that is linear against the number of bots.  But the performance generally degrades with (worst case) the square of the number of bots.  Not to mention what happens if it ends up eating all your memory and goes in to virtual memory.

How can we get it to run on a cluster? Also, can this work on early versions of Windows? I'd expect significant performance increases if it runs on Win2k. I want to set up a dedicated computer, so having the latest OS isn't important.

I'm not sure how far back .NET is supported on windows.  But with Mono I'd imagine you could run in any 32/64 bit OS.  Probably even a really barren linux environment.  I've done some mono compatibility testing recently and no problems were reported.  But I haven't actually tested with mono.  And I don't know how good the mono JIT is, so I don't know if there would be any performance penalty or anything like that.

As far as clusters... it's entirely self contained .NET code.  So any platform which can run .NET could run Darwinbots.  I haven't looked, but I imagine there either are solutions to run .NET in distributed environments or there will be soon.  Then the hard part is threading the code enough to properly handle potentially hundreds of different computers.  For a proper game, that wouldn't really work (real time requirements would squish it), but Darwinbots doesn't have to run in real time so there's absolutely no reason why you couldn't send, say, the DNA to another thread/computer to execute and get the output back 100ms later or whatever.  With the way the physics will work it's not even entirely true that you'd have to completely finish one frame before moving on to the next.

I think the most important performance optimization right now is getting something running. Others should probably wait for that.

First version will be reaaaaaaallly slow for that very reason.