| Time |
Nick |
Message |
| 00:10 |
|
imi_ joined #luanti-dev |
| 03:33 |
|
SFENCE_arch joined #luanti-dev |
| 04:42 |
|
mrcheese joined #luanti-dev |
| 05:00 |
|
MTDiscord joined #luanti-dev |
| 05:29 |
|
SFENCE joined #luanti-dev |
| 05:55 |
|
lhofhansl joined #luanti-dev |
| 06:03 |
lhofhansl |
Hi all... Do we still need the ordered (fair) mutex added by #15151? |
| 06:03 |
lhofhansl |
I was looking into why loading a map from disk takes longer with multiple emerge thread. I tracked it back (in part) to the use of ordered_mutex for the env-lock. |
| 06:03 |
lhofhansl |
When I change that back to std::mutex, the load speed is pretty much identical between 1 emerge thread and 4 or 8 merge threads. |
| 06:03 |
lhofhansl |
Whereas with ordered_mutex 4 emerge thread slow the overall load time by about 16% and 8 thread slow loading by about 26%. |
| 06:03 |
lhofhansl |
We added ordered_mutex for a reason. Is that reason still valid? |
| 06:03 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/15151 -- [no squash] Divorce map database locking from env lock by sfan5 |
| 06:04 |
lhofhansl |
sfan5: FYI |
| 06:14 |
|
SFENCE joined #luanti-dev |
| 06:29 |
|
SFENCE joined #luanti-dev |
| 06:35 |
|
SFENCE joined #luanti-dev |
| 08:15 |
|
fluxionary joined #luanti-dev |
| 08:19 |
|
YuGiOhJCJ joined #luanti-dev |
| 09:19 |
sfan5 |
~tell lhofhansl it exists because of this https://github.com/luanti-org/luanti/blob/87669f982c9d998ca68c86bb50fdb66a8a75fb87/src/server.cpp#L1157-L1172 |
| 09:19 |
ShadowBot |
sfan5: OK. |
| 09:28 |
sfan5 |
~tell lhofhansl in particular the testing in #15151 (see also https://irc.luanti.org/minetest-dev/2024-09-25) needs to be repeated so this doesn't kill performance in Warr1024's case again |
| 09:28 |
ShadowBot |
sfan5: OK. |
| 10:08 |
|
imi joined #luanti-dev |
| 11:56 |
|
Sharpman joined #luanti-dev |
| 13:57 |
|
SFENCE_arch joined #luanti-dev |
| 15:37 |
sfan5 |
rubenwardy: do you manually merge the weblate commits to the website or how? |
| 15:37 |
sfan5 |
says " Push is turned off for Luanti/Website. " if I try it from weblate itself |
| 15:37 |
rubenwardy |
manually by git pull weblate master |
| 15:37 |
rubenwardy |
but it would be good to implement push |
| 15:38 |
rubenwardy |
would have to look how to do it with github, I forget |
| 16:05 |
|
SFENCE joined #luanti-dev |
| 17:27 |
|
lhofhansl joined #luanti-dev |
| 17:36 |
lhofhansl |
Does the yielding require fair locking? The yielding happens without the lock held (obviously), so at that time mostly (only?) the emerge threads compete for the lock. In that case at least, I do not see an advantage in fair locking. When we do not yield it's perhaps more interesting. Since the emerge threads need to lock twice to make progress, they'd be more vulnerable to waiting when the main thread acquires the lock in th |
| 17:36 |
lhofhansl |
e. But I am not sure that justifies the fair locking. |
| 17:37 |
sfan5 |
I don't know. needs to be tested. |
| 17:38 |
lhofhansl |
I briefly looked into read-write locks, but that'd require some significant refactoring to separate read and write access in the code. |
| 17:39 |
lhofhansl |
Should I file a draft-PR that reverts back to std::mutex, and then we can ask Warr1024 to give it a spin when they get time...? |
| 17:41 |
sfan5 |
sure |
| 18:01 |
lhofhansl |
#16739 |
| 18:01 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/16739 -- Use std::mutex for the env lock (instead of ordered_mutex), for testing. by lhofhansl |
| 18:01 |
lhofhansl |
Warr1024: FYI in case you are around. |
| 19:05 |
|
SFENCE joined #luanti-dev |
| 19:13 |
|
SFENCE joined #luanti-dev |
| 19:45 |
|
SFENCE joined #luanti-dev |
| 20:03 |
|
SFENCE joined #luanti-dev |
| 20:16 |
|
SFENCE joined #luanti-dev |
| 20:46 |
|
SFENCE joined #luanti-dev |
| 20:50 |
|
fluxionary joined #luanti-dev |
| 21:13 |
|
SFENCE joined #luanti-dev |
| 22:02 |
|
mrcheese joined #luanti-dev |
| 22:30 |
|
SFENCE joined #luanti-dev |
| 22:35 |
MTDiscord |
<wsor4035> @Warr1024 |
| 23:33 |
|
panwolfram joined #luanti-dev |
| 23:35 |
|
mrcheese_ joined #luanti-dev |
