timotimo looks like bad memory accesses here, huh. 00:02
00:04 travis-ci joined
travis-ci MoarVM build failed. Timo Paulssen 'fix wrong int size for string register in getstringfrom' 00:04
travis-ci.org/MoarVM/MoarVM/builds/366937742 github.com/MoarVM/MoarVM/compare/1...637c24becf
00:04 travis-ci left
timotimo what about this spesh slot stuff could be wrong in the jit but correct in the interpreter? 00:06
MasterDuke have you tried jit bisecting it? 00:10
timotimo i could try that 00:11
"this program cannot be bisected" :| 00:12
oh it needs to be in a different workdir
mst MasterDuke: is this a 'gif' pronunciation argument? :D 00:15
MasterDuke heh, took me a little while there to get that 00:16
oddly enough, i'm not sure i have a standard way of pronouncing 'gif' 00:18
now 'gibs' on the other hand...
timotimo i wonder why carg gets 0x5 and 0x3 in the graph 00:29
probably a value inside an enum? 00:30
rather than a size or similar?
ugh, it's already really late 00:31
i'll revert the code for now
Geth MoarVM: a85c2d398d | (Timo Paulssen)++ | src/jit/core_templates.expr
Revert "add an exprjit for sp_getwvalfrom"

because it causes crashes. Somehow the spesh slot in use becomes out of range? In any case, valgrind complains.
This reverts commit 1525500479fd6a99e1a617c6529ca0f80b1e04d5.		 00:32
timotimo .tell brrt could you check out what might be wrong with github.com/MoarVM/MoarVM/commit/1525500479 ? valgrind says the access in cu_string that goes wrong lands just 8 bytes outside of the spesh slot array (pointing at the code that last caused the array to be resized) 00:37
yoleaux timotimo: I'll pass your message to brrt.
timotimo wait
that's from the template i didn't actually commit 00:38
Geth MoarVM/crashy_getxfrom_templates: 288169bb08 | (Timo Paulssen)++ | src/jit/core_templates.expr
commit WIP templates for getstringfrom and getwvalfrom

at least getstringfrom is crashy in rakudo's make test.		 00:39
timotimo .tell brrt i committed the templates in question to the branch "crashy_getxfrom_templates": github.com/MoarVM/MoarVM/commit/288169bb08
yoleaux timotimo: I'll pass your message to brrt.
00:50 travis-ci joined
travis-ci MoarVM build passed. Timo Paulssen 'Revert "add an exprjit for sp_getwvalfrom" 00:50
travis-ci.org/MoarVM/MoarVM/builds/366946102 github.com/MoarVM/MoarVM/compare/9...5c2d398d52
00:50 travis-ci left 00:52 Zoffix joined 01:01 lizmat_ joined 01:06 lizmat joined 01:57 ilbot3 joined 02:31 Kaiepi joined 02:37 Kaiepi joined 05:51 domidumont joined 05:57 domidumont joined 06:26 domidumont joined 06:29 domidumont joined
Geth MoarVM/spesh-limit-debug-log: 2fb5b49151 | (Bart Wiegmans)++ | src/spesh/optimize.c
[Spesh] Log graph of inlinee prior to inlining

Now that we can restrict the amount of logging done, no longer such a problem to log the entire graph.		 07:28
07:29 brrt joined
brrt \o 07:29
yoleaux 00:37Z <timotimo> brrt: could you check out what might be wrong with github.com/MoarVM/MoarVM/commit/1525500479 ? valgrind says the access in cu_string that goes wrong lands just 8 bytes outside of the spesh slot array (pointing at the code that last caused the array to be resized)
00:39Z <timotimo> brrt: i committed the templates in question to the branch "crashy_getxfrom_templates": github.com/MoarVM/MoarVM/commit/288169bb08
brrt yeah, i can tell what's wrong. the spesh slot macro gives you the *address* of the spesh slot, not its value
a pointer to the spesh slot
otherwise i'd have to call it load_spesh_slot_value or something 07:30
07:33 zakharyas joined
brrt then again, you're not exactly the first to fall for that 07:37
Geth MoarVM/spesh-limit-debug-log: 7af32b55fe | (Bart Wiegmans)++ | 6 files
[Spesh] Wrap debug printing

