00:17 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Remove old strings.markdown documentation file' 00:17
travis-ci.org/MoarVM/MoarVM/builds/268167499 github.com/MoarVM/MoarVM/compare/c...f6152deeba
00:17 travis-ci left
MasterDuke timotimo, brrt: i logged the .i64 value of param_op_i when running rukudo's test and spectest, it was always positive. could we use a negative value as a flag? 01:40
01:52 ilbot3 joined
Geth MoarVM: 0b364cb850 | (Samantha McVey)++ | src/strings/ops.c
Speed up `index` 9x when Haystack is strand, needle is 1 long

Use a grapheme iterator when looking for a single grapheme inside of a strand. Large speedup when the Haystack is a strand.		 02:35
02:58 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Speed up `index` 9x when Haystack is strand, needle is 1 long 02:58
travis-ci.org/MoarVM/MoarVM/builds/268212927 github.com/MoarVM/MoarVM/compare/9...364cb850b6
02:58 travis-ci left 03:01 dogbert11 joined
timotimo samcv: you can try removing indexingoptimized from github.com/perl6/nqp/blob/master/s...r.nqp#L418 and see how that impacts performance 06:45
ni many cases we'd probably suffer from having ropes because every access goes through at least two indirection, 1) the strands array, 2) the target string
since we don't have full "trees" built out of our ropes we'll not have terrible performance degradation in cases like for example $foo ~= "a" over and over again 06:46
hm. since we already require $orig to be able to turn into a native string, we could perhaps actually do some things on $orig and some on $target? that could be a bad idea :) 06:47
06:53 domidumont joined 07:06 domidumont joined 07:10 leont joined 08:23 AlexDaniel joined 08:24 zakharyas joined 08:27 robertle joined 08:54 zakharyas joined 09:31 dogbert11 joined 09:47 lizmat joined 11:03 AlexDaniel joined 11:13 vendethiel joined 11:31 lizmat joined 11:59 MasterDuke joined 12:09 brrt joined
brrt MasterDuke, and also nine and others, i'd advise the following API: 12:23
yoleaux 24 Aug 2017 19:02Z <samcv> brrt: can I get the slides from YAPC-EU?
brrt MVM_args_get_positional(tc, frame, position, type, &address) -> boolean 12:24
MasterDuke brrt: type is required|optional? 12:26
brrt also 'I'm not seeing how using a negative value as a flag could in anyway be safe
required
hehe, no 12:27
type is obj/str/int/num
it's used for casting
the caller is responsible for branching or throwing
what's more, currently we're using a nested switch table. that's not necessary. we can encode the 4x4 option matrix as 4 bits and switch on that 12:29
MasterDuke brrt: so e.g., MVM_args_get_required_pos_int would call MVM_args_get_positional(tc, frame, "int", arg_idx)?
brrt the quote before the 'I should not have been there :-)
yeah, actually, MVM_reg_int
rather than "int" 12:30
but yeah
that's what i mean
and there wouldn't have to be a required_get_pos_int intermediate
MasterDuke just curious, but why wouldn't a negative value be safe as a flag?
brrt equally curious, where did you want to store it? 12:31
but in general, because i64 values are signed, so a negative value is just allowed
MasterDuke i didn't mean to store it, to decide which branch in the op to take 12:32
12:32 nwc10__ joined 12:33 leedo_ joined, harrow joined
MasterDuke github.com/MoarVM/MoarVM/pull/660/...05f0fL1018 12:33
12:33 Voldenet joined
MasterDuke and i'm surprised my patch passed spectest, because i don't see how the jitting i added does that branch 12:34
brrt yeah, that suggests missing tests... 12:36
it would fail if you got an optional argument that's 0 12:37
MasterDuke my patch currently? or using a negative value as a flag for the branch? 12:38
brrt your patch. and using a negative value would fail wherever the optional integer argument would be negative 12:39
or for objects, depending on the place of your heap
anway, afk&
MasterDuke doh! for some reason i was thinking that value was an index into an array of the args! 12:41
heh, of course branching on negative would be bad 12:42
12:46 zakharyas joined 13:19 committable6 joined 13:31 geekosaur joined 13:49 lizmat joined 13:55 benchable6 joined 14:17 geekosaur joined
Geth MoarVM: ef2b21ac5b | (Elizabeth Mattijsen)++ | 2 files
Fix spello
 14:28
14:45 lizmat joined 14:56 geekosaur joined 14:58 AlexDaniel joined 15:06 travis-ci joined
travis-ci MoarVM build failed. Elizabeth Mattijsen 'Fix spello' 15:06
travis-ci.org/MoarVM/MoarVM/builds/268388674 github.com/MoarVM/MoarVM/compare/0...2b21ac5b58
15:06 travis-ci left
Geth MoarVM/jit_nativecall: a8698530ed | (Stefan Seifert)++ | src/core/nativecall.c
Extend JITing native calls to all integerial return types
 15:18
