timotimo does libuv do anything afterwards with bufs? 00:00
oh
there's a const in our function signature
you can probably drop that
alternatively put the pointer into our res_buf and then realloc it from there 00:01
i ... don't know why we'd get a run-time error from that
MasterDuke sorry, that was a compile error 00:02
but it worked with the changes i showed
timotimo huh, somehow i missed that line 00:03
more evidence that i should be going to sleep
00:41 markmont joined
MasterDuke A suggested size (65536 at the moment in most cases) is provided, but it’s just an indication, not related in any way to the pending data to be read. The user is free to allocate the amount of memory they decide. As an example, applications with custom allocation schemes such as using freelists, allocation pools or slab based allocators may decide to use a different size which matches the memory chunks they already have. 00:46
from the libuv docs for on_alloc
could we somehow use the FSA for those buffers? 00:47
timotimo we could, but vmarray objects expect to be able to MVM_free their pointers 00:48
we'd have to figure something out for that
MasterDuke i just hard-coded the on_alloc value to 8192 instead of using suggested_size, not a huge difference: 1242396maxresident)k 00:52
timotimo huh
MasterDuke oh, only 516mb were from on_alloc, and that did go down to 69mb 00:54
it's MVM_gc_collect that's doing 1.9gb, then down to 1.7gb 00:55
where are those defined? 00:58
oh, you can't use the FSA, because the signature of on_alloc is fixed and so it doesn't have a tc in it 01:39
here's someone with a similar question/problem in Python: groups.google.com/forum/#!topic/li...QO1HJAIDdA 01:40
01:51 ilbot3 joined 03:30 pharv joined 04:22 yoleaux joined 05:30 lizmat joined 05:52 brrt joined 06:23 brrt joined
Geth MoarVM/even-moar-jit: 74d906b4b6 | (Bart Wiegmans)++ | 3 files
Compile less with --no-jit

We tried to compile all sorts of internal stuff even if we didn't have JTI support configured, and 'stub' had to emulate all sorts of internal routines. That's not necessary now; now the stub only provides a 'public' API, and does not rely on internal structures.		 06:38
06:46 lizmat joined 06:55 brrt joined
brrt good hi, #moarvm 07:04
07:15 Ven joined 07:36 yoleaux joined 07:57 zakharyas joined 08:31 edehont joined 08:36 robertle joined 08:37 edehont joined
jnthn morning o/ 08:50
brrt \o jnthn 08:53
09:01 Ven joined 09:21 Ven_ joined
jnthn brrt: if_o and unless_o aren't marked :invokish, even though they really do invoke 09:45
brrt: I'm considering using invokish/throwish as basic block terminators
Can you think of any problem I'll have if I mark if_o and unless_o with :invokish? 09:46
I'm wondering if there's a reason they are left out.
Ditto for: 09:52
loadbytecode
masttocu
continuationinvoke
parameterizetype
loadbytecdoebuffer
loadbytecodefh
brrt ehm, the main reason is that i translate if_o and unless_o to istrue_o and if_i/unless_i, so i don't need them to be invokish 10:00
and the others i just haven't looked at
jnthn But if I mark them that way because i use these annotations as basic block terminators, I'm not going to upset the JIT? 10:01
brrt not 100% positive, but if you did, it would be easily mitigated
jnthn NQP build/test seems happy with me doing so
(with blocking/nodelay)
Doing a Rakudo build/test to see what it thinks :) 10:02
brrt odds are good the JIT doesn't mind, then
jnthn Didn't change the BB splits yet, just added the annotations.
brrt thanks for the review comments btw :-) 10:04
jnthn Yeah, I didn't get all the way through it yet :)
Will try and continue later on today :) 10:05
brrt yeah, i figured :-) thanks
btw, i since resolved the —no-jit issue
part of the rest of travis's complaining revolves around the use of package foo {..} syntax 10:06
which that version of perl does not support
jnthn ah, ok
Yeah, looks like no bad effects 10:09
Geth MoarVM: 8f70da7674 | (Jonathan Worthington)++ | 2 files
Mark further ops as :invokish.

