|
01:10
vendethiel- joined
01:23
geekosaur joined
01:55
ilbot3 joined
02:22
Ven`` joined
02:57
geekosaur joined
03:16
zakharyas joined
05:22
lizmat joined
05:31
moritz joined
06:09
geekosaur joined
06:52
domidumont joined
06:58
domidumont joined
07:40
geekosaur joined
09:18
geekosaur joined
10:36
robertle joined
11:30
leont joined
11:39
geekosaur joined
12:19
dalek joined,
synopsebot6 joined
12:21
SourceBaby joined
12:26
leont_ joined
12:27
leont joined
12:55
Util joined
12:59
leont joined
13:22
geekosaur joined
14:04
geekosaur joined
14:28
geekosaur joined
15:37
geekosaur joined
|
|||
| Geth | MoarVM: MasterDuke17++ created pull request #704: Add missing word in comment |
16:34 | |
| MoarVM: 187c1cae59 | MasterDuke17++ (committed using GitHub Web editor) | src/6model/reprs/MVMString.h Add missing word in comment |
18:09 | ||
| MoarVM: b46ef34705 | (Jimmy Zhuo)++ (committed using GitHub Web editor) | src/6model/reprs/MVMString.h Merge pull request #704 from MasterDuke17/patch-1 Add missing word in comment |
|||
|
18:12
lizmat_ joined
18:25
travis-ci joined
|
|||
| travis-ci | MoarVM build passed. Jimmy Zhuo 'Merge pull request #704 from MasterDuke17/patch-1 | 18:25 | |
| travis-ci.org/MoarVM/MoarVM/builds/279004659 github.com/MoarVM/MoarVM/compare/7...6ef347054c | |||
|
18:25
travis-ci left
20:16
AlexDaniel joined
21:11
Ven`` joined
|
|||
| 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:18 | |
| reason for asking is this data of a small program run with and without spesh on 2017.07 and the current release | 21:20 | ||
| MVM_SPESH_DISABLE=1 WITH SPESH | |||
| 2017.07 20,325,247,133 Ir 7,861,290,267 Ir | |||
| current 18,419,032,475 Ir 16,440,182,184 Ir | |||
| japhb | dogbert11: What is the "small program"? | 21:25 | |
| yoleaux | 21 Sep 2017 07:30Z <stmuk> japhb: I'll fix that shortly .. thanks! | ||
| 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:29 | |
| dogbert11 | FWIW, here's the script, perhaps I did something wrong when callgrinding. gist.github.com/dogbert17/8d4fd827...c365b2a2f0 | 21:35 | |
| japhb | Ah, a class sieve. That takes me back. :-) | 21:39 | |
| 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:42 | |
| dogbert11 | japhb: it's Project Euler Problem 10 | 21:43 | |
| 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:44 | ||
| 2017.07 runs that code ~15% faster than the current release | 21:45 | ||
|
21:52
geekosaur joined
|
|||
| MasterDuke | jnthn, timotimo: any idea why joining by just copying strands isn't faster and/or uses less mem? | 22:17 | |
| 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:19 | |
| For short strings, it's quite easy to beat (or break even) on that | 22:20 | ||
| 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 | ||
| At 8-bit width, 16 | |||
| 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 | ||
| uh, buffer | |||
| uh, the saving on the copying overhead is lost, I meant | |||
| MasterDuke | hm, i do seem to get some time/mem savings, but it takes using larger strings and higher repeat counts | 22:41 | |
| '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 | ||
| 36.21user 0.04system 0:36.45elapsed 99%CPU (0avgtext+0avgdata 139544maxresident)k # before my change | |||
| jnthn | Yeah, I'd expect there to be a trade-off point where it becomes worthwhile | ||
| MasterDuke | 14.03user 0.02system 0:14.00elapsed 100%CPU (0avgtext+0avgdata 93200maxresident)k # after my change | ||
| jnthn | Wow, that's a big saving | 22:43 | |
| Maybe it wants some heurstic thing though, so that if the total input graphemes are < 16, say, then just flatten it out | |||
| Or some such | |||
| MasterDuke | heh, still needs a spectest though... | 22:44 | |
| jnthn | ;) | ||
| MasterDuke | i got rid of the `&& 16 <= total_graphs / total_strands` here github.com/MoarVM/MoarVM/blob/mast...ps.c#L1698 | 22:45 | |
| just so it would always happen for my testing | 22:46 | ||
| could always add it (or something like it) back if need be | |||
| nqp builds and tests ok... | 22:47 | ||
| jnthn | Yeah, that looks like it's looking to do what I described :) | ||
| timotimo | jnthn: could something have busted speshed lookups for $?CLASS? | ||
|
22:49
geekosaur joined
|
|||
| jnthn | timotimo: Umm....possibly, though I can't think of anything that woulda done that | 22:50 | |
| I mean, that opt had to be re-implemented during the spesh re-wrok | |||
| But I totally remember doing it | |||
| 'cus it ended up needing an extra flag being set in args spesh to indicate that the invocant was specialized on | |||
| And the distance between those two bothered me a tad, but it was the cleanest option I could immediately think of | 22:51 | ||
| timotimo | outputting the name in the "get lexical by name" function gave me a firehose of "$?CLASS" | 22:54 | |
| 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 | |||
| jnthn | Ah, hmm | 22:56 | |
| That'd be worth looking into | |||
| 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 | |
| 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 | |||
| MasterDuke | rakudo builds and passes make m-test m-spectest | 23:02 | |
| here's what i have now gist.github.com/MasterDuke17/9cdf7...9e1e15ecf5 | |||
| should i put that heuristic back in and PR it? | |||
| but afk for a bit now | 23:03 | ||
| jnthn | MasterDuke: Yeah, heuristic is likely worth it | 23:07 | |
| Rest time for me :) o/ | 23:16 | ||
| timotimo | o/ | 23:19 | |