15:44 dogbert11 joined
nine Creating complex JIT graphs manually gets tedious really fast. Maybe I need some help...something like a JIT graph builder... 15:44
15:55 robertle joined
timotimo switch on over to even-moar-jit, see how you like that 15:55
17:19 domidumont joined 17:59 leont joined 18:09 AlexDani` joined
samcv good (* 20:12
timotimo, so what are the most time consuming calls we usually make. that the regex engine does. so there's index. and i have a branch that makes that 2.5x faster indexing a haystack made up of strands 20:13
which could be a game changer regarding having to flatten the strings
robertle you are probably aware of that, but there is something weird with regex performance: I have a piece of code at work that reads logfiles, looks for certain lines with a regex, and then does some more 20:15
this is really slow, but when I provide a fastpath by doing $line.contains('something') && $line ~~ /'something' <some_more_complex_stuff/, it gets twice as fast 20:16
but isn't that the first thing the retgex engine does? to use index() or so to find an appropriate anchor from where to start? 20:17
one would expect that "optimisation" to make little difference...
and this isn't a micro-optimisation thing, it goes from 10 minutes to 4. and according to --profile pretty much all the time is spent in regex code 20:18
...not really a moar thing of course 20:19
samcv robertle, i think maybe you're seeing what i have been? 20:20
i mean the index operation is very fast. as i continue speeding it up more and more
but some other stuff takes a while. *especially* if the needle is a variable and not written in directly 20:21
robertle is contains() just sugar over index(), or is it a separate thing
MasterDuke timotimo has a comment here about things that could be done www.reddit.com/r/perl6/comments/5n...p_regular/
samcv m: use nqp; nqp::index('h' x 100000000 ~ 'i', 'i', 0); say now - INIT now
camelia 1.4560151?
samcv m: ('h' x 100000000 ~ 'i') ~~ /i/; say now - INIT now
camelia 0.365415?
samcv m: use nqp; nqp::index('h' x 100000000 ~ 'i', 'i', 0); say now - INIT now 20:22
camelia 1.7562766?
samcv hmm that must be cause it's flattening it, not sure
m: my $b = 'i'; ('h' x 100000000 ~ 'i') ~~ /$b/; say now - INIT now
anyway my point is that if the regex takes from a variable it's a ridiculous amount of time slower
camelia (timeout) 20:23
samcv not sure if you've been seeing that
robertle timotimo's comments are certainly spot on to what I am seeing, I guess there are also a lot of regexes that use "^" or so... 20:24
MasterDuke samcv: one problem might be that the INTERPOLATE routine is not jitted in the /$foo/ case. i've been trying to figure out how to jit the ops that cause it to bail. that's what github.com/MoarVM/MoarVM/pull/660 is an attempt at, but it's incorrect
samcv i mean it probably can't account for 150x speed reduction can it
MasterDuke and i've been chatting with timotimo and brrt about it
samcv ah nice 20:25
MasterDuke probably not that much, no
samcv and also i need help figuring out how to get ignorecase/ignoremark working when there's INTERPOLATE
MasterDuke but it's 15% in a profile
samcv cause curretly they don't fully work except for literal
JITing or INTERPOLATE 20:26
MasterDuke INTERPOLATE is 15% and not jitted 20:27
for this: `my @l = "s.sql".IO.lines; my $p = "Perl6"; my @m = @l.grep(/ $p /); say @m.elems`, where s.sql has 10k lines 20:28
20:47 lizmat joined
samcv this is odd. i'm getting 20% faster for strands than for non-strand haystack 21:12
that's very interesting 21:13
timotimo samcv: i'm still convinced matching regexes against strandy strings like a thousand h characters is too far away from real world use cases 21:14
samcv since the code i have, if it's not a strand, it doesn't cache the values
github.com/samcv/MoarVM/blob/c449c...#L234-L236
timotimo, well i'm testing against actual books rn
timotimo how do you make strands from books? :)
samcv and getting 1.2s for a collapsed string and getting 1.0 second after i concat a space at the end
just concat a single character at the end
see what i linked 21:15
if it's not a strand my gi_cached_get_grapheme just refers to MVM_string_get_grapheme_at_nocheck which does a raw access
to the blob. but somehow it seems to be faster to cache the last grapheme?
maybe cause cpu cache or how it generates code? idk
1 second vs 1.2 when it was flattened. and it should be slower if it's a strand. so let me try having all strings do the same thing, and cache the last grapheme 21:16
this is not what i expected
(plus it's faster even though i have some debugging code in there to keep track of cache hits/misses)
timotimo, yep it's now the same speed for a strand and for a non-strand which is interesting. turns out caching the last grapheme really does give a 20% boost 21:18
timotimo huh, ok 21:26
samcv yeah i didn't think that would happen... 21:27
but the timings don't lie. i tested on a book broken into 20 strands, and the timing is close as for after i do indexingoptimized 21:28
raw after slurp 0.83409575
after concat: 0.86951226
after indexing opt: 0.8611777
21:35 AlexDani` joined 21:55 lizmat joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!