Auto-Evo refactor to reduce memory usage

Programming
1

There’s been a thread earlier this year about auto-evo performance, but I want to discuss a more specific project here.

I will note that there is now also a separate Github project to handle auto-evo optimisation. And a lot of other work to optimise auto-evo is currently happening (since I started writing this, actually).

For a while now, there’s been a consensus that the current auto-evo method of making a full clone of species for every mutation attempted is wasting a lot of memory. This causes problems on systems with limited memory available, and may slow down auto-evo as a whole. As far as I am aware, there are also two proposals to handle this.

As:

  • I suspect further additions to the auto-evo system will just make attempting this more difficult.
  • Any kind of performance improvement at all for auto-evo would be greatly appreciated to:
    • Ensure further Multicellular additions do not bloat waiting times.
    • Allow more species in parallel so that prokaryote, eukaryote and Multicellular Species can actually all exist in parallel instead of one dominating.
  • Even after moving to Macroscopic in the near future, we probably will still use a system related to this for Macroscopic auto-evo.

I think this may be a good time to attempt this architectural change.

The proposals I have seen, as I understand them:

  • Hhyyrylainen has often suggested switching to a system where “auto-evo is only allowed to work with readonly species + a mutation list wrapper and never directly modify species.”
  • @Gamedungeon has suggested that we look at immutable data structures, designed so when you clone them it only stores the changes and links back for everything else.

For the first option I at least know that the first step would be to ensure all the auto-evo calculations use ReadOnly interfaces. However, those ReadOnly interfaces themselves are not always set up with the best memory allocation efficiency. So those would likely also have to be updated. For example the ReadOnly interfaces do not allow using indexes to iterate in a loop over organelles as:
“implementing that for facade classes would be difficult. The only way it would work with good performance is that on first index call after each modification it would need to generate a list of organelles to use indexing on. Right now it avoids that by just creating a single enumerator instance instead.”
So this would likely have to be updated as well.

I do not yet have a good grasp on what the second option would entail in a practical sense.

The objective of this post is to keep track of the discussion thus far, and not let it be lost in Discord mentions that nobody ever sees again. Please let me know if I misunderstood or missed anything.

I also hope that we can come to some consensus on what should be done so that anyone who is interested in working on this has some idea of what to do to complete the plan. So any suggestions on that front are more than welcome.

2 Likes
2

I feel like that the second suggestion is very similar to mine, just worded differently. Though immutable data structures here might mean that we would first move data from species → immutable version → then calculate with immutable and select results → move the data back. My idea tries to avoid that by just providing the readonly interface to the species data, so any species object can just be interacted with as if it was readonly. So we don’t need to shuffle the data to a secondary source and then do something on it and then move it back.

Of course if we were so ambitious as to remake auto-evo calculations as data oriented calculation, SIMD, or even as a compute shader, these would build upon the base of immutable species data representation in a flat structure. But I think this further step would be even harder and would make modifying auto-evo a lot harder in the future as anyone working on it needs to really understand the data patterns and how the processing flow works. So I don’t really see this option as realistic due to the amount of work, and ongoing problems if the person who manages this conversion then ever leaves the team and there isn’t anyone who is as skilled in these techniques around to continue the work.

But yeah my point is that my idea and GameDungeon’s is basically the same core idea.

2 Likes