timotimo huh ... i don't see rakudo-moar/HEAD excel at trim_string as comparde to rakudo-moar/2014.06; does that just mean the performance didn't regress through the rewrite and optimization pass? 00:04
japhb_ jnthn, Some of the results show non-native string performance scales worse than native strings (meaning, the non-native case angles down, instead of flat across). for_concat_2 v. for_concat_2_native, for instance. 00:06
timotimo, Yeah, I think that's exactly it. Because IIRC, trim regressed really hard before his latest fixes. 00:07
timotimo it *could* be that we can't constant-fold $x ~ $x in one case, but in the other? 00:08
japhb_ Interesting thought. 00:09
Oddly it looks like any_equals regressed a little bit since 2014.06 00:10
Hmmm, I need to fix the work estimate for trim_string, oops.
And probably rat_harmonic too. 00:11
japhb_ blinks twice at the plot for rc-self-describing-numbers
timotimo yeah 00:12
japhb_ Now how the heck did *that* happen
timotimo it confused me, too
did compile times increase a buttload?
japhb_ Yes, at one point, but I thought lizmat (mostly?) fixed that ...? 00:13
It was an S11 code performance bug
timotimo that was a regression that lasted only a few days at most 00:14
i don't think it went into any release, actually
japhb_ Agreed, I was just trying to remember (since I don't backlog #perl6 anymore, I miss out on info like that -- I was lucky to see that one in passing). 00:17
timotimo well, i suppose in the weekly you only get the good news, not necessarily the bad ones that get fixed within the time frame 00:21
anyway, off to bed i go! 00:28
[Coke] ~~ 00:32
japhb_ Oh yeah, the latest changes make a big difference to summary scores for nqp-moar/master and rakudo-moar/nom 00:45
By my estimates, the overall performance of nqp-moar has more than doubled in the last 6 months -- and the overall performance of rakudo-moar has *quadrupled*. 00:46
[Coke] moar is borked. 00:47
japhb_ (startup/compile time excepted, of course)
[Coke] I did an upgrade, realclean, configure, get a ./perl6 that keeps saying:
japhb_ ankh-moarbork?
[Coke] ===SORRY!===
Missing or wrong version of dependency 'src/gen/m-CORE.setting'
[Coke] tries wiping ./install and a git clean -xdf 00:48
japhb_ What about `make install; install/bin/perl6` ?
[Coke] already started the wipe. 00:49
wouldn't help since I'm doing spectesty things.
must have been a stale build file that wasn't cleaned up. seems OK now. 00:56
Internal error: zeroed target thread ID in work pass. whee. 01:00
here's a backtrace for folks to play with: rt.perl.org/Ticket/Display.html?id=122297 01:11
01:30 FROGGS_ joined 01:35 colomon joined
japhb While trying to track down a missing data point in the rakudo-moar history, I discovered that rakudo-moar/2014.05 had a user-visible spesh failure running rc-mandelbrot. 01:49
Thankfully, nothing since.
01:53 teodozjan joined 02:47 avar joined 03:13 dalek joined 03:20 japhb joined, japhb_ joined, woolfy1 joined, nebuchadnezzar joined, moritz joined, itz_ joined, hoelzro joined, jnthn joined, xiaomiao joined, krunen joined, nwc10 joined, diakopter joined, masak joined, BinGOs joined, ashleydev joined, timotimo joined, tokuhirom joined, harrow joined, cxreg joined, camelia joined, flussence joined, TimToady joined 03:22 avar joined 03:23 ChanServ joined 06:16 ggoebel111118 joined
sergot o/ 06:19
06:57 woolfy joined 07:09 zakharyas joined
nwc10 jnthn: pass 07:15
brrt (who is not here): pass
ie ASAN is happy 07:16
(to the end of the spectests)
diakopter we should give the asan continuous integration bot a name. also, a cookie.
07:28 teodozjan joined 07:35 jimmyz joined
jimmyz jnthn: I got a Segmentation fault : gist.github.com/zhuomingliang/5c8d...a39d2ba5cf 07:35
jnthn: when building core setting. 07:36
diakopter hm, deserialize_stable .. sounds like my code 07:43
FROGGS_ jimmyz: would be interesting to know if that also fails under MVM_SPESH_DISABLE=1 07:55
08:05 JimmyZ joined
JimmyZ FROGGS_: yes 08:05
08:13 brrt joined
brrt i sometimes wonder what'd have happened if instead of making the JIT compiler in C / DynASM i'd have started with the JIT compiler as a p6 module 08:21
jnthn Lots of time doing encoding of instructions and figuring out how to get the spesh graph accessed in Perl 6 and plug the thing into the pipeline I guess... :) 08:56
brrt yeah, i suppose so, too 09:12
09:22 klaas-janstol joined
brrt ok, seems i've learned a new dynasm trick 09:24
i can load addresses of labels at run time
jnthn ooh :) 09:25
brrt importantly, that includes 'local' (non-bb) labels
that also means that invokish ops need not be at the end of basic blocks 09:26
jnthn ah, good
brrt (is it invokey or invokish?)
jnthn I'm not sure we settled on that :)
invokish is probably better 09:27
brrt invokey sounds american
i'm good with either :-)
jnthn Well, can't be having that... :P
Let's go with the British-sounding invokish. ;)
brrt :-) 09:28
diakopter invokesque? 09:40
dalek arVM/moar-jit: e47f5ca | (Bart Wiegmans)++ | src/ (6 files):
Load address of entry label in JIT

