MasterDuke samcv: now that you're around, any thoughts about ^^^ 01:06
samcv let me look 01:07
MasterDuke: how does it improve compared to before? 01:09
MasterDuke well, 100_000 took 40s and 3.7g before, 0.5s and 91m after 01:11
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:13
samcv so you're saying it optimizes for a case the previous one didn't? 01:17
but also optimizes for the case it had previously
y/n
MasterDuke it adds an additional case it optimizes for 01:19
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
(of the final strand)
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:23
samcv i'll take a look at it in a bit, thanks! 01:25
i mean a closer look that is hah
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:31
and now it'll just create $as the equivalent of "a" x 4 01:32
np, no hurry
01:49 MasterDuke joined 02:04 MasterDuke_ joined 02:56 ilbot3 joined
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 03:48
samcv MasterDuke_: it's probably flattening the string 05:19
since that's called in 2 places one of which is to flatten a string 05:20
the other one might be flattening too but not sure
Geth MoarVM: 2d2c4ce734 | (Stefan Seifert)++ | src/spesh/manipulate.c
Fix spesh dropping MVM_SPESH_ANN_DEOPT_ONE_INS annotations

MVM_spesh_manipulate_delete_ins did not actually append to the annotations list. Fix that and handle the case when no annotations were on the target instruction while we're at it.		 07:03
nine dogbert2: I just pushed the fix. Thanks for reminding me!
08:35 domidumont joined 08:43 domidumont joined
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:14
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
Not to forget loading the Test module.
10:36 geospeck joined 11:50 geospeck joined
jnthn nine: You saw the link I sent you to deopt.c some days ago? 12:45
14:00 AlexDaniel joined 14:04 robertle joined 14:54 dogbert17 joined
dogbert17 nine++ (MoarVM fix) 14:55
.seen timotimo
yoleaux I saw timotimo 13:58Z in #perl6-dev: <timotimo> ah, moarvm not bumped
dogbert17 was wondering about about this warning I get, is it harmless ? 14:56
[src/profiler/heapsnapshot.c:823]: (error) Shifting 32-bit value by 32 bits is undefined behaviour
[src/profiler/heapsnapshot.c:823]: (error) Signed integer overflow for expression '1l<<32'.
timotimo oh is that not how you spell a 64bit integer literal, eh? 15:00
does it have to be 1L? or maybe 1ll?
dogbert17 perhaps there's a difference between 32 and 64 bit platforms 15:01
timotimo seems like LL
dogbert17 is on 32 bit
MasterDuke_ timotimo: have you looked at github.com/MoarVM/MoarVM/pull/750 ? Any ideas for how to test i didn't slow down more usual concatenation use cases? 15:13
timotimo i'd still like it if there was a function that can eq two strings without creating substrings first 15:18
Geth MoarVM/inline_ignore_instrumentation_bytesize: 88296b3539 | (Timo Paulssen)++ | 6 files
subtract size of profiling ops from bytecode size

so that turning profiling on can't push some functions over the inline size limit, which causes differences between profiled and non-profiled runs.
Not inlining some candidate only during profiling can have ripple effects if an inlined piece of code causes a bigger frame to bail in the JIT.		 15:27
timotimo (just a rebase)
MoarVM/inline_ignore_instrumentation_bytesize: 89731492ea | (Timo Paulssen)++ | src/spesh/codegen.c
ignore PHI and initialize ignored_bytes field
MoarVM/inline_ignore_instrumentation_bytesize: c18017d971 | (Timo Paulssen)++ | src/spesh/codegen.c
don't ignore extops for size calculation
MasterDuke_ timotimo: yeah, some sort of MVM_string_equal_at_at would be more efficient 15:28
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
fix integer literal form for 1ll << 32

  dogbert17++
MasterDuke_ or would it need an offset_a and offset_b also? 15:31
timotimo it needs two offsets but only one length
since if the length differs that'd be an automatic fail 15:32
of course you can allow passing it so the check can go in the function instead of outside it on every usage i guess?
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:34
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
*example
15:37 geospeck joined
MasterDuke_ hm, i could also just explicitly add a length check before the MVM_string_equal i added, that should help out 15:38
that's annoying to calculate though, since i have to go into the MVMStringStrand... 15:43
afk for a while, i'll take a look when i get back
15:55 domidumont joined 16:22 geospeck joined 16:44 geospeck joined 16:48 zakharyas joined 17:15 releasable6 joined
MasterDuke_ timotimo: added a new commit to the PR 17:57
18:54 geospeck joined
MasterDuke lizmat: did you see my comment and recent commit on github.com/MoarVM/MoarVM/pull/750 ? have anything else you'd like to see? 19:13
lizmat commented :-) 19:16
MasterDuke cool, thanks 19:17
samcv MasterDuke: reviewed 20:40
brb 20:41
21:04 colomon joined 21:21 colomon joined 21:36 colomon joined 22:11 colomon joined
MasterDuke updated 22:16
22:41 colomon joined 22:46 colomon joined 22:56 bisectable6 joined 23:01 zakharyas joined
MasterDuke strings are immutable, so i guess nqp::indexingoptimized has to return a new string? 23:23
23:28 colomon joined
samcv MasterDuke: yep 23:28
MasterDuke too bad 23:30
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
since it returns the same string if the string is already flat

Powered by Cro and the Raku® Programming Language.

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

Thank you!