|
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) | |||