00:13 brrt joined 01:47 ilbot3 joined 04:39 colomon joined 06:27 FROGGS joined 06:59 zakharyas joined 07:22 FROGGS joined 08:33 brrt joined
brrt \o 08:36
nwc10 o/ 08:38
jnthn o/
brrt hmm... i have something of a cunning plan, or rather a plethora of plans 08:43
care to hear them out?
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
e.g. (let (($foo (bar)) (($baz (baz $foo))) (if (nz $foo) $baz $foo) 08:45
that one would actually work, btw, but anyway; 08:46
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
well, there are any number of solutions, some of which preferable to others 08:47
a): use the underlying 'linear' order for code generation; that would solve this immediately 08:48
but it is very inflexible with regards to optimizations
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:49
c): adapt the preprocessor and template builder to add roots for the values in the 'let' statement, thereby achieving the same 08:50
(roots were meant to be 'terminals'. like stores, calls, and binds, and have a fixed evaluation order) 08:53
of the three, i think i like C best, because it'll still allow me to change statement order later
jnthn *nod* 08:55
re-ordering needs care
Of note, you need to never re-order memory operations around a fence
brrt uhuh
jnthn Or something that implies one (e.g. lock taking)
brrt hmm 08:56
my suspicion is that most of these things will be calls
jnthn yeah
brrt which already enforce ordering
jnthn which you already take as ... OK, good :)
brrt :-)
09:12 Ven joined 09:31 TEttinger joined
brrt omg 09:37
this just works
jnthn \o/
JimmyZ \o
brrt o/ JImmyZ 09:38
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:39
it's possible to think logically about it, again :-) 09:40
oh, there was another option, D): - just recompile the value if it's 'lost 10:08
that is also a good option
but not universally valid 10:09
dalek arVM/even-moar-jit: 2e20c52 | brrt++ | / (3 files):
Enforce linear let evaluation order

  'let' expressions allow the use of shared subexpressions. If
evaluated in a conditional, the subexpressions may be invalidated, meaning it is 'lost' for further use. By enforcing 'let' expressions to be compiled in their order of declaration, we ensure that they are always available.
In the rare cases that this order is too strict, an optimizer can potentially reorder statements.		 10:11
brrt fairly sure that's not all of it, from inspection 10:13
10:38 Ven joined 10:43 xiaomiao joined 10:56 TEttinger joined, xiaomiao joined 11:03 xiaomiao joined 12:42 brrt joined
brrt hah, that's funny 12:51
the goto statements becomes a root before the stores 12:52
the fact that adding stores-at-the-end is not good enough for most blocks is becoming rather obvious 12:54
or, to put it in another way 13:21
nonexplicit stores are a value management problem
ensuring evaluation orde is a different problem 13:22
13:28 JimmyZ_ joined 13:46 brrt joined
dalek arVM/even-moar-jit: b1f791c | brrt++ | src/jit/log.c:
Small error in roots logging
 13:49
14:40 rob joined 14:42 prammer joined 14:44 harrow joined
brrt blag past: brrt-to-the-future.blogspot.nl/2015...alues.html 15:09
timotimo i'm hoping to get the weekly done on monday this time 15:10
jnthn ooh, I should write my weekly progress report today also then :) 15:11
timotimo oh
i'd appreciate that :)
jnthn just wrote the final content slide of the course he's been working on for way too long
Perl 6 can have the rest of my brainpower today :)
timotimo i like that announcement :)
jnthn I think I need a little break though... 15:12
bbiab
15:20 FROGGS joined 17:49 colomon joined
masak brrt: I like your post. thanks. 18:12
brrt++
TimToady (mental progress)++ 18:14
18:47 colomon joined 18:48 brrt joined
brrt masak, TimToady: thanks :-) 18:49
github ui just let me make a branch out of nothing 19:03
very .. wow o.O
jnthn Oh, a naked branch? 19:04
Or whatever they're called
No wait, I'm thinking of bare repositories...
flussence I think it allows that because it's how they do the website hosting thing, they're called orphan branches iirc 19:06
jnthn yes, orphan! 19:08
.oO( good job this isn't one of my days teaching git... )
brrt hmm... in this case it's just a clone of master. i was speaking of the fact that it happened quite accidentally 19:13
hmm it's advice time again, i think 19:17
currently, i add only roots for a): statements b): at the end for storing the final computed values 19:33
the stores, of course, are also statements
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:36
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
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:39
that would put the proof of reordering to an optimizer 19:41
jnthn brrt: Well, re-ordering generally *is* an optimization... 19:50
brrt clearly :-) 19:51
jnthn And since the best re-ordering may be per CPU arch...
...we don't want to couple of too tightly into anything I guess.
brrt tell me about it... have you read about the instruction scheduling optimisations 19:52
that stuff is ... well, immensely complex
jnthn Not recently, but I'm aware it's a big area :) 19:55
dalek Heuristic branch merge: pushed 16 commits to MoarVM/even-moar-jit by bdw 20:00
brrt ok, i'm off for tonight 20:01
see you tomorrow :-)
jnthn 'night, brrt++
brrt night, jnthn++ :-)
20:17 colomon joined 23:14 xiaomiao joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!