performance - 优化 Netlogo 代码 - 每次运行的刻度太多？

Question

我想优化我的 netlogo 代码，并通过使用探查器扩展来跟踪瓶颈来做到这一点。此外，我在 headless 模式下运行我的模型，我提供了 2 GB RAM (-Xmx2048m)，并且有 2601 个补丁和大约 100-1500 个代理。我用time extension用于网络 Logo 。

现在，我有四个一般性问题。

1) 最好在模型(.nlogo 中)或BehaviorSearch(我在 headless 模式下与 .xml 文件一起使用)中编写退出条件(见下文)，或者没有什么区别？

模型内:

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

在行为空间内:

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

2) 我认为我可以通过优化代码来优化我的模型，使其运行得更快(参见我在模拟运行 6.5 小时后拍摄的屏幕截图):

但是，我越来越怀疑我在模型中缩放每个刻度以代表一天的方式(这实际上是一个关键元素)。我开始怀疑，因为我的模型中可能的最大时间跨度是 472 年。这将使模型的完整运行需要 172280 个刻度!考虑到我所拥有的性能，我不知道每次运行 Netlogo 时有很多刻度是否会成为一个巨大的瓶颈(请参阅上面的分析器输出)。

3) 添加 gpu extension 是否合理？进入模型以获得更快的速度还是实现起来并不容易？我问是因为我没有找到任何相关的文档。这种可能性(？)似乎在很大程度上被忽略了，参见this thread .

4) 这有意义吗？技术上是否可以在 RAM 中运行 netlogo-headless？您可能已经在这些问题上看到我对这些技术细节并不真正坚定，但对可能性感兴趣。

编辑: 在下面您可以找到请求的orientation 代码片段:

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

这部分代码已成为最近讨论的主题 here在 stackoverflow 上。

Answer 1

感谢您发布代码!幸运的是，它可以被优化!带有 [pcolor = green] 的补丁将迭代每个补丁，检查哪些是绿色的。 ... in-radius 3 将迭代所有绿色的，检查哪些距离足够近。但是，如果您首先在半径 3 内进行补丁，NetLogo 可以准确计算出哪些补丁位于该半径内，而无需检查所有补丁。然后，需要检查颜色的色 block 也少得多。通过交换它们的顺序，我获得了近 10 倍的加速:

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

查询补丁时必须小心，因为通常会有很多补丁。在其他检查之前进行in-radius检查会有很大帮助，因为NetLogo可以优化patches in-radius。

快速回答您的问题:

1. 应该没有什么区别，但我喜欢把我的放在BehaviorSpace 中。
2. 更多蜱虫本身并不一定是坏事。例如，请参阅伊辛。
3. 还没用过，但如果它有效的话我会感到非常惊讶。最后一次提交是在 4 年前，也就是许多 NetLogo 版本之前。也就是说，如果你能成功，我很想知道!
4. 不太清楚您的意思，但 NetLogo 完全运行 RAM。也就是说，如果 NetLogo 和同时运行的其他程序使用的内存多于 RAM，则操作系统将 offload memory onto the hard drive ，在某些情况下可能会导致严重的减速。这不太可能，但对于超大型模型(你的不是)绝对可能是一个问题。您的计算机有多少内存？

最后，确保您让BehaviorSpace 在您的计算机上为每个核心使用一个线程。这是默认设置，因此除非您设置线程数，否则应该会发生这种情况。可以肯定的是，运行 NetLogo 时每个核心都应该接近 100%。您的操作系统事件监视器应该能够为您提供此信息。如果这种情况没有发生(也许 NetLogo 错误地检测了核心数量)，您可以尝试显式设置 --threads 选项。