The intention is that MVM_spesh_debug_enabled(tc) can be made more specific than just having a spesh log file handle or not.
Specifically, setting MVM_SPESH_LIMIT in conjunction with MVM_SPESH_LOG will restrict the log to that particular frame.		 07:44
MoarVM/spesh-limit-debug-log: a5b71afccf | (Bart Wiegmans)++ | src/spesh/optimize.c
[Spesh] Log graph of inlinee prior to inlining

Now that we can restrict the amount of logging done, no longer such a problem to log the entire graph.
08:22 AlexDaniel joined 08:29 AlexDaniel joined 09:45 lizmat joined 09:52 zakharyas joined 10:03 brrt joined
timotimo thank you, brrt, now it's not crashy any more 10:05
Geth MoarVM: e24afe9a9a | (Timo Paulssen)++ | src/jit/core_templates.expr
JIT expr templates for getstringfrom and getwvalfrom

the secret sauce that was missing before was dereferencing the result of ^spesh_slot, just like it is done everywhere else in the file …		 10:10
timotimo i can also build an improved ^cu_string that tries to do the lookup of the string before invoking the "grab string from cu and maybe deserialize" function first 10:11
Unknown node type ARRAY(0x55f593335580) at tools/expr-template-compiler.pl line 95, <STDIN> line 18. 10:19
this is the line my ^cu_string macro is used for the first time
ah, ok
the value part of the let node had a layer of () too many 10:20
anyway, this should make everything everywhere a tiny bit faster 10:24
like, an unnoticable bit
huh, that's weird ... i let fix_wval go through the inliner's SC dependencies to see if any of them refer to the same SC as the inlinee's one, but even if i panic if getting the object from both diverges i get a behavioural change? 10:35
"that's weird" should be an automatic "run it with valgrind" 10:36
... and that makes it pass
10:38 brrt joined
timotimo asan is bored, but the program still fails 10:40
brrt which program?
timotimo oh, just "make install" in nqp 10:41
the very first step
Geth MoarVM: 161b47672d | (Bart Wiegmans)++ | 2 files
Rename ^spesh_slot to ^spesh_slot_addr and add ^spesh_slot_value

This should hopefully unconfuse expression template writers		 10:42
timotimo oh what the heck %) 10:44
i did it rather very wrong 10:46
very cool. the majority of wval and wval_wide accesses are now just kept as wval instead of being made indirect in one way or the other 10:47
that should be a bit faster in general
dogbert17 timotimo++: your latest changes have restored the speed of the bickpackid program 10:48
timotimo that's reassuring
dogbert17 I get 4.91 s in ST mode and 1.39 s in MT mode 10:50
timotimo it's very unlikely, but maybe the next commit will shave off another 0.01s :P
dogbert17 why not, moar speed is a good thing 10:51
Zoffix New blog post: "WANTED: Perl 6 Historical Items": rakudo.party/post/WANTED-Perl-6-Hi...ical-Items 10:52
Geth MoarVM: 70ae7eb61b | (Timo Paulssen)++ | 2 files
inline simple cu string access into exprjit template

just like the MVM_STATIC_INLINE function we use to get strings from a CU, we do a fast path for already deserialized strings, which ought to be extremely common.		 11:03
MoarVM: 9c7afdfde3 | (Timo Paulssen)++ | src/spesh/inline.c
keep wvals if only dep needs changing

