Some things that can lead to poor NLW performance:
* Having lots of agents
* Having lots of plots
* Having lots of… anything
o Someone once said, “Less is more.” Another person once said,
“More is more.” I think both sides make some pretty good
points. I don’t really know what “less is more” /means/, but if
it makes your model better, I highly encourage you to follow
that policy.
* Making a lot of tiny movements when a single one would suffice (e.g.
|ask turtle 0 [ repeat 100 [ jump 1 ] ]| vs. |ask turtle 0 [ jump
100 ]|)
o The reason for this being that NLW generates update objects for
each drawable change in model state. Serializing lots of
updates and then reading and applying them to draw the new world
state… turns out to be somewhat costly in terms of performance
(though great in many other regards).
* Checking equality a lot (e.g. |<=|, |>=|, |=|, |!=|)
o The NLW equality procedure is a total CPU hog, and I hate it,
and I think I can fix it to not be so awful, but I’ll need some
time on that
* Making a lot of RNG draws (e.g. calling |ask| or |n-of| a bunch)
* Standard CS optimization stuff (e.g. O(n^2) algorithms, using the
wrong data structure for the task at hand, or iterating over the
same collection for the same information many, many times, etc.)
The model isn't openly available in this mailing list thread, but David
sent me a copy, and I noticed a few things. Namely, it initially sets
|pcolor|s on a bunch of patches, and then almost never changes the
|pcolor|s, but, several times per tick, calls things like |count
(patches with [pcolor = yellow or pcolor = dark-green])|. This behavior
is computationally costly, and it turned out to be unnecessary to
recompute those patchsets so often, so I just cached the yellow patches
and green patches in variables, and it resulted in a pretty noticeable
speedup.
It looked to me like the number of patches was artificially reduced so
as to keep performance under control, and that was a step in the right
direction, but I think the important thing to keep in mind is that
repeatedly recomputing those patchsets is going to be costly no matter
how many patches you have (assuming that number is greater than 0).
Ultimately, though, in the original model, equality-checking and patch
variable lookups were the blaring klaxons that made themselves known in
the profiler results (eating up close to 40% of the CPU with just those
two things). Caching the patchsets helped to eliminate a lot of those
lookups and equality checks, but I suspected that an even greater
performance boost could be gotten by, instead of doing branching logic
by asking patches things like |if pcolor = yellow or pcolor = green [
... ]|, skipping the equality-checking on |pcolor| and using patch-level
booleans for |green?|, |brown?| and |yellow?|. This isn’t /elegant/,
per se, but I suspected that it would be faster than looking up |pcolor|
repeatedly and running equality checks on it.
Having implemented that change in the model, indeed, equality-checking
went from eating up 33% of CPU in the original model, to 19% in the
version with the “cached patchsets” version, and 0.5% in final version.
Average-case results for running the model for 100 ticks:
* Original: 28s
* Just caching patchsets: 10.6s
* Both optimizations: 6.6s
The moral of the story: Death to equality-checking.
On 07/15/2015 01:21 PM, David Quigley wrote:
I need some help with improving speed for Netlogo Web models. Any
suggestions? Details below.
We're working on a project to build simulations for HS Biology
lessons. Students are using these simulations in the classroom in a
manner similar to a typical experimental process. The "Wolf Sheep
Predation" sample model is very similar to one of our models, though
many of the others are more complex (though of a similar structure).
For these lessons, we need to strike a balance between robustness,
realism, and speed. Unfortunately, in tests with students in the
classroom, we found that the speed is a hindrance to completing the
task, especially for a complex model.
I'm using the Create Standalone tool to export my original Netlogo
simulations to the JS implementation and simply saving those files.
For my personal speed tests, I'm just running them locally.
The students are running the simulations on the Samsung Chromebook
(XE303C12-A01US) from the native Chrome web browser. The simulations
are hosted on our website so the students have access.
For ease of discussion, we'll simply talk about the Wolf/Sheep
Predation model for speed improvement tips.
What I've done:
- Ensured I only loop through each turtle once (previously I was
doing multiple iterations for each tick, and that was SLOW)
- Simplified the turtle behaviors as much as possible
- I have tried removing different behaviors one at a time to see
if any are responsible for significant slowness. Unfortunately, the
slowest pieces are the interactions between turtle breeds (e.g. wolves
eating sheep), which are very necessary for our models. I also need
models with more complex behavior than the wander pattern found in the
Wolf-Sheep Predation model.
- Reduced the number of patches/turtles as much as feasible
- Reducing the simulation space and the number of turtles involved
contributes heavily to a loss of robustness for the models. Simple
chance has a much greater impact when the number of agents is small,
leading the students to misinterpret the data.
What I've tried (and hasn't helped):
- Simplifying variables for random turtle behaviors
- For example, I have some simulations where the birth rate of
turtles should be based on the number of patches with a certain color
(i.e. number of food sources). I've tried making the birth rate
constant for testing purposes, but this doesn't have any improvement
over the improvements found from having fewer turtles.
- Changing the draw time (from continuous to on-tick). This has no
impact on speed in the web version.
Thoughts? Suggestions?
--
You received this message because you are subscribed to the Google
Groups "netlogo-devel" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"netlogo-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
