| Time |
Nick |
Message |
| 01:00 |
|
shadowzone joined #minetest-dev |
| 01:03 |
|
twoelk joined #minetest-dev |
| 01:06 |
|
Nate123 joined #minetest-dev |
| 01:29 |
sofar |
odd mod question. I'm trying to create a nice static data table and put it in a sepaate lua file so it's easy to edit |
| 01:30 |
sofar |
but after dofile() it's not known outside that one lua file? |
| 01:30 |
ShadowNinja |
sofar: What's the format of the file? Also, more of a #minetest question. |
| 01:31 |
sofar |
it's just lua for a mod |
| 01:31 |
VanessaE |
declare a table like, mymod = {}, then in the file that's dofile()'d, assign the table contents to mymod.sometable |
| 01:31 |
VanessaE |
declare that initial table in your init.lua I mean |
| 01:31 |
sofar |
yeah, ok, that will work |
| 01:50 |
|
Fadi_ joined #minetest-dev |
| 01:50 |
Fadi_ |
is there a way yo make the breath bar always appear? |
| 01:50 |
Fadi_ |
oh wait this is the wrong channel, sorry |
| 02:33 |
est31 |
Hello, attempting to start MT, getting error: /builtin/mainmenu/tab_settings.lua:169: attempt to concatenate field 'friendly_name' (a nil value) |
| 02:36 |
|
MichaelRpdx joined #minetest-dev |
| 02:50 |
|
MichaelRpdx joined #minetest-dev |
| 02:52 |
|
Wayward_One joined #minetest-dev |
| 02:54 |
est31 |
seems to be because my gfx drv sux |
| 02:54 |
est31 |
gonna shutdown -r now |
| 02:55 |
hmmmm |
nope |
| 02:56 |
|
kaeza joined #minetest-dev |
| 02:56 |
hmmmm |
it sounds like a bug with what i wrote recently |
| 02:57 |
est31 |
git pull? |
| 02:57 |
hmmmm |
what..? |
| 02:57 |
est31 |
did you fix the bug or just file it? |
| 02:57 |
hmmmm |
i did neither |
| 02:58 |
est31 |
what does "with what I wrote" mean then= |
| 02:58 |
est31 |
? |
| 02:58 |
hmmmm |
a commit i wrote |
| 02:58 |
hmmmm |
could it be that you recently updated your repository and tried running the executable without recompiling it? |
| 02:59 |
hmmmm |
i think that's much more likely to be the problem |
| 03:00 |
est31 |
my HEAD is on Sat Jan 24 |
| 03:00 |
est31 |
but yes the version string != git commit |
| 03:01 |
hmmmm |
well it might be a smart idea to recompile your executable |
| 03:01 |
est31 |
doing right now |
| 03:01 |
est31 |
its blazingly fast with an SSD |
| 03:01 |
est31 |
60 secs |
| 03:02 |
est31 |
works thanks |
| 03:02 |
hmmmm |
problems like this occur when something changed with the builtin lua scripts that either use a new API or an API that had its interface changed |
| 03:02 |
est31 |
ah |
| 03:03 |
est31 |
yeah makes sense |
| 03:06 |
est31 |
works now |
| 03:20 |
hmmmm |
14:29 gregorycu Let's look at JMutex. I relied on JMutex and it appeared to work. But it does different things on different platforms. Using the standard library, and you get less varience |
| 03:20 |
hmmmm |
recursive mutexes are bad design and shouldn't be use. I don't quite understand what the reason is for not passing the new value to the callback though |
| 03:21 |
hmmmm |
be used* |
| 03:21 |
hmmmm |
switching to C++11 can gloss over your design problem, sure... |
| 03:30 |
|
Zeno` joined #minetest-dev |
| 04:00 |
|
Miner_48er joined #minetest-dev |
| 04:03 |
hmmmm |
hey guys, src/subgame.cpp, initializeWorld has sqlite3 hardcoded as what it writes to world.mt |
| 04:04 |
hmmmm |
didn't look, but i assume the server will only try to use the database it's been compiled to use.. this is sort of dumb |
| 04:06 |
hmmmm |
can somebody explain to me how the entire subgame system is supposed to work (i can see how it actually works) |
| 04:57 |
|
DFeniks joined #minetest-dev |
| 05:09 |
|
Fadi_ joined #minetest-dev |
| 05:35 |
|
OldCoder joined #minetest-dev |
| 05:46 |
|
selat joined #minetest-dev |
| 05:49 |
|
nore joined #minetest-dev |
| 05:54 |
|
NakedFury joined #minetest-dev |
| 05:55 |
|
chchjesus joined #minetest-dev |
| 05:55 |
|
chchjesus joined #minetest-dev |
| 06:02 |
|
jin_xi joined #minetest-dev |
| 06:38 |
VanessaE |
hmmmm: how do you mean, how subgames work? |
| 06:40 |
|
Hunterz joined #minetest-dev |
| 06:42 |
hmmmm |
from what it looks like, world.mt was supposed to supercede map_meta.txt??? |
| 06:42 |
hmmmm |
and map_meta.txt is this old, deprecated format |
| 06:45 |
VanessaE |
not that I know of; mostly it just dictates the game to use and the mods to use with the world, but when it comes to the latter, I skip that file and just put my mods in worlds/myworld/worldmods |
| 06:46 |
VanessaE |
(for servers that is -- it's a pain in the ass dealing with a text file when mere presence in a directory works just as well) |
| 07:13 |
|
ImQ009 joined #minetest-dev |
| 07:21 |
|
leat joined #minetest-dev |
| 07:37 |
hmmmm |
hm |
| 07:40 |
|
selat joined #minetest-dev |
| 07:51 |
hmmmm |
flowing liquid should draw a face on the underside if the material it's up against is solid |
| 08:09 |
|
selat joined #minetest-dev |
| 08:20 |
|
selat joined #minetest-dev |
| 08:37 |
|
gregorycu joined #minetest-dev |
| 08:41 |
|
kilbith joined #minetest-dev |
| 08:49 |
gregorycu |
hmmmm: |
| 08:49 |
gregorycu |
Hello |
| 08:49 |
gregorycu |
Zeno has suggested that you may be the man to get #2156 in |
| 08:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/2156 -- Optimise MapBlockMesh functions by gregorycu |
| 08:50 |
hmmmm |
ah this PR again |
| 08:50 |
hmmmm |
i thought that was taken care of... |
| 08:51 |
hmmmm |
can't you make ContentIgnoreNode static const if you initialize it with brackets? |
| 08:52 |
gregorycu |
How? |
| 08:52 |
gregorycu |
Nevermind |
| 08:52 |
hmmmm |
no I'm asking |
| 08:52 |
gregorycu |
Parentesis |
| 08:52 |
hmmmm |
I'm not 100% sure if you can |
| 08:53 |
gregorycu |
You may be able to, that was probably an oversight by me, give me a sec and I'll check out that branch |
| 08:53 |
hmmmm |
static const MapNode VoxelManipulator::ContentIgnoreNode = {CONTENT_IGNORE, 0, 0}; |
| 08:54 |
gregorycu |
static const MapNode VoxelManipulator::ContentIgnoreNode (MapNode(CONTENT_IGNORE, 0, 0)); // May also work |
| 08:54 |
gregorycu |
Let me have a play |
| 08:54 |
gregorycu |
Actually, you may be right |
| 08:54 |
gregorycu |
To be honest, I don't use brace initilisation much |
| 08:55 |
hmmmm |
it means something different though |
| 08:55 |
gregorycu |
What is what you've done? |
| 08:55 |
gregorycu |
that's brace initialisation yeah? |
| 08:56 |
hmmmm |
POD can be initialized by braces and it simply assigns the members whereas the former calls the constructor |
| 08:56 |
gregorycu |
Sorry, yeah, we've done different things |
| 08:56 |
hmmmm |
how that's optimized by the compiler.. i have no clue. i would expect it to be the same but i've been wrong before |
| 08:57 |
gregorycu |
MapNode is pod? |
| 08:57 |
hmmmm |
errm |
| 08:57 |
hmmmm |
actually no it's not POD, it's that classification that you need to be POD |
| 08:57 |
hmmmm |
forget what it's called.. i'd have to pull up the C++ standard |
| 08:58 |
hmmmm |
that would be POD as per C++11 |
| 08:59 |
gregorycu |
I've had severe trouble lately compiling and running code |
| 08:59 |
gregorycu |
I just got a bad alloc error |
| 08:59 |
gregorycu |
No idea what's happening |
| 09:03 |
gregorycu |
Yesterday, something = new Something(); and something was null |
| 09:03 |
gregorycu |
Like, wtf |
| 09:03 |
gregorycu |
How is that even possible |
| 09:04 |
est31 |
gregorycu: perhaps you have no free mem anymore? |
| 09:04 |
est31 |
that can happen |
| 09:05 |
gregorycu |
Don't you need to use no-throw new? |
| 09:05 |
est31 |
always check after new and malloc whether the pointer points to 0 |
| 09:06 |
est31 |
ok you are right, c++ actually throws an exception |
| 09:07 |
gregorycu |
It had me stumped |
| 09:11 |
gregorycu |
Still has me stumped |
| 09:39 |
|
ImQ009 joined #minetest-dev |
| 09:53 |
|
nrzkt joined #minetest-dev |
| 10:10 |
|
Megaf_ joined #minetest-dev |
| 10:14 |
|
DFeniks joined #minetest-dev |
| 10:14 |
|
Weedy joined #minetest-dev |
| 10:20 |
|
selat joined #minetest-dev |
| 10:24 |
|
Weedy joined #minetest-dev |
| 10:24 |
|
Weedy joined #minetest-dev |
| 10:25 |
|
alexxss joined #minetest-dev |
| 10:25 |
gregorycu |
Do we support collision with non-cube nodes? |
| 10:27 |
gregorycu |
Ahh doesn't matter, we support collision with non-nodse |
| 10:35 |
gregorycu |
I really hate touching any code that has anything to do with collision detection |
| 10:38 |
est31 |
As it seems, a bad data structure for getCraftRecipes causes unified inventory to load around 20 secs for dreambuilder. Only thing uniInv does is looping over all registered items and calling that function. When you add up the time spent in the function, you miss the overall time by ~100ms https://github.com/minetest/minetest/blob/70074800a207974a0c1383275186cefe6955f297/src/craftdef.cpp#L974 |
| 10:38 |
est31 |
getCraftRecipes is implemented as for(item i in items) { if(i.name == searched_name) {do_things}} |
| 10:39 |
est31 |
you should rather use a hashmap or something like that |
| 10:39 |
est31 |
I'm sure when you implement it with lua tables it runs 1000x faster |
| 10:39 |
est31 |
of100x |
| 10:39 |
est31 |
or* |
| 10:42 |
est31 |
also its weird that the list is iterated in reverse order |
| 10:42 |
gregorycu |
est31, if you give me a reproducable case (and an issue) I promise I'll look into making that faster |
| 10:42 |
gregorycu |
(Like, a lua script that calls that heaps) |
| 10:43 |
gregorycu |
It's not just if(i.name == searched_name), it's also a string modification |
| 10:44 |
est31 |
thats only for helping |
| 10:44 |
gregorycu |
But what is it doing? It's getting a list of CraftDefinitions that produce a given item? |
| 10:45 |
gregorycu |
Am I reading that right? |
| 10:45 |
nrzkt |
@ est31 sure, it's a bad search function |
| 10:45 |
est31 |
gregorycu: try starting a server instance of dreambuilder. Then comes a line "Server for ..." listening". immediately after that the unified inv starts that loop, and when its finished it outputs "Unified Inventory. inventory size: 1781 " |
| 10:46 |
est31 |
so the time between those two stdout lines is the time spent running through that loop |
| 10:46 |
gregorycu |
I don't know what dreambuilder or unified inv is... I don't really care... |
| 10:46 |
gregorycu |
But yeah, if there is a really slow lua method that could be sped up, that's what I care about :) |
| 10:46 |
est31 |
you want me to make a change to minimal development test? |
| 10:47 |
est31 |
(a test-purpose one) |
| 10:47 |
gregorycu |
Sure, and create an issue |
| 10:47 |
est31 |
It would be also nice if that function only outputs the last craft, like in here: https://github.com/minetest/minetest/blob/70074800a207974a0c1383275186cefe6955f297/src/craftdef.cpp#L944-L945 |
| 10:48 |
est31 |
last craft for the same inputs |
| 10:48 |
gregorycu |
I don't really do functional changes, just perf ones |
| 10:49 |
gregorycu |
But mention it in the issue if you think it's a bug |
| 10:49 |
gregorycu |
(Which I suspect it probably is) |
| 10:58 |
nrzkt |
what do you think about using two addition std::map for Player * Environment::getPlayer(u16 peer_id) and Player * Environment::getPlayer(const char *name) ? |
| 10:58 |
gregorycu |
Are they called often, and how many players are we talking about |
| 10:59 |
gregorycu |
Because a vector is faster than a map for a low number of elements (about 50) |
| 10:59 |
gregorycu |
(At least for simple things like ints) |
| 10:59 |
nrzkt |
okay, then it's useless here, there are ~30 calls in server.cpp |
| 10:59 |
nrzkt |
but playerneed or peer_id, it's not normalized |
| 11:00 |
gregorycu |
I suppose with anything, we'd have to profile to see if it has a positive impact |
| 11:02 |
gregorycu |
playername ? |
| 11:02 |
nrzkt |
playername* yes |
| 11:02 |
nrzkt |
because some structures are using playernames |
| 11:02 |
gregorycu |
Yeah, that's not very nice, should be normalised for sure |
| 11:03 |
gregorycu |
Probably should get translated from name to id as soon as possible |
| 11:03 |
gregorycu |
And everything should use the id |
| 11:03 |
gregorycu |
Oh well |
| 11:03 |
|
Fadi_ joined #minetest-dev |
| 11:06 |
|
Megaf_ joined #minetest-dev |
| 11:07 |
nrzkt |
i'll look at this, and hope this is not stored into db :p |
| 11:08 |
nrzkt |
oh a stupid thing here :p |
| 11:08 |
nrzkt |
PlayerSAO* Server::StageTwoClientInit(u16 peer_id) |
| 11:09 |
nrzkt |
playername = client->getName(); |
| 11:09 |
nrzkt |
RemotePlayer *player = |
| 11:09 |
nrzkt |
static_cast<RemotePlayer*>(m_env->getPlayer(playername.c_str())); |
| 11:09 |
nrzkt |
... |
| 11:11 |
gregorycu |
Who knows what's going on there |
| 11:11 |
nrzkt |
the lines doesn't follow but WTF :p |
| 11:16 |
gregorycu |
So, a bugfix introduces another bug |
| 11:16 |
gregorycu |
Where if you're falling down a wall, you can move into the wall, and sometimes you "land" on nodes in the wall |
| 11:17 |
gregorycu |
Even though there is no way you can land |
| 11:19 |
|
rubenwardy joined #minetest-dev |
| 11:30 |
est31 |
gregorycu: weird, I've done grep -r | wc -l for minetest.register_craft and got 1725... and the getCraftRecipes function claims to run ~19k iterations every time. When I cleanly call minetest.register_craft 1725 times using a lua loop, the function only reports 1725 iterations as it should... |
| 11:30 |
est31 |
"should" |
| 11:30 |
gregorycu |
Some mods have functions that call register_craft |
| 11:31 |
est31 |
It seems that some functionality clutters up m_craft_definitions |
| 11:31 |
gregorycu |
With parameters |
| 11:31 |
est31 |
ah |
| 11:31 |
gregorycu |
Yeah, it's annoying |
| 11:32 |
nrzkt |
hmmm removing playername from getPlayer needs modification on LUA API |
| 11:32 |
nrzkt |
because LUA call names, not peer_ids |
| 11:33 |
est31 |
I guess its some automated slab function or something like that |
| 11:34 |
gregorycu |
The LUA API should be exposed to peerIds |
| 11:34 |
gregorycu |
That's an internal thing |
| 11:34 |
gregorycu |
Err... |
| 11:34 |
gregorycu |
SHOULDN'T |
| 11:34 |
nrzkt |
okayer |
| 11:34 |
nrzkt |
okay*. Then i think we need a mapper somewhere, to map peer_id and playernames, isntead of searching in all players |
| 11:34 |
nrzkt |
after |
| 11:35 |
gregorycu |
Iterating through a vector of players to find the name may be faster than a map |
| 11:35 |
nrzkt |
oops, sorry for enter. After networking rework i think i'll add a PlayerMgr to manage some common calls to player maps and vectors |
| 11:35 |
gregorycu |
Because of cache locatily |
| 11:36 |
gregorycu |
Depends on how big the player structure is, and also if we are storing pointers or objects |
| 11:38 |
nrzkt |
#2209 |
| 11:38 |
ShadowBot |
https://github.com/minetest/minetest/issues/2209 -- Little performance improvement: use getPlayer(peer_id) instead of getPlayer(playername) by nerzhul |
| 11:38 |
|
FR^2 joined #minetest-dev |
| 11:38 |
|
exio4 joined #minetest-dev |
| 11:39 |
est31 |
gregorycu: yes confirm, the overall count is near 18k |
| 11:40 |
gregorycu |
That's 18k calls to register_craft? |
| 11:45 |
gregorycu |
The other option is to, instead of returning one-by-one, return all recepies |
| 11:49 |
est31 |
gregorycu: #2210 |
| 11:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/2210 -- getCraftRecipes implementation is very slow |
| 11:49 |
|
rubenwardy joined #minetest-dev |
| 11:50 |
gregorycu |
Thanks est31, that's exactly the code I was looking for |
| 11:50 |
est31 |
side note: the comment "Get output, then decrement input (if requested)" seems to be a leftover from a copy-paste and is now wrong |
| 11:50 |
est31 |
great |
| 11:51 |
exio4 |
18000 'things' taking more than one second doesn't sound like a data-structure problem, 18000 isn't really much, is it? |
| 11:51 |
est31 |
exio4: unfortunately thats the case |
| 11:52 |
gregorycu |
Hmm... |
| 11:52 |
gregorycu |
There is one way to find out |
| 11:52 |
rubenwardy |
FIGHT!!! |
| 11:52 |
gregorycu |
;) |
| 11:52 |
rubenwardy |
( https://www.youtube.com/watch?v=8ajHs8tCWew ) |
| 11:53 |
gregorycu |
Give me 8 minutes, and I'll have a look at this |
| 11:54 |
est31 |
inside the uniinv code, there is a for loop over all minetest.registered_items, and then a second for loop over all minetest.get_all_craft_recipes for every element. I've counted the iterations of that loop and came to 18k |
| 11:54 |
est31 |
exio4: ^ |
| 11:54 |
exio4 |
that's O(n^2) |
| 11:54 |
exio4 |
or O(n*m) with n = items, m = recipes |
| 11:54 |
est31 |
also, I've counted the iterations of this loop, and also came to the same result https://github.com/minetest/minetest/blob/70074800a20/src/craftdef.cpp#L983-L1008 |
| 11:55 |
gregorycu |
do we know what the lua function call overhead is like? |
| 11:55 |
est31 |
yea seems to be too much |
| 11:55 |
exio4 |
that looks more like a problem in the algorithm used to do that |
| 11:56 |
gregorycu |
Also |
| 11:56 |
gregorycu |
tmpout.item.substr(0,output.item.length()) == output.item) |
| 11:56 |
est31 |
there is not much lua around minetest.get_all_craft_recipes |
| 11:56 |
est31 |
its a basic string comparison, but can be done better yes |
| 11:57 |
|
SudoAptGetPlay joined #minetest-dev |
| 11:57 |
gregorycu |
When you call it 18k times, creating a temp string can be bad for perf |
| 11:57 |
est31 |
seems so |
| 11:57 |
gregorycu |
There are a few things to try |
| 11:57 |
exio4 |
is lua's garbage collector that crap? |
| 11:57 |
est31 |
yea |
| 11:57 |
est31 |
nono its all in c |
| 11:57 |
est31 |
++ |
| 11:58 |
exio4 |
oh, well, thought it was lua |
| 11:59 |
est31 |
gregorycu: If you're on it, can you also fix getCraftRecipe? |
| 11:59 |
est31 |
I'd like to call it too |
| 11:59 |
est31 |
also for every element :) |
| 11:59 |
gregorycu |
Maybe I should just fix everything? |
| 12:00 |
rubenwardy |
That would be good. |
| 12:00 |
rubenwardy |
:D |
| 12:00 |
est31 |
:) |
| 12:00 |
gregorycu |
I should have started by doing that |
| 12:00 |
est31 |
thats not that important |
| 12:00 |
est31 |
in fact, I think I'll do more logic in lua, and be happy |
| 12:01 |
gregorycu |
bb in 5 |
| 12:01 |
exio4 |
est31, what's the time spent in your hardware with that test mod? |
| 12:02 |
est31 |
18 secs |
| 12:02 |
est31 |
yours? |
| 12:02 |
exio4 |
time spent: 13170507 |
| 12:02 |
est31 |
13 secs |
| 12:02 |
* est31 |
has amd |
| 12:02 |
|
fz72 joined #minetest-dev |
| 12:12 |
|
Fadi joined #minetest-dev |
| 12:14 |
gregorycu |
28 seconds for me |
| 12:21 |
gregorycu |
Registering 20k items takes half a second |
| 12:22 |
gregorycu |
Looking up 2k of those takes 23 seconds |
| 12:22 |
gregorycu |
lol, not good |
| 12:27 |
|
kaeza joined #minetest-dev |
| 12:35 |
|
crazyR joined #minetest-dev |
| 12:39 |
|
fz72 joined #minetest-dev |
| 12:47 |
exio4 |
replacing the temp string with a compare call pretty much reduced the time by 60% over here |
| 12:48 |
exio4 |
which profiler do you use, by the way? |
| 12:50 |
|
ShadowBot` joined #minetest-dev |
| 12:54 |
|
DFeniks joined #minetest-dev |
| 12:54 |
gregorycu |
I use the Visual Studio one |
| 12:55 |
|
Zeno` joined #minetest-dev |
| 12:57 |
gregorycu |
Adding a lookup map increased the population time from 0.5 seconds to 5.7 seconds, but decreased the lookup time from 28 seconds to 59ms |
| 12:58 |
gregorycu |
exio4: What profiler do you use? |
| 12:59 |
exio4 |
I didn't use any profiler, just started the world with and without the change |
| 12:59 |
exio4 |
I didn't try anything else |
| 12:59 |
gregorycu |
ok |
| 13:05 |
gregorycu |
I suspect any move to optimise the lookup to the detriment of population will not be supported |
| 13:05 |
gregorycu |
Because everyone populates, but few lookup |
| 13:06 |
est31 |
what about having a lua function that creates a lookup table, and uses that from then on? |
| 13:07 |
gregorycu |
Though it's only a 30% slowdown on insertion |
| 13:07 |
gregorycu |
I was off by one order of magnitude before |
| 13:07 |
gregorycu |
Stupid digits |
| 13:08 |
gregorycu |
You mean a function that you call via lua that initialises a map in C++ land? |
| 13:08 |
est31 |
yea |
| 13:08 |
est31 |
but its only 30%... |
| 13:08 |
est31 |
thats not much |
| 13:09 |
est31 |
on the other side you have a decrease by 500% |
| 13:09 |
est31 |
sorry 500.000% |
| 13:10 |
gregorycu |
Urgh, europeans |
| 13:10 |
est31 |
:D |
| 13:10 |
gregorycu |
Let me make sure this is accurate, I haven't tested functionality, only perf, lol |
| 13:12 |
est31 |
or 50,000%, not 500,000 |
| 13:13 |
gregorycu |
A lot |
| 13:13 |
est31 |
:) |
| 13:14 |
est31 |
gtg brb |
| 13:22 |
Zeno` |
500%? O.o |
| 13:23 |
Zeno` |
what takes 28 seconds to look up? |
| 13:26 |
gregorycu |
est31: For when you get back, I decided to benchmark with 1 million items |
| 13:26 |
gregorycu |
(Register, Lookup) |
| 13:26 |
gregorycu |
New: (33 seconds, 13 seconds) |
| 13:26 |
gregorycu |
Old( 23 seconds, ... still going) |
| 13:27 |
Zeno` |
performance is relative |
| 13:27 |
|
shadowzone joined #minetest-dev |
| 13:28 |
Zeno` |
and requires context |
| 13:30 |
nrzkt |
Hi Zeno` please look at #2209, it's a little PR easy to commit :) |
| 13:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/2209 -- Little performance improvement: use getPlayer(peer_id) instead of getPlayer(playername) by nerzhul |
| 13:32 |
Zeno` |
nrzkt, looks good |
| 13:34 |
|
Jeija joined #minetest-dev |
| 13:36 |
Jeija |
Commit https://github.com/minetest/minetest/commit/800d192 breaks old maps, see my comment there |
| 13:37 |
puhfa |
what would be the best way to find out what is right next to a newly-placed node |
| 13:37 |
puhfa |
i am mainly looking for a way that does not crash the client |
| 13:37 |
Zeno` |
#2156 |
| 13:37 |
ShadowBot |
https://github.com/minetest/minetest/issues/2156 -- Optimise MapBlockMesh functions by gregorycu |
| 13:38 |
Zeno` |
please stop polluting global namespace |
| 13:38 |
Zeno` |
voxel.cpp line 624 needs fixing |
| 13:38 |
gregorycu |
lol @ puhfa |
| 13:38 |
gregorycu |
You have strange requirements :) |
| 13:39 |
puhfa |
well, both on_construct and on_place work fine as long as i am not going to use the parameters anywhere |
| 13:39 |
puhfa |
and i am not talking about a lua error message but a full-blown ctd |
| 13:39 |
gregorycu |
hmm |
| 13:40 |
gregorycu |
That's not good |
| 13:40 |
gregorycu |
Is this a known issue? |
| 13:40 |
puhfa |
dunno. might be me doing something wrong too |
| 13:40 |
puhfa |
on_construct = function(pos) local node = minetest.env:get_node(pos) |
| 13:41 |
gregorycu |
Is the node guaranteed to exist before on_construct is called |
| 13:42 |
Zeno` |
gregorycu, are you going to address the issues brought up regarding 215^? |
| 13:42 |
Zeno` |
2156? |
| 13:42 |
gregorycu |
Yeah, apparently it is |
| 13:42 |
gregorycu |
Well, I'm off to bed |
| 13:43 |
Zeno` |
if not I'll close the PR |
| 13:44 |
Zeno` |
If you do plan to address the issues discussed in IRC then I'll just label it as WIP |
| 13:47 |
Zeno` |
e.g. why is MapNode VoxelManipulator::ContentIgnoreNode = MapNode(CONTENT_IGNORE); extern (and not static) and why isn't it const? |
| 13:49 |
Zeno` |
*sigh* |
| 13:49 |
Zeno` |
ok, marking it as WIP |
| 13:51 |
gregorycu |
est31: I've updated that issue, here is a commit with the work, if the concept is good, I'll do a PR |
| 13:51 |
gregorycu |
We may be able to regain that 50% slowdown by optimising other parts of code |
| 13:51 |
gregorycu |
So it's neutral |
| 13:51 |
Zeno` |
gregorycu, are you going to answer the question? |
| 13:51 |
gregorycu |
https://github.com/gregorycu/minetest/commit/7ad3f9c4ae9e4ec2679e3a657a7eccbb1ea7dcff |
| 13:59 |
|
chchjesus joined #minetest-dev |
| 14:03 |
Zeno` |
very odd |
| 14:05 |
Zeno` |
nrzkt, have you looked at https://github.com/minetest/minetest/commit/800d19270250bb13cc6b2d330199815bf8e96446? |
| 14:05 |
|
T4im joined #minetest-dev |
| 14:08 |
Zeno` |
I'll have to revert it. Can you make it just not crash, nrzkt? |
| 14:10 |
|
fz72 joined #minetest-dev |
| 14:14 |
shadowzone |
Zeno`: was there suppose to be a "?" at the end of that link? |
| 14:23 |
Zeno` |
yeah, because I asked a question :) |
| 14:26 |
shadowzone |
Okay |
| 14:27 |
est31 |
back |
| 14:30 |
nrzkt |
Zeno` what crash ? i tested it :o |
| 14:31 |
nrzkt |
oh i see in the comment. |
| 14:31 |
Zeno` |
so in light of that, what is the responsible thing for me to do? :( |
| 14:32 |
nrzkt |
map upgrade will be useful to prevent those stupid things... :( |
| 14:32 |
Zeno` |
yeah, but in the meantime |
| 14:33 |
Zeno` |
i.e. perhaps the interim solution it just to stop the server crashing if the the version is incorrect |
| 14:33 |
nrzkt |
to prevent the problem you need to handle _INIT packet properly by comparing with 24 instead of SER_FMT_VER_LOWEST |
| 14:33 |
Zeno` |
yep |
| 14:34 |
Zeno` |
we cannot have old worlds broken though |
| 14:34 |
nrzkt |
but WTF we have two serial versions in fact.. |
| 14:34 |
Zeno` |
yeah, it's crazy |
| 14:34 |
nrzkt |
mapblock::serialize need client_serial_version instead of global_serial_version |
| 14:34 |
nrzkt |
pffff... |
| 14:34 |
nrzkt |
it's crazy stupid and subject to bugs like this |
| 14:35 |
nrzkt |
let me do another patch to fix this |
| 14:35 |
Zeno` |
because there is a release imminent I'll probably revert that commit (even though it's technically what is needed) |
| 14:35 |
nrzkt |
no problem. I fix the crash for the release, please wait the next pull |
| 14:35 |
Zeno` |
ok, if you can fix it with another commit, that's better |
| 14:35 |
Zeno` |
or should I revert for now to give you more time? |
| 14:36 |
nrzkt |
revert, i need to change the design of the bugfix |
| 14:36 |
Zeno` |
ok cool |
| 14:36 |
nrzkt |
this design cannot bet used for master |
| 14:36 |
nrzkt |
be* |
| 14:36 |
nrzkt |
but you can commit #2209 doesn't use old worlds :p |
| 14:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/2209 -- Little performance improvement: use getPlayer(peer_id) instead of getPlayer(playername) by nerzhul |
| 14:37 |
|
NakedFury joined #minetest-dev |
| 14:38 |
Zeno` |
what is your git username? I'll add a comment to the revert.... |
| 14:38 |
nrzkt |
nerzhul |
| 14:38 |
Zeno` |
sounds like something from Lord of the Rings :) |
| 14:38 |
nrzkt |
warcraft please :p |
| 14:39 |
Zeno` |
oh, sowwy |
| 14:39 |
Zeno` |
lol |
| 14:42 |
nrzkt |
ok, i created #define SER_FMT_CLIENT_VER_LOWEST 24 in serialization.h and use it in server.cpp |
| 14:42 |
nrzkt |
and i removed the assert too, same cause, it's useless because client was already checked |
| 14:43 |
Zeno` |
made a new PR? |
| 14:43 |
nrzkt |
let me 5 minutes, jenkins compile it, i test it and i push |
| 14:43 |
Zeno` |
yeah, no rush |
| 14:43 |
Zeno` |
take as long as you want |
| 14:44 |
Zeno` |
I think the main thing to address for this release is the potential to crash a server |
| 14:44 |
nrzkt |
of course, it was the goal :p |
| 14:45 |
nrzkt |
i didn't think there is a so stupid thing, client serialization can be different than mapblock |
| 14:49 |
|
CraigyDavi joined #minetest-dev |
| 14:49 |
Zeno` |
well I checked it as well; I just didn't have any old worlds hehe. I did have concerns but didn't realise there was a "sharing" (again) of client/server code |
| 14:49 |
|
alexxs joined #minetest-dev |
| 14:51 |
Zeno` |
sharing is ok of course |
| 14:52 |
Zeno` |
just not unintended side-effects heh |
| 14:52 |
nrzkt |
ofc :( |
| 14:53 |
nrzkt |
#2212 |
| 14:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/2212 -- Fix a crash (assert) when client set serial version < 24 in INIT and by nerzhul |
| 14:53 |
nrzkt |
PR is ok |
| 15:00 |
nrzkt |
you can test and push it now : |
| 15:00 |
nrzkt |
:) |
| 15:00 |
nrzkt |
my jenkins was okay: http://jenkins.unix-experience.fr/job/minetest/34/console |
| 15:09 |
sfan5 |
nrzkt: we already have travis which tests gcc, clang, win32 and win64 |
| 15:09 |
sfan5 |
https://travis-ci.org/minetest/minetest/builds/48350520 |
| 15:10 |
nrzkt |
i know :p but i'm using jenkins for my own tests :) |
| 15:10 |
Zeno` |
bbiab |
| 15:10 |
|
leat joined #minetest-dev |
| 15:10 |
nrzkt |
bbiab ? |
| 15:10 |
nrzkt |
what is this ? |
| 15:10 |
kilbith |
variant of bbl |
| 15:11 |
shadowzone |
Be |
| 15:11 |
shadowzone |
Be Back In a Bit |
| 15:11 |
nrzkt |
thanks |
| 15:16 |
|
hmmmm joined #minetest-dev |
| 15:16 |
|
Fadi_ joined #minetest-dev |
| 15:24 |
|
kaeza joined #minetest-dev |
| 15:30 |
|
Fadi joined #minetest-dev |
| 15:32 |
|
jin_xi joined #minetest-dev |
| 15:33 |
|
ImQ009 joined #minetest-dev |
| 15:49 |
|
fz72 joined #minetest-dev |
| 15:50 |
nrzkt |
another performance fix: #2214 |
| 15:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/2214 -- Performance improvement -> Craftdef.cpp: Improve loop and mathematics for CraftDefinitionShaped::check by nerzhul |
| 15:56 |
|
Player_2 joined #minetest-dev |
| 15:56 |
Player_2 |
mornin' all |
| 15:56 |
|
Gethiox joined #minetest-dev |
| 15:57 |
nrzkt |
hi |
| 15:59 |
Wayward_One |
hmmmm: https://github.com/minetest/minetest/issues/2145#issuecomment-71483381 |
| 16:00 |
|
diemartin joined #minetest-dev |
| 16:01 |
|
Gethiox joined #minetest-dev |
| 16:01 |
kilbith |
impressive |
| 16:05 |
hmmmm |
Wayward_One: it seems your ABM handlers are taking up over 37% of your execution time |
| 16:06 |
Wayward_One |
hmm, not sure what that means- is it something i did, or just minetest...? |
| 16:06 |
hmmmm |
also for some reason it looks like Connection::Receive is consuming an incredible amount of CPU |
| 16:06 |
hmmmm |
it means your mods suck |
| 16:07 |
hmmmm |
this is odd |
| 16:08 |
T4im |
weakly related implementation detail question: is it generally save to assume that node timers provide a better performance than abm's where applyable? |
| 16:10 |
Wayward_One |
weird, i have no mods except for default there... |
| 16:10 |
Wayward_One |
...and minetest_time |
| 16:11 |
|
Weedy joined #minetest-dev |
| 16:13 |
|
roniz joined #minetest-dev |
| 16:13 |
est31 |
hmmmm: I'm currently investigating an issue in universal inventory and now I'm not sure whether its an engine bug or a lua bug. The problem is that when you overwrite a craft with its |
| 16:14 |
hmmmm |
Wayward_One: how long were you running minetest for with pid 23205? |
| 16:14 |
nrzkt |
is there any reason that there are so many #if 0 in map.cpp... |
| 16:15 |
Wayward_One |
hmmmm: about 40 minutes |
| 16:15 |
hmmmm |
nrzkt: preserving historic code... map.cpp is mostly celeron55's original stuff |
| 16:15 |
hmmmm |
ahh |
| 16:15 |
est31 |
... with another result, then the engine refuses to craft but the lua function minetest.get_all_craft_recipes gives both ways, the non-disabled one and the disabled one |
| 16:15 |
est31 |
I dont know whether the engine should filter out the overwritten crafts or the lua should do its own logic |
| 16:15 |
hmmmm |
est31: don't take my word for it but I think that could possibly be expected behavior, I recall hearing about a similar issue |
| 16:16 |
hmmmm |
but this isn't my area to begin with. PilzAdam or ShadowNinja are the ones who typically work on crafting |
| 16:16 |
nrzkt |
original code isn't so different than existing code, many #if 0 could be destroyed because they are redundant |
| 16:16 |
est31 |
ok what are your areas? |
| 16:16 |
|
troller joined #minetest-dev |
| 16:17 |
hmmmm |
mostly everything else |
| 16:17 |
est31 |
heh |
| 16:18 |
celeron55 |
T4im: no, they are fundamentally different things |
| 16:19 |
|
SopaXorzTaker joined #minetest-dev |
| 16:19 |
celeron55 |
replacing one with another implies a different kind of behavior with different kinds of optimizations and caveats |
| 16:19 |
est31 |
anyone else having an opinion on that |
| 16:19 |
est31 |
(my question about the bug) |
| 16:20 |
celeron55 |
T4im: basically what you have to do is use timers if you have a few nodes for which you want exact timing, and ABMs if you have masses of nodes for which you don't need exact timing |
| 16:21 |
T4im |
ah,… so a switch from abms to nodetimer for furnaces. autocrafters, entitiy-vacuum nodes is called for, but handling dirt or stone should remain with abms? |
| 16:21 |
celeron55 |
yes, those are exactly what they have been created for |
| 16:22 |
T4im |
alright thanks :) |
| 16:22 |
hmmmm |
oh look at that |
| 16:22 |
hmmmm |
__cxa_throw: 67.55% |
| 16:22 |
nrzkt |
beautiful :D |
| 16:22 |
hmmmm |
ffs, from now on exceptions are banned |
| 16:22 |
hmmmm |
this is ridiculous i'm sorry |
| 16:24 |
est31 |
why is so much functionaliy on the sneak key and not on the use key. for example building next to stuff with an inventory could greatly profit from not having to fly down or search a place you can stand on (when you have fly mode enabled) |
| 16:25 |
est31 |
s/inventory/formspec menu/ |
| 16:27 |
hmmmm |
Wayward_One: are you still there? |
| 16:28 |
hmmmm |
Wayward_One: could you tune your log level to log infostream? |
| 16:28 |
est31 |
ah ok there is an option to give climb down to the use key |
| 16:30 |
Wayward_One |
hmmmm: how do i do that? |
| 16:31 |
hmmmm |
set debug_log_level to 3 |
| 16:31 |
|
Zeno` joined #minetest-dev |
| 16:31 |
hmmmm |
it's going to be pretty spammy but |
| 16:31 |
hmmmm |
it'll be worth it to diagnose this |
| 16:31 |
hmmmm |
so just run around in singleplayer for a few minutes with that loglevel |
| 16:31 |
|
Calinou joined #minetest-dev |
| 16:31 |
T4im |
I think escalating in loglevel --info --verbose --trace are available also while calling the binary |
| 16:31 |
hmmmm |
yeah should be |
| 16:31 |
celeron55 |
why not even more loglevel, skimping on that makes no sense |
| 16:32 |
hmmmm |
because the error i'm looking out for is printed to infostream |
| 16:32 |
Wayward_One |
ok |
| 16:32 |
Zeno` |
hmmmm, gregorycu has made an optimisation to increase performance by 50000% |
| 16:32 |
hmmmm |
Zeno`: haha. |
| 16:32 |
Zeno` |
maybe that will help you, Wayward_One |
| 16:32 |
Wayward_One |
hehe |
| 16:32 |
Wayward_One |
yes please! :D |
| 16:34 |
Zeno` |
hmmmm, I'm not joking btw |
| 16:34 |
hmmmm |
what component..? |
| 16:34 |
Zeno` |
#2210 |
| 16:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/2210 -- getCraftRecipes implementation is very slow |
| 16:34 |
hmmmm |
oh |
| 16:34 |
hmmmm |
well that's just crafting receipies |
| 16:34 |
hmmmm |
you darn australians always overinflate performance claims |
| 16:35 |
hmmmm |
remember that euclideon guy: "A MILLION TIMES FASTER" |
| 16:35 |
Zeno` |
but... 50 THOUSAND. We have to do this everywhere |
| 16:35 |
hmmmm |
"UNLIMITED DETAIL" |
| 16:35 |
hmmmm |
but yea. |
| 16:35 |
Zeno` |
a million times faster? |
| 16:36 |
hmmmm |
there are a lot of places where linear lookups are used where they should not be |
| 16:36 |
Zeno` |
doesn't sound very realistic |
| 16:36 |
hmmmm |
CNodeDefManager::getIds was a rather bad case of this |
| 16:36 |
hmmmm |
celeron wrote them when prototyping, never fixed them, and now nobody knows where they are until they trip on top of one |
| 16:36 |
Zeno` |
anyway, just for the record I am currently vetoing all of gcu's PRs |
| 16:37 |
hmmmm |
why. |
| 16:37 |
Zeno` |
when he decides that he'd like to discuss things on IRC and answer simple questions I'll stop |
| 16:37 |
hmmmm |
lol okay. |
| 16:37 |
Zeno` |
Because he will not discuss his pull requests |
| 16:38 |
Zeno` |
i.e. he does not want to be part of the team |
| 16:38 |
Zeno` |
(apparently) |
| 16:38 |
|
ImQ009 joined #minetest-dev |
| 16:38 |
hmmmm |
speaking of discussion, I read part of some conversation from a few days ago and you disapprove of the coding guidelines |
| 16:38 |
Zeno` |
me? |
| 16:38 |
hmmmm |
instead of just not liking it and keeping quiet maybe we could start a conversation |
| 16:38 |
Zeno` |
I said I didn't agree with all of them but accept them (IIRC) |
| 16:39 |
hmmmm |
but that requires me to spend time writing the rationale for all the current points |
| 16:39 |
hmmmm |
agh I'm distracted by 500 different things |
| 16:39 |
Zeno` |
nah, there will always be disagreements with coding guidelines |
| 16:39 |
Zeno` |
ya just stick with them |
| 16:40 |
Zeno` |
It's ok to disagree with some points though |
| 16:40 |
hmmmm |
the references one I'm a bit more flexible on than when I wrote that |
| 16:41 |
Zeno` |
I don't disagree with any of them strongly enough to make a fuss; put it that way |
| 16:41 |
Zeno` |
well... except maybe the m_ thing |
| 16:41 |
Zeno` |
but even then I just *shrug* :) |
| 16:41 |
hmmmm |
i don't like it in spirit because it's C++ for the sake of being C++... there's no functional difference between passing a pointer |
| 16:41 |
hmmmm |
shit like that |
| 16:41 |
hmmmm |
why change the syntax of something |
| 16:42 |
hmmmm |
except it's useful and necessary in certain circumstances because the rest of the language was built under the assumption that they have that and you'll use it now |
| 16:42 |
hmmmm |
Zeno`: let's talk about m_ |
| 16:43 |
hmmmm |
are you in support of it? do you not like m_? |
| 16:44 |
|
VargaD_ joined #minetest-dev |
| 16:45 |
Zeno` |
I like m_ |
| 16:45 |
hmmmm |
yeah but don't use it if you're exposing a member to the public |
| 16:45 |
Zeno` |
I know that you can see that the object is not in scope, but... |
| 16:46 |
Zeno` |
oh yeah, of course |
| 16:46 |
nrzkt |
m_ must use getters instead of being exposed :( |
| 16:47 |
Zeno` |
I am of the opinion that if a getter and setter are both provided for the object/variable then that variable should just be public |
| 16:47 |
Zeno` |
unless it's meant to be abstracted away |
| 16:48 |
Zeno` |
gettor/settor that simply return or assign are silly |
| 16:48 |
hmmmm |
that's ridiculous Java stuff that has no place here |
| 16:48 |
Zeno` |
but yes, m_ must use getters |
| 16:49 |
hmmmm |
in any case |
| 16:49 |
hmmmm |
look at irrlicht |
| 16:49 |
Zeno` |
if it's public then the m_ should be omitted and the variable made public |
| 16:49 |
Zeno` |
Do I have to look at irrlicht? :( |
| 16:49 |
nrzkt |
look at mangos |
| 16:49 |
est31 |
Zeno`: I have described a realistic use case for 20k items in the issue. |
| 16:50 |
hmmmm |
you don't do things like video_data.m_OpenGLLinux.m_X11Display |
| 16:50 |
hmmmm |
and you don't do things like |
| 16:50 |
Zeno` |
est31, I know. But there is not a 50000% performance increase |
| 16:50 |
hmmmm |
video_data.getOpenGLLinux().getX11Display() |
| 16:50 |
hmmmm |
directly accessing members is so much cleaner |
| 16:50 |
Wayward_One |
hmmmm: http://pastebin.com/7vhNmwZc |
| 16:50 |
|
Krock joined #minetest-dev |
| 16:51 |
est31 |
Zeno`: see https://github.com/minetest/minetest/issues/2210#issuecomment-71492760 |
| 16:51 |
Zeno` |
est31: that is not a 50000% increase in performance |
| 16:51 |
Zeno` |
perCENT |
| 16:52 |
est31 |
its 500x agreed? |
| 16:52 |
Zeno` |
you don't calculate function cost based on total runtime |
| 16:52 |
Zeno` |
no, it's not even 500x |
| 16:52 |
est31 |
on what else then? |
| 16:53 |
Zeno` |
an average (very basically) |
| 16:53 |
Zeno` |
that is what the CENT in perCENT really means |
| 16:53 |
est31 |
yeah, like executing a function several hundred times |
| 16:53 |
Zeno` |
yeah |
| 16:53 |
est31 |
and then taking the total runtime |
| 16:53 |
est31 |
thats what my gist does |
| 16:54 |
Zeno` |
but... "time from 28 seconds to 59ms" |
| 16:54 |
Zeno` |
is that what this is based on? |
| 16:54 |
est31 |
yes |
| 16:54 |
Zeno` |
you've divided both sides of the equation by the number of iterations? |
| 16:54 |
est31 |
nice try |
| 16:54 |
Zeno` |
seriously |
| 16:55 |
est31 |
its the same for both |
| 16:55 |
hmmmm |
Wayward_One: did you have the same singleplayer lag that time when you were collecting data? |
| 16:55 |
Zeno` |
it's not the same :/ |
| 16:55 |
est31 |
why not? |
| 16:55 |
Zeno` |
the number of iterations must be included in the calculation |
| 16:55 |
est31 |
I dont think he changed the lua loop? |
| 16:55 |
Zeno` |
otherwise the number is meaningless |
| 16:56 |
Wayward_One |
hmmmm: crap, no, i forgot to re-enable mesh caching, one sec... |
| 16:56 |
est31 |
yes, when the iteration numbers differ, the code is meaningless. |
| 16:56 |
est31 |
I gonna check out his code and try to confirm what he has seen |
| 16:56 |
Zeno` |
no, the number of iterations needs to be included as part of the final number |
| 16:56 |
Zeno` |
i.e. divide the total time by number of iterations |
| 16:57 |
Zeno` |
there is not a 50000% or even 500% increase |
| 16:57 |
Zeno` |
isn't this obvious? :( |
| 16:58 |
est31 |
so when I have 100 iterations, and dont optimize my code, then I say ok, I'm dividing 1 by 100, so I got an 1% increase? |
| 16:58 |
|
MinetestForFun joined #minetest-dev |
| 16:58 |
Zeno` |
you divide the total execution time by 100 (if you have 100 iterations) yes |
| 16:59 |
Zeno` |
if you have 62 million iterations you divide the total execution time by 62 million |
| 16:59 |
hmmmm |
Wayward_One: that won't make a difference |
| 16:59 |
Zeno` |
this gives you a rough estimate |
| 17:00 |
Zeno` |
then you do the same with an alternative solution |
| 17:00 |
hmmmm |
Wayward_One: I didn't see what I was looking for in the logfile you pasted... seems odd, unless the server is getting a flood of PeerNotFoundException |
| 17:00 |
Zeno` |
divide that by 62 million as well and *then* calculate the % difference |
| 17:01 |
est31 |
ok we have the formula: "increase* time_optimized/iterations = time_unoptimized/iterations" |
| 17:02 |
est31 |
now write "increase = (time_unoptimized/iterations)/(time_optimized/iterations)" -> "increase =time_unoptimized/time_optimized " |
| 17:02 |
hmmmm |
hey Zeno, how did you come up with the suggestion to set enable_mesh_cache = false? |
| 17:02 |
est31 |
there the iterations arent needed anymore, as they are the same for both sides |
| 17:02 |
hmmmm |
doesn't that seem to suggest the problem exists mostly on the client-side rather than server side? |
| 17:02 |
est31 |
anyway, I gonna try his commit |
| 17:02 |
Zeno` |
hmmmm, I was profiling something entirely unrelated and noticed a decrease in performance |
| 17:03 |
hmmmm |
but caching things is supposed to increase performance!! :( |
| 17:03 |
Zeno` |
supposed to yes :( |
| 17:03 |
Zeno` |
I don't know the real cause of the issue (or even if it's a real issue), it's just something I noticed and suggested Wayward_One try |
| 17:04 |
|
selat joined #minetest-dev |
| 17:04 |
Zeno` |
I should really look at the code |
| 17:05 |
Zeno` |
perhaps there is a simple bug there |
| 17:05 |
hmmmm |
my current theory is that because of some bug the server is producing an enormous amount of PeerNotFoundExceptions |
| 17:05 |
nrzkt |
hmmmm this will be lightneed by network rework |
| 17:05 |
nrzkt |
but network rework will be done for 1.0.0 |
| 17:06 |
nrzkt |
i'm doing many and many work to improve networking handling, reduce coding error and improve protocol |
| 17:06 |
hmmmm |
nrzkt, it's just a theory. i have no idea if that's the reason |
| 17:06 |
hmmmm |
if I had to point out something as being the reason it'd be the ABM handlers that take up more than 1/3rd of all the execution time |
| 17:09 |
hmmmm |
man i am not feeling good |
| 17:09 |
hmmmm |
i need to lay down |
| 17:11 |
Zeno` |
est31, are you telling me that a single lookup of whatever is being looked up takes 28 seconds? |
| 17:12 |
est31 |
no, its 1725 lookups, although they are done "in the wild" by a lua mod, and I havent found a good method to do it otherwise |
| 17:13 |
|
Fadi joined #minetest-dev |
| 17:14 |
Zeno` |
if it's done 1725 times then that is 16ms per call |
| 17:14 |
est31 |
seems so |
| 17:14 |
Zeno` |
but gregorycu has "improved" it to 89ms per call? |
| 17:14 |
Zeno` |
58* |
| 17:14 |
est31 |
not per call, but overall |
| 17:15 |
Zeno` |
overall is meaningless |
| 17:15 |
est31 |
and it was rather 580, at least from my benchmarks |
| 17:15 |
est31 |
divide through the number of calls, and you get the perf per call |
| 17:15 |
est31 |
580 ms is certainly better than 28 seconds? |
| 17:16 |
Zeno` |
what is 580? |
| 17:16 |
|
Hunterz joined #minetest-dev |
| 17:16 |
est31 |
580 ms |
| 17:16 |
est31 |
for 1725 iterations |
| 17:16 |
Zeno` |
that seems worse than 16ms per call |
| 17:17 |
Zeno` |
is 580 the total runtime? |
| 17:17 |
est31 |
yes |
| 17:17 |
Zeno` |
ok, well that's 33ms per call |
| 17:17 |
est31 |
so 580/1725 is .33 ms |
| 17:17 |
Zeno` |
no |
| 17:18 |
Zeno` |
let's get the units straight if you are saying that ;) |
| 17:18 |
est31 |
580 ms/1725 iterations is .33 ms |
| 17:19 |
Zeno` |
so that's a 1.8% increase |
| 17:20 |
est31 |
whatever |
| 17:20 |
est31 |
as long as it got better |
| 17:20 |
hmmmm |
wow |
| 17:20 |
hmmmm |
where'd this 50000% increase go |
| 17:21 |
est31 |
hmmmm: try calculating 1/5000% |
| 17:21 |
est31 |
its only a 5000% increase sorry :) |
| 17:23 |
est31 |
but yes I get the point that it is not completely ok to call it 5000% increase. |
| 17:23 |
est31 |
so, whatever, as long as it got better |
| 17:25 |
Zeno` |
yeah, whatever. I just don't like seeing stupidly inflated figures like 50000% |
| 17:25 |
* est31 |
feels sorry |
| 17:26 |
Zeno` |
there was another issue where adding a callback to "cache" the enable_fog led to reducing the main (cleint) game loop by 8% |
| 17:27 |
Zeno` |
which is dumb, because not even spread_light uses 8% of the CPU time; but a single map lookup did? |
| 17:27 |
Zeno` |
boggles the mind |
| 17:28 |
Zeno` |
Don't get me wrong... things are slow, but I'd like to see *real* numbers |
| 17:28 |
|
proller joined #minetest-dev |
| 17:30 |
est31 |
and it wasnt 1725 but rather 2325 sorry |
| 17:35 |
est31 |
Zeno`: see latest github comment on that issue |
| 17:37 |
Zeno` |
so.. 1.5x better |
| 17:37 |
Zeno` |
I'm not saying it's not faster (it's obvious it would be) |
| 17:38 |
|
proller joined #minetest-dev |
| 17:41 |
est31 |
you find the tradeoff bearable? or should there rather be a function that dumps the whole table into a lua table? --> perhaps still with some logic, as there are ~1-2k items in minetest.registered_nodes , and 20k crafts (so some result crafts dont appear in registered_nodes). The function I'm trying to optimize is only interested in registered nodes |
| 17:47 |
|
shadowzone joined #minetest-dev |
| 17:56 |
|
proller joined #minetest-dev |
| 17:57 |
|
Fadi_ joined #minetest-dev |
| 18:04 |
|
Wayward_One joined #minetest-dev |
| 18:05 |
|
rubenwardy joined #minetest-dev |
| 18:08 |
* sofar |
fixes up const std::string stuff sfan5 wanted |
| 18:09 |
sofar |
const stuff in C I've got no trouble with, but I still need more C++ training to feel more comfortable ;) |
| 18:10 |
|
Wayward_One joined #minetest-dev |
| 18:17 |
|
SopaXorzTaker joined #minetest-dev |
| 18:27 |
|
iqualfragile joined #minetest-dev |
| 18:32 |
sfan5 |
sofar: you mean ShadowNinja |
| 18:33 |
sofar |
wheps, I do |
| 18:34 |
sofar |
I'm confusing unicorn with anime girl |
| 18:34 |
sofar |
wait, it's a beaver |
| 18:36 |
sofar |
sfan5: what's usually the timeframe for pull requests to be accepted/rejected and closed? |
| 18:36 |
sofar |
(I'm not worried about mine, it's a minor change) |
| 18:37 |
sfan5 |
sofar: some pulls take forever, others get merged rather quickly |
| 18:41 |
sofar |
heh no kidding, there's some open from 2013-01 |
| 18:42 |
sofar |
I should janitor some of these away... there's a few that just need rebasing |
| 18:51 |
|
proller joined #minetest-dev |
| 18:53 |
|
Miner_48er joined #minetest-dev |
| 19:28 |
|
fz72 joined #minetest-dev |
| 19:31 |
|
est31 joined #minetest-dev |
| 19:34 |
|
younishd joined #minetest-dev |
| 19:46 |
|
shadowzone joined #minetest-dev |
| 20:06 |
|
shadowzone joined #minetest-dev |
| 20:24 |
|
MinetestForFun joined #minetest-dev |
| 21:03 |
|
fz72 joined #minetest-dev |
| 21:08 |
|
roniz_ joined #minetest-dev |
| 21:19 |
|
iqualfragile_ joined #minetest-dev |
| 21:23 |
|
proller joined #minetest-dev |
| 21:57 |
|
acerspyro joined #minetest-dev |
| 22:01 |
|
iqualfragile joined #minetest-dev |
| 22:43 |
|
roniz joined #minetest-dev |
| 23:22 |
|
Player_2 joined #minetest-dev |
| 23:35 |
|
diemartin joined #minetest-dev |
| 23:40 |
|
blaaaaargh joined #minetest-dev |
| 23:58 |
|
Megaf joined #minetest-dev |
| 23:58 |
|
Megaf joined #minetest-dev |