if both CUs have the SC in question in their dependency lists, but at different indices, we can find the right entry and only change the index.
timotimo dogbert17: if you could run the code a bunch of times and see if there's a statistically significant difference, that'd be nice :)
timotimo does RSI rest break out on the balcony
brrt timotimo++ 11:11
dogbert17 timotimo: I'll check while you rest 11:13
timotimo: ran a few tests and I get the impression that the code now is a teeny-tiny bit slower than before 11:24
11:28 domidumont joined
timotimo hahaha 11:34
that sucks :) 11:35
dogbert2_ if it improves other programs it might be worth keeping I guess 11:49
dogbert17 I got like 5.03 s ST and 1.41 s MT 11:50
timotimo i have no idea if it actually makes other programs faskter 11:51
11:53 robertle joined
dogbert17 whatever you choose to do I'd say that the blockage is unclogged :), i.e. R#1733 11:55
synopsebot R#1733 [open]: github.com/rakudo/rakudo/issues/1733 [perf][regression][⚠ blocker ⚠] Performance regression after latest MoarVM bump
dogbert17 releasable: next 11:56
...
stupid bot
AlexDaniel where is it btw 12:00
12:01 releasable6 joined, committable6 joined
AlexDaniel releasable6: next 12:01
releasable6 AlexDaniel, Next release in ≈5 days and ≈6 hours. 7 blockers. 224 out of 237 commits logged
AlexDaniel, Details: gist.github.com/5223ef5da9f206e5c5...e3da9ba95d 12:02
AlexDaniel dogbert17: can't call someone stupid if they're not here! :)
timotimo i thought maybe i'll get more reliable results regarding performance if i use callgrind 12:03
except it's extremely noisy
i need something single-threaded instead, i think
AlexDaniel dogbert17: would be nice to have a comment on R#1733
12:09 domidumont joined
dogbert17 AlexDaniel: you have it :) 12:11
timotimo: one part of the program is ST
releasable: uptime 12:12
releasable6 dogbert17, 10 minutes and 34 seconds, 232.136719MiB maxrss. This is Rakudo version 2018.03-134-g20495f097 built on MoarVM version 2018.03-56-g85fc758ce implementing Perl 6.c.
timotimo i know 12:13
dogbert17 releasable: next 12:16
releasable6 dogbert17, Next release in ≈5 days and ≈6 hours. 6 blockers. 224 out of 237 commits logged
timotimo nice, this code is very stable
releasable6 dogbert17, Details: gist.github.com/6153140569559110fe...c7e48410e7
dogbert17 releasable: uptime
releasable6 dogbert17, 14 minutes and 48 seconds, 252.863281MiB maxrss. This is Rakudo version 2018.03-134-g20495f097 built on MoarVM version 2018.03-56-g85fc758ce implementing Perl 6.c.
dogbert17 hmm
AlexDaniel quotable6: uptime
quotable6 AlexDaniel, 1 day, 8 hours, 55 minutes, and 9 seconds, 375.523438MiB maxrss. This is Rakudo version 2018.03-134-g20495f097 built on MoarVM version 2018.03-56-g85fc758ce implementing Perl 6.c.
timotimo damn, it really does take more instructions 12:21
dogbert17 your last fix ? 12:22
timotimo yeah 12:23
er, no, not the fix
just the additional "optimization"
dogbert17 :)
12:49 Zoffix left 13:40 lizmat_ joined
dogbert17 heh, 'moar: src/gc/collect.c:218: process_worklist: Assertion `*item_ptr != item->sc_forward_u.forwarder' failed. Aborted (core dumped)' 13:40
is it ok for two threads to be running process_worklist simultaneously ? 13:47
timotimo yes 13:49
dogbert17 ok, would you like to take a peek at gist ?
gist.github.com/dogbert17/3c3ac42b...002604385a 13:50
Geth MoarVM: 77fc202822 | (Timo Paulssen)++ | src/gc/orchestrate.c
global destruction shall suspend other threads

this reduces "invalid read" and "invalid write" spam in valgrind/asan when --full-cleanup is used.		 13:51
MoarVM: 4e129a4ec2 | (Timo Paulssen)++ | src/spesh/inline.c
free copied spesh_slots in one missing place

