github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:00 raku-bridge left 00:01 raku-bridge1 is now known as raku-bridge 00:20 konvertex left 00:58 pamplemousse joined 03:08 farcas1982regreg joined 06:09 pamplemousse left
nine MasterDuke: you need to check if hash is actually an MVMHash (in theory it could be something else). 06:50
MasterDuke: doing the same for gethllsym is a good idea. It's always called with a static HLL name.
07:38 zakharyas joined
MasterDuke oh right, that hash check is easy. gethllsym seems like it should be easy also, any preference on creating a new sp_gethllsym or doubling up on the meaning of sp_getcurhllsym (and if so, should it get renamed)? 07:42
nine I think one spesh op suffices as they will look exactly the same. I'd go with sp_gethllsym 07:46
Or.... sp_gethashentryvalue as that's exactly what it does with no regards for how we actually got that hash entry 07:47
But naming is hard
MasterDuke i'm liking the idea of renaming 07:50
btw, think that template looks right? 07:51
nine template? 07:53
MasterDuke `(template: sp_getcurhllsym (^getf (copy $1) MVMHashEntry value))` 07:54
nine Looks so simple....probably because it just is :) 07:55
Is the copy necessary? 07:56
MasterDuke i based it on github.com/MoarVM/MoarVM/blob/mast...s.expr#L16 07:57
07:58 Altai-man_ joined 08:16 camelia joined 08:17 sena_kun joined
nine It's documented as =COPY= | =(copy reg)= | =reg= | Copy this value (opaque to tiling) 08:18
08:18 Altai-man_ left
nine I don't see why we'd have to copy something. For the const ops we want to copy the literal to some register. 08:18
MasterDuke i can try just using $1 directly. my test has a bail immediately before the sp_getcurhllsym, so the template wasn't being created, but maybe i can come up with something that'll exercise it 08:20
nine Btw. what (^getf (copy $1) MVMHashEntry value) does is really "take the constant value and add another constant value and access the resulting memory location". We could actually do the adding in optimize_hllbool already: ins->operands[1].lit_i64 = &entry->value; 08:22
.oO(Is there now end to how far we can optimize this thing?)
s/now/no/
MasterDuke so taking out one more pointer follow? 08:25
nine No, just the addition. Which is probably about 1 CPU cycle... 08:27
MasterDuke there's no way to delete an operand is there? i'd have to create a new MVMSpeshIns with fewer operands, populate it, and then replace the old ins, right? 08:30
oh, looks like i can just put in new operands? 08:38
heh, something's wrong. `MoarVM oops: Malformed DU chain: reading sp_gethashentryvalue of 7(4) not in graph` 08:45
ok, everything builds and passes tests 08:55
and i see "specialized from" both gethllsym and getcurhllsym 09:08
09:30 konvertex joined 09:52 farcas1982regreg left 10:16 Altai-man_ joined
nine Sounds quite excellent :) I wonder what other cases this speeds up 10:18
10:19 sena_kun left
nine MasterDuke: I guess it's time for a PR? 10:20
MasterDuke anybody have a preference for a new PR vs force pushing these changes over github.com/MoarVM/MoarVM/pull/1281 ? 10:41
and are there any other hash lookups that could be turned into an sp_gethashentryvalue? 10:48
nine A force push will keep the PR's conversation intact, i.e. keep the reasoning 11:52
Btw. feel free to use whatever you find useful in my comment for a good explanatory commit message :) 11:53
12:17 sena_kun joined 12:18 Altai-man_ left
MasterDuke determined the template is getting called. now to see if just $1 works 12:43
timotimo .o( a coverage measurement tool for the jit ) 12:48
MasterDuke be nice if there was an easy way. i just stuck a call to MVM_dump_backtrace in 12:53
timotimo "easy" :) 12:54
probably easy to add a dumb way that's #ifdef'd in
12:57 pamplemousse joined
timotimo brrt, it could be interesting to see if the lines not covered in moarvm.github.io/coverage/libmoar/...xpr.c.html are not reached by the tests for some good reason, or just because 13:00
er 13:01
for a good reason, or because they are dead, or unused, or maybe not correct
13:02 farcas1982regreg joined
timotimo actually, i think we only profile nqp and its test suite for moarvm's coverage 13:05
MasterDuke yeah. i ran a coverage of a spectest a while ago, but didn't get around to processing the raw files (and then deleted them because they were out of date)
but it's something i'd like to have automated 13:06
timotimo i wonder if the nqp-profile script wants to be updated now that our launchers are actually binaries rather than scripts 13:08
the nqp-profile utility executes the moar binary directly with all the --libpath flags and such
if the stuff in samcv/moarvm-cover can be easily applied to rakudo builds, that could get an extra task to do spec test coverage 13:09
i wonder how much extra coverage you get from rakudo's "make test" and how much the next step up, "make spectest" will add 13:12
MasterDuke github.com/MoarVM/MoarVM/pull/1281 was just updated with a force push of the new implementation 13:18
timotimo: any thoughts on github.com/MoarVM/MoarVM/pull/1277 ? 13:32
timotimo the bigger we make the pages, the higher the "waste" will be at most / on average 13:44
so the 1024 one may be a bit much 13:45
page 15 being about 130 kilobytes is kind of rough :D 13:46
MasterDuke yeah, but i wanted something extreme enough to show that it did in fact make a difference
timotimo ah
MasterDuke i guess i'm trying to figure out is there some simple thing we can do e.g., increase the page size (maybe by a lot), or if something more complicated is needed, e.g., dynamically increase the page size if a lot are being allocated 13:48
and i'd be happy for suggestions at either end of the spectrum
timotimo mhm 13:49
well, here's a wild suggestion
virtual memory, right?
if we pre-register 64 megabytes for every size bin, but end up never writing to it 13:50
then the kernel does all the decisions for us
lizmat
.oO( a kernel of wisdom )
 13:53