This will allow us to load addresses of labels that aren't start of basic blocks, and thus to deal with invokish ops without putting them at the end of basic blocks.		 09:45
brrt invokesque, i like 09:47
weird, update-ops drops the MVM_PUBLIC prefix for MVM_op_get_op 09:49
should it have that? 09:50
dalek arVM/moar-jit: 3842c04 | (Bart Wiegmans)++ | / (3 files):
Add 'invokish' field to opcode info

The JIT needs to know if we've invoked something and whether we should return to the interpreter. This flags allows us to compile a guard.		 09:54
brrt hmm... anyone a good name for the invokish-guard-node? 09:59
10:00 japhb joined 10:01 nebuchadnezzar joined, BinGOs joined, masak joined, diakopter joined, nwc10 joined, krunen joined, xiaomiao joined, jnthn joined, hoelzro joined 10:03 japhb_ joined, moritz joined, itz_ joined, flussence joined, camelia joined, cxreg joined, harrow joined, tokuhirom joined, timotimo joined, ashleydev joined, TimToady joined
brrt bbi3h 10:06
10:07 brrt left 10:08 woolfy joined 10:49 woolfy1 joined 11:55 carlin joined 12:09 jnap joined 12:15 klaas-janstol joined
timotimo o/ 12:20
hoelzro o/ timotimo
dalek arVM/moar-jit: 7a30d11 | (Bart Wiegmans)++ | src/ (11 files):
Add support for invokish operators and decont

Decont isn't actually compiled, though, so don't consider this
  'tested' just yet.		 12:32
12:32 brrt joined
timotimo oh, that was sudden 12:33
does the oplist actually have parsing for :invokish yet? 12:34
jnthn That was in the parent commit 12:35
timotimo ah
[Coke] jnthn: did you see my moar segfault? 12:37
rt.perl.org/Ticket/Display.html?id=122297 12:38
jnthn [Coke]: Yeah, saw you RT'd it. Thanks.
I'll take a look after $dayjob.
[Coke] jnthn++
brrt much wow, decont actually seems to work 12:52
timotimo wowza. 12:53
that'll bring a whole slew of frames closer to completion in one fell swoop!
[Coke] wonders if there are other swoop varieties.
dalek arVM/moar-jit: 6fd5469 | (Bart Wiegmans)++ | src/ (7 files):
Add support for smart stringify / numify.

This means that decont is also tested (and found to work).		 12:54
timotimo this is excellent news :3
jnthn I've seen it miswritten as "one foul swoop" :)
[Coke] jnthn: mmmhehee 12:55
brrt it doesn't exactly mean that the invokish guard actually works :-) i'm not sure if that code path is actually involved much 12:56
12:56 jnap joined
brrt unless_o was invokish, too, right? 12:56
jnthn brrt: For decont not so often; but num/str then just numify an object with a Num method a load of times... 12:57
brrt: Yes, and if_o too
brrt: 'cus they can call .Bool
brrt ok
does this work in nqp or only in perl6?
jnthn istrue/isfalse also; they should be quite easy.
if_o and unless_o show up all over teh place in perl 6
The use of smrt_* is in NQP-generated code 12:58
We don't do it that way in full-blown Perl 6.
Whenever you stringify a match object with ~ in NQP, it uses the smart stringify which calls a method, for example
brrt hmmok 13:01
jnthn if_o and unless_o are harder as they want to branch *after* the method call... 13:03
brrt oh... i see 13:15
jnthn Yeah, they are amongst the funkiest of ops.
brrt o.O funky indeed 13:17
jnthn apologises for the funk 13:18
They are common, though...
brrt will find a way arround the funk
jnthn brrt++ 13:20
brrt :-)
dalek arVM/moar-jit: 1d0f170 | (Bart Wiegmans)++ | src/ (3 files):
Add support for istrue, isfalse
 13:26
