00:26 lucasb joined
lucasb Just want to report that I tried to patch MVM_string_gi_move_to 00:27
I managed to make it work for a simple nqp test
nqp builds fine, but then, its t/qregex/01-qregex.t fails 00:28
rakudo doesn't even build
I must be doing something very wrong
timotimo gist.github.com/timo/23a1edfe46f9d...1f6f39ce4a - i went through pahole's output for libmoar.so, and there's a bunch of holes in structures we allocate many of during regular use of the VM 00:36
especially in places like the MVMJIT* structs we'll directly benefit because we use bump-the-pointer allocation for these and we may get away with fewer big-ish blocks allocated all in all to hold our stuff 00:37
i fixed all except MVMInstance (not used often enough) and a second MVMCArrayReprData 01:17
it makes the structs a bit less logical to read, though, which kind of sucks 01:18
multiple of the structs aren't "fixable" according to pahole, though 01:27
dalek arVM/pahole: 6e9e3cb | timotimo++ | src/ (45 files):
Merge branch 'annotate_refs_reprapi'

This adds a reprop that gets called instead of gc_mark and has the extra property of giving each referenced object a human-readable description, be it an index or a name.
01:29
arVM/pahole: 8e61b7c | timotimo++ | build/setup.pm:
Merge branch 'master' of git://github.com/MoarVM/MoarVM
MoarVM/pahole: 1edae3f | timotimo++ | src/ (9 files):
MoarVM/pahole: optimize a few structs according to pahole.
timotimo oh, whoops
a few commits i didn't mean to commit 01:30
01:48 ilbot3 joined 07:09 zakharyas joined 07:37 Unavowed joined 07:46 leont joined 08:30 leont joined
leont o/ 08:30
nwc10 \o 08:31
leont I should probably rakudobug yesterday's issue, even if I'm very much expecing it to be a moarbug, right? 08:34
nwc10 I can't usefully answer that. Not sure who is awake who could. 08:35
timotimo if it seems quite like it's a moarbug, i'd prefer a moarbug 08:36
leont Proc::Async supplies don't get closed on program exit, that does feel like a moarbug to me. 08:40
timotimo very well could be, yeah 08:41
08:51 zakharyas joined
leont I have a hunch, and not enough time left on my trainride to build a new rakudoā€¦ 08:57
timotimo understood 08:58
when can you try next time?
leont Tonight probably 08:59
timotimo OK
looking forward to it :)
jnthn leont: At the exit of the spawned process, right? 09:00
timotimo yeah
that's what he means
leont Yeah
jnthn OK, good :)
leont It either is SupplySequencer or moar 09:01
jnthn Well, not good in that "that sounds busted", but good as in "we can easily agree that's bust"
meeting &
timotimo meting, youting, theyting
moritz thoughting 09:02
storting
en.wikipedia.org/wiki/Storting
timotimo we seem to be generating a Slip.sink every time we have a "foo bar baz unless blah blah" 09:21
hm, i may be misattributing this 09:22
bu ti don't really know where else that might come from
ah, that's just another case of a block being cut out, but not completely 09:24
er, no, wrong again
timotimo adjusts eyes
yeah, that unless grabs a Slip object from the serialized blob and tries to sink it :\ 09:26
moritz for the empty return value? 09:28
timotimo yes
(this is about ASSIGN-KEY(Hash:D: Str:D \key, Mu \assignval) is raw)
moritz does that happen only if the unless is the last statement in a block? 09:29
timotimo all of those start with a "unless the $!storage is already concrete, initialize it
" piece of code
moritz that looks like suboptimal codegen
timotimo agreed 09:30
moritz I mean, we know that the unless doesn't need to return anything, it's in sink context
so it doesn't need to return that Slip object at all
timotimo aye, maybe it'd be the optimizer's job to throw that out?
i don't know how much about sinkyness we already know at the point the unless gets code-genned
of course it could build a big Want node where the Slip doesn't exist in one branch 09:31
other than this sink there's an invocation of STORE 09:33
so we won't be turning ASSIGN-KEY and friends into a not-invoking-anything thing with that fix 09:34
but it cuts the amount of invocation in half
i wonder how expensive a "can" op can be
trying a bit of code change for "unless" 09:46
may also want to give "if" the same treatment
10:06 domidumont joined 10:11 domidumont joined
timotimo it's not so easy to clone this qast node :\ 10:17
shallow_clone is not enough to get a separate list inside it, and calling the "generate this for me please" thing twice will b0rk out because it's destructive
11:41 vendethiel joined 12:55 lizmat_ joined 13:19 d4l3k_ joined, cognominal joined 14:07 zakharyas joined 14:39 domidumont joined 14:49 lucasb joined
lucasb jnthn: do you remember if there was any special reason for putting the functions inside src/strings/iter.h? would you accept a commit to split things into iter.h and iter.c? 15:02
jnthn lucasb: Because they're inline static is the usual reason 15:03
Yeah, that's the case for all of them in there, I think 15:04
So that's why they're there/need to stay there.
If build time is your worry, make -j 15:06
:)
lucasb jnthn: ah, ok. understood. thanks! 15:07
15:07 zakharyas joined
jnthn We use inline statics most of the places we might be tempted to write macros but don't really need anything weird :) 15:08
Knowing that they're safer but going to generate code in the same kinda way 15:09
16:32 zakharyas joined 16:38 Ven joined 16:57 Ven joined 17:09 Ven joined 17:16 Ven joined 17:23 Ven joined 17:29 leont joined
leont Having my laptop suspended in the middle of stagestats was interesting. 17:33
17:33 Ven joined
leont It's not a speed-monster, but 30504.355 seconds is a bit harsh :-p 17:34
17:46 Ven joined
leont First theory doesn't seem correct, increasingly the problem seems to be in moar, but need one more test 17:46
17:57 FROGGS joined 18:23 Ven joined 18:38 Ven joined 18:50 leont joined 19:04 Ven joined
dalek arVM/cache_sc_idx: e688260 | timotimo++ | src/6model/reprs/MVMStaticFrame.c:
add instrumentation values to MVMStaticFrame's unmanaged size.
20:08
arVM/cache_sc_idx: 4812655 | timotimo++ | src/6model/reprs/MVMStaticFrame.c:
account for unmanaged_size of spesh candidates and jitcode.
arVM/cache_sc_idx: 2e303cf | timotimo++ | src/6model/reprs/MVMStaticFrame.c:
fix the typos
arVM/cache_sc_idx: eba9b0f | (Steve Mynott)++ | build/setup.pm:
fix compile on FreeBSD 9
diakopter merge from master 20:09
timotimo OK
diakopter found the problem with the path munging 20:45
need to convert one of the captures to a lookahead 20:46
bleh
.. because otherwise it will always break on single-character directory names 20:47
dalek arVM: 9c885bc | (Matthew Wilson)++ | Configure.pl:
handle single-char dirnames by changing capture to lookahead
20:59
arVM/cache_sc_idx: 9c885bc | (Matthew Wilson)++ | Configure.pl:
handle single-char dirnames by changing capture to lookahead
21:03
arVM/cache_sc_idx: b55a082 | (Matthew Wilson)++ | Configure.pl:
Merge pull request #354 from MoarVM/master

