Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-11-11

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

All times shown according to UTC.

Time Nick Message
01:06 MasterDuke samcv: now that you're around, any thoughts about ^^^
01:07 samcv let me look
01:09 samcv MasterDuke: how does it improve compared to before?
01:11 MasterDuke well, 100_000 took 40s and 3.7g before, 0.5s and 91m after
01:13 MasterDuke but the case it's optimizing for is probably not the most common, so i'm more looking to make sure it doesn't hurt any of the more common cases too much
01:17 samcv so you're saying it optimizes for a case the previous one didn't?
01:17 samcv but also optimizes for the case it had previously
01:17 samcv y/n
01:19 MasterDuke it adds an additional case it optimizes for
01:20 MasterDuke before, if the LHS of a concat was a strand, and the final strand was equal to the complete string of the RHS, it would just increment the LHS's repetition
01:20 MasterDuke (of the final strand)
01:23 MasterDuke what i added was if the the LHS of a concat was a strand, and the RHS is single strand, and the "base" of the LHS's final strand is equal to the "base" of the RHS's strand, just add the number of the RHS's repetitions to the LHS's final strand
01:25 samcv i'll take a look at it in a bit, thanks!
01:25 samcv i mean a closer look that is hah
01:31 MasterDuke so before, `my $a1 = "a" x 2; my $a2 = "a" x 2; my $as = $a1 ~ $a2` wouldn't just increment the repetition counter, since the final strand of $a1 ("a") ne all of $a2 ("aa")
01:32 MasterDuke and now it'll just create $as the equivalent of "a" x 4
01:32 MasterDuke np, no hurry
01:49 MasterDuke joined #moarvm
02:04 MasterDuke_ joined #moarvm
02:56 ilbot3 joined #moarvm
02:56 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:48 MasterDuke_ samcv: btw, a performance thing you might have an interest in. `my $a = "a" x 1_000_000; $a ~~ /./ for ^1000` spends  93% of its time in iterate_gi_into_string
05:19 samcv MasterDuke_: it's probably flattening the string
05:20 samcv since that's called in  2 places one of which is to flatten a string
05:20 samcv the other one might be flattening too but not sure
07:03 Geth ¦ MoarVM: 2d2c4ce734 | (Stefan Seifert)++ | src/spesh/manipulate.c
07:03 Geth ¦ MoarVM: Fix spesh dropping MVM_SPESH_ANN_DEOPT_ONE_INS annotations
07:03 Geth ¦ MoarVM:
07:03 Geth ¦ MoarVM: MVM_spesh_manipulate_delete_ins did not actually append to the annotations
07:03 Geth ¦ MoarVM: list. Fix that and handle the case when no annotations were on the target
07:03 Geth ¦ MoarVM: instruction while we're at it.
07:03 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2d2c4ce734
07:03 nine dogbert2: I just pushed the fix. Thanks for reminding me!
08:35 domidumont joined #moarvm
08:43 domidumont joined #moarvm
09:14 nine Some new thoughts: while the goto carrying the DEOPT_INLINE annotation is at the end of an inlined basic block, IIRC it's actually the invocation point of a nested inline. So my previous "something seems to assume that an inlinee is entered through a goto" still holds.
09:16 nine Also I think it's highly likely that the issue only appears with nested inlines, i.e. relatively rarely. Otherwise it'd be a huge surprise that some test files actually pass, since compilation itself will already run lots of code.
09:16 nine Not to forget loading the Test module.
10:36 geospeck joined #moarvm
11:50 geospeck joined #moarvm
12:45 jnthn nine: You saw the link I sent you to deopt.c some days ago?
14:00 AlexDaniel joined #moarvm
14:04 robertle joined #moarvm
14:54 dogbert17 joined #moarvm
14:55 dogbert17 nine++ (MoarVM fix)
14:55 dogbert17 .seen timotimo
14:55 yoleaux I saw timotimo 13:58Z in #perl6-dev: <timotimo> ah, moarvm not bumped
14:56 dogbert17 was wondering about about this warning I get, is it harmless ?
14:56 dogbert17 [src/profiler/heapsnapshot.c:823]: (error) Shifting 32-bit value by 32 bits is undefined behaviour
14:56 dogbert17 [src/profiler/heapsnapshot.c:823]: (error) Signed integer overflow for expression '1l<<32'.
15:00 timotimo oh is that not how you spell a 64bit integer literal, eh?
15:00 timotimo does it have to be 1L? or maybe 1ll?
15:01 dogbert17 perhaps there's a difference between 32 and 64 bit platforms
15:01 timotimo seems like LL
15:01 * dogbert17 is on 32 bit
15:13 MasterDuke_ timotimo: have you looked at https://github.com/MoarVM/MoarVM/pull/750 ? Any ideas for how to test i didn't slow down more usual concatenation use cases?
15:18 timotimo i'd still like it if there was a function that can eq two strings without creating substrings first
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: 88296b3539 | (Timo Paulssen)++ | 6 files
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: subtract size of profiling ops from bytecode size
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize:
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: so that turning profiling on can't push some functions
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: over the inline size limit, which causes differences
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: between profiled and non-profiled runs.
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize:
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: Not inlining some candidate only during profiling can
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: have ripple effects if an inlined piece of code causes
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: a bigger frame to bail in the JIT.
15:27 timotimo (just a rebase)
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: review: https://github.com/MoarVM/MoarVM/commit/88296b3539
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: 89731492ea | (Timo Paulssen)++ | src/spesh/codegen.c
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: ignore PHI and initialize ignored_bytes field
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: review: https://github.com/MoarVM/MoarVM/commit/89731492ea
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: c18017d971 | (Timo Paulssen)++ | src/spesh/codegen.c
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: don't ignore extops for size calculation
15:27 Geth ¦ MoarVM/inline_ignore_instrumentation_bytesize: review: https://github.com/MoarVM/MoarVM/commit/c18017d971
15:28 MasterDuke_ timotimo: yeah, some sort of MVM_string_equal_at_at would be more efficient
15:30 MasterDuke_ what do you think the signature would be? `MVMint64 MVM_string_equal_at_at(MVMThreadContext *tc, MVMString *a, MVMint64 length_a, MVMString *b, MVMint64 length_b);`
15:30 Geth ¦ MoarVM: d3655ff7b5 | (Timo Paulssen)++ | src/profiler/heapsnapshot.c
15:30 Geth ¦ MoarVM: fix integer literal form for 1ll << 32
15:30 Geth ¦ MoarVM:
15:30 Geth ¦ MoarVM: dogbert17++
15:30 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d3655ff7b5
15:31 MasterDuke_ or would it need an offset_a and offset_b also?
15:31 timotimo it needs two offsets but only one length
15:32 timotimo since if the length differs that'd be an automatic fail
15:32 timotimo of course you can allow passing it so the check can go in the function instead of outside it on every usage i guess?
15:34 MasterDuke_ yeah, you have to check length somewhere, otherwise you'd get the same behavior i ran into yesterday, if you're checking strands, you have to take the start and end into account
15:36 MasterDuke_ otherwise you could falsely say two strands "bases" are equal, if they were differently sized parts of the same larger blob_string for examle
15:36 MasterDuke_ *example
15:37 geospeck joined #moarvm
15:38 MasterDuke_ hm, i could also just explicitly add a length check before the MVM_string_equal i added, that should help out
15:43 MasterDuke_ that's annoying to calculate though, since i have to go into the MVMStringStrand...
15:43 MasterDuke_ afk for a while, i'll take a look when i get back
15:55 domidumont joined #moarvm
16:22 geospeck joined #moarvm
16:44 geospeck joined #moarvm
16:48 zakharyas joined #moarvm
17:15 releasable6 joined #moarvm
17:57 MasterDuke_ timotimo: added a new commit to the PR
18:54 geospeck joined #moarvm
19:13 MasterDuke lizmat: did you see my comment and recent commit on https://github.com/MoarVM/MoarVM/pull/750 ? have anything else you'd like to see?
19:16 * lizmat commented :-)
19:17 MasterDuke cool, thanks
20:40 samcv MasterDuke: reviewed
20:41 samcv brb
21:04 colomon joined #moarvm
21:21 colomon joined #moarvm
21:36 colomon joined #moarvm
22:11 colomon joined #moarvm
22:16 MasterDuke updated
22:41 colomon joined #moarvm
22:46 colomon joined #moarvm
22:56 bisectable6 joined #moarvm
23:01 zakharyas joined #moarvm
23:23 MasterDuke strings are immutable, so i guess nqp::indexingoptimized has to return a new string?
23:28 colomon joined #moarvm
23:28 samcv MasterDuke: yep
23:30 MasterDuke too bad
23:35 samcv well it doesn't have to return a new string, but the thing that calls it has to assume a new string may be returned
23:35 samcv since it returns the same string if the string is already flat

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