Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-03-30

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

All times shown according to UTC.

Time Nick Message
00:26 lucasb joined #moarvm
00:27 lucasb Just want to report that I tried to patch MVM_string_gi_move_to
00:27 lucasb I managed to make it work for a simple nqp test
00:28 lucasb nqp builds fine, but then, its t/qregex/01-qregex.t fails
00:28 lucasb rakudo doesn't even build
00:28 lucasb I must be doing something very wrong
00:36 timotimo https://gist.github.com/timo/23a1edfe46f9d0afb0b5a01f6f39ce4a  -  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:37 timotimo 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
01:17 timotimo i fixed all except MVMInstance (not used often enough) and a second MVMCArrayReprData
01:18 timotimo it makes the structs a bit less logical to read, though, which kind of sucks
01:27 timotimo multiple of the structs aren't "fixable" according to pahole, though
01:29 dalek MoarVM/pahole: 6e9e3cb | timotimo++ | src/ (45 files):
01:29 dalek MoarVM/pahole: Merge branch 'annotate_refs_reprapi'
01:29 dalek MoarVM/pahole:
01:29 dalek MoarVM/pahole: This adds a reprop that gets called instead of gc_mark and has the
01:29 dalek MoarVM/pahole: extra property of giving each referenced object a human-readable
01:29 dalek MoarVM/pahole: description, be it an index or a name.
01:29 dalek MoarVM/pahole: review: https://github.com/MoarVM/MoarVM/commit/6e9e3cba95
01:29 dalek MoarVM/pahole: 8e61b7c | timotimo++ | build/setup.pm:
01:29 dalek MoarVM/pahole: Merge branch 'master' of git://github.com/MoarVM/MoarVM
01:29 dalek MoarVM/pahole: review: https://github.com/MoarVM/MoarVM/commit/8e61b7caba
01:29 dalek MoarVM/pahole: 1edae3f | timotimo++ | src/ (9 files):
01:29 dalek MoarVM/pahole: optimize a few structs according to pahole.
01:29 timotimo oh, whoops
01:30 timotimo a few commits i didn't mean to commit
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
07:09 zakharyas joined #moarvm
07:37 Unavowed joined #moarvm
07:46 leont joined #moarvm
08:30 leont joined #moarvm
08:30 leont o/
08:31 nwc10 \o
08:34 leont I should probably rakudobug yesterday's issue, even if I'm very much expecing it to be a moarbug, right?
08:35 nwc10 I can't usefully answer that. Not sure who is awake who could.
08:36 timotimo if it seems quite like it's a moarbug, i'd prefer a moarbug
08:40 leont Proc::Async supplies don't get closed on program exit, that does feel like a moarbug to me.
08:41 timotimo very well could be, yeah
08:51 zakharyas joined #moarvm
08:57 leont I have a hunch, and not enough time left on my trainride to build a new rakudo…
08:58 timotimo understood
08:58 timotimo when can you try next time?
08:59 leont Tonight probably
08:59 timotimo OK
08:59 timotimo looking forward to it :)
09:00 jnthn leont: At the exit of the spawned process, right?
09:00 timotimo yeah
09:00 timotimo that's what he means
09:00 leont Yeah
09:00 jnthn OK, good :)
09:01 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"
09:01 jnthn meeting &
09:01 timotimo meting, youting, theyting
09:02 moritz thoughting
09:02 moritz storting
09:02 moritz https://en.wikipedia.org/wiki/Storting
09:21 timotimo we seem to be generating a Slip.sink every time we have a "foo bar baz unless blah blah"
09:22 timotimo hm, i may be misattributing this
09:22 timotimo bu ti don't really know where else that might come from
09:24 timotimo ah, that's just another case of a block being cut out, but not completely
09:24 timotimo er, no, wrong again
09:24 * timotimo adjusts eyes
09:26 timotimo yeah, that unless grabs a Slip object from the serialized blob and tries to sink it :\
09:28 moritz for the empty return value?
09:28 timotimo yes
09:28 timotimo (this is about ASSIGN-KEY(Hash:D: Str:D \key, Mu \assignval) is raw)
09:29 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
09:29 timotimo " piece of code
09:29 moritz that looks like suboptimal codegen
09:30 timotimo agreed
09:30 moritz I mean, we know that the unless doesn't need to return anything, it's in sink context
09:30 moritz so it doesn't need to return that Slip object at all
09:30 timotimo aye, maybe it'd be the optimizer's job to throw that out?
09:30 timotimo i don't know how much about sinkyness we already know at the point the unless gets code-genned
09:31 timotimo of course it could build a big Want node where the Slip doesn't exist in one branch
09:33 timotimo other than this sink there's an invocation of STORE
09:34 timotimo so we won't be turning ASSIGN-KEY and friends into a not-invoking-anything thing with that fix
09:34 timotimo but it cuts the amount of invocation in half
09:34 timotimo i wonder how expensive a "can" op can be
09:46 timotimo trying a bit of code change for "unless"
09:46 timotimo may also want to give "if" the same treatment
10:06 domidumont joined #moarvm
10:11 domidumont joined #moarvm
10:17 timotimo it's not so easy to clone this qast node :\
10:17 timotimo 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 #moarvm
12:55 lizmat_ joined #moarvm
13:19 d4l3k_ joined #moarvm
13:19 cognominal joined #moarvm
14:07 zakharyas joined #moarvm
14:39 domidumont joined #moarvm
14:49 lucasb joined #moarvm
15:02 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:03 jnthn lucasb: Because they're inline static is the usual reason
15:04 jnthn Yeah, that's the case for all of them in there, I think
15:04 jnthn So that's why they're there/need to stay there.
15:06 jnthn If build time is your worry, make -j
15:06 jnthn :)
15:07 lucasb jnthn: ah, ok. understood. thanks!
15:07 zakharyas joined #moarvm
15:08 jnthn We use inline statics most of the places we might be tempted to write macros but don't really need anything weird :)
15:09 jnthn Knowing that they're safer but going to generate code in the same kinda way
16:32 zakharyas joined #moarvm
16:38 Ven joined #moarvm
16:57 Ven joined #moarvm
17:09 Ven joined #moarvm
17:16 Ven joined #moarvm
17:23 Ven joined #moarvm
17:29 leont joined #moarvm
17:33 leont Having my laptop suspended in the middle of stagestats was interesting.
17:33 Ven joined #moarvm
17:34 leont It's not a speed-monster, but 30504.355 seconds is a bit harsh :-p
17:46 Ven joined #moarvm
17:46 leont First theory doesn't seem correct, increasingly the problem seems to be in moar, but need one more test
17:57 FROGGS joined #moarvm
18:23 Ven joined #moarvm
18:38 Ven joined #moarvm
18:50 leont joined #moarvm
19:04 Ven joined #moarvm
20:08 dalek MoarVM/cache_sc_idx: e688260 | timotimo++ | src/6model/reprs/MVMStaticFrame.c:
20:08 dalek MoarVM/cache_sc_idx: add instrumentation values to MVMStaticFrame's unmanaged size.
20:08 dalek MoarVM/cache_sc_idx: review: https://github.com/MoarVM/MoarVM/commit/e688260d53
20:08 dalek MoarVM/cache_sc_idx: 4812655 | timotimo++ | src/6model/reprs/MVMStaticFrame.c:
20:08 dalek MoarVM/cache_sc_idx: account for unmanaged_size of spesh candidates and jitcode.
20:08 dalek MoarVM/cache_sc_idx: review: https://github.com/MoarVM/MoarVM/commit/481265520b
20:08 dalek MoarVM/cache_sc_idx: 2e303cf | timotimo++ | src/6model/reprs/MVMStaticFrame.c:
20:08 dalek MoarVM/cache_sc_idx: fix the typos
20:08 dalek MoarVM/cache_sc_idx: review: https://github.com/MoarVM/MoarVM/commit/2e303cf175
20:08 dalek MoarVM/cache_sc_idx: eba9b0f | (Steve Mynott)++ | build/setup.pm:
20:08 dalek MoarVM/cache_sc_idx: fix compile on FreeBSD 9
20:08 dalek MoarVM/cache_sc_idx: review: https://github.com/MoarVM/MoarVM/commit/eba9b0f00c
20:09 diakopter merge from master
20:09 timotimo OK
20:45 diakopter found the problem with the path munging
20:46 diakopter need to convert one of the captures to a lookahead
20:46 diakopter bleh
20:47 diakopter .. because otherwise it will always break on single-character directory names
20:59 dalek MoarVM: 9c885bc | (Matthew Wilson)++ | Configure.pl:
20:59 dalek MoarVM: handle single-char dirnames by changing capture to lookahead
20:59 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9c885bce8f
21:03 dalek MoarVM/cache_sc_idx: 9c885bc | (Matthew Wilson)++ | Configure.pl:
21:03 dalek MoarVM/cache_sc_idx: handle single-char dirnames by changing capture to lookahead
21:03 dalek MoarVM/cache_sc_idx: review: https://github.com/MoarVM/MoarVM/commit/9c885bce8f
21:03 dalek MoarVM/cache_sc_idx: b55a082 | (Matthew Wilson)++ | Configure.pl:
21:03 dalek MoarVM/cache_sc_idx: Merge pull request #354 from MoarVM/master
21:03 dalek MoarVM/cache_sc_idx:
21:03 dalek MoarVM/cache_sc_idx: merge from master
21:03 dalek MoarVM/cache_sc_idx: review: https://github.com/MoarVM/MoarVM/commit/b55a082556
21:06 diakopter jnthn: I fixed something lol
21:07 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
21:07 diakopter *with name of length 1
21:09 jnthn d'oh :)
21:09 diakopter oooo
21:09 diakopter and I just tried the cache_sc_idx branch
21:11 diakopter 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??
21:11 diakopter well today it went up lol
21:11 jnthn diakopter: Wow. I'll give it another spin, then :)
21:11 diakopter jnthn: wait
21:11 diakopter lemme spectest
21:12 diakopter but setting compilation went from 87.7 seconds to 68.2
21:14 jnthn \o/
21:14 jnthn diakopter++
21:14 jnthn And if it doesn't work for me, I'll have time to debug it this time around.
21:14 diakopter spectesting
21:15 diakopter last time it hung on S09, but I *think* it was because of the config.c thing
21:15 diakopter *hanged or was hung
21:20 diakopter well, still hanging on S09 tests
21:20 jnthn OK...will see if I can reproduce that tomorrow
21:20 jnthn For now, sleep time...'night o/
21:21 diakopter (8 minutes into spectest)
21:21 diakopter trying spectest on master now
21:26 timotimo try hellgrind? :)
21:27 diakopter wth is that
21:29 timotimo the multi-threading problem finder for valgrind
21:41 diakopter I dunno why the S09 types would be using threads
21:42 diakopter *tests
21:47 timotimo oh
21:47 timotimo uhhh
21:47 timotimo brainfart :)
21:51 diakopter well, the S09 test hanged on master moarvm branch too, so that means it's attributable to VS 2015
21:51 diakopter (or our code/jit not doing the right thing for the newer compielr)
21:51 diakopter so allegedly, jnthn won't need to debug anything at all ;)
22:01 diakopter well, that time it was 10% slower
22:02 diakopter SIGH
22:03 timotimo uh? :o
22:04 diakopter I mean, the master branch didn't speed up; the cache_sc_idx branch got 40% slower
22:05 diakopter oh, my laptop isn't plugged in
22:05 diakopter bleh
22:06 diakopter never do unscientific benchmarking/optimization when operating from a battery in an OS that vehemently tries to conserve power
22:07 diakopter nine: would you mind trying out the cache_sc_idx branch? I'm curious if you see any interesting interactions with the precomp speed

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