Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-11-15

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

All times shown according to UTC.

Time Nick Message
00:02 TimToady joined #moarvm
00:16 samcv well that's not good. it's a synthetic (non utf-c8 synthetic though it does have a utf8-c8 synthetic later in the string)
00:16 samcv but the issue is a normal synthetic whose first cp is: L and the second one is 0xFFFFFFF9
00:18 samcv oops no. the second one is synthetic -7
00:18 samcv got the fprintf wrong. ok so it's a synthetic with a synthetic inside it. that or corruption
00:19 samcv the results seem identical each time though
00:23 timotimo getting fprintf wrong is a thing i definitely do routinely
00:24 timotimo why isn't there a macro or something for "just output this piece of data correctly"
00:24 samcv synths inside synths!
00:24 samcv deeper deeper!
00:25 samcv ok i see what's happening. it created a synth which is L + utfc8-synth
00:25 samcv argh
00:33 Geth ¦ MoarVM: dae72d2fb0 | (Samantha McVey)++ | src/strings/ops.c
00:33 Geth ¦ MoarVM: If problem NFG_CHECK grapheme is a synth, give detailed info
00:33 Geth ¦ MoarVM:
00:33 Geth ¦ MoarVM: Shows whether or not it is a utf8-c8 synthetic or not, as well as shows
00:33 Geth ¦ MoarVM: what the first two codepoints inside it as well as the total number of
00:33 Geth ¦ MoarVM: codepoints in the synthetic.
00:33 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/dae72d2fb0
00:56 samcv ok i think i found the problem :0
00:56 samcv i just have to change a 0 to a 1 and things i think will work. running spectest now
00:56 samcv does it count as off by one  if a 0 should be a 1
00:57 MasterDuke_ definitely. is this something it's easy to add a roast test for?
00:57 samcv if i forget to run make spectest without nice -n 19, my system starts lagging really badly when NFG_CHECK is on
00:57 samcv i'm sure the memory pressure must be pretty bad runniig 9 threads
00:58 samcv hmm well we ca utf8-c8 synthetic and something else i guess but the problem becomes they're going to probably match fine
00:58 samcv maybe using .NFG on it hm
00:58 samcv though .NFG i think will flatten utf8-c8
00:59 samcv i can't run t/02-rakudo/08-repeat.t with NFG_CHECK i run out of memory
01:02 samcv anyway gonna run make spectest and make sure no more NFG_CHECK problems
01:10 MasterDuke_ good deal
01:18 Geth ¦ MoarVM: a0dc2747c3 | (Samantha McVey)++ | src/strings/normalize.c
01:18 Geth ¦ MoarVM: Fix bug causing utf8-c8 synthetics to combine with other codepoints
01:18 Geth ¦ MoarVM:
01:18 Geth ¦ MoarVM: Fixes a bug in MVM_unicode_normalize_should_break() where it returned 0
01:18 Geth ¦ MoarVM: incorrectly when it should have been returning 1 to indicate NO break.
01:18 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a0dc2747c3
01:18 samcv fixed. and all is good with the world once again :)
01:22 samcv m: use nqp; (nqp::indexingoptimized('L' ~ Buf.new(255).decode(<utf8-c8>))).chars.say
01:22 camelia rakudo-moar fff43fd70: OUTPUT: «1␤»
01:22 samcv MasterDuke: this triggers it
01:22 samcv but we can't use indexingoptimized in roast
01:22 samcv and just concatting by itself doesn't trigger it
01:23 MasterDuke so run a regex on the string, that calls indexingoptimized
01:24 samcv good point
01:24 samcv well. no. it doesn't return the string
01:24 samcv though it won't match now
01:24 timotimo maybe put it into t/rakudo or nqp's test suite instead?
01:24 samcv say ('L' ~ Buf.new(255).decode(<utf8-c8>)) ~~ /L/
01:24 evalable6 samcv, rakudo-moar fff43fd70: OUTPUT: «Nil»
01:24 samcv m: say ('L' ~ Buf.new(255).decode(<utf8-c8>)) ~~ /L/
01:24 camelia rakudo-moar fff43fd70: OUTPUT: «Nil␤»
01:25 samcv m: say ('LL' ~ Buf.new(255).decode(<utf8-c8>)) ~~ /L/
01:25 camelia rakudo-moar fff43fd70: OUTPUT: «「L」␤»
01:25 samcv m: say ('L' ~ Buf.new(255).decode(<utf8-c8>)) ~~ /L/
01:25 camelia rakudo-moar fff43fd70: OUTPUT: «Nil␤»
01:25 samcv yeah so that shows it
01:29 samcv ok i found where to put it
01:30 MasterDuke cool, more tests are good
01:31 Geth ¦ MoarVM/in-situ-strings: e8f01d9c0f | (Timo Paulssen)++ | 6 files
01:31 Geth ¦ MoarVM/in-situ-strings: store short strings inside string's body
01:31 Geth ¦ MoarVM/in-situ-strings:
01:31 Geth ¦ MoarVM/in-situ-strings: uses the 8 bytes that the pointer to a buffer usually
01:31 Geth ¦ MoarVM/in-situ-strings: takes and puts up to 8 8-bit characters into it.
01:31 Geth ¦ MoarVM/in-situ-strings:
01:31 Geth ¦ MoarVM/in-situ-strings: Currently causes trouble with regex matches.
01:31 Geth ¦ MoarVM/in-situ-strings: review: https://github.com/MoarVM/MoarVM/commit/e8f01d9c0f
01:31 Geth ¦ MoarVM/in-situ-strings: 8caa9736ab | (Timo Paulssen)++ | src/strings/ops.c
01:31 Geth ¦ MoarVM/in-situ-strings: teach string_char_at_in_string about in_situ
01:31 timotimo (a rebase and one extra commit)
01:31 Geth ¦ MoarVM/in-situ-strings: review: https://github.com/MoarVM/MoarVM/commit/8caa9736ab
01:32 MasterDuke timotimo: did you see my comment the first time you pushed?
01:32 timotimo it looks like string_char_at_in_string was what caused regexes to be unhappy in nqp's test suite
01:56 timotimo cool, it survives stresstest
01:59 MasterDuke timotimo: it looks like the ` char *result_c;` at line 48 in latin1.c can be removed
02:01 timotimo oh, that's left over from debugging
02:01 Geth ¦ MoarVM/in-situ-strings: 1c4aba109d | (Timo Paulssen)++ | src/strings/latin1.c
02:01 Geth ¦ MoarVM/in-situ-strings: remove left-over debugging, MasterDuke++
02:01 Geth ¦ MoarVM/in-situ-strings: review: https://github.com/MoarVM/MoarVM/commit/1c4aba109d
02:06 MasterDuke very cool. what sort of savings are you seeing?
02:06 timotimo depends strongly on the workload
02:07 samcv timotimo: will we be able to store 2 32 bit graphemes in the poniter too?
02:08 timotimo 50 megs saved in combing the core setting into an array
02:08 timotimo yes, that needs more code though :)
02:08 samcv combing it?
02:08 timotimo yeah, my @foo = "CORE.setting".IO.comb
02:08 samcv also the reason you are doing this is to reduce memory usage or allocations?
02:08 timotimo so it keeps all the strings around
02:08 samcv ah
02:09 timotimo saves an allocation for very short strings, one less pointer deref you have to do if you operate on it
02:09 timotimo lots of reasons
02:09 samcv yeah
02:09 samcv for sure
02:09 samcv with comb i can *totally* see the benefit
02:09 timotimo need to adjust lots of fastpaths that don't know about the new storage type
02:15 timotimo these 50 megs of savings were about 25 bytes per character in the file combed
02:16 timotimo that was only a little piece of total memory usage though
02:18 Geth ¦ MoarVM/in-situ-strings: 1afd45e895 | (Timo Paulssen)++ | src/strings/ops.c
02:18 Geth ¦ MoarVM/in-situ-strings: create in situ for nqp::chr if it fits into 8bit.
02:18 Geth ¦ MoarVM/in-situ-strings: review: https://github.com/MoarVM/MoarVM/commit/1afd45e895
02:26 MasterDuke timotimo: just curious, but in the changes you made to MVM_string_latin1_decode and iterate_gi_into_string, would it be beneficial to use the fsa for *old (since you know it's going to be small)
02:30 timotimo that would require MVMString to learn about fsa in general
02:30 timotimo as old is just the pointer stolen from the blob_8
02:32 MasterDuke oh, duh, of course
02:33 MasterDuke hm, maybe need to work on my fsa_for_strings_storage branch some more
02:43 timotimo hm, i added in situ 32 but my gc_mark code still points out a big amount of 32bit strings with 2 or fewer graphemes
02:54 timotimo anyway, bedtime.
02:54 MasterDuke later...
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
05:41 samcv timotimo: sounds fun
06:47 ilbot3 joined #moarvm
06:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
06:51 domidumont joined #moarvm
07:22 nine timotimo: doesn't this cause a lot of branching in string handling code?
07:46 brrt joined #moarvm
07:59 lizmat joined #moarvm
08:24 domidumont joined #moarvm
08:57 zakharyas joined #moarvm
09:12 zakharyas joined #moarvm
10:14 AlexDaniel joined #moarvm
10:25 robertle joined #moarvm
11:11 brrt good * #moarvm
11:11 yoleaux 14 Nov 2017 17:15Z <jnthn> brrt: the branch inline-lastexpayload fails t/02-rakudo/repl.t but works without the expr JIT. The problem is in the code at Proc.pm:73 in Rakudo; the try thunk is inlined into the enclosing block (not new, I think), but now the .receive method was inlined into the thunk with my branch. So it seems to have needed the nested inline to trigger it.
11:20 brrt thanks jnthn
11:20 brrt i will try and debug it
13:31 zakharyas joined #moarvm
14:07 lizmat joined #moarvm
14:42 zakharyas joined #moarvm
15:15 timotimo nine: we already branch a bunch for the other storage strategies
15:24 robertle joined #moarvm
16:05 brrt joined #moarvm
17:32 releasable6 joined #moarvm
17:41 domidumont joined #moarvm
17:52 samcv good *
18:01 Zoffix \o
18:16 zakharyas joined #moarvm
18:25 zakharyas joined #moarvm
18:32 zakharyas joined #moarvm
18:32 nwc10 joined #moarvm
18:56 dogbert17 joined #moarvm
18:59 AlexDaniel joined #moarvm
18:59 dogbert17 o/
19:01 dogbert17 .seen samcv
19:01 yoleaux I saw samcv 18:07Z in #perl6-dev: <samcv> i mean select them on my amazon smile profile that is
19:02 dogbert17 .tell samcv have a SEGV which might be of interest, https://gist.github.com/dogbert17/52ce8a69ec85eca79b2e7eb6114a379a
19:02 yoleaux dogbert17: I'll pass your message to samcv.
19:03 samcv gcc should remove conditionals that can never be triggered right
19:03 yoleaux 19:02Z <dogbert17> samcv: have a SEGV which might be of interest, https://gist.github.com/dogbert17/52ce8a69ec85eca79b2e7eb6114a379a
19:03 samcv dogbert17: are you using the latest MVM?
19:06 dogbert17 yes
19:07 dogbert17 MoarVM version 2017.10-80-ga0dc2747
19:08 samcv well that runs out of memory for me at least with strict on
19:08 samcv not sure about without strict
19:12 dogbert17 valgrind says the following before the SEGV
19:12 dogbert17 ==17656== Invalid write of size 4
19:12 dogbert17 ==17656==    at 0x41C6A97: re_nfg (ops.c:287)
19:12 dogbert17 ==17656==    by 0x41C5F22: NFG_checker (ops.c:80)
19:12 dogbert17 ==17656==    by 0x41C615E: NFG_check_concat (ops.c:120)
19:12 dogbert17 ==17656==  Address 0xa5f5140 is 0 bytes after a block of size 0 alloc'd
19:13 dogbert17 the last line feels a bit strange
19:17 samcv i will check that in a bit. thanks
19:21 dogbert17 yay :)
19:31 samcv dogbert17: we can't throw inside MVMROOT right?
19:32 dogbert17 I don't know :(
19:41 timotimo probably problematic to do that
19:42 timotimo but since it's equivalent to a return, and the end of the mvmroot block is just a pop or pop_n, you can probably get away with putting a pop in place before the throw
19:42 timotimo i'd probably convert the whole mvmroot macro into push and pop instructions instead, though
19:46 samcv i mean can't it throw inside another function you call
19:46 samcv you have an MVMROOT and then inside it you call a function. which happens to throw
19:46 samcv then what
19:46 samcv i'm sure that happens
20:23 Geth ¦ MoarVM: samcv++ created pull request #753: collapse_strands with memcpy if all strands are same type 4x faster
20:23 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/753
21:06 samcv sadly with this PR compliing the core setting is slower
21:06 samcv not sure why yet
21:12 samcv going to try working to reduce the branching
21:48 samcv ok i believe i fixed the issue
22:13 timotimo hmm. if that happens, that's probably kinda bad
22:14 timotimo because then there'd be pointers pointing at random locations in stackframes
22:16 timotimo or maybe we have a baseline of temp roots that we just restore to when an exception jumps things around
22:17 timotimo ah yes
22:18 timotimo throw_adhoc_free_va does MVM_gc_root_temp_pop_all near the end
22:23 samcv ah ok timotimo
22:23 samcv so i don't have to worry about it then?
22:45 timotimo looks like no
22:59 jnthn Yeah, I designed it so you can throw and not worry about what's on the temp root stack
22:59 jnthn The problem isn't so much local throwing, but you'd have to never *call* something in MVMROOT that might throw, and that'd be...very awkward. :)
23:37 lizmat joined #moarvm

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