Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-01-06

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

All times shown according to UTC.

Time Nick Message
01:14 [Coke] joined #moarvm
01:14 konobi joined #moarvm
01:14 arnsholt_ joined #moarvm
01:14 leedo joined #moarvm
01:14 sivoais joined #moarvm
01:14 sivoais joined #moarvm
01:25 zostay joined #moarvm
01:44 SmokeMachine joined #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:18 dalek joined #moarvm
06:55 brrt joined #moarvm
07:38 brrt it appears i have found the root cause of the wrong spillage
07:38 brrt contrary to what i want to do, the load is inserted just after the use
07:39 * brrt should probably ressurrect tile debug dumping
07:39 brrt hmm, that may not be true after all...
07:40 samcv brrt, how do i make callgrind give me more data
07:41 samcv it's not giving me any of the functions called by the utf8 stream decoder
07:41 samcv just saying that function is using that, but i know it calls many other utf-8 functions
07:43 brrt i'm actually not all that familiar with calgrind
07:43 brrt i know valgrind and i know ASAN
08:22 brrt joined #moarvm
08:34 btyler joined #moarvm
08:37 tbrowder joined #moarvm
08:37 ilmari joined #moarvm
08:37 mst joined #moarvm
08:37 camelia joined #moarvm
08:37 nine joined #moarvm
08:37 nebuchadnezzar joined #moarvm
08:37 stmuk joined #moarvm
08:37 japhb joined #moarvm
08:37 nwc10 joined #moarvm
08:37 mtj_ joined #moarvm
08:37 BinGOs joined #moarvm
08:37 moritz joined #moarvm
08:37 jnthn joined #moarvm
08:37 Util joined #moarvm
08:37 JimmyZ joined #moarvm
08:37 ChanServ joined #moarvm
08:44 sivoais joined #moarvm
08:56 zakharyas joined #moarvm
09:18 leego joined #moarvm
10:10 jnthn morning o/
10:10 yoleaux2 5 Jan 2017 23:45Z <samcv> jnthn: so I am trying to get certain emoji working, and so i made this change here https://github.com/samcv/MoarVM/commit/a29f54d973a59668e81da1b05df3420d73f6c58d#diff-60b7c4ce4f16e0e46451e0610dbc21b3R579
10:10 yoleaux2 5 Jan 2017 23:47Z <samcv> jnthn: and oh oops i made a mistake. sorta nvm
10:10 yoleaux2 05:10Z <MasterDuke> jnthn: if you don't mind taking a look at https://irclog.perlgeek.de/perl6-dev/2017-01-06#i_13865466, do you have an opinion? should we give the same error and suggestion for all Nd's as for [1..9]?
10:11 samcv morning jnthn
10:11 samcv also yeah nvm that thing i said. i got it working :)
10:11 samcv PR is on moar and ready for merge
10:11 jnthn \o/
10:11 jnthn Review coming shortly then :)
10:12 lizmat moarning jnthn   :-)
10:12 yoleaux2 05:10Z <MasterDuke> lizmat: if you don't mind taking a look at https://irclog.perlgeek.de/perl6-dev/2017-01-06#i_13865466, do you have an opinion? should we give the same error and suggestion for all Nd's as for [1..9]?
10:12 samcv i want only 1 yoleaux2
10:12 jnthn hi lizmat
10:12 samcv not 2
10:13 jnthn samcv: About your calling question in backlog, what flags did you build with?
10:13 jnthn You may get more into with --debug=3
10:13 samcv --debug
10:13 samcv ah. ok :)
10:14 jnthn s/calling/callgrind/ # d'oh :)
10:14 samcv i will do that then
10:14 jnthn But I don't know whether callgrind can take advantage of that
10:14 arnsholt Could be inlining?
10:14 jnthn Since it's a dynamic analysis, and inlining means that some frames really don't exist
10:14 samcv i don't think the utf-8 stream decode is inlined but
10:14 jnthn gdb seems to happily untangle that with --debug=3
10:14 samcv ah nice :)
10:15 jnthn So I guess that data's there at least.
10:15 arnsholt --debug=3 turns into -g3?
10:16 jnthn With gcc I believe so, yeah
10:16 jnthn Maybe it's same for clang too, forget these intricacies :)
10:16 arnsholt Yeah, I assume it's different for MSVC =)
10:16 arnsholt Anyways, -g3 is really nice
10:16 arnsholt Another *very* useful thing it adds is macro definitions
10:17 samcv nice
10:17 samcv i've been using the kcachegrind program to inspect the logs
10:17 arnsholt So that you can p OBJECT_BODY(a_thing), rather than figuring out the definition *again*
10:18 arnsholt (Though note that gdb can also be told about macros run-time, so that at least you only have to figure them out once per session =)
10:18 arnsholt Yeah, kcachegrind is nice
10:19 samcv urm yeah this is more in depth for sure
10:19 jnthn Nice :)
10:19 jnthn PR reviewed
10:24 jnthn Righty, I was looking into that leak...
10:30 nwc10 Merry Christmas 2.0, jnthn
10:31 jnthn Thanks! :)
10:31 * jnthn celebrates with coffee and deleting code :)
10:33 samcv jnthn, fixes made
10:50 Ven joined #moarvm
10:50 brrt my spilling code doesn't break, but does return the wrong value, and i need to figure out why
10:50 brrt to be continued
10:52 dalek MoarVM: ebc4abc | samcv++ | src/strings/normalize.c:
10:52 dalek MoarVM: Don't break after ZWJ or for MALE SIGN and FEMALE SIGN
10:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ebc4abc7ea
10:52 dalek MoarVM: d26f8c0 | samcv++ | src/strings/normalize.c:
10:52 dalek MoarVM: use #define’s for the ZWJ, ZWNJ, MALE SIGN and FEMALE sign
10:52 dalek MoarVM:
10:52 dalek MoarVM: Also use a switch for a = MVM_UNICODE_PVALUE_GCB_ZWJ in should_break()
10:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d26f8c03c0
10:52 dalek MoarVM: 331a6b4 | jnthn++ | src/strings/normalize.c:
10:52 dalek MoarVM: Merge pull request #486 from samcv/emoji
10:52 dalek MoarVM:
10:52 dalek MoarVM: Don't break after ZWJ or for MALE SIGN, FEMALE SIGN or Glue_After_ZWJ
10:52 samcv yey
11:18 dalek MoarVM/work-lifetime: 1d3cdad | jnthn++ | / (12 files):
11:18 dalek MoarVM/work-lifetime: Eliminate the getregref_ ops.
11:18 dalek MoarVM/work-lifetime:
11:18 dalek MoarVM/work-lifetime: These meant that we could not rely on ->work no longer being needed
11:18 dalek MoarVM/work-lifetime: after the frame's execution was completed. This implied that, short of
11:18 dalek MoarVM/work-lifetime: static analysis to check these ops were not used, we could not be sure
11:18 dalek MoarVM/work-lifetime: it was OK to throw out ->work right after the frame's dynamic scope
11:18 dalek MoarVM/work-lifetime: ended. The ops were not being used in Rakudo, nor in NQP besides in
11:18 dalek MoarVM/work-lifetime: the code that compiled into them, which was already been removed. They
11:18 dalek MoarVM/work-lifetime: only existed to allow lowering of lexicalref => localref at some point
11:18 dalek MoarVM/work-lifetime: in the future, but an optimization that pessimizes the world is hardly
11:18 dalek MoarVM/work-lifetime: a win. It would also have been a huge pain for the JVM backend, and
11:18 dalek MoarVM/work-lifetime: likely the JS backend too, to implement localref (neither did so).
11:18 dalek MoarVM/work-lifetime: review: https://github.com/MoarVM/MoarVM/commit/1d3cdad467
11:24 jnthn While I'm killing off unused stuff that costs us...
11:25 jnthn Nothing anywhere in Rakudo or NQP, except some tests cases that don't entirely pass anyway, needs multi-shot continuations.
11:25 jnthn We only need one-shot ones in Rakudo
11:25 jnthn But we complicate some hot code-paths by attempting to support them
11:25 jnthn And I can't see us ever needing them
11:25 jnthn We only really need co-routine power
11:26 jnthn Which we get from one-shot
11:26 jnthn For both gather/take and in the future for non-blocking await
11:27 jnthn This comes up now because I'm tidying up the code path in question.
11:27 jnthn But also because I suspect we can reduce memory pressure for gather/take along the way
11:27 jnthn The only reason I put this in was because I was porting the JVM backend continuation tests
11:29 arnsholt Sounds sensible enough killing it off, then
11:29 arnsholt I mean continuations are cool, and all, but if they're costly and unused...
11:29 jnthn Right
11:30 jnthn And given we fail the multi-shot tests anyway (I didn't sink time into them then 'cus we didn't need it) I'm doubtful anyone is using it
11:30 lizmat YAGNI applies, I guess  :-)
11:31 jnthn *nod*
11:31 jnthn Yes, I'd prefer to make things better for all the users I know I have than keep a feature only interesting to users I can imagine might feasibly exist. :)
11:36 arnsholt My only use case for continuations is non-deterministic search, and I think one-shot is fine for that too
11:39 dalek MoarVM/work-lifetime: f2dae67 | jnthn++ | src/core/frame.c:
11:39 dalek MoarVM/work-lifetime: Re-order/simplify operations in remove_one_frame.
11:39 dalek MoarVM/work-lifetime:
11:39 dalek MoarVM/work-lifetime: If the frame is on the call stack, we don't need to NULL stuff in it;
11:39 dalek MoarVM/work-lifetime: it's going away anyway. We also eliminate a duplicate call to the
11:39 dalek MoarVM/work-lifetime: function MVM_args_proc_cleanup_for_cache for the callstack case (the
11:39 dalek MoarVM/work-lifetime: MVM_args_proc_cleanup in MVM_frame_destory calls it anyway). We may
11:39 dalek MoarVM/work-lifetime: have continuation tags in a frame that was never promoted, since we
11:39 dalek MoarVM/work-lifetime: may add tags but never actually take a continuation (a `gather` that
11:39 dalek MoarVM/work-lifetime: never does `take` would be such an example), so we take care not to
11:39 dalek MoarVM/work-lifetime: leak those. That duplication can be cleaned up a little later.
11:39 dalek MoarVM/work-lifetime: review: https://github.com/MoarVM/MoarVM/commit/f2dae6715f
11:52 * dogbert17 notices a hive of activity :)
11:54 dalek MoarVM/work-lifetime: 202c266 | jnthn++ | / (10 files):
11:54 dalek MoarVM/work-lifetime: Eliminate continuationclone op.
11:54 dalek MoarVM/work-lifetime:
11:54 dalek MoarVM/work-lifetime: Unused by anything in Rakudo, and in NQP only used in a test case. It
11:54 dalek MoarVM/work-lifetime: was added because nqp-j had the op, and MoarVM continuations were done
11:54 dalek MoarVM/work-lifetime: to the same API. However, we never used it besides that test case, and
11:54 dalek MoarVM/work-lifetime: it didn't really work properly anyway because we didn't need it, so it
11:54 dalek MoarVM/work-lifetime: is a bit hard to imagine any unknown users seriously relying on it.
11:54 dalek MoarVM/work-lifetime: The removal of this will help to simplify ->work lifetime management.
11:54 dalek MoarVM/work-lifetime: review: https://github.com/MoarVM/MoarVM/commit/202c266a17
11:54 dogbert17 does anyone know how to run a single spectest file with the perl6 test harness? TEST_HARNESS=6 does not seems to work
11:56 dogbert17 e.g. 'make t/spec/S24-testing/line-numbers.t TEST_HARNESS=6' runs with t/harness5 :(
12:13 * dogbert17 notices that this behaviour is hard coded into Configure.pl
12:20 dalek MoarVM/work-lifetime: 3819e7b | jnthn++ | src/ (2 files):
12:20 dalek MoarVM/work-lifetime: Enforce one-shot invocation of continuations.
12:20 dalek MoarVM/work-lifetime:
12:20 dalek MoarVM/work-lifetime: One-shot is all that Rakudo needs for gather/take, and will suffice
12:20 dalek MoarVM/work-lifetime: for non-blocking `await` also. We never really properly handled the
12:20 dalek MoarVM/work-lifetime: multi-shot case anyway, out of not needing it. And our incomplete
12:20 dalek MoarVM/work-lifetime: attempts to support it came with some nasty memory management risks.
12:20 dalek MoarVM/work-lifetime: The only non-trivial test for this in the NQP test suite already was
12:20 dalek MoarVM/work-lifetime: failing, so there's no loss there. This protection will also be useful
12:20 dalek MoarVM/work-lifetime: for catching bugs when we introduce non-blocking `await` in Rakudo, as
12:20 dalek MoarVM/work-lifetime: any double invocation there will surely be a screw-up.
12:20 dalek MoarVM/work-lifetime: review: https://github.com/MoarVM/MoarVM/commit/3819e7b1a3
12:35 jnthn Lunch time, but looks like the next commit - provided spectest passes - brings some nice simplifications :)
13:10 jnthn Darn. A couple of fails.
13:17 * jnthn re-does it in small steps
13:18 nwc10 but will *you* finish before ilmari remembers to have lunch?
13:18 FROGGS joined #moarvm
13:19 * jnthn hopes so ;)
13:25 dalek MoarVM/work-lifetime: 8035038 | jnthn++ | src/core/ (3 files):
13:25 dalek MoarVM/work-lifetime: Simplifications from making continuations 1-shot.
13:25 dalek MoarVM/work-lifetime:
13:25 dalek MoarVM/work-lifetime: We no longer need the `in_continuation` flag, which eliminates the
13:25 dalek MoarVM/work-lifetime: code to set it, the storage (though due to alignment we won't really
13:25 dalek MoarVM/work-lifetime: save anything) and the code to check it. It was checked every time a
13:25 dalek MoarVM/work-lifetime: callframe was taken off the stack, which adds up over a program's
13:25 dalek MoarVM/work-lifetime: lifetime. Furthermore, we can now unconditionally clear up any
13:25 dalek MoarVM/work-lifetime: continuation tags.
13:25 dalek MoarVM/work-lifetime: review: https://github.com/MoarVM/MoarVM/commit/8035038c00
13:25 jnthn That part seems innocent :)
13:33 dalek MoarVM/work-lifetime: 0ed5e11 | jnthn++ | src/core/frame.c:
13:33 dalek MoarVM/work-lifetime: Avoid duplicate continuation tag cleanup check.
13:33 dalek MoarVM/work-lifetime:
13:33 dalek MoarVM/work-lifetime: This was harmless, but a waste of a few cycles on frame destruction.
13:33 dalek MoarVM/work-lifetime: Given that only frames that were on the call stack will ever have had
13:33 dalek MoarVM/work-lifetime: opportunity to run a `continuationreset`, there unconditional cleanup
13:33 dalek MoarVM/work-lifetime: of them in `remove_one_frame` should suffice. (Deserialized contexts
13:33 dalek MoarVM/work-lifetime: of closures will never have any continuation_tags and no means to get
13:33 dalek MoarVM/work-lifetime: them.)
13:33 dalek MoarVM/work-lifetime: review: https://github.com/MoarVM/MoarVM/commit/0ed5e11eae
13:33 jnthn And that one.
13:41 jnthn Umm
13:41 jnthn If I read the numbers right, CORE.setting compilation mighta just got somewhat faster. :)
13:43 ilmari nwc10: I have now finished lunch
13:44 jnthn I'm slower. :)
13:44 nwc10 :-)
13:51 dalek MoarVM/work-lifetime: 5c1ecc0 | jnthn++ | src/core/frame.c:
13:51 dalek MoarVM/work-lifetime: Always release ->work at end of a frame's scope.
13:51 dalek MoarVM/work-lifetime:
13:51 dalek MoarVM/work-lifetime: This is safe to do unconditionally now that continuations are one-shot
13:51 dalek MoarVM/work-lifetime: and register references are no more. This brings forward when memory
13:51 dalek MoarVM/work-lifetime: can be released, and also prevents things from lingering in the
13:51 dalek MoarVM/work-lifetime: inter-generational set for so long (we now really only ever do that
13:51 dalek MoarVM/work-lifetime: when the frame is still in dynamic scope - for very long-lived and
13:51 dalek MoarVM/work-lifetime: heap-promoted frames - since we don't enforce write barriers on
13:51 dalek MoarVM/work-lifetime: registers).
13:51 dalek MoarVM/work-lifetime: review: https://github.com/MoarVM/MoarVM/commit/5c1ecc0a95
14:09 dalek MoarVM/work-lifetime: 3398380 | jnthn++ | src/core/exceptions.c:
14:09 dalek MoarVM/work-lifetime: Use ->work as our "in dynamic scope" test.
14:09 dalek MoarVM/work-lifetime:
14:09 dalek MoarVM/work-lifetime: It now reliably provides this information.
14:09 dalek MoarVM/work-lifetime: review: https://github.com/MoarVM/MoarVM/commit/339838079f
14:09 dalek MoarVM/work-lifetime: 5918061 | jnthn++ | src/ (3 files):
14:09 dalek MoarVM/work-lifetime: Eliminate `tc` field in MVMFrame.
14:09 dalek MoarVM/work-lifetime:
14:09 dalek MoarVM/work-lifetime: We used to use it to track whether a frame is in dynamic scope, but
14:09 dalek MoarVM/work-lifetime: now the `work` field can be reliably used for that. This shaves a
14:09 dalek MoarVM/work-lifetime: memory write off every frame setup, but more significantly cuts the
14:09 dalek MoarVM/work-lifetime: size of every MVMFrame by 4 (32-bit) or 8 (64-bit) bytes, which will
14:09 dalek MoarVM/work-lifetime: reduce memory pressure.
14:09 dalek MoarVM/work-lifetime: review: https://github.com/MoarVM/MoarVM/commit/5918061358
14:09 timotimo cool, that also means more frames fit into our callstack regions :)
14:11 jnthn Aye
14:18 timotimo i wonder when other people get the pedantic anti-warning warning problem
14:19 dalek MoarVM/work-lifetime: fdfe07b | jnthn++ | src/core/args. (2 files):
14:19 dalek MoarVM/work-lifetime: Simplify args cleanup functions.
14:19 dalek MoarVM/work-lifetime:
14:19 dalek MoarVM/work-lifetime: Reduce to one function, removing the confusingly-named "for_cache"
14:19 dalek MoarVM/work-lifetime: form that did only part of the work.
14:19 dalek MoarVM/work-lifetime: review: https://github.com/MoarVM/MoarVM/commit/fdfe07b721
14:22 dalek MoarVM/work-lifetime: e592dbc | jnthn++ | src/gc/roots.c:
14:22 dalek MoarVM/work-lifetime: Reduce number of checks in GC frame marking.
14:22 dalek MoarVM/work-lifetime:
14:22 dalek MoarVM/work-lifetime: If the frame is no longer in dynamic socpe, we can't possibly have any
14:22 dalek MoarVM/work-lifetime: args to care about.
14:22 dalek MoarVM/work-lifetime: review: https://github.com/MoarVM/MoarVM/commit/e592dbc127
14:39 jnthn I...what...number did I just see for CORE.setting parse?
14:39 timotimo oooh, spill the beans!
14:39 * jnthn will have to do some measuring after testing the upcoming patch
14:40 brrt ohoooh
14:40 brrt we need to know
14:41 dalek MoarVM/work-lifetime: 275c9b5 | jnthn++ | src/gc/roots.c:
14:41 dalek MoarVM/work-lifetime: Fix typo in comment; MasterDuke17++.
14:41 dalek MoarVM/work-lifetime: review: https://github.com/MoarVM/MoarVM/commit/275c9b5810
14:45 timotimo wow, that commit made core setting parse so much faster?
14:45 timotimo interesting, because this patch makes it do more
14:45 timotimo SCNR :)
14:47 dalek MoarVM/work-lifetime: c7dcce5 | jnthn++ | src/core/frame.c:
14:47 dalek MoarVM/work-lifetime: Only need to NULL ->work on return now.
14:47 dalek MoarVM/work-lifetime:
14:47 dalek MoarVM/work-lifetime: Thanks to GC using this to guard against all scanning of things that
14:47 dalek MoarVM/work-lifetime: are only alive in dynamic scope, there's no reason to also NULL out
14:47 dalek MoarVM/work-lifetime: cur_args_callsite.
14:47 dalek MoarVM/work-lifetime: review: https://github.com/MoarVM/MoarVM/commit/c7dcce5e07
14:47 dalek MoarVM/work-lifetime: 6605510 | jnthn++ | src/core/args.c:
14:47 dalek MoarVM/work-lifetime: No need to zero the nameds used buffer size.
14:47 dalek MoarVM/work-lifetime:
14:47 dalek MoarVM/work-lifetime: We never look at this number to decide anything except how much memory
14:47 dalek MoarVM/work-lifetime: to free, which only happens once.
14:47 timotimo yay, not as much memset!
14:47 timotimo (i think?)
14:48 dalek MoarVM/work-lifetime: a83f7f7 | jnthn++ | src/core/args.c:
14:48 dalek MoarVM/work-lifetime: Remove unrequired NULLing of flattend arg buffers.
14:48 dalek MoarVM/work-lifetime:
14:48 dalek MoarVM/work-lifetime: The ->work flag prevents us ever looking at these in GC after the
14:48 dalek MoarVM/work-lifetime: lifetime of a frame is over, so this isn't needed.
14:48 dalek MoarVM/work-lifetime: review: https://github.com/MoarVM/MoarVM/commit/a83f7f7cbc
14:48 jnthn timotimo: No, this was just assigning a zero in this case
14:49 jnthn Clarity around ->work lifetime allows quite a lot of cleanups.
14:49 arnsholt [Event "Let's Play!"]
14:49 arnsholt [Site "Chess.com"]
14:49 arnsholt [Date "2016.12.27"]
14:49 arnsholt [White "arnsholt"]
14:49 arnsholt [Black "Garoof"]
14:49 arnsholt [Result "1-0"]
14:49 arnsholt [ECO "C60"]
14:49 arnsholt [WhiteElo "1109"]
14:49 arnsholt Whoops!
14:49 notviki c-c-c-combobreaker!
14:53 JimmyZ jnthn: maybe a good read for you http://www.inf.puc-rio.br/~roberto/docs/MCC15-04.pdf ,and others
14:56 brrt that's from the lua dudes innit
14:56 JimmyZ yeah
14:57 timotimo ohai JimmyZ
14:57 JimmyZ timotimo: hello timotimo
14:59 jnthn Some numbers coming soon
15:01 JimmyZ jnthn++ said we need one shot continuations to implement coroutines, this pdf said  full coroutines is easy to implement, which makes me think it may be a good read
15:02 jnthn JimmyZ: Thanks, will take a look over that
15:05 jnthn https://gist.github.com/jnthn/de0c1b39fd17e1ce27fa725f93541cfb
15:06 timotimo *nice*
15:06 timotimo stage mast and stage optimize were also very happy
15:06 JimmyZ nice improvement
15:06 jnthn m: say 1375456 - 1244512
15:06 camelia rakudo-moar dd5759: OUTPUT«130944␤»
15:07 jnthn Also 130MB less RAM to build CORE.setting
15:07 jnthn m: say 1244512 / 1375456
15:07 camelia rakudo-moar dd5759: OUTPUT«0.904800␤»
15:09 jnthn Given this is a notable chance, it'd be nice do give it at least an ASAN run and perhaps a GC stress run too
15:12 nwc10 at a83f7f7cbcc4f81f0672e5462f2637b6db9f5c70 ASAN was happy
15:13 nwc10 but t/spec/S15-nfg/emoji-test.rakudo.moar fails a lot of subtest
15:13 jnthn Yeah, I branched earlier than the merge of that work
15:14 jnthn Just reviewing the changes, I suspect I've introduced a leak for continuations that are taken and never invoked.
15:14 jnthn (Thankfully, easily fixed.)
15:20 dalek joined #moarvm
15:28 dogbert17 what nursery size do you recommend?
15:30 * dogbert17 goes for 128k
15:31 jnthn That'll do it, I'd think
15:31 dogbert17 using this combo: his is Rakudo version 2016.12-230-g3c52aa096 built on MoarVM version 2016.12-83-ga83f7f7c
15:35 dalek MoarVM/work-lifetime: 88adca5 | jnthn++ | src/core/continuation.c:
15:35 dalek MoarVM/work-lifetime: Remove dead variable/assignment.
15:35 dalek MoarVM/work-lifetime: review: https://github.com/MoarVM/MoarVM/commit/88adca5236
15:43 dalek MoarVM/work-lifetime: 74a6125 | jnthn++ | src/core/frame.c:
15:43 dalek MoarVM/work-lifetime: GC-destroying a frame still must check work, etc.
15:43 dalek MoarVM/work-lifetime:
15:43 dalek MoarVM/work-lifetime: Since if the frame was taken as part of a continuation that was then
15:43 dalek MoarVM/work-lifetime: never invoked, its work and tags need cleaning up.
15:43 dalek MoarVM/work-lifetime: review: https://github.com/MoarVM/MoarVM/commit/74a61255ad
15:46 dogbert17 the emoji test can be ignored here I think
15:50 jnthn dogbert17: yes
15:50 * jnthn hurls https://github.com/MoarVM/MoarVM/pull/487
15:54 dogbert17 ok, spectest clean with 128k nursery, FSA_SIZE_DEBUG 1 and MVM_GC_DEBUG 2
15:54 jnthn \o/
15:55 jnthn Very nice.
16:45 dalek MoarVM/even-moar-jit: a4b3f46 | brrt++ | src/jit/compile. (2 files):
16:45 dalek MoarVM/even-moar-jit: Tile for compiling breakpoints
16:45 dalek MoarVM/even-moar-jit:
16:45 dalek MoarVM/even-moar-jit: For debugging purposes only
16:45 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/a4b3f46cbe
16:45 dalek MoarVM/even-moar-jit: 0e66a23 | brrt++ | src/jit/linear_scan.c:
16:45 dalek MoarVM/even-moar-jit: Implement spilling and loading of live ranges
16:45 dalek MoarVM/even-moar-jit:
16:45 dalek MoarVM/even-moar-jit: This fixes the NQP test case moar/50-jit-register-alloc.t, and paves the
16:45 dalek MoarVM/even-moar-jit: way for the correct implementation of function calls etc.
16:45 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/0e66a23dd2
16:46 brrt joined #moarvm
16:47 brrt ^ my eastern-orthodox christmas present
16:47 brrt we can now actually, as in really, as in literally, spill and load registers
16:47 brrt and it works.... correctly
16:48 dalek MoarVM/more-pressure: 539346d | jnthn++ | src/io/ (3 files):
16:48 dalek MoarVM/more-pressure: Take into account actual allocated of I/O buffers.
16:48 dalek MoarVM/more-pressure:
16:48 dalek MoarVM/more-pressure: It seems libuv suggest we allocate 64KB sometimes, even when the
16:48 dalek MoarVM/more-pressure: input we get is tiny. While I'm not sure second-guessing it is wise,
16:48 dalek MoarVM/more-pressure: we should at least be honest internally about what's allocated. By
16:48 dalek MoarVM/more-pressure: storing the actual allocated size, the GC can track it as part of
16:48 dalek MoarVM/more-pressure: the gen2 promotion statistics, and be smarter about triggering full
16:48 dalek MoarVM/more-pressure: collections. This reduces memory overhead.
16:48 dalek MoarVM/more-pressure: review: https://github.com/MoarVM/MoarVM/commit/539346da66
16:49 brrt jnthn++ has to outdo me, as usual :-P
16:49 jnthn brrt++ :)
16:54 brrt i'm actually very, very, very happy that this works
16:55 brrt i've been scheming on how to make the register allocator for the better part of a year
16:55 dalek MoarVM/heap-prof-tweaks: 8bfbb0e | jnthn++ | src/gc/orchestrate.c:
16:55 dalek MoarVM/heap-prof-tweaks: Tweak full collection criteria in heap profiling.
16:55 dalek MoarVM/heap-prof-tweaks:
16:55 dalek MoarVM/heap-prof-tweaks: The recording of heap snapshots will of course use memory, which will
16:55 dalek MoarVM/heap-prof-tweaks: throw off the RSS heuristic and make us a *lot* less likely to ever do
16:55 dalek MoarVM/heap-prof-tweaks: a full collection, distorting the profiles. This is also a bit of a
16:55 dalek MoarVM/heap-prof-tweaks: distortion (to more regular heap profiles being taken), but it's an
16:55 dalek MoarVM/heap-prof-tweaks: improvement. (To do better, we could try tracking RSS before/after
16:55 dalek MoarVM/heap-prof-tweaks: snapshots and excluding that memory from the calculation. Patches
16:55 dalek MoarVM/heap-prof-tweaks: welcome if anyone tries it and finds that a viable appraoch.)
16:55 dalek MoarVM/heap-prof-tweaks: review: https://github.com/MoarVM/MoarVM/commit/8bfbb0ef47
16:55 dalek MoarVM/heap-prof-tweaks: 68b5e35 | jnthn++ | src/profiler/heapsnapshot.c:
16:55 dalek MoarVM/heap-prof-tweaks: Null-check the *correct* thread's ->cur_frame.
16:55 dalek MoarVM/heap-prof-tweaks:
16:56 brrt anyway, decommute &
17:02 nwc10 jnthn: ASAN finds work-lifetime unworthy of comment
17:03 dalek MoarVM/free-spesh-log-slots: 4d87b1c | jnthn++ | src/spesh/candidate.c:
17:03 dalek MoarVM/free-spesh-log-slots: Free up spesh log slots after specialization.
17:03 dalek MoarVM/free-spesh-log-slots:
17:03 dalek MoarVM/free-spesh-log-slots: Spesh logging keeps values alive, preventing the GC from collecting
17:03 dalek MoarVM/free-spesh-log-slots: them. It logs values to sample what types show up, which is fine, but
17:03 dalek MoarVM/free-spesh-log-slots: we should not hang on to them beyond the point the specializer has
17:03 dalek MoarVM/free-spesh-log-slots: used them in its analysis. This reduces memory overhead, perhaps
17:03 dalek MoarVM/free-spesh-log-slots: quite notably in some applications that have large objects (for
17:03 dalek MoarVM/free-spesh-log-slots: example, RT #130494 leaked many objects in this way). On CORE.setting
17:03 dalek MoarVM/free-spesh-log-slots: compilation it saves ~3MB - not much in the scheme of things, but nice
17:03 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=130494
17:03 dalek MoarVM/free-spesh-log-slots: to win.
17:04 jnthn So, post yesterday or so's discussion on review, I've put my work today into PRs for review! https://github.com/MoarVM/MoarVM/pulls :)
17:04 jnthn Feedback encouraged. Though I note nine++ who thought this was a good idea has gone on vacation. :P :P
17:05 jnthn nwc10: Glad ASAN is happy :-)
17:09 jnthn I'm off to relax :)
17:16 geekosaur joined #moarvm
17:31 japhb Holy shazbot, that's a heck of a day's output!
17:31 * japhb looks forward to building a fresh Rakudo with changes like these.  :-)
17:34 [Coke] jnthn++
17:39 japhb .ask brrt Now that you have a working register allocator, what's left before you can merge that branch?
17:39 yoleaux2 japhb: I'll pass your message to brrt.
17:42 diakopter shazbot
17:42 yoleaux2 11:11Z <samcv> diakopter: why did you lol wut notviki’s commit???
17:42 diakopter samcv: oh, I was just lolwut about the long messages
17:43 notviki That's it?
17:43 notviki heh
17:43 notviki And I layed awake at night, thinking my code was off :)
17:45 domidumont joined #moarvm
17:48 domidumont joined #moarvm
17:51 diakopter notviki: I guess I was surprised dalek survived the long message
17:52 notviki heh
17:58 [Coke] .u { .uniname ~~ / 'DOUBLE-STRUCK'/ }
17:58 yoleaux2 U+0020 SPACE [Zs] ( )
17:58 yoleaux2 U+0027 APOSTROPHE [Po] (')
17:58 yoleaux2 U+002D HYPHEN-MINUS [Pd] (-)
17:58 [Coke] u: { .uniname ~~ / 'DOUBLE-STRUCK'/ }
17:59 [Coke] whoops, not the best window for that. sorries
18:16 timotimo i could have sworn we already cleaned up log slots in spesh ...
18:23 diakopter lizmat: another thing that could use p6ified (last I checked) is the dalek
18:24 diakopter and it's definitely not performance-constrained, so it's not like it's a serious risk of becoming unusable (like a prospective port of ucd2c.pl might be)
18:25 notviki Yeah, I can p6ify dalek
18:25 notviki dalek you hear that! People are talking about replacing you!
18:27 TimToady joined #moarvm
18:27 diakopter ohai
18:27 geekosaur .oO { P6-IN-ATE! }
18:32 diakopter notviki: I'm pretty sure looking at dalek's source wouldn't help you any; but do you know where it is?
18:33 notviki Yeah
18:34 notviki @hack:/home/dalek/dalek
18:35 notviki dalek: karma
18:35 notviki dalek: help
18:35 notviki Well, I guess I'm not looking to reinvent all of possible features it has, but just what we need. I'm guessing watching for commits and reporting them is one... anything else?
18:36 [Coke] we have so many bots, I think we've already decided one-feature-per-bot is fine. :)
18:36 [Coke] and yes, I think that's dalek's one thing.
19:02 notviki OK. Then Tuesday we'll have a new dalek
19:10 Zoffix_ joined #moarvm
19:12 notviki Excep I'll call it "Geth" :)
19:12 notviki http://masseffect.wikia.com/wiki/Geth
19:12 timotimo that's a cute idea
19:12 timotimo i know that reference
19:15 geekosaur or go with the similar thing in the original universe... cybermen >.>
19:17 timotimo cyber cyber cyber cyber
19:29 samcv notviki, the diakopter’s mystery is over
19:29 yoleaux2 18:24Z <notviki> samcv: what do you think of https://github.com/rakudo/rakudo/pull/990 can you merge it if it looks fine?
19:29 samcv will look
19:34 samcv i don't really like how we specify all the zero value glyphs :\ but otherwise i am not opposed to it at all
19:34 notviki samcv: yeah me neither :)
19:34 notviki samcv: MasterDuke .ask'ed TimToady for an opinion too... via the bot
19:35 samcv m: "0٠۰߀०০੦૦୦௦౦೦൦෦๐໐༠၀႐០᠐᥆᧐᪀᪐᭐᮰᱀᱐꘠꣐꤀꧐꧰꩐꯰0????????????????????????????????????????????????????????????????????????????????????".comb.».unival.say
19:36 camelia rakudo-moar dd5759: OUTPUT«(0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0)␤»
19:36 samcv m: "a".unival.say
19:36 camelia rakudo-moar dd5759: OUTPUT«NaN␤»
19:36 samcv still i don't like that part. at all specifying them
19:37 notviki m: "༳".unival.say
19:37 camelia rakudo-moar dd5759: OUTPUT«-0.5␤»
19:37 notviki neat
19:38 notviki m: say "༳" ~~ /\d/
19:38 camelia rakudo-moar dd5759: OUTPUT«Nil␤»
19:40 samcv also why don't we just check unival on it… or create some character class internally for one number value?
19:41 samcv idk i don't really like having to specify all those values. i think that's the wrong way to do it
19:57 dogbert17 jnthn: about the free-spesh-log-slots branch, I checked it out and tried both htmlify.p6 and the RT code example. Maybe that's not the right way to do it because I can't see any improvements in memory usage.
20:02 dogbert17 I'm still unable to build the docs with htmlify.p6 :( MoarVM panic: Memory allocation failed; could not allocate 1880616 bytes
20:02 samcv dogbert17, can't build it at all? or can't build unless you set the thread level to 1?
20:03 dogbert17 samcv: isn't 1 the default?
20:03 samcv maybe
20:04 samcv brb gonna logout login my laptop is slowing down
20:05 dogbert17 running htmlify under /usr/bin/time gives: 616.96user 27.90system 8:55.10elapsed 120%CPU (0avgtext+0avgdata 2576668maxresident)k ; 17904inputs+200680outputs (17major+7320835minor)pagefaults 0swaps
20:13 dogbert17 samcv: did you manage to speed up your laptop?
20:13 samcv no. i am going to reboot ;\
20:13 samcv burb
20:21 nebuchadnezzar joined #moarvm
20:30 zakharyas joined #moarvm
20:33 samcv OpenGL compositing (the default) has crashed KWin in the past.
20:33 samcv This was most likely due to a driver bug.
20:33 samcv If you think that you have meanwhile upgraded to a stable driver,
20:33 samcv you can reset this protection but be aware that this might result in an immediate crash!
20:33 samcv Alternatively, you might want to use the XRender backend inst
20:33 samcv ok so that is why it was acting so crappy :P
21:31 timotimo oh, instead of turning compositing off completely, it just fell back to software rendering
21:31 timotimo that's one way to do it ...
21:41 samcv uh it may have done it completely… cause it was pretty horrible
22:33 timotimo if you don't have compositing, it'll usually be fine
22:54 [Coke] dogbert17: yes, building the docs is a dog and has been for ages.
23:00 dogbert17 [Coke]: slow as a dog I can live with, a crash not so much
23:04 [Coke] works fine on my 16G laptop? (sheepish grin)
23:11 dogbert17 I only have 8 gigs on my six year old desktop but I suspect the problems occur because I'm running this stuff in a 32 bit VM

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