Оптимизация кода Netlogo - слишком много тиков при каждом запуске?

Question

Я хотел был бы оптимизировать мой netlogo-код и сделал это, используя расширение профилировщика для отслеживания узких мест. Кроме того, я запускаю свою модель в режиме безголовного режима, которую я даю 2 ГБ ОЗУ (-Xmx2048m), и имеет 2601 патчей со 100-1500 агентами. Я использую time extension для netlogo.

Теперь у меня есть четыре общих вопроса.

1) Что лучше записать условия выхода (см внизу) в рамках модели (в .nlogo) или в BehaviorSearch (который я использую с файлом XML-в обезглавленный режиме), или делает это не в чем разница?

В модели:

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

В BehaviorSpace:

<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) Будет ли это иметь смысл, и было бы технически возможно запустить netlogo-headless в ОЗУ? Возможно, вы уже видите по этим вопросам, что я не очень уверен в таких технических проблемах, но интересуюсь возможностями.

Edit: вниз ниже вы найдете фрагмент кода 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

Благодарим за отправку кода! К счастью, его можно оптимизировать! patches with [pcolor = green] будет проходить через каждый патч, проверяя, какие зеленые. ... in-radius 3 будет перебирать все зеленые, проверяя, какие из них достаточно близки. Однако, если вы сначала сделаете patches in-radius 3, NetLogo может точно вычислить, какие патчи находятся в этом радиусе, не проверяя их все. Тогда есть еще меньше патчей, чтобы проверить цвет.Я получил почти 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. Больше клещей не обязательно плохо. См. Например, Ising.
3. Не использовали его, но я был бы очень удивлен, если он сработает. Последняя фиксация была более 4 лет назад, и это много версий NetLogo назад. Тем не менее, если вы его заработаете, я бы с удовольствием узнал!
4. Не совсем уверен, что вы имеете в виду, но NetLogo запускает полностью RAM. Тем не менее, если NetLogo и другие программы, работающие в то же время, используют больше памяти, чем у вас есть ОЗУ, ОС будет offload memory onto the hard drive, что может привести к серьезному замедлению в некоторых случаях. Это маловероятно, но, безусловно, может быть проблемой для супер огромных моделей (которых у вас нет). Сколько оперативной памяти имеет ваш компьютер?

Наконец, убедитесь, что вы позволяете BehaviorSpace использовать один поток на ядро ​​на вашем компьютере. Это значение по умолчанию, поэтому, если вы не задаете количество потоков, это должно происходить. Разумеется, каждое ядро ​​должно быть близко к 100% при запуске NetLogo. Монитор активности вашей ОС должен быть в состоянии предоставить вам эту информацию. Если этого не происходит (возможно, NetLogo неправильно обнаруживает количество ядер), вы можете попробовать установить опцию --threads явно.