CODEWITHSUNDEEP
performanceoptimizationtimenetlogo
Til Hund
Til Hund

Reputation: 1671

Optimizing Netlogo Code - too much ticks each run?

I would like to optimize my netlogo code and did this by using the profiler extension to track down bottlenecks. Furthermore, I am running my model in headless mode, which I give 2 GB of RAM (-Xmx2048m), and have 2601 patches with around 100-1500 agents. I use the time extension for netlogo.

Now, I have four general questions.

1) Is it better to write the exit conditions (see down below) within the model (in .nlogo) or in BehaviorSearch (which I use with the .xml file in headless mode), or does it not make any difference?

Within the Model:

if count turtles = 0 [ stop ]
if time:is-equal dt (time:create "1722-04-05") [ stop ] ;using the time extension

Within BehaviorSpace:

<exitCondition>count turtles = 0</exitCondition>
<exitCondition>time:is-equal dt (time:create "1722-04-05")</exitCondition>

2) I think I could optimize my model to the extent that it hardly runs faster by optimizing the code (see screenshot which I took after 6,5 hours of simulations running):

screenshot

But, I am getting more and more doubtful about the way I scale each tick to represent a day in my model (which is actually a crucial element). I am getting doubtful because the maximal time span possible in my model would be 472 years. That would make 172280 ticks for a complete run of the model! I do not know if having a lot of ticks per run in Netlogo can be a huge bottleneck given the performance I have (see profiler output above).

3) Would it be reasonable to add the gpu extension into the model to gain more speed or is it not so easy to implement that? I ask because I have not found any documentation about that. This possibility(?) seems to be largely ignored, see this thread.

4) Would it make sense and would it be technically possible to run netlogo-headless in RAM? You might already see upon these questions that I am not really firm about such technicalities but interested about the possibilities.

Edit: Down below you find the code snippet of orientation as requested:

to orientation
   ifelse (energy < 4) [ ;if hungry
     let nearest-resource min-one-of (patches with [pcolor = green] in-radius 3 ) [ distance myself ] ;check distance between you and nearest resource (3 fields 360 degrees view)
     if is-patch? nearest-resource [ ;if green patch exist at all
     move-to nearest-resource ]
    ]
   [ rt random-float 30 - random-float 30 ] ;otherwise just walk randomly around
end

This part of the code has been subject of a recent discussion here on stackoverflow.

Upvotes: 2

Views: 723

Answers (1)

Bryan Head
Bryan Head

Reputation: 12580

Thanks for posting your code! Luckily, it can be optimized! patches with [pcolor = green] will iterate through every single patch, checking to see which are green. ... in-radius 3 will iterate through all the green ones, checking to see which are close enough. However, if you do patches in-radius 3 first, NetLogo can compute exactly which patches are in that radius without having to check them all. Then, there are far fewer patches to check the color of as well. I got an almost 10x speedup from swapping the order of those:

to orientation
   ifelse (energy < 4) [ ;if hungry
     let nearest-resource min-one-of (patches in-radius 3 with [pcolor = green] ) [ distance myself ] ;check distance between you and nearest resource (3 fields 360 degrees view)
     if is-patch? nearest-resource [ ;if green patch exist at all
     move-to nearest-resource ]
    ]
   [ rt random-float 30 - random-float 30 ] ;otherwise just walk randomly around
end

You have to be careful with querying on patches since there are typically a lot of patches. Doing in-radius checks before other checks can help a lot, since NetLogo can optimize patches in-radius.

Quick answers to your questions:

  1. Shouldn't make a difference, but I like to put mine in BehaviorSpace.
  2. More ticks alone is not necessarily bad. See Ising for example.
  3. Haven't used it, but I would be really surprised if it worked. The last commit was over 4 years ago, which is many NetLogo versions ago. That said, if you get it working, I'd love to know!
  4. Not exactly sure what you mean, but NetLogo runs entirely RAM. That said, if NetLogo and other programs running at the same time are using more memory than you have RAM, the OS will offload memory onto the hard drive, which can cause a serious slowdown in some cases. This is unlikely, but can definitely be a concern with super huge models (which yours is not). How much RAM does your computer have?

Finally, make sure you're letting BehaviorSpace use one thread per core on your machine. This is the default, so unless you're setting the number of threads, it should be happening. To be sure, each core should be close to 100% when running NetLogo. Your OSes activity monitor should be able to give you this information. If this is not happening (perhaps NetLogo is incorrectly detecting the number of cores), you can try setting the --threads option explicitly.

Upvotes: 2

Related Questions