To get a more accurate set of ops that might invoke.
jnthn Well, we sure get more basic blocks when I start splitting at throwish/invokish :) 10:13
But not more PHIs, which is what I'd expect
e.g. there's no increase in join points
Some failures from the additional splitting though 10:20
brrt hmmm 10:21
jnthn MoarVM oops: Spesh: failed to fix up handlers (-1, 138, 138)
Hmm
At least a couple of those 10:22
a SEGV inside of spesh
And a second one in another place 10:23
OK, so three distinct failure modes 10:24
Quite possibly all of which will turn out to be long-standing issues that we just never hit before...let's see
oh goodness 10:33
The crashes are because we end up with more basic blocks now, and optimize_bb recurses
We actually blow the C stack
brrt lol
jnthn haha 10:34
It happens in the mainline of github.com/perl6/roast/blob/master...c-concat.t 10:35
Which we only try to optimize at all because of NODELAY
That now ends up with 51,000 basic blocks 10:36
And since it's all linear code, the dominance tree will also be a straight line :P
brrt ouch 10:38
jnthn Yeah.
So this only happens because of NODELAY
We'd never attempt to optimize that code in any normal conditions
But for the sake of being robust, I think I'll just stick in an upper limit on bytecode size or some such 10:39
nwc10 until someone (else) refactors optimize_bb not to recurse (and it's no less complex than the current implementaiton) 10:45
jnthn Even then, an upper limit is probably still wise 10:48
The algorithms we're using aren't all O(n)
Geth MoarVM: 7eb021fc60 | (Jonathan Worthington)++ | 2 files
Put hard upper limit on bytecode size to optimize.

To avoid ending up with gigantic, stack-blowing CFGs and dominance trees. We can tweak this limit as needed, but 64KB of bytecode seems quite substantial.		 10:49
jnthn It substantial enough that we never hit it during CORE.setting compilation 10:50
And I know we've some sizable rules/tokens and methods in that
Geth MoarVM: 65bdc2f56a | (Jonathan Worthington)++ | src/spesh/manipulate.c
Move annotations multiple basic blocks if needed.

Sometimes the next or previous basic block won't have an instruction to move the annotation to. So, search until we find one.		 11:04
jnthn With that, my patch to split in invokish/throwish is OK even with blocking+nodelay 11:06
But oddly it seems to cause the number of inlined frames in that lines benchmark to drop? o.O 11:07
Yup, it's exactly that change that does it. Darn. 11:08
oh, I see 11:18
Geth MoarVM: 75f9ac37ed | (Jonathan Worthington)++ | 3 files
Eliminate "blocked by alias" propagation checks.

We explicitly guard decont now, and so cannot run into these kinds of issues any more (and the guards that looked into containers are gone also). We will do some alias analysis in the future to remove some of the guards when we can prove they aren't needed. But we are now safe by default, without needing a check like this.		 11:29
11:31 edehont joined
Geth MoarVM: 4ce52ef48f | (Jonathan Worthington)++ | src/spesh/graph.c
End basic blocks after all throwish/invokish.

This is a bit more honest, and also paves the way for trying to put in more accurate edges for control exception handlers.		 11:31
jnthn lunch &
Oh, also it's possbile that 65bdc2f will have fixed github.com/MoarVM/MoarVM/issues/629 11:32
11:33 lizmat joined 12:07 colomon joined
jnthn back 12:16
brrt ohai
jnthn o/ brrt 12:17
So, let's see if I can figure out this exception handler thingy 12:18
brrt which exception handler thingy is that? 12:19
jnthn The one where instead of anchoring control exception handlers from the root of the graph, we instead link them from all basic blocks within the handler region 12:20
Just going to do it for control exceptions for now
dogbert17 ./perl6 -e 'my $a; for ^100_000 { $a = $_.comb.sort.uniq }; say $a'
No such method 'uniq' for invocant of type 'Seq'. Did you mean 'unique'? 12:21
jnthn What if you MVM_SPESH_BLOCKING=1 and MVM_SPESH_NODELAY=1 on it? 12:25
brrt (i have no idea what that actually means though) 12:26
12:26 colomon joined 12:30 zakharyas joined 12:31 colomon joined
jnthn brrt: The end goal is that we get more precise dominance frontiers, so less PHIs joining things from the entry point, where we know nothing. 12:32
dogbert17 jnthn: both works
jnthn dogbert17: yay :)
dogbert17 jnthn++ bug swatter :) 12:34
Geth MoarVM/even-moar-jit: 94f55f927d | (Bart Wiegmans)++ | tools/tiler-table-generator.pl
Use fewer 'new' perl features

