Sadly, this doesn’t eliminate memory copies, according to the documentation:
In the current implementation, every object insert and look-up operation results in a copy of the object.
JEG2
Author of Designing Elixir Systems with OTP
0
gregvaughn
I’m envisioning it only being written one cell at a time. And only read 8 cells at a time (or perhaps one single value if match specs can be used).
I was suggesting that the rendering process could be the writer/owner of the ETS table precisely so it can have an in-memory cache, optimized for rendering, of the whole lake and never have to read the entirety of it from ETS.
0
Qqwy
TypeCheck Core Team
Oh snap. I don know why I wrote down that completely unrelated number ^^'.
Yes, you are right. I did not consider this. This is sort of a problem, unless you decide that the speed at which you want to see the state does not need to be as fast as the simulation itself.
What I think is the best solution, is to have a single global, name-registered ‘observer’ process that receives notifications each time a Lilypad’s state changes. It does not contain references to any of the Lilypads, it only receives information like {x, y, type_of_critter_inside}. This can sort of be seen as a digital equivalent of ‘looking at’ something (i.e. light rays(messages) travel from the things that change state to the entity that observes). This single process will become a bottleneck, but because it is at the edge of our system, the simulation itself is not affected by it.
Of course, if the simulation runs so quick that this outside process is unable to work through the messages quick enough, it will start lagging further and further behind in the past.
We can go even further overboard, introduce vector-clocks for all state-change messages the Lilypads send and create a (non-OTP) process, reading the message queue as LIFO (last-in-first-out) and discarding messages whose vector clock value isn’t higher as the one in the current representation we have.
Introducing these vector clocks probably actually means introducing two vector-clock-like-values: One for how often a Lilypad has been restarted (This needs to be kept track of in the ‘World’ process and passed along to the newly restarted Lilypad each time), and a second for how many state-change-messages this version of the Lilypad has sent. I would argue that timers are a bad solution here, as we do not actually care how fast something has happened, only how often something has happened. Time has many peculiarities (leap seconds, changing clocks, network delays, CPU temperature et cetera) that make it hard to determine what will actually happen in a system.
I think that doing this is taking it too far, but I think this is possible.
Yes, I completely agree with you. Conway’s Game of Life is suited a lot better for a single process because the whole computation of moment n+1 depends on the state of each of the cells of moment n. It’s possible to start a separate process for each new cell and pass it its old state plus its neighbours, but because the next-timestep computation is so simple, this would incur a lot of unnecessary overhead.
In a situation like this Pond simulation where entities act on the current state around them and influence the same state at that time, however, processes seem like a natural fit.
What would definitely be interesting to solve concurrently, though, is a Hashlife algorithm.
0
Qqwy
TypeCheck Core Team
If you store the position of on what lilypad it is only in the critter, how would the critter know how many neighbouring critters it has?
Embedding the information of the critters on the Lilypads instead of in their own process is possible. However, the main reason to split them into two, is because of a separation of concerns. If either of these things grows in complexity (say, we want to have special lilypads that only turtles can walk on), it can do so without directly affecting the other. Also, consider what happens when one of the things crashes: If a Lilypad-embedded-with-critter-info crashes, that critter is lost. If a Lilypad crashes whose critter is in a separate process, this process can wait for a new Lilypad to appear at its location.
Conversely, if a Lilypad-embedded-with-critter-info crashes while executing its critter-movement code, the whole Lilypad crashes as well. In the case these are separated, again only the critter crashes and is restarted.
0
sasajuric
Author of Elixir In Action
My first hunch is to model the world as a purely functional data structure and maintain it inside a single process. This means there would be some tick operation the result of which is that some critters move (i.e. the world transitions to the next state). A main benefit of this approach is consistency. When everything is in a single process you can get a consistent snapshot of the world and move it to the next state predictably.
That’s not the case with everything-as-a-process. Since processes are separate, you can’t get a snapshot of the world, so you’re always operating on possibly stale knowledge. For example, counting neighbours means asking 8 processes. When you get a last response, all of them might already be stale, since all entities run independently. It’s also unclear when each entity is moving its own state. There’s less guarantees about order and no guarantees about synchronism, which is quite non-deterministic. Perhaps that’s actually desirable when simulating real-life, but it’s certainly harder to reason about.
If you wanted, I think you could add randomness to a single process world. For example, you can have more frequent ticks, moving only some random part of the world in each tick.
A single process world might also help with drawing. After you tick the world, you know all the changes, so you can send them to the drawing process which could probably render them in a single pass.
I’m not convinced about error isolation benefits. It seems to me in everything-as-a-process approach the processes would mostly perform a couple of primitive operations, such as keeping an occupied state, counting neighbours, or selecting a next destination. It seems fairly unlikely these things will crash. I mean, it’s always a possibility, but the processes seem extremely simple at this point. It’s also unclear what should happen when an entity process crashes. Perhaps a drawing process should be notified about this and clear the entity from display. Or maybe a supervisor might restart and resume the entity process, but then you’re restoring the state, so the process might crash again. The fault-tolerance point seem too fine-grained for this case. I’d probably opt to kill the entire world if something goes wrong.
I’m also skeptical about the performance/scalability benefits of multiple processes. Again, it seems these processes would do very little, so the cost of message passing will probably shadow possible gains of utilizing multiple cores.
Processes are great, and they should be used extensively, but there’s always a trade-off. Otherwise, we’d be running every single line of code in a separate process 
As you say, there are 14192 entities, which doesn’t seem so large Erlang is not known for raw CPU speed, but I’m positive it could work efficiently with that size, assuming proper data structures and algorithms are chosen. For some larger scale, I’d consider partitioning the world, then on every tick handle each partition separately. This would still keep synchronism (and thus consistency) while introducing some potential for parallelism.
Standard disclaimers apply of course It seems to me the problem is still a moving target, so it’s hard for me to identify with it its nuances. That said, single-process-world would be the road I’d explore.
It’s worth mentioning that Torben Hoffmann did an everything-as-a-world take on Conway’s game of life. You might find the video useful if you decide to take that approach.
Best of luck!
4
JEG2
Author of Designing Elixir Systems with OTP
Just to be clear, I totally respect the value of a single process approach. My reasoning for doing this exercise is that a simulation allows you to see the processes moving around. I’m using it as a teaching tool.
0
gregvaughn
I’ll add one more point here that I had meant to mention earlier in the thread. Francesco Caesarini’s talk from the first ElixirConf was great. It discussed a lot about scalability bottlenecks. He mentioned at one point that you should use processes for each “concurrent activity” in your system. At the time that was vague to me, but I’ve come to understand it better and embrace it myself. If you take this approach, then there is no reason at all to have the cells of the pond be processes. The critters – sure, but not the pond cells.
If you use processes for the wrong sorts of things, they become bottlenecks. I understand the value of “MOAR PROCESSES” as an educational tool, however I caution you from letting students go away with the idea that is the best way to scale a system (without an analysis of what the concurrent activities are, that is).
2
terakilobyte
I’m still pretty new to programming and especially Elixir, but I think I’d start this off with just lily pads as processes with a world process over it.
They can have 4 possible states: empty, occupied by turtle and has neighbors open, occupied by frog and has neighbors, occupied but locked(ratio around it can never change or no open pads within range).
From the world process pulse an update call where each pad determines if the resident will move. When the pads report back, the movement happens as a message from the world process to each pad that will have a state change.
The overall world picture could be kept in a table, allowing asynchronous reads from the pads and used by the world to restart a pad with correct state.
As the program runs pads that will never change could let the world process know and then be skipped on subsequent pulses.
0
JEG2
Author of Designing Elixir Systems with OTP
Point taken. I’ll be careful.
My current solution has a lot less processes than some are recommending here. 
0
JEG2
Author of Designing Elixir Systems with OTP