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