NOBLE APE MAILOUT - FEBRUARY 2005
LIFE CYCLES OF THE HAIRY AND SIMULATED
LIFE CYCLES OF THE HAIRY AND SIMULATED
Working through the distributed Darwin@Home-ised version of the Simulation, introducing and testing an active life cycle seemed to be relatively central to this theme. Whilst the threading model has existed for a number of versions, it seemed necessary to brush up the model a little to allow for an even distribution of a random number of apes over processors and also to look again at the issues associated with graphics rendering shared between processors.
Life cycles in this context means simulating the birth, reproduction and death of the Noble Apes. The biggest change initially is that the file format can finally translate to a dynamic number of Noble Apes. A user can edit the file to contain a number of apes starting from the same point with the same characteristics and track their interaction and divergence.
Introducing reproduction means the apes need to show an interest in each other. This code has, funnily enough, come through Noble Warfare. The effects of charging in combat can be equated to the Noble Ape courting ritual.
As always, the central issue is stability. Both in the simulated sense and also in the software sense. In the simulated sense, you don't want a simulation where the population of the apes always drops. In a software sense, you don't want the new dynamism of population to lead to crashes and various strange behaviours. In short, you want the same level of stability expected of the Simulation by the userbase without any additional unwanted effects.
THREADING and PAGE FAULTS
Working through the source code prior to my departure from the UK, two aspects of the code have been reworked - threading and page faults. With the Simulation moving to a shared processing paradigm - be it through threads or through simulation elements over a network - the ability to simulate a varying number of apes and a number of apes spread over two processors on the same machine has required some reworking and a little analysis of the multi-processor methodology to-date.
The result has been a simplification of the existing code without breaking the Stockholm Re-write paradigms of autonomy in the source structure. My personal log has some expansion of this for those interested;
The second aspect of this month's changes relate to page faults. This is explained in Apple's Performance notes although I am sure the same is analogous on Wintel;
The short of the document is that the Simulation should minimise the traversing of memory outside 4k. This seems an inordinately small amount of memory for modern computing. But it works out quite well through aspects of the simulation like the brain mapping.
Visitors to the site over a weekend this month were greeted with a note on the front page and the forum saying the site had been taken over by a hacker. Alas, it was only a weakness in the forum software. One of the few parts of the site that was part of a global open source pool.
The site is back to normal bar the removal of the forum. With a single external post, I don't think I will be putting the forum back on the site. Disappointing in some regard, but the general email traffic associated with the Simulation shows those who need assistance or want to offer feedback will go through email.
APES AT HOME UPDATE
Aside from the source code changes with the Simulation for Darwin@Home, I am working with the USC team and the project's founder, Bruce Damer, to establish what the D@H protocol will look like. It is early days in the development.
For Noble Ape, I am using the initial ''call to code'' to give momentum to developing the Simulation in directions discussed in mailouts prior to the D@H launch. The usual mantra - any colaboration improves the Simulation code - be it Noble Warfare or Darwin@Home.
Hope all is well with you all,
Tom Barbalet, 17 February 2005.