brrt although i grant that it won't be very simple 13:27
jnthn Well, an alternative is to desugar it into istrue and if_i 13:29
Needs a place for a temporary result. 13:30
Which is the tricky-ish bit.
Though an unused args slot may do 13:31
brrt i suppose that's true 13:32
diakopter heh, talk about stack allocation
brrt if_o, unless_o, also require a place for a temporary result 13:33
jnthn Yeah.
I'd lean towards the desugar. 13:34
brrt because in the case that JIT -> boolify (interpreter) -> JIT back, i can't use a register (hasn't an address), and i can't properly use stack space either (we'll return from the JIT frame)
me too
jnthn if_o and unless_o are worth it for the interpreter and keeping bytecode size down.
But the JIT doesn't carry interpreter overhead and we're only paying this for hot paths of code we actually run. 13:35
brrt i can have the JIT graph builder do the desugar, i think?
jnthn Yes. 13:36
And use args[2] or so 13:37
brrt why args[2]? will the args buffer be used otherwise? 13:38
(probably, yes; the args[0] may contain the invocant)
jnthn Yes, args[0] will have the invocant, and in the unlikely case the invocant is a thingy with a postcircumfix:<( )> it may re-shuffle the args too. 13:39
timotimo is there a plan to turn bunches of those c functions we call into in-linable assembly code at some point? 13:40
jnthn Well, that's partly for spesh to do (and what it is doing already in places)
For example, many calls related to attrs are turned into object accesses.
timotimo right 13:41
jnthn And istrue and if_o on known types will be able to become cheaper too
Since we can see the boolification spec.
timotimo right; i could build that code at some point 13:42
brrt btw, there's one small annoyance i've just had - the MVM_args_get_pos_* return a struct, and that's not very cool in ASM land
i.e. it can be done but there's hardly any official specification for it
jnthn Hm. What'd you prefer it to do? 13:45
Pass it a pointer to something on the stack and have it populate that, maybe?
[Coke] keeps seeing if_o as some kind of weird smiley. 13:47
13:48 woolfy1 left 13:51 woolfy joined 13:52 woolfy left
carlin now also sees it as some kind of smiley, thanks [Coke] :| 13:57
[Coke] maybe a guy with a monocle? 13:59
brrt jnthn - that's pretty much my preference, yes 14:28
jnthn brrt: Feel free to refactor it that way 14:29
Will need changes in a few bits of the code, I suspect.
brrt ok, will do (in due course)
jnthn *nod*
brrt i suspect work[sf->work_size-1] would be a good address for the args buffer 14:52
or, in other words, how large is the args buffer?
dinner & 14:59
14:59 brrt left
jnthn Always at least 3-4 slots 15:02
[Coke] S17-promise/allof.t 10 - got the right order 17:00
I just fudged the other moar failure (has an RT)
so, that's the last one.
looks like that test fails randomly. 17:02
17:26 lizmat joined 17:28 mj41 joined 17:29 vendethiel joined 17:50 klaas-janstol joined 18:01 klaas-janstol left, klaas-janstol joined 18:09 kjs2 left, kjs2 joined 18:17 bcode joined 18:24 teodozjan joined 18:33 carlin joined 19:04 tgt joined 19:12 mj41 joined
dalek arVM/moar-jit: 8f5e4f0 | (Bart Wiegmans)++ | src/jit/graph.c:
Added support for if_o and unless_o

Due to general funkiness of if_o and unless_o operators, this is a bit hacky, but nevertheless effective. Boolification of objects is invokish in general. To deal with this, the interpreter supplies the boolification function with 'true' and 'false' continuation addresses. This is not feasibile for the JIT because bytecode addresses do not correspond directly to JIT addresses. So instead these ops are transformed as it were into the sequence of istrue / isfalse followed by if_i. Register space outside of the range of locals
  (that is to say, in the args buffer) is used to store the temporary
