Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-09-23

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

All times shown according to UTC.

Time Nick Message
01:10 vendethiel- joined #moarvm
01:23 geekosaur joined #moarvm
01:55 ilbot3 joined #moarvm
01:55 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:22 Ven`` joined #moarvm
02:57 geekosaur joined #moarvm
03:16 zakharyas joined #moarvm
05:22 lizmat joined #moarvm
05:31 moritz joined #moarvm
06:09 geekosaur joined #moarvm
06:52 domidumont joined #moarvm
06:58 domidumont joined #moarvm
07:40 geekosaur joined #moarvm
09:18 geekosaur joined #moarvm
10:36 robertle joined #moarvm
11:30 leont joined #moarvm
11:39 geekosaur joined #moarvm
12:19 dalek joined #moarvm
12:19 synopsebot6 joined #moarvm
12:21 SourceBaby joined #moarvm
12:26 leont_ joined #moarvm
12:27 leont joined #moarvm
12:55 Util joined #moarvm
12:59 leont joined #moarvm
13:22 geekosaur joined #moarvm
14:04 geekosaur joined #moarvm
14:28 geekosaur joined #moarvm
15:37 geekosaur joined #moarvm
16:34 Geth ¦ MoarVM: MasterDuke17++ created pull request #704: Add missing word in comment
16:34 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/704
18:09 Geth ¦ MoarVM: 187c1cae59 | MasterDuke17++ (committed using GitHub Web editor) | src/6model/reprs/MVMString.h
18:09 Geth ¦ MoarVM: Add missing word in comment
18:09 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/187c1cae59
18:09 Geth ¦ MoarVM: b46ef34705 | (Jimmy Zhuo)++ (committed using GitHub Web editor) | src/6model/reprs/MVMString.h
18:09 Geth ¦ MoarVM: Merge pull request #704 from MasterDuke17/patch-1
18:09 Geth ¦ MoarVM:
18:09 Geth ¦ MoarVM: Add missing word in comment
18:09 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b46ef34705
18:12 lizmat_ joined #moarvm
18:25 travis-ci joined #moarvm
18:25 travis-ci MoarVM build passed. Jimmy Zhuo 'Merge pull request #704 from MasterDuke17/patch-1
18:25 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/279004659 https://github.com/MoarVM/MoarVM/compare/7d00853f1dd4...b46ef347054c
18:25 travis-ci left #moarvm
20:16 AlexDaniel joined #moarvm
21:11 Ven`` joined #moarvm
21:18 dogbert11 wrt to the spesh rewrite a few weeks ago, are there optimization not yet implemented in the new version which were present before the rewrite?
21:20 dogbert11 reason for asking is this data of a small program run with and without spesh on 2017.07 and the current release
21:20 dogbert11 MVM_SPESH_DISABLE=1      WITH SPESH
21:20 dogbert11 2017.07       20,325,247,133 Ir     7,861,290,267 Ir
21:20 dogbert11 current       18,419,032,475 Ir    16,440,182,184 Ir
21:25 japhb dogbert11: What is the "small program"?
21:25 yoleaux 21 Sep 2017 07:30Z <stmuk> japhb: I'll fix that shortly .. thanks!
21:29 jnthn dogbert11: No, it should be capable of all, and more, though given the difference in the disabled I can't help but wonder if something got changed that made things more efficient unoptimized, but threw off optimization
21:35 dogbert11 FWIW, here's the script, perhaps I did something wrong when callgrinding. https://gist.github.com/dogbert17/8d4fd82748f808eb95491fc365b2a2f0
21:39 japhb Ah, a class sieve.  That takes me back.  :-)
21:42 MasterDuke huh. i just implemented only copying strands in MVM_string_join if the separator and pieces are all strands, but `my $s = ","; my $a = "a"; my $b = "bb" x 2; my $c = "ccc" x 3; for ^1_000_000 { $ = join($s, $a, $b, $c, "dddd") }` has the same runtime and maxresident as before
21:43 dogbert11 japhb: it's Project Euler Problem 10
21:44 dogbert11 it should check for prime numbers up to 2_000_000 but with that number callgrind grinded to a halt :) so I changed to 200_000
21:45 dogbert11 2017.07 runs that code ~15% faster than the current release
21:52 geekosaur joined #moarvm
22:17 MasterDuke jnthn, timotimo: any idea why joining by just copying strands isn't faster and/or uses less mem?
22:19 jnthn A strand points to an MVMString. Each strand list entry is sizeof(MVMStringsStrand) or whatever the type is. Plus some memory allocator overhead. The strands then point to an MVMString which has a header and points to a data buffer.
22:20 jnthn For short strings, it's quite easy to beat (or break even) on that
22:21 jnthn A strand probably takes at least 16 bytes of memory. Even at 32-bit width you can fit 4 graphemes in that space
22:21 jnthn At 8-bit width, 16
22:23 jnthn So for short strings, then the memory saving stands might give might well be eaten by the strands themselves, and the copying overhead is lost because building the stand list involves at least as much work as just copying the strings into a flat butter
22:23 jnthn uh, buffer
22:23 jnthn uh, the saving on the copying overhead is lost, I meant
22:41 MasterDuke hm, i do seem to get some time/mem savings, but it takes using larger strings and higher repeat counts
22:42 MasterDuke 'my $s = ","; my $a = "a"; my $b = "bbbbbbbb" x 200; my $c = "cccccccccccccc" x 300; for ^1_000_000 { $ = join($s, $a, $b, $c, "dddd") }'
22:42 MasterDuke 36.21user 0.04system 0:36.45elapsed 99%CPU (0avgtext+0avgdata 139544maxresident)k # before my change
22:42 jnthn Yeah, I'd expect there to be a trade-off point where it becomes worthwhile
22:42 MasterDuke 14.03user 0.02system 0:14.00elapsed 100%CPU (0avgtext+0avgdata 93200maxresident)k # after my change
22:43 jnthn Wow, that's a big saving
22:43 jnthn Maybe it wants some heurstic thing though, so that if the total input graphemes are < 16, say, then just flatten it out
22:43 jnthn Or some such
22:44 MasterDuke heh, still needs a spectest though...
22:44 jnthn ;)
22:45 MasterDuke i got rid of the `&& 16 <= total_graphs / total_strands` here https://github.com/MoarVM/MoarVM/blob/master/src/strings/ops.c#L1698
22:46 MasterDuke just so it would always happen for my testing
22:46 MasterDuke could always add it (or something like it) back if need be
22:47 MasterDuke nqp builds and tests ok...
22:47 jnthn Yeah, that looks like it's looking to do what I described :)
22:47 timotimo jnthn: could something have busted speshed lookups for $?CLASS?
22:49 geekosaur joined #moarvm
22:50 jnthn timotimo: Umm....possibly, though I can't think of anything that woulda done that
22:50 jnthn I mean, that opt had to be re-implemented during the spesh re-wrok
22:50 jnthn But I totally remember doing it
22:50 jnthn 'cus it ended up needing an extra flag being set in args spesh to indicate that the invocant was specialized on
22:51 jnthn And the distance between those two bothered me a tad, but it was the cleanest option I could immediately think of
22:54 timotimo outputting the name in the "get lexical by name" function gave me a firehose of "$?CLASS"
22:54 timotimo and since it goes via HASH_GET, which uses MVM_string_equals, iirc, that could explain why MVM_string_equals got such a massive bump of cpu usage in a recent version upgrade
22:56 jnthn Ah, hmm
22:56 jnthn That'd be worth looking into
23:00 timotimo i also put a little opt into spesh that can turn an eq_s or ne_s with an empty string into an istrue_s or isfalse_s
23:00 timotimo not sure if it's worth a lot. it only made a tiny dent into MVM_string_equals calls, but maybe after $?CALL is inspected it'll be worth more
23:02 MasterDuke rakudo builds and passes make m-test m-spectest
23:02 MasterDuke here's what i have now https://gist.github.com/MasterDuke17/9cdf715bc10093721345db9e1e15ecf5
23:02 MasterDuke should i put that heuristic back in and PR it?
23:03 MasterDuke but afk for a bit now
23:07 jnthn MasterDuke: Yeah, heuristic is likely worth it
23:16 jnthn Rest time for me :) o/
23:19 timotimo o/

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