Time Nick Message 11:52 MTDiscord Is there any way to do minetest.get_biome_data in bulk? 11:53 MTDiscord Mineclonia calls this for every x,y,z as it generates the map 11:54 MTDiscord I helped prettyful_lord diagnose why mineclonia was slow on the M1, and this is where it spends most its time. I'm guessing Lua-to-C-to-Lua could be more expensive on that platform. 12:00 sfan5 https://github.com/minetest/minetest/blame/master/doc/lua_api.md#L4941 what about this 12:01 sfan5 a bit sparsely documented but it sounds like it should do the same 12:02 MTDiscord nice, thanks 13:27 MTDiscord rubenwardy: re: textdomain comment ... isn't it possible for a single file to have multiple textdomains? It seems like it was intended that textdomain could be something other than just strictly == modname 13:27 rubenwardy No it's not possible 13:28 rubenwardy Actually worth verifying 13:31 MTDiscord There does seem to be a kind of underlying question we keep asking about whether the name of a thing should be based on the filesystem, or some internal configuration. We do it with mod name in mod.conf too, but then we made the opposite decision when it comes to game names and game.conf. 13:32 rubenwardy The game thing is just legacy, it would have been done if the name key wasn't already taken 13:51 MTDiscord We could have an "id" key (considering that we refer to "game id" in other places like world.mt and command line) 13:51 MTDiscord It would be nice to have some consistency, of course, but then we'd break our consistent inconsistency. 13:59 pgimeno @paradust https://love2d.org/forums/viewtopic.php?p=255853#p255853 may this be the issue on Mac? 13:59 MTDiscord i don't think so 14:00 pgimeno I believe textdomain is a gettext thing 14:01 MTDiscord hm. it's worth a try to disable jit though 14:02 pgimeno @paradust remember the setting is per thread 14:04 MTDiscord we determined that the time is being spent here: https://codeberg.org/mineclonia/mineclonia/src/branch/main/mods/MAPGEN/mcl_mapgen_core/init.lua#L258 14:04 MTDiscord I assume it would be enough to disable jit just for that function? which is on the main thread 14:05 MTDiscord if it is recompiling that block on every loop iteration, that would certainly explain it 14:07 pgimeno you can certainly do that, but the slowdown should affect everything, not just that function, it's worth to add a jit.off() at the beginning and checking what happens 14:27 MTDiscord pgimeno: that seems to have fixed it 14:27 MTDiscord I wonder if there's a way to reserve more memory for the jit 14:43 MTDiscord Was this a different issue? https://github.com/minetest/minetest/commit/af38bae57f4f0f77bf2c0cf029928567e554b60b 16:33 sfan5 pgimeno: huh didn't gc64 solve that? (re. love2d.org link) 16:34 sfan5 paradust: not sure if related but the linking flags were only needed for luajit 2.0 16:50 sfan5 rubenwardy: can I merge #14382? 16:50 ShadowBot https://github.com/minetest/minetest/issues/14382 -- [no squash] Android stuff by sfan5 17:42 MTDiscord sfan5: The problems look similar but definitely different. It appears the only solutions on offer are to either build a custom LuaJIT with image_base set (to move it away from everything else), or else disable the JIT on ARM. 17:43 sfan5 is this the 4GiB RAM limit you mean? 17:44 MTDiscord this problem specifically https://github.com/LuaJIT/LuaJIT/issues/285 17:45 MTDiscord the thread is a little confusing, but it ultimately becomes about the bug where luajit cannot generate code further than 2GB away from "lj_vm_exit_handler", which is a dynamically loaded symbol 17:46 MTDiscord and so it has a very limited range in which it can place code. And that range is almost immediately wiped out by malloc/new 17:51 sfan5 so this seems to affect all platforms but only affects JIT code and not objects on the heap 17:52 MTDiscord I think yes, it affects all platforms, but only on some platforms does lj_vm_exit_handler end up tightly packed next to where heap allocation starts 17:53 MTDiscord not sure what you mean by affecting objects on the heap 17:54 MTDiscord I assume luajit has no problem placing objects at any address. It's only because it needs to do relative jumps back to lj_vm_exit_handler that code placement is a problem. 17:54 sfan5 the problem gc64 solved (and the problem i have generally heard of in the context of MT) is that luajit could only use either 31 or 32 bits for pointers to lua objects so you would quickly run out of virtual address space despite having enough physical memory available 17:54 sfan5 that's what I mean 17:54 sfan5 > but only on some platforms does lj_vm_exit_handler end up tightly packed next to where heap allocation starts 17:55 sfan5 that would clear my skepticism on how this issue could possibly go unsolved for so long if it affects windows or linux x64 17:55 sfan5 (which are main platforms used by companies for thier workloads etc. so either mike pall would prioritize fixing it or eventually someone would sponsor him to do it) 18:08 MTDiscord It seems to primarily affect ARM64, Android and Apple Silicon. There's a mention of x64, but i'm not sure that's actually the same issue 18:09 sfan5 so is there any good way to tell when this is happening? checking the process maps? tracing? 18:09 MTDiscord yea, it should show up in tracing 18:10 sfan5 LJ_TARGET_JUMPRANGE is 2^27 on arm64 so that'd mean luajit can't jit more than 128MB of code, certainly bad 18:10 sfan5 it's 2GB on x64, probably why nobody cares about this otherwise 18:11 MTDiscord yikes 18:13 sfan5 but surely the easiest fix for this is replacing an ADRP/ADRL with more instructions that manually compute a bigger offset? 18:14 MTDiscord yup: https://github.com/LuaJIT/LuaJIT/issues/285#issuecomment-285194907 18:16 sfan5 its weird to see people posting patches implementing the trampoline solution when that should be much simpler 18:26 MTDiscord That's how it goes sfan, duct tape on 15 solutions to fix 1 18:43 MTDiscord sfan5: could be there's not an extra register free for doing a BR 18:50 sfan5 i could try to find out if I knew where to look 18:50 pgimeno pgimeno: huh didn't gc64 solve that? (re. love2d.org link) 18:50 pgimeno no, unrelated 19:32 sfan5 merging #14405, #14378 in 10m 19:32 ShadowBot https://github.com/minetest/minetest/issues/14405 -- [no sq] Use newer IrrlichtMt by sfan5 19:32 ShadowBot https://github.com/minetest/minetest/issues/14378 -- Change how max_lag is calculated and reported by sfan5 19:39 MTDiscord sfan5: could you also mention vsync in the comment added by 7c033749d33f148a002bc44bee2b756f6bef0944? 19:40 sfan5 sure 19:45 MTDiscord cool 21:00 sfan5 planning to push https://github.com/minetest/minetest/commit/f5126e71108c04a2a394c5c88f533acc48798e3e if build passes 21:01 sfan5 why such a hurry? -> float f; abs(f) resolving to abs(int) instead of abs(float) seems to be new after the irrlichtmt update 21:48 pgimeno that must be breaking a lot of stuff then 21:50 sfan5 i dont get how abs(float) could have worked before anyway, we don't have "using namespace std;" or similar 21:50 sfan5 ¯\_(ツ)_/¯ 22:13 MTDiscord that sounds like a transitive include type of issue... 22:14 MTDiscord what editor do you use? can't your "intellisense" tell you where the abs is coming from?