02:15 colomon_ joined 05:08 geekosaur joined 05:32 brrt joined 05:45 domidumont joined
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.
brrt nine: that is true :-)
but
y'all knew there was going to be a
'but' 05:46
in my experinece, the effort to pick the 'right' data structure has payed of heavily in the development of the new linear scan allcoator
especially compared to the previous allocator
05:46 domidumont joined
brrt well, i should say, 'right' data structures and 'right' algorithms 05:47
05:53 domidumont joined
Geth MoarVM/even-moar-jit: 7a88f7236b | (Bart Wiegmans)++ | src/jit/linear_scan.c
Actually use the bitmap sets correctly

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