Travis CI tells me it trips over package + block syntax, and apparently also over the /r modifier for substituting regular expressions; we can also do without.		 12:38
brrt lets see if travis Ci agrees with that 12:39
re: the whole stack-spilling-vs-anywhere else discussion, I do believe some CPU's 'optimize' stack-relative access to registers 12:42
or at least, i've heard tell 12:43
the problem with that is that either you now allocate everything from stack, or, you point your stack to your heap-allocated frame - nothing wrong with that, until you start calling other C functions, which expect the stack to be the stack 12:44
13:04 lizmat_ joined
brrt travis is happy! 13:07
jnthn yay :) 13:18
samcv grant status update 3 is up cry.nu/perl6/grant-status-update-3/ 13:26
brrt sancv++ 13:31
sorry samcv++
JimmyZ samcv: s/3.5%/3.5x/ maybe? 13:34
samcv JimmyZ, nice catch heh
JimmyZ samcv: do you mean won't make it more compact which you planed? 13:37
samcv compact? 13:43
timotimo samcv: "add to nqp::codes op to"? :)
"in stthe string"? :)
samcv i think i hit my keyboard in a few places 13:44
since that wasn't there the last time i read through it :P 13:45
should be fixed now 13:46
timotimo i usually hit my keyboard all over the place :D
JimmyZ samcv: reduce the unicode data size 13:47
samcv ah
yeah it might not happen. we will see
JimmyZ that's a sad ,haha
samcv i still am planning to do it though 13:48
timotimo it'll be partially my fault if it doesn't happen :| 13:49
samcv well hm we could do the name space savings. and i leave the rest of the unicode database 13:50
that is workable
since i remember it being substantial, the savings
JimmyZ any a bit improvement is good :) 13:55
samcv but it was like 1.5MB-> like 350KB with the string compression i had experimented with. so that's pretty nice 13:59
Geth MoarVM: 6c02672c95 | (Jonathan Worthington)++ | src/spesh/candidate.c
Extra fflush so spesh log is written before crash.

So we have the data to look at if the next step goes bad.		 14:06
MoarVM: bd6d9222cd | (Jonathan Worthington)++ | src/spesh/graph.c
Ensure frame handler start/ends are BB boundaries.

This will almost always have been the case anyway, but this means we can rely on it.
jnthn So there's good news and bad 14:07
The good is that I seem to have got a working change that gets a more accurate CFG for control exceptions.
brrt the bad is?
jnthn That because an osrpoint is linked from the entry block also, we still have a PHI r7(0) 14:09
14:09 lizmat joined
timotimo oof 14:11
jnthn And that edge is there because when we jump into the optimized code, we don't actually know what holds.
Which is a safe solution
But, uh... :)
ah crap, and my patch doesn't actually quite work :/ 14:17
Oh no, it just uncovers something else... 14:36
timotimo doesn't it always :| 14:37
jnthn We now can end up discovering more things as being unreachable
That it's not quite clear why we don't kill them off when doing BB elimination in optimize.c 14:38
And so they survive until graph.c
Uh, that is, they are parsed again but this time as an inlinee
It looks like we're somehow optimizing out a conditonal 14:42
But the body that becomes unreachable doesn't go away 14:43
Bah, it's 'cus spesh is smarter than I am :P 14:50
Or something like that :)
So there's an osrpoint instruction 14:51
Which is removed
But the basic block is alive and referenced from the entry point because it used to be there
This is all fine
So then we turn it into bytecdoe etc. 14:52
So inline makes a graph of this
But because the osrpoint is done it correctly doesn't insert the edge from the entry point
This is totally correct because there's no way we'll ever OSR into an inline
But know this makes more code dead
Which in turn means handlers get whipped out
*Bu tnow 14:53
But we don't mark them up as such on this code path, and thus why we get fixup errors
The final result of the inlining, if we did succeed in code-gen, is a goto shorter thanks to all of this. 14:54
.oO( why did nobody tell me building optimizers is hard? :P )
 14:55
