Oooft! Lots of great info here!
At the moment the program can be set to compile CoreWars code, OR my own system inspired by it - though they work in the same way - my way is a little more modern BUT requires a
little more processing power (i.e it's slightly less efficient). As a result, the flow chart below uses "pMARS" as the assembly compiler/tester instead of my own system (and there are more efficient MARS compilers out there anyway - I haven't optimised that side of things yet!)
Relating to the program flow:
The code all runs under an
overseer application (python) which starts off all the other modules and then acts as a watchdog timer and memory manager - deleting old files as required.
The
overseer starts the
compiler, using a series of initial parameters - this generates a series of test-code, each in it's own text file (typically <500Bytes, limited to about 4.2kB) - how these are stored depends on the config file (they can be stored in RAM or on a particular drive)
The
overseer then starts the
scheduler which splits up the population for testing, again based on the configuration - deciding which cores to start processes in.
On top of that, (but still under the
overseer) is the
controller, which controls the data flow between the master node (which does everything except testing) and any slave nodes. I know that's not the right terminology but you understand exactly what I mean so I'm not going to stop using it
The
controller just sends test-orders and any required code-to-be-tested to the slaves, and receives the results back (which it in turn reports back to the
compiler which then "breeds" the test-code) and the process restarts.
The test just involves generating a virtual memory core with assembly commands in it and then executing the code while alternating between a number of pointers: after a number of conditions are met (usually the number of cycles) a scoring algorithm is run and the "winner" reported back to the
controller: there isn't particularly hard on the PC - in fact, CoreWars was originally released in 1984 and it ran fine then
- the RAM requirements are minimal - each simulated "Core" requires 448KB for the data in the core, and another 50kB for the supporting code - it's tiny - which is what I rely on when I run as many tests as I can!
BUT because of this it's quite a lot of high-level stuff - I'm not sure it'd be easy to optimise to run on a GPU =/ There are some optimisation tweaks I've done so far and I'll optimise it a little more as I go through it.
Those
Hello,
I'd suggest checking out the NanoPi NEO
Allwinner H3 (quad 1.2GHz)
for under $8 (256MB) or $10 (512MB)
http://www.friendlyarm.com/index.php?route=product/product&product_id=132
And the Orange Pi Zero https://aliexpress.com/store/1553371
Ah, that NanoPi might be exactly what I'm after: the cost:power ratio is pretty high - the Orange Pi Zero has higher power consumption and costs more - so the Neo may be better for my application in terms of cost.
As for cooling (and noise pollution
) - I'm thinking of simply submerging them in a tank of mineral oil (and maybe use an aquarium pump to add some flow to the oil) - provided it's low oxygen oil it shouldn't cause any corrosion problems.
16x NanoPi Neo works out at ~16 GHz of processing (including losses - it'll likely be higher) and that should be fairly expandable - so I can start slow and ramp up the power over time.
Not sure what I'll go for yet though - still researching it!
In the meantime I have a MiniPC from 2003 that I'll use for running 24/7 in the living room while I work on upping the processing power - it's a little slow but it will at least look pretty!