NetLogo
feature: sparse/lightweight internal representation of agents
an old 2011 writeup of mine:
An internal technical improvement that will permit the addition of a variety of user-visible improvements is changing the engine's internal representation of agents, including patches in the patch grid, to use a sparser, more lightweight representation so that adding agent variables and using large numbers of agents will become more practical.
We propose to develop new underlying data structures such that:
- Worlds with large numbers of patches will be cheap to create and will use memory proportional only to the amount of informationactually stored in the patches, rather than directly proportional to the patch count.
- Unbounded patch grids, in which turtles can wander an arbitrary distance from the origin without ever encountering a world boundary, will become possible for the first time.
- New properties can be added to turtles and patches without increasing memory usage for models in which properties are not used. For example, users often ask for control over the font size of labels attached to turtles, but so far we haven't added that because it would decrease speed and increase memory usage for all models.
I think these are very good ideas, I was waiting for something like that since a few years (and am now feeling a real need now that I am doing serious research and still use NetLogo for my first simulations drafts, this would allow me to avoid re-implementing in MatLab or something like that just for simulating with a big number of elements).
What is the current implementation for agents, simple classes? Akka Actors seem to be the obvious implementation in the case of agents?
currently they are plain Java classes.
NetLogo's programming model is deterministic, hence the engine is single-threaded. rethinking the programming model to allow real concurrency, with actors or something as the underlying implementation, would be a Ph.D-level project, and would likely make an individual agent's footprint larger, not smaller, so I think it's orthogonal to this ticket.
If agents were something like prototype-based, it would be much more lightweight. Take for example, color. If you have 10,000 patches with the same color, only one of them will include the actual color(of course, the runtime can increase because you have to trace back the actual value, but if Firefox and Chrome could do it fast in JS, why not us).
Another idea (although similar to the above) is to imitate what happens when you fork a process. The address space remains shared between the parent and child, and certain pages will get separated only when they are changed in either parent or child. To take the analogy back to NetLogo, agents are processes, agent variables are pages (some properties might be grouped for one page, for example xcor and ycor) and you can't create an agent out of the blue like you can't create a process (this needs some thought for crt), you rather 'fork' agents.
Worlds with large numbers of patches will be cheap to create and will use memory proportional only to the amount of information actually stored in the patches, rather than directly proportional to the patch count.
relates to: #686 wherein long narrow worlds cannot be created even though they have no more or fewer patches (and thus no more or less information) than wider / fatter worlds
New properties can be added to turtles and patches without increasing memory usage for models in which properties are not used. For example, users often ask for control over the font size of labels attached to turtles, but so far we haven't added that because it would decrease speed and increase memory usage for all models.
relates to: #548 wherein we cannot add a line-thickness property without it using inordinate amounts of memory.
#686 is related in the sense that it is a major contributor to memory usage that depends on world size.
I've updated my comment to clarify the relationship between this and the other bugs.