merge from master
diakopter jnthn: I fixed something lol 21:06
jnthn heh, that was your weird path thing? :) 21:07
diakopter yeah, it wasn't replacing all the backslashes because I had a directory of length 1
*with name of length 1
jnthn d'oh :) 21:09
diakopter oooo
and I just tried the cache_sc_idx branch
jnthn: it knocks 22% off the setting compilation time 21:11
timotimo wait, i thought the benefit went down a whole lot in the mean time??
diakopter well today it went up lol
jnthn diakopter: Wow. I'll give it another spin, then :)
diakopter jnthn: wait
lemme spectest
but setting compilation went from 87.7 seconds to 68.2 21:12
jnthn \o/ 21:14
diakopter++
And if it doesn't work for me, I'll have time to debug it this time around.
diakopter spectesting
last time it hung on S09, but I *think* it was because of the config.c thing 21:15
*hanged or was hung
well, still hanging on S09 tests 21:20
jnthn OK...will see if I can reproduce that tomorrow
For now, sleep time...'night o/
diakopter (8 minutes into spectest) 21:21
trying spectest on master now
timotimo try hellgrind? :) 21:26
diakopter wth is that 21:27
timotimo the multi-threading problem finder for valgrind 21:29
diakopter I dunno why the S09 types would be using threads 21:41
*tests 21:42
timotimo oh 21:47
uhhh
brainfart :)
diakopter well, the S09 test hanged on master moarvm branch too, so that means it's attributable to VS 2015 21:51
(or our code/jit not doing the right thing for the newer compielr)
so allegedly, jnthn won't need to debug anything at all ;)
well, that time it was 10% slower 22:01
SIGH 22:02
timotimo uh? :o 22:03
diakopter I mean, the master branch didn't speed up; the cache_sc_idx branch got 40% slower 22:04
oh, my laptop isn't plugged in 22:05
bleh
never do unscientific benchmarking/optimization when operating from a battery in an OS that vehemently tries to conserve power 22:06
nine: would you mind trying out the cache_sc_idx branch? I'm curious if you see any interesting interactions with the precomp speed 22:07