Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-07-21

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:06 TEttinger joined #moarvm
02:54 FROGGS joined #moarvm
03:55 dalek MoarVM: cc23702 | hoelzro++ | src/io/syncs (2 files):
03:55 dalek MoarVM: Die when we try to accept() or read() outside an originating thread
03:55 dalek MoarVM:
03:55 dalek MoarVM: Addresses MoarVM #165
03:55 dalek MoarVM:
03:55 dalek MoarVM: libuv doesn't like it when you use a uv_stream_t outside of the
03:55 dalek MoarVM: event loop that created it, and since MoarVM has an event loop
03:55 dalek MoarVM: per thread, this causes problems.  The problem you see is that your
03:55 dalek MoarVM: reads are always zero in length and your accepts never return.
03:55 dalek MoarVM:
03:55 dalek MoarVM: This change is not ideal; I'd rather change MoarVM so that a user
03:55 dalek MoarVM: can actually do this (there are some strategies discussed on
05:05 lizmat joined #moarvm
05:13 lizmat_ joined #moarvm
06:05 FROGGS joined #moarvm
06:54 Ven_ joined #moarvm
07:00 zakharyas joined #moarvm
07:13 brrt joined #moarvm
07:23 brrt good \o
07:24 nwc10 good  o/
07:38 brrt i think i can calculate first use, last use, num use etc. information during tree construction
07:39 brrt question is, should i
07:39 brrt or should i add an analysis step to achieve the same
07:41 lizmat_ would you ever *not* need that information?
07:42 brrt one can scrape by without it
07:42 brrt but generate very, very lousy code
07:42 lizmat so you would always need it basically
07:42 lizmat then I would think during tree construction...
07:43 lizmat but jnthn may have better feedback...
07:43 lizmat and I'm about to get some sleep&
07:43 brrt sleep well :-)
07:49 brrt it's not very costly to do it either way
07:49 brrt hmm
07:51 brrt ok, i think you're right
07:51 brrt it won't complicate construction too much
08:00 Ven joined #moarvm
09:04 nwc10 good *, jnthn
09:18 Ven joined #moarvm
09:50 JimmyZ_ joined #moarvm
09:59 brrt ok, i was wrong, it's much harder to do during template construction than during a separate analysis phase, *but* that requires i keep array of speshins -> root
09:59 brrt that's probably a good idea anyway
10:11 brrt question.. what should be my policy on revisitng nodes in the expr DAg
10:11 brrt DAG
10:12 brrt a): make it optional
10:12 brrt a): continued: make it optional by adding a single flag that determines the behavior of the traverser
10:13 brrt b): make it optional by adding a revist function pointer, to determine if i should visit it again
10:13 jnthn You need to be careful not to get into infinite loops here, I guess?
10:15 brrt by default, infinite loops are prevented by the acyclicness of the graph. if anything ever introduces a cycle, we have a problem anyway, not just with traversal :-)
10:15 brrt i have c) and d) left, which are always and never revisit
10:15 jnthn Oh...
10:16 brrt currently we always revist
10:16 jnthn b may be overkill?
10:16 brrt hmm
10:16 jnthn Unless you have a use-case
10:16 brrt yes, i think so too
10:16 brrt i may have one
10:16 jnthn And invoking FPs lots can be costly
10:16 jnthn Well, depends on their stability I guess :)
10:16 brrt suppose the compiler finds that a node has been previously visited but it's value is 'lost'; it'd need a recompute
10:17 brrt suppose the tiler visits the same node from another  direction; it may choose a completely different tile
10:17 brrt revisiting is not so bad, is what i mean :-)
10:18 brrt c) is relatively costly though, because the DAG can have ehm... I think you can find an example of pretty bad visiting complexity
10:19 brrt d) is too restricitive - or requires the compiler to use more passes, thereby defeating the purpose
10:21 brrt of course, its always possible to decide to do no work in case of c or b
10:21 Ven joined #moarvm
10:49 brrt hmm
10:49 brrt i can't really expect realloc to give a zeroed-at-edges block
10:49 brrt that's a bit of a problem
10:57 brrt a solvable problem, fortunately
10:58 brrt we can just memset the grown block to 0
10:58 brrt pointer arithmetic ftw
11:23 dalek MoarVM/even-moar-jit: f1506ce | brrt++ | src/ (2 files):
11:23 dalek MoarVM/even-moar-jit: Ensure dynamic array block is zeroed
11:23 dalek MoarVM/even-moar-jit:
11:23 dalek MoarVM/even-moar-jit: Being zeored at initialisation is very useful, especially for
11:23 dalek MoarVM/even-moar-jit: pointer arrays.
11:23 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/f1506cef9b
11:45 Ven joined #moarvm
12:24 arnsholt brrt: Yeah, the lack of a realloc that blanks the fresh memory is annoying
12:25 brrt hence my patch :-)
12:26 * brrt wonders if bzero is considerably faster than memset with 0
12:28 arnsholt Probably not, I'd say, unless it's in extremely resource sensitive code (which the JIT could be, arguably)
12:28 arnsholt Also, it might be system dependent which is faster
12:30 brrt hmm...
12:31 brrt one of the benefits of being 'dumb' is that we compile considerably faster than the competition
12:31 brrt of course, the output of the competition is usually much faster
12:36 Ven joined #moarvm
12:38 rudi_s I don't know the details, but bzero is deprecated and most likely not faster than memset with 0 which is heavily optimized in e.g. glibc.
12:39 rudi_s *details of the discussion
12:54 brrt hmmm
12:55 brrt statements yield no values, therefore have no first use or last use
12:55 brrt therefore, i don't actually need to do anything to add to their analysis
13:13 dalek MoarVM/even-moar-jit: 7799558 | brrt++ | src/ (3 files):
13:13 dalek MoarVM/even-moar-jit: Collect usage data for node values
13:13 dalek MoarVM/even-moar-jit:
13:13 dalek MoarVM/even-moar-jit: We collect the first use, last use, and num uses; also the
13:13 dalek MoarVM/even-moar-jit: spesh ins mapping to the node (if any), the expression op info
13:13 dalek MoarVM/even-moar-jit: (we always need it), and the final address of the value (again,
13:13 dalek MoarVM/even-moar-jit: if any).
13:13 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/7799558b1e
13:17 brrt heh, i can also precompute the args, nchild, and children
13:24 * FROGGS .oO( my wife is also good at precomputing N children... )
13:30 JimmyZ_ joined #moarvm
13:31 brrt are these children also nodes?
13:38 * brrt is really rather starting to enjoy pointer arithmetic
13:38 brrt if i end up a bearded C hacker, then i have you to blame
13:40 brrt bbiab
13:41 timotimo personally, i like the "pointer arithmetic" hack where putting the "next" pointer of a linked list entry struct as the very first member so you can just repeatedly dereference the pointer to a single entry and move along the chain
13:41 timotimo but that's hardly pointer arithmetic
13:42 timotimo maybe the opposite is "poitner rithmetic"?
14:10 brrt joined #moarvm
14:11 brrt pointer practice
14:14 brrt i think, until we converted most things in the JIT to expression trees, global register allocation is pretty uninteresting
14:28 arnsholt brrt: Yeah, I got into that same "pointer arithmetic isn't that hard, after all" space after working on the NativeCall code
14:28 brrt it's really useful, in fact
14:30 arnsholt Yeah, it really is a key skill in C programming
14:54 dalek MoarVM/even-moar-jit: 24916b9 | brrt++ | src/jit/log.c:
14:54 dalek MoarVM/even-moar-jit: Minor change, use collected info in tree logging
14:54 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/24916b9eeb
14:57 JimmyZ_ joined #moarvm
15:06 FROGGS joined #moarvm
15:18 Ven joined #moarvm
15:35 JimmyZ_ joined #moarvm
15:57 lizmat joined #moarvm
17:25 brrt joined #moarvm
17:46 Ven joined #moarvm
18:13 zakharyas joined #moarvm
19:48 TEttinger joined #moarvm
20:02 zakharyas joined #moarvm
20:03 lizmat joined #moarvm
20:06 brrt joined #moarvm
20:10 vendethiel joined #moarvm
20:21 lizmat joined #moarvm
20:53 lizmat joined #moarvm
21:52 TEttinger joined #moarvm
22:50 lizmat joined #moarvm
23:02 vendethiel joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary