00:17:14  * zhangyqjoined
00:19:11  * rmg_joined
00:23:25  * rmg_quit (Ping timeout: 250 seconds)
00:24:02  * tunniclm_quit (Ping timeout: 244 seconds)
00:49:42  * dap_quit (Quit: Leaving.)
01:03:32  * brsonquit (Quit: leaving)
02:20:44  * rmg_joined
02:24:51  * rmg_quit (Ping timeout: 240 seconds)
03:05:11  * terinjokesquit (Ping timeout: 240 seconds)
03:09:06  * terinjokesjoined
04:22:11  * rmg_joined
04:26:31  * rmg_quit (Ping timeout: 250 seconds)
04:27:00  * zju_xjoined
04:28:15  * zju3quit (Ping timeout: 250 seconds)
04:29:07  * rgrinbergquit (Ping timeout: 250 seconds)
05:06:52  * zju_xquit (Ping timeout: 260 seconds)
05:32:43  * phaopart ("Leaving")
06:23:15  * seishunjoined
06:23:41  * rmg_joined
06:28:22  * rmg_quit (Ping timeout: 272 seconds)
07:19:43  * rendarjoined
07:24:28  * rmg_joined
07:28:55  * rmg_quit (Ping timeout: 252 seconds)
07:51:51  * seishunquit (Ping timeout: 240 seconds)
07:56:31  * thefourtheyejoined
08:37:08  * Fishrock123joined
09:25:57  * rmg_joined
09:30:28  * rmg_quit (Ping timeout: 252 seconds)
10:31:27  * Fishrock123quit (Remote host closed the connection)
10:40:25  * davijoined
10:40:25  * daviquit (Changing host)
10:40:25  * davijoined
10:51:52  * thealphanerdquit (Quit: farewell for now)
10:52:23  * thealphanerdjoined
11:21:44  * zhangyqquit (Ping timeout: 244 seconds)
11:22:30  * Fishrock123joined
11:27:26  * rmg_joined
11:31:55  * rmg_quit (Ping timeout: 258 seconds)
12:02:47  * Jacob843quit (Remote host closed the connection)
12:03:43  * Jacob843joined
12:14:04  * PerilousApricotjoined
12:18:11  * daviquit (Ping timeout: 240 seconds)
12:20:44  * PerilousApricotquit (Remote host closed the connection)
12:22:24  * rgrinbergjoined
12:26:03  * rgrinbergquit (Client Quit)
12:26:26  * rgrinbergjoined
13:28:58  * rmg_joined
13:33:47  * rmg_quit (Ping timeout: 260 seconds)
14:10:26  * tunniclm_joined
14:19:19  * zju3joined
14:29:39  * rmg_joined
14:34:04  * rmg_quit (Ping timeout: 252 seconds)
14:45:55  * Fishrock123quit (Remote host closed the connection)
14:47:40  * Fishrock123joined
15:01:03  * zju3quit (Ping timeout: 276 seconds)
15:30:00  * importantshockjoined
15:31:34  * rgrinbergquit (Ping timeout: 240 seconds)
15:41:39  * zju3joined
15:42:38  * brsonjoined
15:43:08  * importantshockquit (Remote host closed the connection)
15:47:03  * Fishrock123quit (Remote host closed the connection)
15:52:38  * dap_joined
16:00:28  * rgrinbergjoined
16:02:50  * importantshockjoined
16:06:23  * seishunjoined
16:19:30  * Fishrock123joined
16:25:22  * PerilousApricotjoined
16:31:08  * rmg_joined
16:35:11  * rmg_quit (Ping timeout: 240 seconds)
16:48:24  * davijoined
16:48:24  * daviquit (Changing host)
16:48:24  * davijoined
16:53:53  * PerilousApricotquit (Remote host closed the connection)
16:54:02  * daurnimatorquit (Quit: WeeChat 1.4)
16:56:14  * PerilousApricotjoined
17:05:47  * PerilousApricotquit (Read error: Connection reset by peer)
17:06:25  * PerilousApricotjoined
17:18:53  * importantshockquit (Remote host closed the connection)
17:27:52  * rgrinbergquit (Ping timeout: 252 seconds)
17:28:09  * importantshockjoined
17:30:20  * rgrinbergjoined
17:30:24  * rgrinbergquit (Client Quit)
17:30:46  * rgrinbergjoined
17:37:31  * seishunquit (Ping timeout: 240 seconds)
17:37:40  * daviquit (Ping timeout: 264 seconds)
17:55:33  * seishunjoined
18:13:56  * qard-appnetajoined
18:14:10  * rgrinbergquit (Ping timeout: 250 seconds)
18:17:52  * happy-dudejoined
18:21:42  * zju3quit (Ping timeout: 258 seconds)
18:24:48  * daurnimatorjoined
18:32:40  * rmg_joined
18:37:08  * rmg_quit (Ping timeout: 250 seconds)
18:39:33  * Fishrock123quit (Remote host closed the connection)
18:41:20  * zju3joined
18:44:18  * rendarquit (Ping timeout: 272 seconds)
19:06:49  * importantshockquit (Remote host closed the connection)
19:12:52  * rendarjoined
19:26:51  * rgrinbergjoined
19:30:50  * addaleaxjoined
19:31:50  * Fishrock123joined
19:37:56  * importantshockjoined
20:07:08  * Fishrock123quit (Remote host closed the connection)
20:08:17  * Fishrock123joined
20:09:18  * Fishrock123quit (Client Quit)
20:09:59  <Dirkson>Just a quick sanity check - There are no known problems with having a large number of mutexes in your program, correct? On the order of tens of thousands?
20:34:12  * rmg_joined
20:39:03  * rmg_quit (Ping timeout: 276 seconds)
20:51:12  * zju_xjoined
20:53:16  * zju3quit (Ping timeout: 264 seconds)
21:01:10  * Fishrock123joined
21:32:21  * piscisaureusjoined
21:39:30  * rgrinbergquit (Ping timeout: 276 seconds)
21:44:12  * piscisaureusquit (Quit: Leaving.)
21:47:51  * seishunquit (Ping timeout: 240 seconds)
21:56:59  <Ralith_>Dirkson: that's generally overwhelming evidence that there's a problem with your *design*, but it shouldn't present a difficulty for the OS
22:11:05  <Dirkson>Ralith_: I'm reasonably certain that I've located the cause of the problem - I don't appear to lock the overarching structures properly when I destroy mutexes. Oops! The large number of them are because they're guarding a large octree-like structure. If performance ever becomes an issue, I could probably move them up a level in the tree structure and not notice much of a difference, but so far I haven't seen
22:11:08  <Dirkson>mutex locks/unlocks taking up a large amount of cpu time.
22:12:20  <Ralith_>large quantities of shared memory like that are generally considered a serious design smell, yes
22:13:03  <Ralith_>performance isn't the worry so much as safety and predictability
22:14:25  <Ralith_>if you're locking individual tree nodes like that my immediate concern would be that you haven't taken any measures to ensure that tree-processing code sees a consistent view, for example
22:17:25  * Dirksonconsiders, "I don't see any other way around it. I have extremely large structures that the whole game centers around. The only other design that'd make any kind of sense would be to have one thread own the large structures, and have all other threads communicate with it for reads and writes. And it seems likely that -that- solution is going to have a really horrible effect on performance.
22:20:40  <Dirkson>Currently I'm making heavy use of asan, tsan, valgrind, and recently helgrind to locate and debug threading/mutex issues. But apparently none of them notice use-after-destroy errors : )
22:23:57  <Dirkson>It's definitely -not- fun to debug. I'd strongly prefer a more message based approach, if I could work out how to do it efficiently.
22:27:55  <rendar>Dirkson: 10k mutexes = your program sucks
22:28:04  <rendar>you must change the design
22:29:05  <Dirkson>rendar: It functions at a good clip, and threading issues are rare. What metric are you using for 'suck'?
22:29:51  <rendar>Dirkson: the metric which says mutexes weren't made for such a purpose..maybe you want to consider spinlocks, but not 10k either
22:30:19  <rendar>as far as i understand, you have a mutex for each octree-like leaf?
22:31:05  <Dirkson>rendar: I have one mutex per 1000 leaves.
22:31:23  <Dirkson>Depending on how you define a leaf. You could argue the number is a lot higher.
22:32:10  <rendar>still, having 10k mutexes is not practical by any measure of good design, i think what you're looking for is lock-free data structures, or, N thread unsafe octree, 1 per-thread and those threads communicates by lock-free queues, which are *very* fast
22:33:06  <rendar>so each thread will modify its "part" or subset of the tree without locking and waiting
22:33:44  <Dirkson>I've considered lock free data structures. As I understand them, they take about half the time of a mutex operation. Which seems like a nice benefit... But again, profiling does not indicate that my mutex locks are a significant source of slowdown.
22:34:09  <rendar>it's not the time benefit, it's the design benefit
22:34:24  <rendar>having 10k mutexes is not good design, check this on the web if you don't trust me
22:35:42  * rmg_joined
22:38:09  * dap_quit (Quit: Leaving.)
22:38:47  <rendar>Dirkson: i know that you now feel awesome because your pogram finally woks, but you don't have write code to "make it works", you must love the intellectual challenge it needs to be well designed, if Linus Torvalds would have seen 10k mutexes in some code i'm sure he started yelling at you in all-caps email or something :P
22:40:02  <Dirkson>The LF alternative would basically force me into designing even the simplest function as a series of async functions. (or figuring out how to do coroutines in C) This might end up being as fast, or even mildly faster, than my current solution. But it's certainly not going to make the code a lot more readable. I'd just be trading one difficult-to-reason-about abstraction for another. Again - I really don't like
22:40:05  <Dirkson>using mutexes. Where at all possible, I strongly prefer to send messages. But I haven't been able to come up with a message passing system with -this- data that makes as much sense as just doing the mutex locks.
22:40:16  * rmg_quit (Ping timeout: 252 seconds)
22:41:10  <rendar>let me guess, is this an octree structure to store virtual objects in a real space like that pokemon go app?
22:43:14  <Dirkson>And if the -number- of mutexes is your only objection... Shucks, that's easy to cheat. I could easily just move the mutexes up several layers in the octree-like structure, and suddenly I have like 10 of them. But why bother? I'd still have to reason about the same number of concurrent mutexes, which is where all the real complexity comes in. Except now whenever one thread wants -anything- in one of the
22:43:16  <Dirkson>octrees, it's got to lock down the whole octree.
22:43:35  <Dirkson>rendar: No? I'm storing ships in space. It's a voxel space game.
22:43:50  <rendar>cool
22:45:05  <Dirkson>I can totally see your guys' objections if I were trying to grab a bunch of mutexes concurrently. Anything more than 2-3 mutexes grabbed at the same time and I start trying to find ways to fix my design :D
22:45:18  <Dirkson>(At the same time on the same thread)
22:45:33  <rendar>Dirkson: my point is: i could write an hashtable with 10k mutexes, where i have 1 mutex for each row of the table, but that would suck because lock-free hash table do exist.. it's not the high number of mutexes, it's just maybe you want to design it in another way and reconsider the overall design.. e.g. check this out: https://github.com/tunabrain/sparse-voxel-octrees
22:45:39  <rendar>https://github.com/adriankrupa/Octree
22:45:53  <rendar>http://stackoverflow.com/questions/11184734/threading-an-octree
22:46:12  <Dirkson>rendar: C++ :-/
22:47:27  <rendar>so?
22:47:40  <rendar>v8 and node.js are in C++
22:48:40  <Dirkson>rendar: I'm currently coding in C, and don't know C++. I don't know v8 or node.js either. These are not insurmountable issues, but they do increase the amount of time it'd take me to make headway. Particularly C++ - It's huge beyond belief.
22:49:32  <rendar>Dirkson: a l33t coder doesn't just say ":/" for a language, he just learns it..i hate java but i can read it, and i enjoy to spot differences with C++, for instance - what you need practically now to know is that C++ data structures are almost C code, i mean the big part you need to understand-the algo-is basically plain C
22:49:40  <rendar>just ignore the other stuff
22:49:49  * Fishrock123quit (Quit: Leaving...)
22:50:00  <Dirkson>rendar: I am definitely not any kind of l33t :D
22:50:06  <rendar>lol
22:50:38  <rendar>i need to sleep now, but if you want we can discuss this tomorow, i like to discuss more about octrees, since it's a topic i'm working on
22:50:41  <rendar>good night
22:50:44  <Dirkson>Night
22:50:53  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
23:00:42  <Dirkson>Well damn. I seem to be wrong about what was causing my error anyway.
23:04:59  * importantshockquit (Remote host closed the connection)
23:05:45  * addaleaxquit (Remote host closed the connection)
23:28:43  * importantshockjoined
23:36:23  * rmg_joined
23:38:29  * addaleaxjoined
23:39:22  * rgrinbergjoined
23:40:34  * rmg_quit (Ping timeout: 244 seconds)
23:42:03  * importantshockquit (Remote host closed the connection)
23:52:23  * PerilousApricotquit (Remote host closed the connection)
23:56:56  * PerilousApricotjoined