when a spesh graph was created from a candidate, we copy its spesh slots since a recent change. That means it has to be freed whenever the graph gets let go.
We don't do this in spesh_graph_destroy, because usually the spesh_slots array is shared.
timotimo might be good to run it without jit so the backtraces don't get messed up 13:54
but i've gotta head out now
dogbert17 I'll give that a shot
hah, we're lucky ... 13:55
ok updated gist.github.com/dogbert17/3c3ac42b...002604385a 13:57
timotimo: ^^ for when you get back. The code causing this is Zoffix 'golf' from github.com/rakudo/rakudo/issues/1709 14:00
14:03 zakharyas joined
jnthn .tell timotimo `perl6 --profile -e 'for ^870 { EVAL q/sub foo() { }/ }'` = SEGV (on HEAD or close enough); fine without --profile 14:33
yoleaux jnthn: I'll pass your message to timotimo.
dogbert17 jnthn: are you back from vacation? 14:35
jnthn dogbert17: Yes :) 14:37
dogbert17 was it relaxing and snowy?
jnthn Saw plenty of snow on the train trip over the alps, at least :) 14:38
Ate plenty of nice things too. And found some good beer. :)
dogbert17 where did you end up, Italy?
jnthn Munich, then Bolzano (which is in Italy, yes) 14:39
dogbert17 cool, a computer free week then
jnthn Pretty much :) 14:40
dogbert17 and a nice beer or two :)
14:51 zakharyas joined
dogbert17 releasable: uptime 15:03
releasable6 dogbert17, 3 hours, 2 minutes, and 14 seconds, 310.082031MiB maxrss. This is Rakudo version 2018.03-134-g20495f097 built on MoarVM version 2018.03-56-g85fc758ce implementing Perl 6.c.
15:07 zakharyas joined 16:07 lizmat joined
AlexDaniel dogbert17: excessive leaking of releasable6 was my mistake actually, now fixed 16:46
right now only shareable6 is showing some problems, and everything else is above normal but maybe ok 16:47
shareable6: uptime
shareable6 AlexDaniel, 1 day, 10 hours, 41 minutes, and 3 seconds, 713.292969MiB maxrss. This is Rakudo version 2018.03-134-g20495f097 built on MoarVM version 2018.03-56-g85fc758ce implementing Perl 6.c.
AlexDaniel reportable6: uptime
reportable6 AlexDaniel, 1 day, 6 hours, 47 minutes, and 44 seconds, 462.15625MiB maxrss. This is Rakudo version 2018.03-134-g20495f097 built on MoarVM version 2018.03-56-g85fc758ce implementing Perl 6.c.
AlexDaniel well, about twice above normal, yea… 16:48
timotimo jnthn: yeah, the profiler still sometimes manages to crash, and sometimes it even causes a super weird fail where when trying to dump profiler data (i.e. after instrumentation should have been reverted) it stumbles over invalid bytecode 16:52
yoleaux 14:33Z <jnthn> timotimo: `perl6 --profile -e 'for ^870 { EVAL q/sub foo() { }/ }'` = SEGV (on HEAD or close enough); fine without --profile
dogbert17 MVM_SPESH_DISABLE=1 makes the problem disappear 17:17
timotimo huh, that code doesn't segfault for me, it gives a bogus P6opaque: no such attribute '$!restart' on type NQPMu in a Perl6::Grammar when trying to get a value instead 17:27
with the right spesh limit it actually segfaults 17:31
17:44 lizmat joined
dogbert17 for me it SEGV'd here 17:54
0x00007ffff75c2547 in MVM_interp_run (tc=0x604a20, initial_invoke=0x7ffff77045e3 <toplevel_initial_invoke>, invoke_data=0x6800e0) at src/core/interp.c:5330
5330 if (!check || !IS_CONCRETE(check) || STABLE(check) != want)
timotimo yup
so, what it looks like from here, and this could be totally wrong, it's calling guardconc on a non-object lexical's value 18:02
dogbert17 timotimo: do you or jnthn have any theories wrt gist.github.com/dogbert17/3c3ac42b...002604385a 18:07
timotimo sp_getlex_ins r19(2), lex(idx=15,outers=1,$MVM_reg_obj) 18:08
sp_guardconc r19(2), sslot(0), litui32(662)
this is rather obviously wrong :) 18:09
dogbert17 at least for you :) 18:10
18:33 domidumont joined 19:06 lizmat joined 19:09 Kaiepi joined 19:23 lizmat joined
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/04/16/...6-so-that/ 21:14
21:30 robertle joined 22:07 Kaiepi joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!