Geth MoarVM: 6e438edf67 | (Jonathan Worthington)++ | src/spesh/dump.c
Don't explode on spesh dump when no facts.

We may dump at this point when things go wrong, such as in the reverse post-order calculation.		 14:58
japhb jnthn: Because some things you have to learn by doing? ;-) 14:59
15:03 lizmat joined 15:13 brrt joined
Geth MoarVM: 693c5e3574 | (Jonathan Worthington)++ | src/spesh/manipulate.c
Add descriptions to various functions.
 15:24
MoarVM: 9b4bde5403 | (Jonathan Worthington)++ | src/spesh/inline.c
Cope with extra successors when inlining.

Once we start inserting extra successors due to the presence of control exceptions, this will be needed.
jnthn To be fair, many of the correct-but-not-precise things I put in genuinely did allow dealing with tricky things to be put off until there was time to do that. 15:25
And let us have the benefit in the meantime.
Geth MoarVM: 35f82730a4 | (Jonathan Worthington)++ | 6 files
Factor our and re-use dead BB elimination.

The version in optimize was more complete and more correct than the one in graph. This unifies them, using a flag to convey the one small difference that needs to be taken into account.		 15:28
MoarVM: 39dbe1bd77 | (Jonathan Worthington)++ | src/spesh/dead_bb_elimination.c
Allow for GOTO handler to become unreachable.
japhb The bill always comes due, or so they say. Still, as you say, nice the have the benefit in the meantime.
*to have 15:29
[Coke] wonders if japhb has just recently watched Doctor Strange.
japhb I've watched it a couple times. Not terribly recently though. 15:30
15:33 lizmat joined
samcv eater wanted to add unix sockets to moar what has our work been so far with that? 15:37
Geth MoarVM: 0fe5cd606c | (Jonathan Worthington)++ | src/spesh/graph.c
More precise CFGs for control exception handlers.

Prior to this, they were always linked from the entry block. This meant that:
1) PHI nodes were always inserted at the start of a handler, and the
   join always included the entry point. Since this has an empty set
