Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-07-09

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

All times shown according to UTC.

Time Nick Message
09:14 FROGGS joined #moarvm
09:38 dalek joined #moarvm
10:04 pyrimidi_ joined #moarvm
13:50 mst joined #moarvm
13:50 mst_ joined #moarvm
13:57 mst joined #moarvm
13:57 brrt joined #moarvm
14:07 dalek MoarVM: f47a6ce | jnthn++ | src/6model/reprs/MVMMultiCache.c:
14:07 dalek MoarVM: Remove not-exactly-right and unhelpful comment.
14:07 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f47a6ce801
14:47 brrt joined #moarvm
14:53 brrt good * #moarvm
14:55 timotimo hey brrt
14:55 brrt hey timo
14:55 brrt how are you
14:56 timotimo i'm all right, i think
14:56 timotimo i'm glad i had a bit of energy to start work on the split_bb_at function, but i'ven't been able to actully test it yet
14:58 brrt hmmmm
14:58 brrt i have an idea
14:58 timotimo oh? :)
14:58 brrt put in test code that splits basic blocks at every 'say' op
14:58 brrt they are basically never used
14:59 timotimo that's not bad
14:59 brrt count on me for you daily evil hacks ;-)
14:59 timotimo \o/
15:00 brrt if i ever start blogging again, i should have a sections 'madmens hacks'
15:00 brrt anyway
15:00 brrt i will hopefully have time again to work on moarvm in some weeks
15:00 brrt because, i am soon to be finished with my thesis
15:01 timotimo \o/
15:01 timotimo with the exprjit, guardcontconc and friends will hopefully become quite a bit cheaper
15:01 brrt some time, at least, because i'm starting my new job just afterwards
15:01 timotimo because right now we have that as "check if it's concrete, call its .fetch and check the result against the provided type"
15:02 timotimo but i expect the .fetch (aka decont) could be quite a bit cheaper if it were spesh'd, too
15:02 brrt well, i think the point of that is more that we should internalize the rakudo extensions
15:02 timotimo i.e. if we were able to turn it into a sp_p6oget_o or sp_geto or what it's called
15:02 timotimo that, too
15:02 timotimo but i don't see how that directly interacts with what i mentioned?
15:03 brrt i think... hmmm..
15:03 timotimo also, after a guardcontconc (or whatever) we're likely to have a decont following it to use the actual value inside, so we'll end up deconting at least twice
15:03 brrt right
15:03 brrt so we should kill that bit where we have to decont in the guard
15:03 timotimo hm, though, making the decont better relies on knowing the type, right?
15:04 brrt i think so...
15:04 timotimo maybe that's also part of what's guarded for. so instead, we should replace the upcoming decont with just re-using the value we found when guarding? maybe?
15:04 * timotimo checks the code again
15:04 brrt this is another one of these areas where i don't really know
15:05 timotimo this piece of perf report is so jumbled %)
15:05 timotimo the asm is all over the place with regards to the original source code
15:05 brrt we could possibly replace the sp_guardcontconc with a guard for the container, a decont, and a guard for the result
15:06 brrt possibly one of the reasons why we didn't do that before was that we couldnt allocate a scratch register in spesh, and now we cna
15:06 brrt *can
15:06 timotimo what made me aware of this is this
15:06 timotimo i ran a random example code under perf record -g
15:06 timotimo and the instruction perf jumped to when i told it to annotate mvm_interp_run, was in "if (r.o && IS_CONCRETE(r.o) && STABLE(r.o) == want_v)"
15:07 brrt unrelated thought: i realised that all technical projects have 3 phases, whcih are research, design, and development; no project can skip any of those phases;, most development methodologies either conciously or not tend to ignore one of them
15:07 timotimo that's in guardcontconc
15:08 brrt uhuh..... (what does perf record -g do?)
15:08 timotimo same as perf record, but also records the stack above whatever got sampled
15:08 timotimo need it to get inclusive vs exclusive measurements
15:09 brrt aha
15:10 brrt (for instance, 'waterfall' tends to ignore or minimize the research phase; while 'scrum' tends to focuso on development to the detriment of all else, substituting meetings for design)
15:12 psch brrt: i think specifically for waterfall that's an artifact of how new and quickly-growing IT is
15:12 psch brrt: as in, in traditional engineering projects, waterfall comes with a research phase
15:12 brrt i tend to think that waterfall is kind of a strawman
15:12 timotimo waterfall is meant to have the research phase in the beginning
15:13 timotimo where you run interviews with users and such
15:13 brrt in traditional engineering projects, prototypes and mockups are par for the course
15:13 brrt and macquettes etc
15:13 timotimo i don't know what a macquette is
15:13 brrt it is possibly a dutch word
15:13 timotimo sounds a bit french :)
15:13 brrt a small scale model
15:13 timotimo ah
15:13 timotimo mockup :)
15:13 brrt right
15:13 timotimo well, it sounds like that at least?
15:14 brrt yeah
15:14 brrt you get the point at least :-)
15:14 timotimo aye
15:14 brrt well, point is, there is nothing wrong with a 'waterfall' model /if/ a prototype has proven that the principle is sound
15:15 * jnthn was part of a team doing scrum for some months, and can relate to the meetings/design thing
15:15 brrt and neither is there anything wrong with agile, /if/ it manages to keep a proper place for research and design
15:15 timotimo i wonder if the split_bb_at api should also take an extra BB and make sure that gets properly hooked up
15:16 jnthn There's this notion of "ok, this task is bit, let's break it down"
15:16 timotimo rather than asking the consumer of the API to do that
15:16 brrt what extra bb is that
15:16 timotimo well, i split bbs because i want to turn the tail of the bb into two parts
15:16 brrt yeah, i think it isn't quite obvious that this is a design thing to do
15:16 jnthn But to me decomposition is one of the hardest things to get right.
15:16 timotimo in my use case that's the original tail and a deopt bridge
15:16 brrt uhuh
15:16 jnthn And there's no way I can do it optimally in a meeting.
15:16 jnthn I don't even think it wants doing by a group.
15:17 psch well, "design by comitee" is meme for a reason
15:17 psch +t
15:18 brrt could also explains why most engineers hate having to make estimates, because we're often asked to do this before we have even started the research phase
15:18 jnthn timotimo: I'd keep split_bb as just doing the splitting. Done one thing and do it well. :)
15:18 timotimo mhm, right
15:18 * brrt agrees
15:18 jnthn *Do one...
15:18 timotimo though i think i want to add a second function to do the splicing, then
15:19 jnthn timotimo: Sure :)
15:19 timotimo it'd have to touch the forked bb to add an extra succ, and an extra child, as well as give the new bb its pred
15:19 timotimo we don't link from child to parent, at least
15:19 timotimo though maybe at some point we'll want to?
15:20 timotimo because succ vs parent isn't 1:1, right?
15:20 jnthn child/parent are about the dominance tree
15:20 jnthn next/succ are about the CFG
15:21 timotimo yeah
15:21 timotimo is dominator tree only interesting for creating the SSA, though?
15:21 timotimo won't we want to sometimes ask the dominator tree what's what?
15:21 jnthn Well, we use it as a traversal order for one
15:21 timotimo that part i remember
15:22 jnthn And I believe get some safety promises as a result
15:23 jnthn https://rt.perl.org/Ticket/Display.html?id=128553&results=44d4793b344a946f7295328a78838a6d is some kind of MoarVM bug around call captures...ran out of energy to hunt it for now
15:24 jnthn Can reproduce it just by cloning the Perl6-Base64 module of ugexe and running the second test under perl6-valgrind-m
15:25 jnthn Will continue on it next week but if anyone fancies a bug hunt... :-)
15:25 jnthn bbiab
15:49 domidumont joined #moarvm
15:55 domidumont joined #moarvm
16:10 domidumont joined #moarvm
17:04 domidumont joined #moarvm
17:59 rurban_ joined #moarvm
19:51 domidumont joined #moarvm
21:15 zakharyas joined #moarvm
21:45 TimToady joined #moarvm

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