Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-07-20

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

All times shown according to UTC.

Time Nick Message
00:13 brrt joined #moarvm
01:47 ilbot3 joined #moarvm
01:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
04:39 colomon joined #moarvm
06:27 FROGGS joined #moarvm
06:59 zakharyas joined #moarvm
07:22 FROGGS joined #moarvm
08:33 brrt joined #moarvm
08:36 brrt \o
08:38 nwc10 o/
08:38 jnthn o/
08:43 brrt hmm... i have something of a cunning plan, or rather a plethora of plans
08:43 brrt care to hear them out?
08:44 jnthn You're sharing my attention with slide writing, but sure :)
08:44 brrt (the problem, for what it's worth, is that the evaluation order of the expression DAG can be quite different from the linear order of the exprlist, even though the exprlist order is quite valid
08:45 brrt e.g. (let (($foo (bar)) (($baz (baz $foo))) (if (nz $foo) $baz $foo)
08:46 brrt that one would actually work, btw, but anyway;
08:46 brrt the (baz $foo) is only evaluated as the second child of if, not before, although it is placed in the (written) order in the tree
08:47 brrt well, there are any number of solutions, some of which preferable to others
08:48 brrt a): use the underlying 'linear' order for code generation; that would solve this immediately
08:48 brrt but it is very inflexible with regards to optimizations
08:49 brrt b): detect these cases of 'cross evaluation' during an analysis phase (i.e. in a tree walk) and insert new 'roots' to ensure their linear pre-evaluation
08:50 brrt c): adapt the preprocessor and template builder to add roots for the values in the 'let' statement, thereby achieving the same
08:53 brrt (roots were meant to be 'terminals'. like stores, calls, and binds, and have a fixed evaluation order)
08:53 brrt of the three, i think i like C best, because it'll still allow me to change statement order later
08:55 jnthn *nod*
08:55 jnthn re-ordering needs care
08:55 jnthn Of note, you need to never re-order memory operations around a fence
08:55 brrt uhuh
08:55 jnthn Or something that implies one (e.g. lock taking)
08:56 brrt hmm
08:56 brrt my suspicion is that most of these things will be calls
08:56 jnthn yeah
08:56 brrt which already enforce ordering
08:56 jnthn which you already take as ... OK, good :)
08:56 brrt :-)
09:12 Ven joined #moarvm
09:31 TEttinger joined #moarvm
09:37 brrt omg
09:37 brrt this just works
09:37 jnthn \o/
09:37 JimmyZ \o
09:38 brrt o/ JImmyZ
09:39 brrt not that it's perfect, it's all still very pseudo. but at least the evaluation order doesn't seem to trip us up as much
09:40 brrt it's possible to think logically about it, again :-)
10:08 brrt oh, there was another option, D): - just recompile the value if it's 'lost
10:08 brrt that is also a good option
10:09 brrt but not universally valid
10:11 dalek MoarVM/even-moar-jit: 2e20c52 | brrt++ | / (3 files):
10:11 dalek MoarVM/even-moar-jit: Enforce linear let evaluation order
10:11 dalek MoarVM/even-moar-jit:
10:11 dalek MoarVM/even-moar-jit: 'let' expressions allow the use of shared subexpressions. If
10:11 dalek MoarVM/even-moar-jit: evaluated in a conditional, the subexpressions may be invalidated,
10:11 dalek MoarVM/even-moar-jit: meaning it is 'lost' for further use. By enforcing 'let' expressions
10:11 dalek MoarVM/even-moar-jit: to be compiled in their order of declaration, we ensure that they
10:11 dalek MoarVM/even-moar-jit: are always available.
10:11 dalek MoarVM/even-moar-jit:
10:11 dalek MoarVM/even-moar-jit: In the rare cases that this order is too strict, an optimizer can
10:11 dalek MoarVM/even-moar-jit: potentially reorder statements.
10:11 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/2e20c52e79
10:13 brrt fairly sure that's not all of it, from inspection
10:38 Ven joined #moarvm
10:43 xiaomiao joined #moarvm
10:56 TEttinger joined #moarvm
10:56 xiaomiao joined #moarvm
11:03 xiaomiao joined #moarvm
11:03 xiaomiao joined #moarvm
12:42 brrt joined #moarvm
12:51 brrt hah, that's funny
12:52 brrt the goto statements becomes a root before the stores
12:54 brrt the fact that adding stores-at-the-end is not good enough for most blocks is becoming rather obvious
13:21 brrt or, to put it in another way
13:21 brrt nonexplicit stores are a value management problem
13:22 brrt ensuring evaluation orde is a different problem
13:28 JimmyZ_ joined #moarvm
13:46 brrt joined #moarvm
13:49 dalek MoarVM/even-moar-jit: b1f791c | brrt++ | src/jit/log.c:
13:49 dalek MoarVM/even-moar-jit: Small error in roots logging
13:49 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/b1f791ca39
14:40 rob joined #moarvm
14:42 prammer joined #moarvm
14:44 harrow joined #moarvm
15:09 brrt blag past: http://brrt-to-the-future.blogspot.nl/2015/07/of-values.html
15:10 timotimo i'm hoping to get the weekly done on monday this time
15:11 jnthn ooh, I should write my weekly progress report today also then :)
15:11 timotimo oh
15:11 timotimo i'd appreciate that :)
15:11 * jnthn just wrote the final content slide of the course he's been working on for way too long
15:11 jnthn Perl 6 can have the rest of my brainpower today :)
15:11 timotimo i like that announcement :)
15:12 jnthn I think I need a little break though...
15:12 jnthn bbiab
15:20 FROGGS joined #moarvm
17:49 colomon joined #moarvm
18:12 masak brrt: I like your post. thanks.
18:12 masak brrt++
18:14 TimToady (mental progress)++
18:47 colomon joined #moarvm
18:48 brrt joined #moarvm
18:49 brrt masak, TimToady: thanks :-)
19:03 brrt github ui just let me make a branch out of nothing
19:03 brrt very .. wow o.O
19:04 jnthn Oh, a naked branch?
19:04 jnthn Or whatever they're called
19:04 jnthn No wait, I'm thinking of bare repositories...
19:06 flussence I think it allows that because it's how they do the website hosting thing, they're called orphan branches iirc
19:08 jnthn yes, orphan!
19:08 jnthn .oO( good job this isn't one of my days teaching git... )
19:13 brrt hmm... in this case it's just a clone of master. i was speaking of the fact that it happened quite accidentally
19:17 brrt hmm it's advice time again, i think
19:33 brrt currently, i add only roots for a): statements b): at the end for storing the final computed values
19:33 brrt the stores, of course, are also statements
19:36 brrt however, that leaves me with the odd situation of frames that a): compile first the last statement, e.g. goto, and then b): calculate all values and store them in appropriate places
19:38 jnthn Hm, that sounds...awkward.
19:38 brrt i can of course catch that particular situation, but the general theme - evaluating stuff in any particular order, defined by the dependency order of statements
19:39 brrt the safest thing i can imagine is defaulting on source instruction  order, that is, to add roots even for expressions (i.e. that yield a value)
19:41 brrt that would put the proof of reordering to an optimizer
19:50 jnthn brrt: Well, re-ordering generally *is* an optimization...
19:51 brrt clearly :-)
19:51 jnthn And since the best re-ordering may be per CPU arch...
19:51 jnthn ...we don't want to couple of too tightly into anything I guess.
19:52 brrt tell me about it... have you read about the instruction scheduling optimisations
19:52 brrt that stuff is ... well, immensely complex
19:55 jnthn Not recently, but I'm aware it's a big area :)
20:00 dalek Heuristic branch merge: pushed 16 commits to MoarVM/even-moar-jit by bdw
20:01 brrt ok, i'm off for tonight
20:01 brrt see you tomorrow :-)
20:01 jnthn 'night, brrt++
20:01 brrt night, jnthn++ :-)
20:17 colomon joined #moarvm
23:14 xiaomiao joined #moarvm

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