... (12 more lines)
jnthn Phew
samcv: We don't support that in Moar yet, but it should be a case of patching asyncsocket.c 15:38
[Coke] japhb: I just rewatched last night, so that stood out to me as one of mordo's lines.
samcv yeah i know we don't support it yet. will let him know about that. thanks
jnthn Will also need some kind of API design choice up at Perl 6 level, but that's the easy part once we get it working :) 15:39
Well, except for bikeshedding :)
samcv eater is making some init system in perl6 i believe 15:40
jnthn Man, didn't expect to spend all day on that CFG thing
But worth it
samcv github.com/the-eater/shinit 15:41
jnthn The OSR point thing is tricky though...hmm 15:42
What we really want is a way to get the set of guards that we should ensure are upheld in order to enter the code at the OSR point 15:45
ilmari giggles childishly at "already_succs"
jnthn ;)
15:48 lizmat joined
samcv o/ lizmat 15:55
lizmat samcv o/
so, your presentations are ready ? :-) 15:56
jnthn I *think* that if, after doing the opts, we walk the dominance tree...
And note each guard that we encounter
Disregard those that guard an already-changed register
Uh, I mean, if there's two guards on the same register, we take the latter 15:57
Then we should end up with an *over-estimate* of the set of guards that would be in place at that point
The reason being that the dominance tree indicates code paths we always have taken to reach this point 15:58
It's an overestimate becuase we may never rely on the guards again from that point on 15:59
I just worry if there's a way for it to be an underestimate...
samcv lizmat, yeah. just gotta practice a little bit more
and got my grant report done today as well- 16:00
16:01 zakharyas joined
lizmat yeah, it will be in the weekly! 16:02
jnthn Ah, yeah, I guess the problem is that there may have been guards in two branches and then a join point, and the osrpoint would be in the join 16:06
16:06 Ven joined
jnthn while blah() { if foo() { ...guard 1... } else { ...guard 2 ... }; osrpoint; ...blah... } 16:07
Then (if this code structure could happen) we'd have a merge of the facts from guard 1 and guard 2 by osrpoint
But those branches don't dominate the BB where the osrpoint is 16:08
So no, it can't be so simple as I suggested after all.
16:09 robertle joined 16:14 Ven_ joined
jnthn Guess I'll ponder that this evening :) 16:17
afk for a bit
16:28 dogbert11 joined 16:45 lizmat joined 17:13 Ven joined 17:17 edehont joined 17:44 Ven_ joined 18:15 Ven joined 18:28 geekosaur joined 19:04 brrt joined
brrt good * #moarvm 19:06
timotimo good
brrt timotimo: will you be coming to TPC? 19:07
timotimo nope :(
brrt aw, too bad
i thik we've never met in person, have we
timotimo not yet, no 19:10
hrmpf. i'm late for grocery shopping and we haven't decided what to cook yet 19:11
Geth MoarVM: 127fa2ce73 | (Samantha McVey)++ | 8 files
Add indexim_s op and improve/fix bugs in eqatim_s

eqatim_s used to only check that the first codepoints of string a and b were the same using MVM_string_ord_basechar_at. The MVM_string_equal_at_ignore_mark function was added and we now use this instead for the eqatim_s op which fixes the bug when it would say the two strings were eqat when only one codepoint was.
MVM_string_index_ignore_mark was also added, which is accessible as the indexim_s op.		 19:19
19:35 edehont joined
samcv ok so i found a bug in nqp::ordbaseat. it just returns the base character if it happens to be a synthetic — but it can be a base character which still decomposes 19:38
m: use nqp; dd nqp::ordbaseat("\c[LATIN SMALL LETTER J WITH CARON, COMBINING DOT BELOW]", 0).uniname
camelia "LATIN SMALL LETTER J WITH CARON"?
samcv when it should be J
i guess it just assumed that would be the case, but it's a bad assumption to make. so will make that change 19:39
19:39 brrt joined 19:44 travis-ci joined
travis-ci MoarVM build errored. Samantha McVey 'Add indexim_s op and improve/fix bugs in eqatim_s 19:44
travis-ci.org/MoarVM/MoarVM/builds/261960078 github.com/MoarVM/MoarVM/compare/0...7fa2ce73ff
19:44 travis-ci left
samcv m: use nqp; dd "\c[LATIN SMALL LETTER J WITH CARON, COMBINING DOT BELOW]" ~~ /:m:i j/ 19:44
camelia Nil?
samcv m: use nqp; dd "\c[LATIN SMALL LETTER J WITH CARON, COMBINING DOT BELOW]" ~~ /:m:i J/
camelia Nil?
19:46 lizmat joined 19:53 edehont joined, lizmat_ joined 21:10 dogbert11 joined 21:27 Ven joined 21:52 stmuk joined 22:08 stmuk joined
lizmat_ and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/08/07/...eekly-101/ 22:09
japhb
.oO( lizmat is best mat )
 22:30
:-)

Powered by Cro and the Raku® Programming Language.

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

Thank you!