Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-07-24

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

All times shown according to UTC.

Time Nick Message
01:53 ilbot3 joined #moarvm
01:53 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:07 vendethiel joined #moarvm
04:37 AlexDaniel joined #moarvm
06:18 domidumont joined #moarvm
07:06 vendethiel joined #moarvm
07:22 zakharyas joined #moarvm
07:48 domidumont joined #moarvm
08:02 jnthn morning, #moarvm
08:19 jnthn I couldn't reproduce the ASAN barfage that nwc10++ reported using valgrind
08:19 jnthn But I did spot a bug where it pointed
08:20 jnthn Still a load of test failures alas
08:23 Geth ¦ MoarVM/spesh-worker: 9abca38a03 | (Jonathan Worthington)++ | src/spesh/osr.c
08:23 Geth ¦ MoarVM/spesh-worker: More robust OSR frame resize calculations.
08:23 Geth ¦ MoarVM/spesh-worker:
08:23 Geth ¦ MoarVM/spesh-worker: Of note, this copes with the case where we deopt, but OSR returns us
08:23 Geth ¦ MoarVM/spesh-worker: to the optimized version again at a later point.
08:23 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/9abca38a03
08:24 jnthn Oh, I think that I also managed a pointer type screwup in the arithmetic of the previous code
08:24 jnthn Which this also fixes
08:31 jnthn Hmm. A Rakudo built with spesh disabled passes make test even with spesh enabled.
08:31 jnthn And a load more spectests
08:32 jnthn I'm guessing that some OSR bug is causing a mis-compilation.
08:41 robertle joined #moarvm
08:47 Geth ¦ MoarVM/spesh-worker: 7a3ca8c4ff | (Jonathan Worthington)++ | src/spesh/osr.c
08:47 Geth ¦ MoarVM/spesh-worker: Make MVM_SPESH_OSR_DISABLE work again.
08:47 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/7a3ca8c4ff
08:47 Geth ¦ MoarVM/spesh-worker: c6d586f931 | (Jonathan Worthington)++ | src/spesh/osr.c
08:47 Geth ¦ MoarVM/spesh-worker: Add a way to get a simple log of performed OSR.
08:47 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/c6d586f931
08:48 jnthn Looking at spectests that explode, it seems that the issue is indeed that when we enter OSR'd code, we may be after guards which are then used
08:48 jnthn This should have been a problem in the past always however
08:49 jnthn So I can only assume we're somehow doing a lot more OSR now
08:49 jnthn And got lucky enough before now
09:14 lizmat .oO( moar OSR is good for you )
09:15 lizmat jnthn: fwiw, looking at --profile output, in many cases code that *is* OSR'd according to MVM_JIT_LOG, is not marked as OSR'd with --profile
09:15 lizmat this is on HEAD, not your branch, BTW
09:20 jnthn Hm, curious
09:39 Geth ¦ MoarVM/spesh-worker: b5f2b4b77e | (Jonathan Worthington)++ | src/spesh/graph.c
09:39 Geth ¦ MoarVM/spesh-worker: Fix bad guard assumptions around OSR points.
09:39 Geth ¦ MoarVM/spesh-worker:
09:39 Geth ¦ MoarVM/spesh-worker: Prior to this, it was possible that a condition checked before an OSR
09:39 Geth ¦ MoarVM/spesh-worker: point would always hold after it. This was not a good assumption, as
09:39 Geth ¦ MoarVM/spesh-worker: at the point OSR happens the current value in the interpreted code may
09:39 Geth ¦ MoarVM/spesh-worker: not have met the guard.
09:39 Geth ¦ MoarVM/spesh-worker:
09:39 Geth ¦ MoarVM/spesh-worker: <…commit message has 5 more lines…>
09:39 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/b5f2b4b77e
09:41 jnthn The good news is that fixes a lot.
09:42 jnthn The bad news is that it doesn't fix the mis-compile of Rakudo
09:42 jnthn Worse, spectest seems to pass cleanly
09:42 jnthn With a Rakudo compiled without OSR, and then OSR enabled
09:43 jnthn So at the moment the haystack is "all of Rakudo" :/
09:44 jnthn Apparently, CORE.setting can be excluded though
09:45 nine That doesn't leave all that much anymore?
09:45 jnthn nine: Only all of the grammar/actions/world :)
09:53 domidumont joined #moarvm
10:08 Geth ¦ MoarVM/spesh-worker: 1d799dd4c7 | (Jonathan Worthington)++ | src/spesh/stats.c
10:08 Geth ¦ MoarVM/spesh-worker: Detect another case of incomplete type tuples.
10:08 Geth ¦ MoarVM/spesh-worker:
10:08 Geth ¦ MoarVM/spesh-worker: When we have a container type, but no information on its contents.
10:08 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/1d799dd4c7
10:18 dogbert17 joined #moarvm
10:23 samcv jnthn, what's OSR stand for?
10:23 jnthn On Stack Replacement
10:24 samcv ah ok
10:24 jnthn It's where you're in a hot loop, and produce an optimized version of that code, and then replace the version currently running "on the call stack" with the optimized version
10:39 jnthn hah, found somehting
10:39 jnthn *something
10:52 nine Memory used in 8649 for http://localhost:3000/search_results: 6092 KiB
11:02 Geth ¦ MoarVM/spesh-worker: ec1ed15fbf | (Jonathan Worthington)++ | src/spesh/osr.c
11:02 Geth ¦ MoarVM/spesh-worker: More detailed logging of what OSR does.
11:02 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/ec1ed15fbf
11:02 Geth ¦ MoarVM/spesh-worker: 21122e1aab | (Jonathan Worthington)++ | 2 files
11:02 Geth ¦ MoarVM/spesh-worker: Make native references OSR-safe.
11:02 Geth ¦ MoarVM/spesh-worker:
11:02 Geth ¦ MoarVM/spesh-worker: Previously, they could end up pointing into freed memory. This is not
11:02 Geth ¦ MoarVM/spesh-worker: a new bug, just one that recent spesh refactors have brought to the
11:02 Geth ¦ MoarVM/spesh-worker: surface.
11:02 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/21122e1aab
11:03 lizmat joined #moarvm
11:04 jnthn And the mis-compile remains
11:06 jnthn This is gonna be tedious, I fear. :S
11:13 dogbert17 jnthn: I could build rakudo with your branch, am I missing something?
11:13 jnthn dogbert17: make test?
11:14 dogbert17 one test failed
11:14 dogbert17 t/04-nativecall/21-callback-other-thread.t
11:14 jnthn Huh, odd
11:15 jnthn (that others don't fail too, I mean)
11:15 jnthn You may want to try bulding with MVM_SPESH_BLOCKING=1 which may un-hide it
11:16 jnthn I'm getting failures in most NativeCall tests and some spectests
11:16 dogbert17 perhaps this might be of interest: https://gist.github.com/dogbert17/dffb56a8c0f33ba06168cd65e68bb9da
11:16 jnthn That one fails 'cus it's missing a patch from master :)
11:17 dogbert17 from master
11:17 dogbert17 so where does MVM_SPESH_BLOCKING hide
11:17 jnthn It's an env var
11:18 jnthn We do specializations on a background thread
11:18 jnthn This means that a bug may hide or show up depending on timing
11:18 dogbert17 ok, I'll rebuild rakudo with MVM_SPESH_BLOCKING=1
11:19 dogbert17 or is it enough to run the tests with it
11:19 jnthn No
11:19 jnthn So far as I can tell we do something wrong when compiling Rakudo that then causes the tests to fail whatever you run them with
11:19 jnthn I thought it was an OSR thing
11:20 jnthn But...just did a build with that disabled and still got a busted build
11:20 jnthn I mean, the build is OK, but the result is bad
11:20 jnthn Just got that again
11:20 jnthn Grr
11:22 jnthn lunch time, bbiab
11:27 domidumont joined #moarvm
12:06 AlexDani` joined #moarvm
12:09 * jnthn back
12:16 dogbert17 jnthn: exported MVM_SPESH_BLOCKING=1, applied your patch, rubuilt moarvm and rakudo, no spectest fails but t/04-nativecall/21-callback-other-thread.t still fails albeit differently this time
12:18 jnthn Very strange
12:18 dogbert17 could it be because I'm on 32 bit?
12:18 jnthn I wonder what's different
12:18 jnthn Maybe but...hard to see how
12:19 jnthn Just done a rebuild of NQP to make sure it wasn't something there
12:22 dogbert17 have you had to make any changes to frame.c?
12:22 jnthn Various
12:22 jnthn I wonder
12:23 dogbert17 anything here? https://gist.github.com/dogbert17/f97eea4262ac1e364d4681696525ef91
12:24 * jnthn nukes his install directory in case he polluted it in the past
12:25 jnthn dogbert17: Just to confirm: you're on the spesh-worker branch of MoarVM?
12:26 dogbert17 On branch spesh-worker
12:26 dogbert17 Your branch is up-to-date with 'origin/spesh-worker'.
12:27 jnthn And HEAD NQP/Rakudo?
12:27 * jnthn is updating his now
12:28 jnthn And 21-callback-other-thread.t is the only failure you see in `make test`?
12:29 dogbert17 that's the only failure. as for nqp I'm on HEAD detached at 3e8089404
12:29 zakharyas joined #moarvm
12:30 jnthn ah, that's HEAD anyway
12:30 jnthn And same as me now
12:30 jnthn OK, then we're certainly seeing different things
12:31 jnthn (I'm seeing a lot more of make test fail)
12:31 dogbert17 odd
12:31 dogbert17 I built Moar with '--debug --no-optimize --asan'
12:31 jnthn Just --debug here
12:32 jnthn I nuked all I could think of that I coulda corrupted, but still it seems sensitive to spesh being enabled or disabled when building Rakudo
12:33 jnthn And, interestingly, not sensitive to OSR or inlining
12:36 jnthn Spesh disabled for everything up to CORE.setting, then enabled for CORE.setting, seems to show the bug
12:37 dogbert17 how did you do that
12:38 jnthn Just Ctrl+C at the appropriate point then "make" again with the other flags
12:38 jnthn Well, env vars, not flags
12:38 jnthn If you're not seeing the problem with spesh enabled the whole way through, and even with MVM_SPESH_BLOCKING=1 set, though, I don't think you're likely to reproduce it
12:39 dogbert17 that limits my possibilities :(
12:40 jnthn OK, spesh enabled until metamodel, then metamodel, BOOTSTRAP, and CORE.setting with it fully disabled makes things work
12:40 dogbert17 cool
12:40 jnthn So next question is if I include metamodel and bootstrap
12:43 jnthn Then it also passes
12:43 jnthn So darn, it's a CORE.setting mis-compile
12:43 dogbert17 interesting
12:45 nine now that's a huge chunk :/
12:45 jnthn Yeah, if I rm CORE.setting and make it again and then test, then I get the failures
12:45 jnthn Includes if I do it with OSR and inlining disabled, so can rule those out
12:46 jnthn Though now I'm curious how I didn't see this before
12:46 domidumont joined #moarvm
12:46 jnthn Trying now with JIT disabled
12:46 * dogbert17 wouldn't be surprised if that worked
12:46 jnthn Since when I brought back kicking out osrpoint suddenly we could JIT loads of stuff again
12:47 nine jnthn: could you narrow it down by moving parts of CORE.setting to CORE.d.setting?
12:47 jnthn hah, pass
12:47 jnthn So it's something that only happens when CORE.setting is compiled and the compiler is JITted
12:49 jnthn Hm, I just wonder...
12:52 jnthn dogbert17: oh, and this explains why you don't see it on 32-bit: we only JIT on x64, not x86
12:54 dogbert17 indeed, so it seems that I won't be able to help fix this particular problem :(
12:54 dogbert17 the fail in t/04-nativecall/21-callback-other-thread.t reamins though but that's possibly something different
12:56 jnthn Yeah, that's 'cus the fix for it is in master but not merged into spesh-worker
12:56 dogbert17 ahh
12:57 dogbert17 so I'm essentially bug free then :)
12:57 jnthn Wow, all the failures are variants on the theme "Expected Callable but got <something here that you'd expect to be callable>"
12:57 * dogbert17 tries a stresstest instead
12:57 jnthn And always with things mixed in on the RHS
13:09 buggable joined #moarvm
13:11 buggable joined #moarvm
13:12 Zoffix That sounds similar to a ticket
13:12 Zoffix m: say Any.^can("push")[0] ~~ Callable;
13:12 camelia rakudo-moar a636fa: OUTPUT: «False?»
13:12 Zoffix https://rt.perl.org/Ticket/Display.html?id=128905#ticket-history
13:19 jnthn Seems that it's that the JIT didn't spit out the SC write barriers
13:19 jnthn It'd be rather nice if we could specialize on lack of need for them
13:19 jnthn But for now I'll pop them in all the time
13:20 jnthn Seems that does it
13:24 jnthn yay, clean tests
13:24 jnthn Now to stress it some :)
13:26 Geth ¦ MoarVM/spesh-worker: b4ad1dcce9 | (Jonathan Worthington)++ | 3 files
13:26 Geth ¦ MoarVM/spesh-worker: JIT should include SC write barriers.
13:26 Geth ¦ MoarVM/spesh-worker:
13:26 Geth ¦ MoarVM/spesh-worker: Otherwise, when we are compiling things that rely on repossession of
13:26 Geth ¦ MoarVM/spesh-worker: serialized objects, that will not happen, resulting in mis-compiles.
13:26 Geth ¦ MoarVM/spesh-worker: It would be nice in the future ot only conditionally include these
13:26 Geth ¦ MoarVM/spesh-worker: (and specialize on us not being in the context of compilation). For
13:26 Geth ¦ MoarVM/spesh-worker: now, this at least gets things correct.
13:26 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/b4ad1dcce9
13:26 jnthn Another bug that's been there a good while
13:27 jnthn Rakudo builds and make tests with MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1
13:28 jnthn As does NQP
13:28 jnthn And make spectest with those flags now running
13:29 timotimo man, it really is fascinating that it never b0rked before from those bugs you're finding here
13:29 jnthn Yeah, really
13:29 jnthn Though I think we knew that MVM_SPESH_NODELAY=1 broke things
13:30 timotimo we did know that
13:30 jnthn But that was never really dub into
13:30 jnthn *dub
13:30 jnthn *dug!
13:30 jnthn I suspect with NQP and Rakudo make test-ing clean with it, we're in a better shape than we've been before
13:31 jnthn Alas, make spectest isn't clean
13:32 jnthn But only 6 files with issues
13:32 timotimo that sounds good already
13:37 jnthn Taking the SEGV first :)
13:39 timotimo oh, huh
13:39 timotimo did i miss something
13:39 timotimo ./perl6-m tools/build/install-core-dist.pl /home/timo/perl6/install/share/perl6
13:39 timotimo ===SORRY!===
13:39 timotimo At Frame 123, Instruction 56, op 'sp_guard' has invalid number (4) of operands; needs 2.
13:39 jnthn wat
13:40 jnthn works for me fwiw
13:40 timotimo i did a fresh configure.pl in rakudo, so it's not the ops.c that coulda b0rk
13:42 jnthn huh, I'm getting MVM_gc_debug_find_region not producing any output
13:42 jnthn Even though there's no cdoe paths where it would not produce output
13:42 timotimo it can't throw exceptions, either?
13:42 jnthn No
13:43 timotimo oh, i did have a gdb still running
13:43 timotimo that could have kept moar or libmoar from being updated
13:45 jnthn ah, if I run fflush(stdout) it does it
13:45 jnthn oh, I see why
13:45 Geth ¦ MoarVM/spesh-worker: 304605c14d | (Jonathan Worthington)++ | src/gc/debug.c
13:45 Geth ¦ MoarVM/spesh-worker: Add missing newline in debug output.
13:45 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/304605c14d
13:46 jnthn So apparently the bad pointer we're following is in gen2 bin of thread 1
13:48 jnthn Huh, with a junk replaced pointer
13:52 timotimo well, spesh creates a sp_guard op and only gives it two parameters
13:52 timotimo on the other hand
13:52 timotimo sp_guard is also defined to only have two arguments
13:53 timotimo oooh
13:53 timotimo i had been working on a nativecallglobalwrite op
13:56 timotimo just adding it caused nativecall tests to segfault
13:56 jnthn d'oh, shoulda noticed the flags
13:56 jnthn Turns out it's a type object
13:57 timotimo ah, there's no valid data there, then
13:57 jnthn yeah
13:59 timotimo callack-other-thread is the one that's "allowed" to crash?
14:00 timotimo it prints "MoarVM panic:" and immediately segfaults, that might be what you're hunting now, then
14:00 timotimo however, it also does that without the flags set
14:08 Geth ¦ MoarVM/spesh-worker: b351124ae1 | (Jonathan Worthington)++ | src/spesh/optimize.c
14:08 Geth ¦ MoarVM/spesh-worker: Stronger validation of code objects in optimizer.
14:08 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/b351124ae1
14:08 jnthn timotimo: yeah, that one is fixed in master, not in spesh-worker
14:08 jnthn Just needs a merge/rebase
14:09 jnthn Down to 5 after that patch
14:09 timotimo oooh
14:21 Geth ¦ MoarVM/spesh-worker: 217334e2b6 | (Jonathan Worthington)++ | src/spesh/osr.c
14:21 Geth ¦ MoarVM/spesh-worker: NULL out registers on re-OSR.
14:21 Geth ¦ MoarVM/spesh-worker:
14:21 Geth ¦ MoarVM/spesh-worker: If we previously ran the OSR'd code for this frame, then we don't need
14:21 Geth ¦ MoarVM/spesh-worker: to resize work/env. However, they were unused while the deopt code was
14:21 Geth ¦ MoarVM/spesh-worker: being run, and so may contain outdated pointers that will upset the
14:21 Geth ¦ MoarVM/spesh-worker: GC if it comes across them. Fix this by making sure that space is
14:21 Geth ¦ MoarVM/spesh-worker: cleared out.
14:21 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/217334e2b6
14:22 jnthn And now down to 4.
14:22 japhb w00t!
14:22 jnthn Which give the same kinda error, so may be the same thing.
14:23 japhb Would be nice if so
14:23 jnthn Also they go away with OSR disabled
14:24 jnthn Who'd have thought replacing running code with an optimized version of that code could be so tricky :P
14:25 timotimo nobody knew code care would be this complicated  - Dolan Drumpf, probably
14:30 jnthn oh, interesting
14:30 jnthn MVM_JIT_DISABLE=1 also fixes it
14:31 jnthn So more then likely to be a JIT issue
14:34 jnthn It's the JIT of can_meta in Perl6::Grammar that's at issue, it seems
14:35 jnthn If I disable JITting that, it works out
14:35 timotimo disabling jitting that, as in, a jit limit? or a non-jittable op right in the middle?
14:35 jnthn I just check for the name can_meta :)
14:37 timotimo ah, heh
14:37 jnthn oh
14:38 jnthn I bet the JIT doesn't do https://github.com/MoarVM/MoarVM/blob/master/src/core/interp.c#L2354
14:40 timotimo you're right
14:41 jnthn What an annoying thing to need to do
14:41 timotimo i wonder how hard it is to insert labels into the jit graph directly
14:41 timotimo yes, it is
14:41 timotimo much easier in the new jit, for sure
14:41 timotimo let me investigate
14:42 jnthn I guess the easy option is for us to not devirt it for now and to put the check into MVM_repr_at_key_o
14:42 timotimo we only devirt if the type is known to spesh facts
14:42 timotimo but not that it's known to be concrete
14:42 jnthn Oh
14:42 jnthn If we add the "know it's concrete"
14:42 jnthn Then we're good :)
14:43 timotimo hm, you know
14:43 timotimo since the jit uses the reprconv
14:43 jnthn Well, provided we stick the check into the function too
14:43 jnthn Right, that's the function I meant to tweak :)
14:43 timotimo ah, yes
14:44 jnthn oh, it already *is* in there
14:44 jnthn Except it returns a real NULL.
14:44 jnthn D'oh
14:45 timotimo aha!
14:45 timotimo is this part of the repr contract? if so, we could actually throw the check out from the interpreter if the repr op function does it again anyway
14:45 jnthn Seems to do it
14:45 timotimo though of course that'll save us a function pointer call
14:46 jnthn The interpreter just doesn't call the convenience function
14:46 timotimo oh, you mean *that* has the check
14:46 jnthn right :)
14:46 timotimo d'oh, i was looking at the first one in the file, which was for atkey_i
14:47 timotimo of course that doesn't have the null check
14:47 jnthn Seems I've a fix :)
14:47 timotimo habemus fixem
14:48 * jnthn lets another spectest with blocking/nodelay rip
14:52 Geth ¦ MoarVM/spesh-worker: d2adde4e23 | (Jonathan Worthington)++ | src/6model/reprconv.c
14:52 Geth ¦ MoarVM/spesh-worker: Never return a real NULL.
14:52 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/d2adde4e23
14:52 Geth ¦ MoarVM/spesh-worker: e44e7b21d4 | (Jonathan Worthington)++ | src/jit/graph.c
14:52 Geth ¦ MoarVM/spesh-worker: Only devirtualize when concreteness is known.
14:52 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/e44e7b21d4
14:52 jnthn ENOCIGAR, alas
14:52 jnthn That accounted for 3 out of the remaining 4 test files with issues
14:53 jnthn t/spec/S32-io/io-spec-win.t remains unhappy
14:53 jnthn Oh.
14:53 jnthn It's gonna be another JIT one
14:55 jnthn Invalid string index: max 1, got 2 at SETTING::src/core/IO/Spec/Win32.pm:81  (./CORE.setting.moarvm:is-absolute)
15:07 jnthn ah, it's 'cus the JIT tries to be clever rather than calling ord_at
15:07 jnthn But they two do different handling of out of bounds
15:08 jnthn And I ain't sure that it's a win anyway
15:08 timotimo ah
15:08 jnthn In that the C compiler probably inlines get_grapheme_at_nocheck
15:10 jnthn Alright, here we go again for a blocking/nodelay test run :)
15:18 Geth ¦ MoarVM/spesh-worker: 53277743d5 | (Jonathan Worthington)++ | src/jit/emit_x64.dasc
15:18 Geth ¦ MoarVM/spesh-worker: Fix JIT of nqp::ordat and nqp::ordfirst.
15:18 Geth ¦ MoarVM/spesh-worker:
15:18 Geth ¦ MoarVM/spesh-worker: They have different rules on out-of-bounds than get_grapheme_at.
15:18 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/53277743d5
15:18 jnthn There we go, spectest happy with MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1
15:21 jnthn Run with a NQP/Rakudo built with the same
15:23 jnthn Even better
15:23 jnthn make stresstest is *also* happy \o/
15:24 timotimo man, this is good stuff
15:25 jnthn So in terms of correctness, we're OK to merge.
15:27 jnthn That bad news is that somewhere along the way doing these improvements we've lost some performance on CORE.setting compilation
15:34 jnthn The perf output is kinda nuts
15:36 jnthn Guess I'm using the wrong options
15:40 jnthn hah, yes
15:52 jnthn Well, more performance analysis tomorrow, I guess
15:53 jnthn cooking time; bbl
15:57 colomon joined #moarvm
16:13 timotimo 2.61% MVM_spesh_arg_guard_run, is that expected?
16:18 [Coke] jnthn++
16:22 timotimo interestingly the core setting compilation takes only 99% cpu time
16:22 timotimo whereas i'd've expected it to have more than 100% because of the spesh worker thread
16:30 nwc10 jnthn: didn't get a chance to say that something you did fixed the ASAN failure
16:30 nwc10 ASAN was a bit bored, but now it is very excited by t/04-nativecall/21-callback-other-thread.t
16:32 timotimo oh, that's the thing that's fixed on master but not rebased for spesh-worker yet
16:32 timotimo so can you rebase or merge master and try that one again?
16:33 nwc10 http://paste.scsys.co.uk/564676
16:33 nwc10 timotimo: I should rebase it locally?
16:33 timotimo yes, or merge locally
16:34 nwc10 yes, that fixes it
16:34 nwc10 ASAN thinks that you are no fun :-)
16:35 timotimo :)
16:35 timotimo sometimes you can't be the fun dad, you have to be the boring dad instead
16:35 jnthn :)
16:35 jnthn Well, there's the bolognese going...
16:35 jnthn timotimo: It's..."not bad" I guess. It's quite a hot path
16:35 jnthn timotimo: Before this logic was sat inside of invoke, which was always very costly
16:36 timotimo indeed it was
17:15 domidumont joined #moarvm
17:17 domidumont joined #moarvm
18:03 robertle joined #moarvm
18:41 lizmat joined #moarvm
20:01 ggoebel joined #moarvm
20:51 lizmat jnthn: would it be a good thing to explain in one paragraph what you've done the past week ?
20:52 jnthn lizmat: Yeah, sounds like a good idea.
20:53 jnthn (Do I need to write said paragraph? :))
20:53 lizmat yes please  :-)
20:57 jnthn Jonathan continued working on the the first step of his overhaul of the MoarVM dynamic optimizer, which optimizes hot code based on collected type information. He now has optimization and JIT compilation running on a background thread rather than interrupting code, and a new means of data collection that will allow for smarter optimization decisions in the future. Along the way, he has fixed a range of optimization bugs that existed prior to his
20:58 jnthn Maybe better: s/now has/now has a branch with/
20:58 [Coke] (stopped on "prior to his")
20:58 jnthn ah
20:59 jnthn prior to his changes and were driven out by stresstesting. With everything working again, he will now switch to tuning it ahead of a merge.
20:59 lizmat jnthn++  :-)
21:00 lizmat (not only making things faster, but also easier for me :-)
21:00 jnthn Trouble is that at this point its slower :P
21:00 jnthn (Thus the tuning to come.)
21:00 jnthn Also this branch isn't really doing any of the clever new things this work aims to enable.
21:01 timotimo btw, we don't put osrpoints into regexes, i don't think. should we?
21:01 lizmat jnthn: BTW, looks like moarvm.org doesn't know about 2017.07 yet
21:01 jnthn oops
21:01 jnthn Thought I'd done that. D'oh.
21:01 * jnthn blames the hot weather last week :P
21:01 timotimo it's pleasantly cold today
21:02 timotimo below 20 degC i believe
21:02 jnthn Yes, now it is
21:02 jnthn Last week it wasn't
21:02 jnthn Right now it's great
21:10 colomon_ joined #moarvm
22:33 lizmat and another Perl 6 Weekly hits the Net: https://p6weekly.wordpress.com/2017/07/24/2017-30-starring-fresh-produce/
23:37 samcv more work going on with the collation-arrays. since i got things working pretty great yesterday now i'm working on making certain sections of it more correct. such as when i start tracing the linked list of possibilities of a codepoint, making sure that i push the last seen node with colation elements to the stack then forwarding the rest of the codepoints back into the function another time
23:43 samcv always feels good to delete a bunch of code and write much nicer code in its place. though it took a lot of work to get to that ugly code i had written in certain areas
23:43 samcv but it's (usually) never a waste because i would never have been able to write the nice code without writing the ugly code first :)

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