|
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 | ||