github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
samcv m: my @list; sub add-to (@list, $item) { if 2.rand.Int && @list { splice @list, 1, 0, $item } else { unshift @list, $item }}; for ^10 {add-to(@list, $_)}; say @list 01:11
camelia [9 5 8 7 6 4 3 0 2 1]
samcv # that is demonstrating randomizing inserting at the first or second place 01:13
so it's more randomized for sure
Geth MoarVM: jstuder-gh++ created pull request #891:
Alter some exprjit templates to remove branching		 02:15
02:23 lizmat left 05:18 brrt joined
brrt \o 05:49
06:01 domidumont joined
samcv \o 06:05
06:08 domidumont left 06:09 domidumont joined 06:19 domidumont left 06:24 brrt left 06:36 robertle joined 07:42 brrt joined 07:54 domidumont joined 08:06 brrt left 08:07 brrt joined 08:13 dogbert17 joined 08:14 robertle left, robertle joined, [Coke] joined 08:15 [Coke] left, [Coke] joined 08:35 lizmat joined
brrt oops, another ARG6 issue that appveyor spotted 09:00
Geth MoarVM: 2592774c56 | (Jeremy Studer)++ (committed by Bart Wiegmans) | 2 files
Make minor alterations to some exprjit templates

  * isfalse_s can use a flagval instead of branch
  * Remove the 'let' from iscoderef template
  * Alter is_vmnull macro so that it can be flagval-ed		 09:04
MoarVM: bd8361e2f8 | (Bart Wiegmans)++ | src/jit/x64/emit.dasc
[JIT] Fix ARG6 for windows better

Can't read from memory and write from memory at the same time		 09:05
09:14 lizmat left 09:34 zakharyas joined 09:40 brrt left 10:17 jpf1 left 10:23 MasterDuke left 10:34 brrt joined 11:49 jpf1 joined
brrt .tell Zoffix we could have such an option, but I'd prefer not to; I'd prefer to have a nativecall impl on WSL that didn't need to make a hole in OS exploit defenses 11:57
yoleaux brrt: I'll pass your message to Zoffix.
12:12 brrt left 12:37 brrt joined 13:45 brrt left
Geth MoarVM: 9745f9216c | (Jonathan Worthington)++ | src/spesh/plugin.c
Add facts to attributes in spesh plugin guards

So that if we do chained attribute lookups, then we'll be able to lower those in the chain.		 13:46
MoarVM: 7ac0610922 | (Jonathan Worthington)++ | src/spesh/plugin.c
Correct a mis-placed `break` statement

Which caused us to sometimes spit out a bogus guard, and thus deopt when we shouldn't have.
jnthn That last one was confusing. "Why does this spesh plugin make things waay slower?!" :)
13:51 scovit joined 14:00 zakharyas left 14:09 brrt joined
jnthn The spesh plugins seem to be working overall quite nicely by this point. 14:52
However, switching assignment to be done in terms of MoarVM bytecode rather than C code makes us very dependent on inlining. 14:53
And there's some cases where the order of producing stuff heuristic leaves us with nothing to inline 14:54
So I think my next task is making it so if we know the target of a call but have no optimized candidate for it yet, then we produce one and try to inline it.
(If the code size is small enough)
That aside, it's nice to start seeing all the binds and checks going on expressed in the bytecode, not hidden away in chunks of C code 14:57
brrt yes, yes, yes 15:12
oh there's two more thoughts that I wanted to discuss 15:13
one. we're running out of opcode space, as in, extops start at 1024, and we're at 870 or so
(it would be interesting to graph) 15:14
jnthn Don't think they grow fast enough for that to be a problem, tbh.
brrt two, maybe there is a systematic way in which we can make 'dependent' spesh candidates, rather than relying on order-of-processing 15:15
jnthn Given that we're already keen to eliminate ext ops
brrt :-)
jnthn Yes, there probably is a way to be cleverer, but we'll still want to produce inlines for things that are used in highly type-variant wys 15:16
*ways
But that specialize nicely once inlined
Geth MoarVM: af455397f0 | (Jonathan Worthington)++ | src/spesh/optimize.c
Refactor inline logging; detect missed inlines

