ABM, optimization and dynamic_liquid [core dev wanted! ;)]

cronvel
Member
 
Posts: 18
Joined: Fri Jan 11, 2019 16:50
GitHub: cronvel

ABM, optimization and dynamic_liquid [core dev wanted! ;)]

by cronvel » Sat Nov 30, 2019 08:30

Hello,
Like many have already asked, I need some clarification on how ABM run in the engine side, and how to make them efficient when modding.

Context: I'm really fan of @FaceDeer mode dynamic_liquid, but as a side-effect, it produces nasty lags. I already tried few optimizations, but it didn't do much (in fact, I see no difference at all). Since I'm addict to this mod, I just can't turn it off, the world seems so boring without it...

The questions (core dev wanted!):
  • What have the most impact on the performance?
    • The number of node having ABM even if the ABM actually change nothing (exit condition triggered)?
    • The number of actual changes produced by ABM?
    • Rather than the number of node, the number of map block that have changed? (i.e. when a node change, is that only node that is transferred to clients, or the whole block it is part of)
    • Is the lag server-side (internal computing) or due to client-server communications (lot of things to send over the network to synchronize clients)?
  • Why dynamic_liquid is so intensive for the server (the mod is already optimized), while at the same time, flowing liquid (which is an engine-stuff) does not need much resource? To me, making flowing liquid is even more complicated than dynamic_liquid behavior, and flowing liquid is a sort of ABM (even if it's technically not). Why flowing is so much optimized compared to a an optimized Lua ABM?
  • Is there any chance/plan that some kind of dynamic liquid behavior could be implemented directly inside the engine?

What I have done to optimize dynamic_liquid (without success): To optimize this mod even better that it was, I have added another node type, that I named block_water. An ABM with a very high delay (20 seconds) turns source_water into block_water if the source_water have no air or flowing_water as its neighbors. Block_water does not have the dynamic ABM. Once in a while (every 30 seconds), I check if those block_water have air or source_water nearby to turn them again into source_water. The idea was to reduce the number of dynamic candidate. For ocean, it probably remove 80% of dynamic node. Alas, it does not do much improvements...
Last edited by cronvel on Sun Dec 01, 2019 09:17, edited 1 time in total.
 

User avatar
Krock
Developer
 
Posts: 4409
Joined: Thu Oct 03, 2013 07:48
Location: Switzerland
GitHub: SmallJoker

Re: ABM, optimization and dynamic_liquid [core dev wanted! ;

by Krock » Sat Nov 30, 2019 13:49

So you summon the witch who knows about the black magic spells... alright.

cronvel wrote:but as a side-effect, it produces nasty lags.

In which cases does it lag really hard? ABMs are run each second unless you tweak the settings. Same for liquid updates. You can set both to a lower value to get a faster "flow".


cronvel wrote:[*]What have the most impact on the performance?

    A few basics for understanding what's happening in the code (entire function).
    1) There's some node caching, but the final effect is negligible (why? see below).
    2) ABMHandler::apply is called for each active mapblock (next to players, usually)
    3) Each node is checked whether it has ABMs assigned to it (3x for-loop)
    4) Each ABM is run and checked for its probability (chance value) and neighbour nodes (3x3x3-1 checks)
    5) If everything's fine, the Lua callback from the ABM definition is run

    So in the worst case there are 1 + 3 + 1 + 3 loops that have to be executed each second. In a test world this takes ~60us to execute it each second. See F6 profiler "SEnv: modify in blocks avg per interval" (average value).

    What likely matters here is the amount of code executed in the Lua callback.

    Things that make ABMs faster (top = most effective)
    • Either use LBMs or node timers to replace ABMs (saves up to 8 loops)
    • Decrease active_block_range to 2 (saves 98 active mapblocks)
    • Increased "chance" or "interval" (saves up to 3 loops, skipped neighbour lookup)
    • Slim "action" callback Lua function (saves time for executed ABMs)
    • Less node replacements in Lua (saves client mapblock mesh creation time and server-side map saving)

    No, neither network nor client lag have an impact on ABM execution.
    Look, I programmed a bug for you. >> Mod Search Engine << - Mods by Krock - DuckDuckGo mod search bang: !mtmod <keyword here>
     

    cronvel
    Member
     
    Posts: 18
    Joined: Fri Jan 11, 2019 16:50
    GitHub: cronvel

    Re: ABM, optimization and dynamic_liquid [core dev wanted! ;

    by cronvel » Sun Dec 01, 2019 09:37

    Thanks for the reply ;)

    Also I'm still surprise that flowing liquid is so easily handled by the engine when dynamic liquid cause so much computing. I was told that Lua was really fast (something like 50% of C, which should be good enough).
    Also, is there any chance something like dynamic liquid make it to the engine?
     

    User avatar
    Krock
    Developer
     
    Posts: 4409
    Joined: Thu Oct 03, 2013 07:48
    Location: Switzerland
    GitHub: SmallJoker

    Re: ABM, optimization and dynamic_liquid [core dev wanted! ;

    by Krock » Sun Dec 01, 2019 13:23

    cronvel wrote:Also, is there any chance something like dynamic liquid make it to the engine?


    There was a finite water and rudimentary weather system in 0.4.7. It was removed later on due to lack of maintenance, API functions and various bugs. Some water functionalities could be added to the engine, but these would unlikely be accepted on public servers due to heavy mapblock modifications (database writes) and rather slow fluid calculations.
    Look, I programmed a bug for you. >> Mod Search Engine << - Mods by Krock - DuckDuckGo mod search bang: !mtmod <keyword here>
     


    Return to Modding Discussion



    Who is online

    Users browsing this forum: No registered users and 1 guest