Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-11-19

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

All times shown according to UTC.

Time Nick Message
00:29 MasterDuke joined #moarvm
00:39 quotable6 joined #moarvm
00:39 tangible6 joined #moarvm
00:39 releasable6 joined #moarvm
00:39 coverable6 joined #moarvm
00:39 nativecallable6 joined #moarvm
00:39 bloatable6 joined #moarvm
00:39 committable6 joined #moarvm
00:39 bisectable6 joined #moarvm
00:39 unicodable6 joined #moarvm
00:39 greppable6 joined #moarvm
00:39 statisfiable6 joined #moarvm
00:39 benchable6 joined #moarvm
00:39 evalable6 joined #moarvm
00:39 squashable6 joined #moarvm
01:00 lizmat joined #moarvm
01:35 evalable6 joined #moarvm
02:05 MasterDuke_ joined #moarvm
02:40 lizmat joined #moarvm
02:55 ilbot3 joined #moarvm
02:55 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:41 evalable6 joined #moarvm
09:29 lizmat joined #moarvm
09:51 domidumont joined #moarvm
09:56 domidumont joined #moarvm
12:16 robertle joined #moarvm
12:59 benchable6 joined #moarvm
13:10 timotimo it occurs to me that if we know the types of our p6 bigints, i.e. Int, we could spesh the "get_boxed_ref" part out of all the bigint ops
13:14 timotimo it's not responsible for a very large chunk, but it's big enough for my tastes
13:14 timotimo 16 billion incl for the whole MVM_bigint_add and 702 million incl for get_boxed_ref
13:15 timotimo of course when we have our jit be very smart about bigint calculations, we might compile a path that doesn't even allocate Int objects at all?
13:18 jnthn With EA we can at least "allocate" them on the stack
13:19 timotimo right
13:20 timotimo in this benchmark a significant chunk of time is spent in mp_set_long :\
13:21 timotimo 6 billion Ir out of the 16
13:21 timotimo and out of those 6 billion, 5 billion are in mp_mul_2d
13:22 timotimo bbl
13:29 evalable6 joined #moarvm
13:38 nine So a MVM_SPESH_ANN_DEOPT_INLINE annotation is really just a "the inlined code had _any_ kind of deopt annotation" marker?
13:44 nine That means the annotation of the original code could have been a MVM_SPESH_ANN_DEOPT_ALL_INS, i.e. the goto carrying the annotation used to be an invoke_*. In that case the real case to look at is the MVM_SPESH_ANN_DEOPT_ALL_INS one, i.e. entering an inlined BB.
14:13 dogbert17 doc question: what would be a good, one line, description of the Encoding class. Currently we don't have any
14:18 nine Another question: does it really matter what I do? A no_op should already be much better than a goto and will be turned into literally nothing by the JIT. So trying to get rid of it doesn't sound like useful use of my time.
14:34 lizmat nine: could it be that Inline::Python still depends on Panda?
14:35 nine lizmat: I wouldn't be surprised
14:36 MasterDuke nine: don't you only get failures in a very few spots? how hard is it to benchmark no_op vs removed entirely?
14:37 jnthn nine: Well, it's kicking whatever deeper problem exists here down the road for you or somebody else to solve, I guess...
14:38 nine jnthn: and the point of the exercise is actually for me to learn about inlining in spesh. And the no_op trick doesn't work in all cases anyway...
14:38 jnthn Ah, if it doesn't work in all cases, it's less attractive.
14:39 nine jnthn: what really scares me is that you meant this to be a kind of beginner exercise as an entry for me. How hard will my actual goal be then??
14:39 Geth ¦ MoarVM/inline_in_place: 4b25ee8603 | (Timo Paulssen)++ (committed by Stefan Seifert) | 4 files
14:39 Geth ¦ MoarVM/inline_in_place: Put inlined blocks between their caller and its succ
14:39 Geth ¦ MoarVM/inline_in_place:
14:39 Geth ¦ MoarVM/inline_in_place: Previously inlined callees were added to the end of the basic block list.
14:39 Geth ¦ MoarVM/inline_in_place: We now put the inlined blocks into the list at the position of the invoke op.
14:39 Geth ¦ MoarVM/inline_in_place: However we cannot yet get rid of the goto ops entering and exiting the inlined
14:39 Geth ¦ MoarVM/inline_in_place: code as that would lead to odd bugs possibly related to the annotations on
14:39 Geth ¦ MoarVM/inline_in_place: these ops.
14:39 Geth ¦ MoarVM/inline_in_place: review: https://github.com/MoarVM/MoarVM/commit/4b25ee8603
14:39 Geth ¦ MoarVM/inline_in_place: b4b8c5765e | (Stefan Seifert)++ | src/spesh/optimize.c
14:39 Geth ¦ MoarVM/inline_in_place: Turn inline_end annotated pointless gotos into no_ops
14:39 Geth ¦ MoarVM/inline_in_place:
14:39 Geth ¦ MoarVM/inline_in_place: We can't remove them completely as that causes weird deopt issues. But turning
14:39 Geth ¦ MoarVM/inline_in_place: them into no_ops should give almost the same benefits without the cost.
14:40 Geth ¦ MoarVM/inline_in_place: review: https://github.com/MoarVM/MoarVM/commit/b4b8c5765e
14:40 nine I pushed it anyway as it documents the findings in a way.
14:41 jnthn You'd not be alone in putting things off for later in spesh. A good while back I marked lastexpayload :noinline to avoid having to debug the issues inlining it brought up. Only in the last week or so did I fix one, golf another into something in the JIT that brrt++ fixed, and there's still one more issue to hunt down.
14:42 jnthn And the issues rarely show up in nice, simple, isolated examples.
14:47 jnthn As to how hard things are - this tends to hinge on whether in the course of the task, something turns up that makes an in-theory straightforward change expose some other problem, and potentially an existing bug.
14:47 jnthn Which I guess is the issue here
14:48 jnthn bbiab
14:48 evalable6 joined #moarvm
15:14 timotimo so anyway, this for loop code, it passes the 32bit boundary if you set $n to 2047 (surely a conicidence!!), so the default of 10⁴ is spending the vast majority of its time doing big int math for under 64 bit numbers
15:17 timotimo er, it passes the boundary if you set it to 2048, 2047 is the last one below the boundary
15:45 zakharyas joined #moarvm
15:50 zakharyas joined #moarvm
16:22 evalable6 joined #moarvm
16:35 domidumont joined #moarvm
16:46 dogbert17 added some, possibly interesting, info to the thread on https://github.com/rakudo/rakudo/issues/1202
20:40 Ven joined #moarvm
21:00 MasterDuke joined #moarvm
21:03 dogbert17 interesting, stresstesting on a 64 bit VM uncovers problems I don't see on my 32 bit VM
21:07 dogbert17 here's one example, https://gist.github.com/dogbert17/cebea4925ff5b5ca6759da1a183813fc
21:13 Ven joined #moarvm
22:11 MasterDuke joined #moarvm
22:30 unicodable6 joined #moarvm

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