Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-05-09

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

All times shown according to UTC.

Time Nick Message
02:15 colomon_ joined #moarvm
05:08 geekosaur joined #moarvm
05:32 brrt joined #moarvm
05:45 domidumont joined #moarvm
05:45 brrt good *
05:45 yoleaux 8 May 2017 20:14Z <nine> brrt: "First make it work, then make it fast" can be an iterative game with even the new JIT that's there to be faster first having to work.
05:45 brrt nine: that is true  :-)
05:45 brrt but
05:45 brrt y'all knew there was going to be a
05:46 brrt 'but'
05:46 brrt in my experinece, the effort to pick the 'right' data structure has payed of heavily in the development of the new linear scan allcoator
05:46 brrt especially compared to the previous allocator
05:46 domidumont joined #moarvm
05:47 brrt well, i should say, 'right' data structures and 'right' algorithms
05:53 domidumont joined #moarvm
06:22 Geth ¦ MoarVM/even-moar-jit: 7a88f7236b | (Bart Wiegmans)++ | src/jit/linear_scan.c
06:22 Geth ¦ MoarVM/even-moar-jit: Actually use the bitmap sets correctly
06:22 Geth ¦ MoarVM/even-moar-jit:
06:22 Geth ¦ MoarVM/even-moar-jit: The tile refs array is set up kind of weirdly; it's zero-biased and
06:22 Geth ¦ MoarVM/even-moar-jit: includes only refs to nodes that it uses (excludes itself), which is
06:22 Geth ¦ MoarVM/even-moar-jit: reasonable by itself, but it is at odds with the register requirements
06:22 Geth ¦ MoarVM/even-moar-jit: bitmap, which does include the output register. So that may be target
06:22 Geth ¦ MoarVM/even-moar-jit: for a cleanup.
06:22 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/7a88f7236b
06:23 brrt i guess my point is, it's easy to pick the 'wrong' solution and buy myself time? but the 'wrong' solution tends to introduce all sorts of accidental complexity that the 'right' solution doesn't
06:37 nine .tell brrt Understood :)
06:37 yoleaux nine: I'll pass your message to brrt.
06:42 brrt joined #moarvm
07:21 domidumont joined #moarvm
07:23 zakharyas joined #moarvm
07:51 AlexDaniel joined #moarvm
07:51 praisethemoon joined #moarvm
07:51 praisethemoon joined #moarvm
09:22 * lizmat wonders what jnthn's thoughts are on  https://github.com/MoarVM/MoarVM/pull/592
09:23 lizmat it would improve the speed of things like .pick, .roll, .grab etc. on Hashes / Sets / Bags / Mixes quite significantly
09:23 lizmat *and* simplify the code  :-)
09:28 * brrt will take a lok
09:28 yoleaux 06:37Z <nine> brrt: Understood :)
09:29 brrt i guess i'm saying, tradeoffs and stuff
09:31 brrt my only point against it is, 'at_pos for a hash, that's weird'
09:33 jnthn It adds nothing you can't already do in high-level code using the iterator
09:33 jnthn And algorithm wise it's doing the very same
09:34 jnthn So it's only faster in the sense of "avoids some interpreter overhead"
09:35 jnthn And possibly allocation overhead
09:36 nine Does it look like something the JIT may be able to optimize to the proposed code anyway at some point?
09:41 jnthn The JIT would do away with the interpreter overhead just fine, I'd say
09:41 jnthn It already can somewhat, and the new JIT will be able to better still
09:42 jnthn And the allocations should be a soft target for escape analysis
09:45 brrt but that means I have to work harder rather than MasterDuke or lizmat :-P
09:54 geekosaur joined #moarvm
09:55 nine brrt: fine with me ;)
10:11 zakharyas joined #moarvm
11:07 brrt joined #moarvm
13:05 robertle joined #moarvm
13:19 zakharyas joined #moarvm
13:37 colomon joined #moarvm
13:43 buggable joined #moarvm
14:07 lizmat my POV re #592 is: wish we had a better JIT and escape analysis, frustrated that it isn't there yet, seems like an easy win in the mean time
14:08 lizmat this also feels somewhat as a downvote on the optimizing work I'm doing in rakudoland:
14:08 lizmat it's all going to be better anyway with a better JIT and escape analysis
14:08 lizmat so why waste the time ?
14:12 brrt well, your work in rakudoland usually works by 'lowering' the level of the moarvm code, correct?
14:12 brrt that still helps the JIT very very much
14:12 jnthn A lot of the Rakudo improvemnets are algorithmic, and also what brrt said
14:13 brrt but I do get your POV, it's just, atpos for a hash, not sure if we want to set that precedent
14:13 brrt now what i could get is a special hash pick method
14:14 brrt because that could be a different algorithm (pick a random location in the hash, search until you find an occupiied space)
14:16 lizmat well, but adding such a functionality, let's call it "rollkey", *would* not be caught by JIT and spesh and such atm
14:17 lizmat and would involve much deeper change s
14:17 brrt rollkey, i like it
14:17 lizmat and that would defeat the purpose at this time
14:17 brrt but i disagree, adding a single op isn't that hard
14:18 lizmat but that takes away time from much more needed improvements
14:18 lizmat or not?
14:18 brrt let me think about it
14:18 jnthn One improvement we need to make is re-implementing VMHash anyway
14:19 jnthn Because the current design is explosive if you abuse it from multiple threads
14:19 brrt well, that, too…
14:19 jnthn Adding an atpos only makes that improvement harder
14:19 lizmat now *that* is a reason I can live wity
14:20 lizmat *with
14:20 lizmat ok, end of discussion here
14:20 jnthn But in general, as a design principle, I'm trying to get the surface area of MoarVM down
14:20 lizmat MasterDuke_: sorry for getting you to do this PR, hope you learned from it :-)
14:20 jnthn Or at least better focused
14:21 MasterDuke_ lizmat: no worries, was much easier than anticipated anyway. timotimo++ for the pointers
14:22 jnthn (And yes, I'm frustrated I haven't been able to get as much optimization work in on MoarVM as I'd like.)
14:23 MasterDuke_ closed the PR with links to these discussions
14:37 brrt thanks MasterDuke_
15:05 zakharyas joined #moarvm
15:06 brrt joined #moarvm
15:07 brrt by the way, i've decided for generalizing the heap cod
15:09 Zoffix .oO( heap tuna )
15:10 brrt *heap code :-P
15:23 zakharyas joined #moarvm
15:32 brrt hmm, that appears to be more involved than i had thought
15:39 timotimo isn't it always :)
15:43 brrt yeah, stuffs hard
16:24 Zoffix joined #moarvm
16:53 ggoebel joined #moarvm
17:36 domidumont joined #moarvm
17:49 zakharyas joined #moarvm
17:56 ggoebel joined #moarvm
19:14 AlexDaniel joined #moarvm
19:22 Ven joined #moarvm
19:27 Ven_ joined #moarvm
19:35 robertle joined #moarvm
19:36 Ven_ joined #moarvm
20:13 zakharyas joined #moarvm
20:14 Ven_ joined #moarvm
20:36 Ven joined #moarvm
21:02 Ven_ joined #moarvm
21:20 Ven joined #moarvm

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