result of istrue/isfalse. It is conceivable this might fail, but it seems to work now. c0d56a2 | (Bart Wiegmans)++ | src/jit/graph.c: Compute the last register index correctly
Inlining changed the size of the work buffer, so it had to be recomputed. Unfortunately I'm not able to use the recomputed value in the spesh candidate as that structure is unavailable to the JIT.		 20:12
20:12 brrt joined
FROGGS_ brrt++ 20:13
brrt jnthn++ for suggesting the solution, by the way :-) 20:14
hmm let's not celebrate all the way yet, though
it appears that nqp actually has a frame that has no args space (and thus, no locals) 20:15
brrt wonders how it ever managed to call then 20:16
ehm, not no locals 20:18
jnthn no locals? o.O 20:19
brrt i'm wondering if it could be OK to increase the allocated size
jnthn I'm not sure how we can end up with a frame with no locals...
brrt no, i don't mean no locals, that's wrong :-)
i mean no space for the args buffer
jnthn ...
Every frame gets that, though. 20:20
brrt i supposed so
jnthn (See allocate_frame in frame.c for details)
brrt wait, i think i see 20:25
num_locals = 62, work_size=384byte (48 registers), dst reg=47
i think this is inlining and /me taking the wrong work size allocated
jnthn You need to look at spesh_cand->num_locals really 20:26
Or are you?
And do we have the wrong size allocated?
This could relate to the segv [Coke]++ RT'd earlier on... 20:27
brrt i think i'll show you :-)
github.com/MoarVM/MoarVM/commit/8f...dd6a719a5d 20:29
basically, i use the work_size of the staticframe, not of the spesh graph 20:30
(i don't have the work size of the spesh graph, really)
ah, i see
work sizes are computed for candidates, not for spesh graphs, and they are related to the num_locals by the compunit max callsite size 20:31
anyway, i still want the last register
jnthn Yeah, there you're using the work size of the static frame, which is going to be the wrong answer for anything with inlining. 20:33
And as you noticed, work_size lives in spesh_candidate 20:34
But I guess we didn't compute that yet..
brrt well, we did or did not, it's not important, i don't have the candidate in the jit graph building, just the spesh graph 20:35
repeating the computation is simple enough, of course :-)
jnthn You can figure it out, though, by doing num_locals + sf->body.cu->body.max_callsite_size
Where num_locals is the one from the spesh graph
Oh, and - 1 on the thing I just gave you.
brrt :-) 20:36
brrt is committing that as we speak
and pushed 20:38
brrt i do notice two failing tests in nqp, although they seem to be parsing errors 20:39
jnthn Well, you're likley JITting part of the parser... :) 20:40
brrt true 20:41
but that would imply i've got errors, and... that'd be an issue
jnthn ;) 20:42
brrt /if/ there's a bug, it's a subtle one, that's for sure 20:44
jnthn Well, MVM_JIT_DISABLE will tell you ;) 20:46
brrt it's a JIT bug :-(
problem seems to be contained in smrt_numify / smrt_strify 20:52
but let's see
yep, smrt_numify is our problem 20:55
seems kind of likely we're passing it the wrong thing 20:56
we / i
jnthn Glad you could at least triangulate it quickly to one op 21:00
brrt yes.. but i'm not sure about what to do with it 21:02
or 'why does this happen'
jnthn Well, could log what smrt_numify receives as args without JIT
Then same with JIT
And diff 21:03
brrt hmm yes 21:04
not sure how much that'll help, though, and i'm afraid it could also be a decont issue 21:05
21:07 brother joined
jnthn bbi10 21:08
brrt hmm, now i suspect deocnt is the problem 21:12
smart_numify isn't the problem, that's for sure 21:16
but why would decont be?
(why wouldn't it, other question) 21:21
y u no work! 21:29
i'll look at this further tomorrow
21:29 brrt left
jnthn is having a hard time reproducing the SEGV [Coke] reported, or the related paste.scsys.co.uk/407476 22:10
timotimo aaw, no working decont yet? :( 22:15
[Coke] jnthn: the linux box is aborting the test, not sure if it's also segfaulting. my mac is definitely segfaulting.
Do you have access to host07? 22:16
weird. test fails when run as "prove -v -e t/fudgeandrun t/spec/integration/99problems-51-to-60.t", but not when run as ./perl6-m t/spec/integration/99problems-51-to-60.t (on host07) 22:18
(with the fudge directive removed) 22:19
ah. jnthn: try using this wrapper: 22:20
#!/usr/bin/env perl
exec "ulimit -t 120; ulimit -v 25000; ulimit -c 0; nice -20 ./perl6-m @ARGV"
at some point, if you reduce the memory available, it segfaults. 22:21
reduce it too much, you get nice: error while loading shared libraries: libc.so.6: failed to map segment from shared object: Cannot allocate memory
at -v 25000 you get the segfault pretty quickly.
s/the/a/, anyway
(host07 lacks gdb, so I cannot verify)
... no clue how to ulimit on windows. 22:22
jnthn Me either, which is where I've been trying to hunt it.
22:24 jnap joined
[Coke] most of the stuff I see is "twiddle it after it's started", which doesn't seem to help. 22:25
jnthn: www.microsoft.com/en-us/download/de...x?id=20028 ?
Looks like a more general tool than "limit my memory" 22:26
Also - I asked for this for parrot ages ago - it'd be nice if moarvm took a parameter that limited how much memory it could allocate. 22:29
22:44 lizmat joined
jnthn [Coke]: Hm, that didn't help much. I'll have to try it over on Linux, but too tired tonight. 22:48
22:48 woolfy joined 22:54 lue joined
jnthn gets some rest & 22:58
[Coke] ah well. jnthn++ 23:17
timotimo jnthn++ and gnite++ :)

Powered by Cro and the Raku® Programming Language.

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

Thank you!