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 |