timotimo if we get "transparent huge pages", though, it could be that each of these pre-registrations could be served by multiples of like x megabytes rather than like 4k chunks or whatever 13:54
we want to be really silly? encode the size of the allocation in the address by mmapping gigantic pieces of the address space 13:55
nine That idea is not as silly as it may sound. Processors already use a couple bits of the 64 for book keeping purposes 13:56
timotimo mhm 14:00
mmap with MAP_FIXED_NOREPLACE and goooooooooooo! 14:01
also, put something in nursery addresses 14:02
using size in fsa addresses will not actually win us anything 14:05
but differentiating nurseries by to vs from (probably with three colors rather than just two) could be intereiting 14:06
or "already marked or not" 14:07
14:16 Altai-man_ joined 14:19 sena_kun left
MasterDuke are the rest of the hashes of things hanging off of tc->instance good candidates for turning access of them into the new sp_gethashentryvalue? 14:52
lizmat yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/05/11/2020-...e-release/ 15:36
nine MasterDuke: if they are access with constant keys and we know that those hashes will never get replaced once in place 15:48
16:02 farcas1982regreg left 16:04 farcas1982regreg joined
MasterDuke they kind of seem like they're unlikely be replaced. not sure about the constant keys. also not sure which ones are accessed as via ops 16:15
16:16 patrickb joined 16:17 sena_kun joined 16:18 Altai-man_ left 17:04 patrickz joined 17:05 patrickb left 17:10 farcas1982regreg left 17:21 farcas1982regreg joined 17:28 zakharyas left 18:16 Altai-man_ joined 18:18 sena_kun left 18:37 robertle left 18:38 robertle joined 18:52 patrickz left 20:06 konvertex left 20:11 konvertex joined 20:17 sena_kun joined 20:18 Altai-man_ left 20:40 farcas1982regreg left 22:16 Altai-man_ joined 22:19 sena_kun left 22:33 Kaiepi left 22:34 Kaiepi joined 22:35 Kaiepi left, Kaiepi joined 22:48 Altai-man_ left 23:11 MasterDuke left 23:40 farcas1982regreg 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!