Minetest logo

IRC log for #minetest-dev, 2015-01-26

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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/minetes​t/blob/70074800a207974a0c1383275186​cefe6955f297/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/70074800a207974a0c1383275186cefe​6955f297/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/minetes​t/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/commi​t/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-experienc​e.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/minete​st/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/minetes​t/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/minetes​t/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

| Channels | #minetest-dev index | Today | | Google Search | Plaintext