18:55 ilogger2 joined
jnthn samcv: Sounds good :-) 19:28
samcv: I did some amount of refactoring and got rid of stuff we weren't using over time, but there's certainly mroe worth doing
19:59 MasterDuke joined
samcv jnthn: i think i may have made MVM_string_gi_get_grapheme 8x faster. it was 8% of this hash test i made. but now it's only 1% 20:05
20:06 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Convert HASH_DEL_IN_BKT and HASH_EXPAND_BUCKETS from macros to inlines' 20:06
travis-ci.org/samcv/MoarVM/builds/383863824 github.com/samcv/MoarVM/compare/ad...4d2c3f8563
20:06 travis-ci left
timotimo i just looked at how the holes in SCRefs are spread out and it doesn't really lend itself to a sparse array scheme, as the holes tend to be mostly small 20:32
135974 total holes out of 177935
145 holes bigger than 128
m: say 135974 / 177935
camelia 0.7641779
timotimo some of those holes are actually rather big, but for example a two-level approach wouldn't make that much sense here 20:34
there's a very big stretch of 1 entry, one hole, 2 entries, 1 hole, repeat
i wonder what that might be 20:35
jnthn samcv: Wow, nice :)
Geth MoarVM/master: 4 commits pushed by (Samantha McVey)++ 20:37
20:51 Kaiepi joined
samcv at least i think i did make it faster... 21:50
well need to do some stuff to try and confirm
actually being annoying to test for it because i've put in fast paths many places like collapse_strands and indexing branches 21:58
timotimo oof :) 22:13
samcv i have made some unicode stuff faster tho 22:19
timotimo can never have enough of that 22:20
jnthn expects to have a decent bit of "making MoarVM faster" time over the summer :)
Geth MoarVM: a84b607bd0 | (Samantha McVey)++ | 2 files
Add branch predictor hints macros

MVM_LIKELY and MVM_UNLIKELY are meant to be used in if conditionals MVM_EXPECT is can be used on things like switches that don't just expect true or false type values.
22:21
jnthn ooh
samcv :)
got like 10% boost on find_cclass
which much of it is querying the unicode properties 22:22
jnthn Wow, that's pretty good going
Bet there's quite a few places we can use that
timotimo i wonder if having find_cclass contain "the" loop 22:23
jnthn Is expection expectation or exception? :)
timotimo rather than calling is_cclass over and over? is that what we are doing?
samcv it can make a pretty big difference 22:24
timotimo: also yes that would be better 22:25
i was thinking about doing that later
timotimo is that a big difference though?
samcv oh i mean the branch predictor hints
can make a big difference
timotimo in some cases we might be able to say "oh this only contains ascii, we can make far fewer checks"
samcv though you should make sure you only use them with benchmarking. because otherwise it can have unexpected results
timotimo oh, i somehow didn't even see that commit up there
samcv heh 22:26
timotimo i bet we can put UNLIKELY in a whole bunch of places with error handling
like reprid checks and such
samcv yeah
i was playing around in MVM_string_gi_get_grapheme. and like if i put MVM_UNLIKELY in gi->repetitions, it makes repetitions a fair amount slower, but has minimal impact on other code (though that may occur more often) i could try things with many short strands. but yeah 22:27
decided not to add it there because i didn't see any improvement or barely any. but it is neat 22:28
Geth MoarVM: f94b029721 | (Samantha McVey)++ | 4 files
Use new branch predictor hints to unicode_db and prop query

Gives about 10% speedup generally. We query general category the most so this can have a fair impact.
Some hot codepaths were also streamlined a bit as well.
samcv was able to use the branch predictor to make it faster to get things in plane 0 of the unicode database
and expect General_Category more likely than the other conditions 22:29
i'm curious about what will happen if i take MVM_string_check_arg and make it unlikely that it'll throw 22:31
if we see any significant changes since it's used a lot? dunno
tbrowder_ another thought about c++: after "converting" to using the c++ compiler you can continue to use C pretty much as usual, but it would allow gradually moving to C++isms, and maybe help others start helping out...just saying. take a look at brlcad.org (over 30 years C but gradually moving to C++) 23:35
japhb tbrowder_: Recently someone posted a video by a Google engineer talking about building a fast hash table in C++, and the last few minutes consisted roughly of "How many geniuses does it take to get a C++ compiler to produce good code?" culminating in admitting that one of these people did nothing but run the compiler to produce assembly code, think really hard about why it was producing the wrong code, and 23:52
tweak the source until it compiled the way they expected. This is *not* the kind of thing you want when writing a language VM. There's a reason C has not disappeared from the world of large complex performance-dependent projects like OS kernels and VMs.
Not saying by any means that it's impossible to write performant code in C++, many people do, just that it's not a clear win to convert a relatively understood C codebase into a C++ one. 23:53
jnthn Furthermore, if we're going to port (parts of) MoarVM to anything, it should probably be to NQP, and head in a self-host direction, like e.g. the Graal folks have. 23:56
(That's a decidedly long-term aim)