|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
02:15
evalable6 left
02:16
evalable6 joined,
p6bannerbot sets mode: +v evalable6
07:35
evalable6 left,
unicodable6 left,
squashable6 left,
bisectable6 left,
bloatable6 left,
nativecallable6 left,
reportable6 left,
statisfiable6 left,
committable6 left,
releasable6 left,
shareable6 left,
undersightable6 left,
greppable6 left,
notable6 left,
quotable6 left,
benchable6 left,
coverable6 left,
committable6 joined
07:36
shareable6 joined,
releasable6 joined,
bloatable6 joined,
p6bannerbot sets mode: +v committable6,
squashable6 joined,
p6bannerbot sets mode: +v shareable6,
p6bannerbot sets mode: +v releasable6,
evalable6 joined,
p6bannerbot sets mode: +v bloatable6
07:37
p6bannerbot sets mode: +v squashable6,
statisfiable6 joined,
p6bannerbot sets mode: +v evalable6,
notable6 joined
07:38
coverable6 joined,
p6bannerbot sets mode: +v statisfiable6,
p6bannerbot sets mode: +v notable6,
quotable6 joined,
p6bannerbot sets mode: +v coverable6
07:39
reportable6 joined,
p6bannerbot sets mode: +v quotable6,
undersightable6 joined,
benchable6 joined,
unicodable6 joined,
bisectable6 joined,
nativecallable6 joined
07:40
p6bannerbot sets mode: +v reportable6,
p6bannerbot sets mode: +v undersightable6,
p6bannerbot sets mode: +v benchable6,
p6bannerbot sets mode: +v unicodable6,
greppable6 joined,
p6bannerbot sets mode: +v bisectable6,
p6bannerbot sets mode: +v nativecallable6
07:41
p6bannerbot sets mode: +v greppable6
09:28
domidumont joined
09:29
p6bannerbot sets mode: +v domidumont
|
|||
| Geth | MoarVM: caf7e4ff2c | (Stefan Seifert)++ | src/jit/x64/emit.dasc Fix jump condition in JIT compiled getcodename We check the code object's MVM_CF_TYPE_OBJECT flag. If the flag is 0 (the object is concrete), the test assembly instruction will set the zero flag to 1. So we need to jump over the throw_adhoc if the zero flag is set, not when it's 0. Fixes GH #1027 |
11:02 | |
| MoarVM: c9cd9880f3 | (Stefan Seifert)++ | src/jit/x64/emit.dasc Fix JIT compiled getcodename not always dieing on type objects In cases where we do get a code object, we never checked if the code object is concrete because we immediately jumped to the success branch. Invert the logic and jump directly to throwing the exception instead to give the other check an opportunity to fail. Fixes "no Segfault when creating a Sub object with .bless and trying to say it" in t/spec/S06-other/misc.t failing due to no exception being thrown. |
13:11 | ||
| nine | Turns out, we had got two bugs for the price of one... | ||
| timotimo | whoops | 13:14 | |
| dogbert17 | nine++ (bughunting) | 13:19 | |
| timotimo | nine: if you use R#1027 or M#1027 synopsebot will immediately understand and post the link | 13:20 | |
| synopsebot | R#1027 [closed]: github.com/rakudo/rakudo/pull/1027 Change atpos of @!named_names to atpos_s | ||
| M#1027 [closed]: github.com/MoarVM/MoarVM/issues/1027 [⚠ blocker ⚠] SEGV when running MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./perl6 t/spec/S32-list/sort.t | |||
| timotimo | though we can totally put in intelligence for GH #1027 in a line starting with "MoarVM" or whatever repo | ||
| dogbert17 | hmm, what's up with the atrocious parse times | 13:23 | |
|
13:23
zakharyas joined
|
|||
| nine | Now we're back to the same old MVM_SPESH_NODELAY spectest failures, which btw. should have become much easier to fix with brrt++'s rework of how the JIT finds the (inlined) frames we're in | 13:23 | |
| timotimo | is everybody getting that now, huh? | ||
|
13:24
p6bannerbot sets mode: +v zakharyas
|
|||
| dogbert17 | timotimo: e.g. it takes 22s to parse the htmlify program from the docs repo ... | 13:25 | |
| timotimo | don't forget parsing also contains module loading time | ||
| could that be the case here, too? | |||
| dogbert17 | true, but it's the same time if I run it several times | ||
| timotimo | OK | 13:26 | |
| well, that's not so good, then | |||
| would you be able to test against other recent versions of rakudo+everything? | |||
| dogbert17 | sure, for comparison, parse time on 2018.10 is 2.3s | ||
| timotimo | whoa | 13:27 | |
| dogbert17 | almost as if precomp has been turned off | ||
| timotimo | i think 2018.11 already had the new compiler backend, right? | ||
| jnthn | nine: I think probably the spesh frame walker that I built can be used to walk stack traces too | ||
| yoleaux | 08:06Z <jmerelo> jnthn: I've edited it a bit to add a "Continue reading" button and avoid ragged lines in item list. Please check that it's OK, and also if there's somethign similar out there. | ||
| timotimo | jnthn: i saw an "out" where an "our" was meant in your post, but was too tired to fix it myself | ||
| dogbert17: you could try turning on RAKUDO_MODULE_DEBUG to see if it does any precomp loading | 13:28 | ||
| dogbert17 | cool, will try ... | ||
| nine | jnthn: definitely yes! | 13:29 | |
| timotimo | we're not doing that yet? oh | ||
| jnthn | Nope, nobody got around to it, I guess :) | 13:30 | |
| dogbert17 | timotimo: it's not precomp | ||
| nine | Classic case of "all the hard work is done and the rest seems to trivial to bother" ;) | 13:32 | |
| dogbert17 | for each module the program needs it logs '1 RMD: Attempting to load 'Perl6::TypeGraph::Viz' - 1 RMD: Late loading 'Perl6::TypeGraph::Viz' | ||
| for each module, after having written 'Late loading ' everyting seems to hang sor a sec or two. Nor so on 2018.10 | |||
| s/sor/for/ and s/Nor/Not/ | 13:33 | ||
| nine | There's even my backtrace_uninline branch which despite being out of date clearly shows the places that need modification | 13:34 | |
| Geth | MoarVM/backtrace_uninline: e25e99cec7 | (Stefan Seifert)++ | 2 files wip |
||
| nine | dogbert17: but are there "RMD: Loading precompiled" lines for those modules? | 13:37 | |
| dogbert17 checks | |||
| hmm, there's some precomp stuff there I think: gist.github.com/dogbert17/75a597d5...73397f699f | 13:41 | ||
| at least the parse problem isn't present in 2018.12, it must have appeared in a later commit | 13:49 | ||
|
13:49
domidumont left
|
|||
| timotimo | fascinating | 13:50 | |
| i mean, cur-candidates is new in 2018.12, isn't it? | |||
| dogbert17 | yes | ||
| timotimo | so that could be it? | 13:51 | |
| dogbert17 | yup | ||
| nine | dogbert17: your gist looks good. Stage parse takes just 2 seconds here though | ||
| dogbert17 | nine: it takes 22s for me with 'Rakudo version 2018.12-37-g45a945b built on MoarVM version 2018.12' | 13:54 | |
| nine | This is Rakudo version 2018.12-38-gc07cfe7af built on MoarVM version 2018.12-3-gc9cd9880f | ||
| dogbert17 rebuilds | |||
| nah, doesn't help, what the .... | 14:00 | ||
| nine | You're not running a debug build, are you? | ||
| timotimo | well, debug would be fine, just not with --optimize= | 14:03 | |
| 0 | |||
| dogbert17 | nine: no I don't :-) | 14:06 | |
| for fun I ran with strace enabled. On 2018.10 the strace output is 9262 lines of which 6556 are stat calls | 14:09 | ||
| on master the strace output is 533892 lines of which 452260 are stat calls | 14:10 | ||
| note that my 'precomp' directories contains lots of old files | |||
| timotimo | so maybe cur-candidates doesn't handle too many stale precomp files as well as the previous versions? | 14:12 | |
| dogbert17 | I fixed it by wiping my /home/dogbert/repos/doc/lib/Pod/precompiled directory, hooray | 14:14 | |
| nine | That's certainly something we should look into | 14:15 | |
| dogbert17 | in the strace output for master 371322 line made references to that directory | 14:16 | |
| perhaps it might also explain lizmat's 'bad' spectest times | 14:18 | ||
|
14:18
zakharyas left
|
|||
| nine | dogbert17: can you profile the slow version? | 14:21 | |
| 376statement | 14:25 | ||
| gen/moar/Perl6-Grammar.nqp:9350.0949% jit1,054276,701,161,105,583.44ms / 1,547.66ms | |||
| 262,524,820,783.29ms / 1.47ms per entry | |||
| timotimo: ^^^ | |||
| timotimo | that's what output looks like when a program uses "exit" | ||
| :( | 14:26 | ||
| dogbert17 | nine: would that still be useful now that I've wiped all the precomp files? | 14:31 | |
| I'll give it a shot anyway | 14:33 | ||
| nine | Would have been more useful with those files. No backup I guess? | 14:35 | |
| timotimo | just build a few random rakudo versions and run a few random programs on top of the program in question or so :) | ||
| nine | dogbert17: I don't even have a lib/Pod/precompiled in my doc repo? | 14:38 | |
| dogbert17 | nine: perhaps you've never actually run htmlify to completion? | 14:50 | |
| I just ean it but ... MoarVM panic: Internal error: zeroed target thread ID in work pass ... sigh | 14:52 | ||
| dogbert17 can't seem to press the correct keys, grrr | 14:53 | ||
| nine | dogbert17: indeed I haven't: Failed to get the directory contents of '/home/nine/install/doc/build/Programs': Failed to open dir: 2 | ||
| dogbert17 | interesting | 14:54 | |
| before my run crashed it managed to create a bunch of files in lib/Pod/precompiled and after that parse times have risen from 2.5s (empty dir) to 5.8s (som files in dir) | 14:55 | ||
| timotimo | hm. that's probably not "too many open files"? | 15:00 | |
| dogbert17 | unfortunately the profile looks a bit strange/busted, i.e. 'Inclusive time' says Inf or NaN and 'Exclusive time' says 11.11% or 0% for all entries | ||
| timotimo: should the profiler pick up what happens in the Parse stage? | 15:01 | ||
| nine | dogbert17: I think the explanation is simple. | 15:02 | |
| CompUnit::Repository::FileSystem reads the whole directory to compute the sha1 hash. While it skips hidden directories (and thus .precomp), it will recurse into precompiled/ | 15:03 | ||
| dogbert17 | nine: but is that a new feature? | 15:05 | |
| I mean, 2018.10 was fast even though the directory contained a gazillion files | |||
|
15:06
domidumont joined
|
|||
| nine | Could be that some caching doesn't work as well anymore | 15:06 | |
|
15:06
p6bannerbot sets mode: +v domidumont
|
|||
| nine | Ah, yes, !distribution doesn't cache its result. So we're recursing over and over again. | 15:07 | |
| dogbert17 | I'll continue experimenting, after arming myself with some coffee. Perhaps perf can find something of interest. | 15:08 | |
| nine | dogbert17: just add some caching to github.com/rakudo/rakudo/blob/mast...m.pm6#L212 | 15:09 | |
|
15:14
klapperl left
|
|||
| nine | Yeah, this patch seems to help: gist.github.com/niner/92729569c472...be9cea3d33 | 15:14 | |
| Need to go now, so if someone wants to test/commit this, please feel free | 15:15 | ||
| dogbert17 | nine++, I'll take a look | ||
| timotimo | dogbert17: only with --profile-stage=compile | 15:33 | |
| er | |||
| --profile-compile=parse | |||
| or something? | |||
| maybe just --profile-compile | |||
| dogbert17 | timotimo: aha, so that was my stupid mistake | 15:43 | |
|
15:45
klapperl joined
15:46
p6bannerbot sets mode: +v klapperl
|
|||
| dogbert17 | nine: your patch fixes the parse speed problem and passes spectest except for t/spec/integration/precompiled.t which fails | 15:54 | |
| dunno, if it's the test itself which is broken | 15:58 | ||
| guess I'll have to leave it until nine or ugexe shows up | 16:04 | ||
| my spectest times improved by ~10% with this patch :) | 16:05 | ||
|
16:12
Ven`` joined
16:13
p6bannerbot sets mode: +v Ven``
16:22
Ven`` left
17:31
zakharyas joined
17:32
p6bannerbot sets mode: +v zakharyas
19:03
zakharyas left
20:05
domidumont left
21:19
AlexDaniel left
21:36
AlexDaniel joined,
p6bannerbot sets mode: +v AlexDaniel
|
|||