Time Nick Message 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_ 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:54 est31 seems to be because my gfx drv sux 02:54 est31 gonna shutdown -r now 02:55 hmmmm nope 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... 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) 06:38 VanessaE hmmmm: how do you mean, how subgames work? 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:37 hmmmm hm 07:51 hmmmm flowing liquid should draw a face on the underside if the material it's up against is solid 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 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: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(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: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: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: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 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: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: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:54 gregorycu I use the Visual Studio one 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: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: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 14:03 Zeno` very odd 14:05 Zeno` nrzkt, have you looked at https://github.com/minetest/minetest/commit/800d19270250bb13cc6b2d330199815bf8e96446? 14:08 Zeno` I'll have to revert it. Can you make it just not crash, nrzkt? 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: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 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: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 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: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 mornin' all 15:57 nrzkt hi 15:59 Wayward_One hmmmm: https://github.com/minetest/minetest/issues/2145#issuecomment-71483381 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: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:17 hmmmm mostly everything else 16:17 est31 heh 16:18 celeron55 T4im: no, they are fundamentally different things 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 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 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 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: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: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 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 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: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 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: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: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 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: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