Several years ago I wrote a falling sand game for the Parallax Propeller chip, which is an 8-core microcontroller. One core was needed to drive the video output, and I had up to 7 other cores running a simple ruleset:
1. If a sand pixel had an empty pixel below it, exchange them.
2. If more than two sand pixels are stacked but there's space to the side, kick one sand grain out to that side.
These rules were enough to make the sand form simple hill shapes. All of the cores bash on the same shared memory array; rather than use locks or synchronization I just had each core start in a different column of the screen and all move left to right by columns - in theory there should be enough separation that they'd never conflict.
However - and this is the part I thought interesting to post about - somehow after a few seconds or minutes the 7 cores would catch up with each other and start running in lockstep (effectively reducing the speed of the simulation to equivalent of 1 core).
Barring a bug that was simply crashing cores, what I think was happening was that not every control flow path took the same number of cycles, so a core processing a column with a complex sand pattern might slow down and allow another core to catch up to it. Once two cores were operating on exactly the same data, they'd be doing the same deterministic logic on the same inputs and writing out the same result, effectively just duplicating the work in lockstep.
1. If a sand pixel had an empty pixel below it, exchange them. 2. If more than two sand pixels are stacked but there's space to the side, kick one sand grain out to that side.
These rules were enough to make the sand form simple hill shapes. All of the cores bash on the same shared memory array; rather than use locks or synchronization I just had each core start in a different column of the screen and all move left to right by columns - in theory there should be enough separation that they'd never conflict.
However - and this is the part I thought interesting to post about - somehow after a few seconds or minutes the 7 cores would catch up with each other and start running in lockstep (effectively reducing the speed of the simulation to equivalent of 1 core).
Barring a bug that was simply crashing cores, what I think was happening was that not every control flow path took the same number of cycles, so a core processing a column with a complex sand pattern might slow down and allow another core to catch up to it. Once two cores were operating on exactly the same data, they'd be doing the same deterministic logic on the same inputs and writing out the same result, effectively just duplicating the work in lockstep.