| Time |
Nick |
Message |
| 02:25 |
|
Noisytoot joined #minetest-dev |
| 02:34 |
|
SFENCE joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:46 |
|
YuGiOhJCJ joined #minetest-dev |
| 06:59 |
|
YuGiOhJCJ joined #minetest-dev |
| 07:02 |
|
v-rob joined #minetest-dev |
| 07:45 |
|
YuGiOhJCJ joined #minetest-dev |
| 07:47 |
|
SFENCE joined #minetest-dev |
| 10:52 |
|
TheCoffeMaker joined #minetest-dev |
| 11:50 |
|
appguru joined #minetest-dev |
| 11:52 |
MTDiscord |
<paradust> Is there any way to do minetest.get_biome_data in bulk? |
| 11:53 |
MTDiscord |
<paradust> Mineclonia calls this for every x,y,z as it generates the map |
| 11:54 |
MTDiscord |
<paradust> 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 |
<paradust> nice, thanks |
| 13:21 |
|
Lupercus joined #minetest-dev |
| 13:27 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<paradust> i don't think so |
| 13:59 |
|
TheCoffeMaker joined #minetest-dev |
| 14:00 |
pgimeno |
I believe textdomain is a gettext thing |
| 14:01 |
MTDiscord |
<paradust> hm. it's worth a try to disable jit though |
| 14:02 |
pgimeno |
@paradust remember the setting is per thread |
| 14:04 |
MTDiscord |
<paradust> 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 |
<paradust> I assume it would be enough to disable jit just for that function? which is on the main thread |
| 14:05 |
MTDiscord |
<paradust> 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 |
<paradust> pgimeno: that seems to have fixed it |
| 14:27 |
MTDiscord |
<paradust> I wonder if there's a way to reserve more memory for the jit |
| 14:43 |
MTDiscord |
<paradust> Was this a different issue? https://github.com/minetest/minetest/commit/af38bae57f4f0f77bf2c0cf029928567e554b60b |
| 15:15 |
|
SFENCE joined #minetest-dev |
| 15:33 |
|
SFENCE joined #minetest-dev |
| 15:34 |
|
SFENCE joined #minetest-dev |
| 15:45 |
|
SFENCE joined #minetest-dev |
| 15:50 |
|
SFENCE joined #minetest-dev |
| 15:54 |
|
SFENCE joined #minetest-dev |
| 16:02 |
|
SFENCE joined #minetest-dev |
| 16:04 |
|
SFENCE joined #minetest-dev |
| 16:05 |
|
SFENCE joined #minetest-dev |
| 16:16 |
|
TheCoffeMaker joined #minetest-dev |
| 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:15 |
|
loggingbot_ joined #minetest-dev |
| 17:15 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. https://dev.minetest.net/ https://irc.minetest.net/ https://github.com/minetest |
| 17:27 |
|
Desour joined #minetest-dev |
| 17:42 |
MTDiscord |
<paradust> 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 |
<paradust> this problem specifically https://github.com/LuaJIT/LuaJIT/issues/285 |
| 17:45 |
MTDiscord |
<paradust> 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 |
<paradust> 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 |
<paradust> 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 |
<paradust> not sure what you mean by affecting objects on the heap |
| 17:54 |
MTDiscord |
<paradust> 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 |
<paradust> 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 |
<paradust> 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 |
<paradust> 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 |
<paradust> 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:19 |
|
pgimeno joined #minetest-dev |
| 18:19 |
|
book` joined #minetest-dev |
| 18:19 |
|
Sokomine joined #minetest-dev |
| 18:19 |
|
hifi joined #minetest-dev |
| 18:26 |
MTDiscord |
<jordan4ibanez> That's how it goes sfan, duct tape on 15 solutions to fix 1 |
| 18:31 |
|
v-rob joined #minetest-dev |
| 18:43 |
MTDiscord |
<paradust> 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 |
<sfan5> 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 |
<grorp> sfan5: could you also mention vsync in the comment added by 7c033749d33f148a002bc44bee2b756f6bef0944? |
| 19:40 |
sfan5 |
sure |
| 19:45 |
MTDiscord |
<grorp> cool |
| 19:45 |
|
proller__ joined #minetest-dev |
| 20:11 |
|
SFENCE joined #minetest-dev |
| 20:56 |
|
proller joined #minetest-dev |
| 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:35 |
|
v-rob joined #minetest-dev |
| 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 |
<luatic> that sounds like a transitive include type of issue... |
| 22:14 |
MTDiscord |
<luatic> what editor do you use? can't your "intellisense" tell you where the abs is coming from? |
| 23:35 |
|
panwolfram joined #minetest-dev |
| 23:45 |
|
SFENCE joined #minetest-dev |