Missed being those where we could potentially do an inline, but we do not do so because we didn't specialize them yet.		 15:17
jnthn That at least lets me see that it is a problem :)
brrt you'd want to extrapolate spesh facts from the inliner to the inlinee (we can probably do that now)
jnthn Yup 15:18
15:21 zakharyas joined
brrt fwiw, I still haven't dropped the whole 'trace specialization' idea :-) 15:35
but I think I can frame it in a way that it fits MoarVM and spesh rather than the other way arround
and hopefully relatively cheap to implement 15:36
jnthn Sounds interesting :)
brrt :-) 15:38
on the other hand, so many broken stuffs to fix left :-(
jnthn Yeah, and the code we're producing after specialization is still full of stuff it'd be nice to be rid of 15:42
After I've done the thing I described a moment ago, I think it'll be time for a revisit of deopt
timotimo jnthn, how detailed would you want deopt logging in the profiler to become, once we log more than just the count of deopts? 15:43
yoleaux 14:53Z <Zoffix> timotimo: this segafauls, in case you're interested: ./perl6 --profile --profile-filename=prof.html -e 'say "127.0.0.1" ~~ /^ [ <{0..255}> ]**4 % \. $/; say now - ENTER now' R#2013 15:44
synopsebot R#2013 [open]: github.com/rakudo/rakudo/issues/2013 [SEGV][perf] Very slow regex
jnthn timotimo: If we can cheaply figure out what kind of guard failed, I guess it's nice, though I dunno if we can
e.g. "Expected type X but got Y" 15:45
timotimo add a profiler version of every guard op, so we don't have to put an "if is profiling" check in every deopt function ... :\
jnthn Just insert a "the last guard is" op before every guard :) 15:50
When profiling
Oh, though I guess that still needs checking 15:51
Though given the overall cost of deopt...I don't think a "are we profiling" check in there will amount to much cost
brrt oh, you know what does need a revision... the code in exception that does the throwpayloadlexcaller 15:53
16:08 zakharyas left 16:18 robertle left 16:21 domidumont left 16:22 zakharyas joined 16:38 zakharyas left 16:44 MasterDuke joined 16:46 lizmat joined 17:21 brrt left 17:28 zakharyas joined 17:37 domidumont joined 17:55 zakharyas left 18:31 brrt joined, brrt left
japhb jnthn: How far do you think you are from merging back to master? What with all the jit templates and such, I'm wondering if a bump is in order, or if we should wait for you to merge ... 18:42
18:51 domidumont left 18:56 kanopis joined 19:16 kanopis left
dogbert17 I haven't seen this before: Bytecode validation error at offset 84, instruction 13: operand type 152 does not match register type 24 19:25
got this with 'MoarVM version 2018.06-103-gaf45539' when running: MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./perl6 t/spec/S02-types/native.rakudo.moar 19:28
19:29 lizmat left 19:33 zakharyas joined
dogbert17 ==20533== Conditional jump or move depends on uninitialised value(s) 19:34
==20533== at 0x11CC2248: ???
==20533== by 0x51C995A: MVM_jit_code_enter (interface.c:24)
MasterDuke dogbert17: can you repro it with the jit(s) disabled? 19:37
19:39 lizmat joined 19:46 lizmat left
dogbert17 MasterDuke: no, it disappears if I add MVM_JIT_DISABLE=1 19:49
MasterDuke what about MVM_JIT_EXPR_DISABLE=1 ? 19:50
dogbert17 with MVM_JIT_EXPR_DISABLE=1 MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 the problem remains 19:52
MasterDuke timotimo: have you looked at github.com/rakudo/rakudo/issues/2013 ? with MVM_SPESH_INLINE_DISABLE=1 it does create a 2.1mb profile, but the most expensive routine (symbol gen/moar/stage2/QASTNode.nqp:936) is only 850ms, which seems odd 19:53
dogbert17: wonder if it's related to github.com/MoarVM/MoarVM/issues/862 ? 19:54
dogbert17 is watching soccer atm, looks as if the game between England and Colombia might go to overtime 19:55
jnthn is probably fuming right now 19:58
moritz that was... close :-) 20:06
20:54 AlexDaniel joined 20:58 zakharyas left
jnthn Can't believe England won a penalty shootout. :P 21:15
21:16 Kaiepi joined
AlexDaniel squashable6: next 21:16
squashable6 AlexDaniel, āš šŸ• Next SQUASHathon in 2 days and ā‰ˆ12 hours (2018-07-07 UTC-12āŒUTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
stmuk_ jnthn: its some strange alternate time line 21:20
jnthn japhb: My branch is in Rakudo, rather than here. In terms of how close: I could in theory polish the branch up in terms of correctness, sort out the JVM regression still to go, and merge. And we'd get a performance regression to go with it.
japhb: Scalar is at the heart of most things, and a bunch of stuff now needs to be re-tuned for the new model. Things that hadn't used to matter so much now matter more. 21:22
japhb: I've decided to deal with the most pressing aspect of that, then get the branch ready for merge. 21:23
japhb Oh sure, that wasn't pressure. That was just wondering if a bump was in order to catch NQP/Rakudo up with current MoarVM, or if you were about to merge everything and make such a bump moot. Turns out the mootness goes the other way, since you're not merging here. :-) 22:04
jnthn Well, may be worth a bump, though my couple of perf fixes in MoarVM today probably only toouch code paths that the new Scalar stuff uses 22:44
(Of course, lots of others have done lots of other stuff :)) 22:58
MasterDuke it's been almost a week since the last bump
jnthn Feel free to do one :) 23:04
MasterDuke oooh, an opportunity to use my new rakudo commit bit 23:12
AlexDaniel yes :) 23:15
MasterDuke is just double-checking that things build ok
jnthn AlexDaniel: A quick heads up: the master branch of Rakudo has a long-standing bug where a Proxy was not decont'd in places it should have been (when returned from a non is rw / is raw sub/method). This caught a couple of busted things in Rakudo's source and there's also some spectests that were wrong. I suspect we'll have a little ecosystem fallout. 23:17
oops, *Fixing this caught
Well, if we just ship the fix we will. 23:19
It's probably possible to put in a bug-compat hack if we gotta.
23:19 Kaiepi left
timotimo just for one release or until 6.d? 23:20
23:21 Kaiepi joined
jnthn Dunno. Probably we'll have to see what the fallout is. 23:21
I suspect our ecosystem is too big for it to be zero. 23:22
AlexDaniel jnthn: thanks. OK, we'll see where we stand after a toaster run 23:24
jnthn Yeah, I think that'll be best
AlexDaniel I'd do it next week if nobody beats me to it 23:26
jnthn OK. I aim to merge later this week.
Though the stuff I'll work on tomorrow has risks of being tricker than I'm hoping it will be. 23:27
Is this a Star release?
AlexDaniel huggable: star 23:28
huggable AlexDaniel, Estimated Rakudo Star releases: .01, .04, .07 & .10
AlexDaniel yes
jnthn Hm, ok.
How easy is it to toaster a branch? 23:29
AlexDaniel just as easy as toasting master
jnthn OK. I wonder if it'd be wise to do that and understand the fallout before merge.
releasable6: status
releasable6 jnthn, Next release in ā‰ˆ17 days and ā‰ˆ19 hours. 1 blocker. 0 out of 64 commits logged 23:30
jnthn, Details: gist.github.com/a1d05b8caf8f7c3fa4...1324c07288
jnthn Ah, 17 days is quite a while
That's enough time to deal with fallout.
(Of my changes in general) 23:31
AlexDaniel uh, not exactly
ugexe++ pointed out an issue some time ago
thing is, most users don't upgrade their modules when they upgrade their rakudo
so ideally we should give it some time to preseed fixed modules 23:32
jnthn Ah, to be clear: I meant fallout of things my branch breaks that I *don't* know about.
Which would almost certainly be things that I just need to fix.
AlexDaniel right
jnthn That's separate from the intended/desired behavior change issue I mentioned earlier.
greppable6: Proxy 23:33
greppable6 jnthn, 359 lines, 69 modules: gist.github.com/40efe0efabcc0daba4...7ccb891cb6
jnthn greppable6: Proxy.new 23:34
greppable6 jnthn, 163 lines, 48 modules: gist.github.com/ae3074335fdc72a467...4022571e87
jnthn greppable6: help 23:35
greppable6 jnthn, Like this: greppable6: password # See wiki for more examples: github.com/perl6/whateverable/wiki/Greppable
jnthn Aww, I can't ask for n lines of context :)
AlexDaniel oh!! That would be so cool!
jnthn Very, then for most cases I could just look at the report and see if the Proxy is used inside of a sub or method that's not marked rw/raw :) 23:36
AlexDaniel how come I didn't think about it, ack/grep is useless without it
jnthn It's already really nice to be able to grep all the known modules :) 23:37
AlexDaniel github.com/perl6/whateverable/issues/335 :)
AlexDaniel sadly looks at 229 issues 23:38
jnthn Issues just mean somebody cares about it :) 23:49
'night o/ 23:58

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!