|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
01:21
sena_kun joined
01:22
Altai-man_ left
02:24
farcas1982regreg joined
02:26
squashable6 left
02:30
bloatable6 joined,
sourceable6 joined
02:32
bloatable6 left,
statisfiable6 joined,
committable6 joined,
quotable6 joined,
greppable6 joined,
releasable6 joined,
unicodable6 joined,
notable6 joined,
evalable6 joined,
nativecallable6 joined,
tellable6 joined,
benchable6 joined,
reportable6 joined,
greppable6 left
02:33
reportable6 left,
linkable6 joined,
reportable6 joined,
committable6 left,
bloatable6 joined,
squashable6 joined,
coverable6 joined,
greppable6 joined
02:34
committable6 joined,
shareable6 joined
03:13
pamplemousse left
03:19
Altai-man_ joined
03:22
sena_kun left
05:13
sourceable6 left,
committable6 left,
squashable6 left,
bloatable6 left,
reportable6 left,
notable6 left,
coverable6 left,
greppable6 left,
statisfiable6 left,
quotable6 left,
releasable6 left,
unicodable6 left,
evalable6 left,
nativecallable6 left,
tellable6 left,
benchable6 left,
linkable6 left,
shareable6 left
05:20
sena_kun joined
05:22
Altai-man_ left
05:23
shareable6 joined,
coverable6 joined
05:24
committable6 joined,
notable6 joined,
quotable6 joined,
sourceable6 joined,
bisectable6 joined
05:25
reportable6 joined,
releasable6 joined,
bloatable6 joined,
statisfiable6 joined,
benchable6 joined,
nativecallable6 joined
05:26
squashable6 joined,
linkable6 joined
06:31
committable6 left
06:32
shareable6 left,
bisectable6 left,
shareable6 joined
06:34
bisectable6 joined,
committable6 joined
07:19
Altai-man_ joined
07:22
sena_kun left
07:24
MasterDuke joined
07:52
zakharyas joined
|
|||
| nwc10 | good *, #moarvm | 08:45 | |
|
09:20
sena_kun joined
09:22
Altai-man_ left
11:19
Altai-man_ joined
11:22
sena_kun left
|
|||
| MasterDuke | why would gist.github.com/MasterDuke17/1a307...821fe36c89 cause a sigabort and `corrupted size vs. prev_size` when doing `raku -e ''`? | 11:30 | |
| timotimo | what does valgrind say? | 11:31 | |
| MasterDuke | bin is 15 (so one of the ones i've changed) and size is 272 | ||
| jnthn | I don't think you changed it to actually allocate the page memory? | ||
| Oh, you did | |||
| MasterDuke | gist updated | 11:32 | |
| jnthn | oh, but | ||
| your alloc limit is probably bogus? | |||
| timotimo | yeah the limit is far too long | ||
| you're allowing fsa to write far, far outside of its pages | |||
| MasterDuke | oh? | 11:33 | |
| should it be unchanged? | |||
| timotimo | what exactly were you going for? | ||
| i may have to explain what alloc_limit means | |||
| MasterDuke | starting with more pages for some bins (vs starting with bigger pages for some bins) | 11:34 | |
| jnthn | Well, the allocator's design assumes that you are either allocating from the free list or, failing that, the latest added page | ||
| timotimo | the alloc limit is a memory address, not a total amount | ||
| jnthn | and yes, what timotimo said | ||
| timotimo | when the alloc limit address is reached, a new page gets created | ||
| jnthn | I don't really see how this change helps much, though, because you're making the same number of mallocs | ||
| timotimo | i think i had suggested making a single bigger page first rather than making loads of pages | 11:35 | |
| jnthn | Yes, that would probably both help more *and* fit better with the overall allocator design | 11:36 | |
| MasterDuke | yeah, but we won't have to go through alloc_slow_path a lot | ||
| i'm just trying to measure a bunch of different options | |||
| timotimo | it's possible that setting up multiple empty pages will just get the allocator to skip all but the first page | ||
| jnthn | Or the last one, but yeah. | ||
| MasterDuke | jnthn: i have some measurements from implementing what timotimo++ suggested, thought i'd also try this way | 11:37 | |
| but i guess it's not (easily) possible | |||
| jnthn | No, it goes against the grain of the allocator design a bit too much | 11:38 | |
| MasterDuke | afk for a bit. gist.github.com/MasterDuke17/0cde6...89c817ef53 has measurements for compiling CORE.c, gist.github.com/MasterDuke17/bf4bd...d8e892e481 for `raku -e ''` | 11:40 | |
|
11:51
pamplemousse joined
|
|||
| timotimo | another thing we can do is serve all the bins from a single malloc (which then would probably become an mmap) | 11:52 | |
| ah, this "just" runs when the first bin is requested | 11:53 | ||
| nine | Unless we're doing hundreds of mallocs here, I'd be sursprised if we could get a measurable speedup | 11:57 | |
| timotimo | but we are | 11:58 | |
| 36 adding a page of size 17408 for bin = 15 | |||
| 37 adding a page of size 8192 for bin = 6 | |||
| 314 adding a page of size 7168 for bin = 5 | |||
| this is running raku -e '' on master | |||
| 39 adding a page for bin = 1 | 11:59 | ||
| 56 adding a page for bin = 8 | |||
| 404 adding a page for bin = 2 | |||
| 406 adding a page for bin = 5 | |||
| and this is with MD's patch to have VMArray use FSA | |||
| MasterDuke | and it's not just the mallocs, it's trying and failing to go through the fast path and having to go through the slow path | 12:13 | |
| i measured ~600k fewer instructions for `raku -e ''` | |||
| timotimo | 0.01s system for raku -e ''; we should strive for that number to get to 0, though i wouldn't expect us to reach a point where the 0.01s are the majority of time spent | 12:38 | |
| jnthn digs back into the dispatcher design work | 12:49 | ||
| timotimo | and a whole bunch of the sys calls have always been brk | ||
| interesting, we actually shrink a couple of times, too | 12:51 | ||
| a plot of the brk numbers shows that the reductions are pretty much inconsequential :D | 12:55 | ||
| that's with out the MD patch,t hough | 12:57 | ||
|
13:20
sena_kun joined
13:22
Altai-man_ left
13:25
Altai-man_ joined
13:28
sena_kun left
|
|||
| MasterDuke | do people have an opinion on just making the first page (much?) bigger vs making the first page bigger and/or making subsequent pages bigger also? | 13:34 | |
| should it just statically be for the bins that we see commonly allocated in some representative code? | |||
| or maybe dynamically resize the page size as more (or fewer) are requested? | 13:35 | ||
| timotimo | difficult to say without a crystal ball | ||
| MasterDuke | hm, maybe if i first write a program that will tell if another program will ever halt... | 13:36 | |
| timotimo | you can record a "trace" of all allocations for all size classes and then simulate what different algorithms would decide, and then find how much wasted space you would be allocating with any given algo | ||
| MasterDuke | so model on some sort of theoretical knapsack and see how efficiently i can put different sized items in? | 13:38 | |
| these are both pretty easy problems, should only take a day or two | |||
| timotimo | i'd not call it that, honestly | 13:39 | |
| since things of the same size always go in their corresponding bins | |||
| the decisions would only be what sizes you'd put for the bins | |||
| MasterDuke | yep, just joking around | ||
| timotimo | like, one approach would allocate exactly the maximum amount of memory used throughout the whole program at the start and then never have to do anything again | ||
| lizmat | I wonder if memory usage information couldn't be kept somewhere, to give hints to any allocation scheme during runtime | 13:47 | |
| a bit like spesh, I guess, but then over several runs | |||
| just brainstorming, and no I'm not suggesting you should drink bleach | 13:48 | ||
| jnthn | While it doesn't tend to be done cross-process, there's all kinds of presizing, pretenuring, and pretransitioning optimizations that are done in this kind of area (not in MoarVM yet, but they are known/described techniques) :) | 14:02 | |
| MasterDuke | yeah, don't think i'm quite up for that level of work just yet. just some new simple heuristics | 14:03 | |
| lizmat | and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/04/27/2020-...g-cleanup/ | 15:02 | |
| jnthn | Goodnes, I always figured that deferral was slow, but if you compare callsame against self.Parentclass::meth (the latter is already well optimized thanks to a spesh plugin) then it's more than 65x slower! | 15:05 | |
| lizmat++ # weekly | 15:07 | ||
| MasterDuke | wow. but you think the redesign will end up with it closer to the same speed? | 15:08 | |
| jnthn | Dunno yet :) | 15:11 | |
| I'm quite happy with the non-resume-related bits of the design by now | |||
| Still trying to find something I like for the resume case | 15:12 | ||
| MasterDuke | resuming exceptions? | 15:18 | |
| jnthn | No | ||
| Resuming dispatches | |||
| The thing that's going on with callsame et al. | 15:19 | ||
|
15:21
sena_kun joined
|
|||
| MasterDuke | ah | 15:22 | |
|
15:22
Altai-man_ left
15:44
pamplemousse left
|
|||
| jnthn | Finally, I think I found something that'll work... | 16:11 | |
|
16:26
sena_kun left,
dogbert11 left,
vesper11 left,
krunen left,
synthmeat left
16:28
synthmeat joined
16:29
vesper11 joined
16:31
sena_kun joined,
dogbert11 joined
16:32
krunen joined,
DrEeevil joined
|
|||
| timotimo | cool! | 16:39 | |
|
16:45
ChanServ joined,
cherryh.freenode.net sets mode: +o ChanServ
17:05
shareable6 left
17:09
shareable6 joined
17:13
zakharyas left
|
|||
| jnthn | Here's my design notes so far, for the curious: gist.github.com/jnthn/e81634dec57a...b92c722959 | 17:18 | |
|
17:19
Altai-man_ joined
|
|||
| jnthn | Home time & | 17:20 | |
|
17:26
krunen left,
DrEeevil left,
sena_kun left,
dogbert11 left
17:29
krunen joined,
DrEeevil joined,
dogbert11 joined
|
|||
| nine | jnthn: ah, I can see how that will help with the dynamically discovered methods in Inline::Perl5::ClassHOW :) | 17:30 | |
| vrurg | Is it possible for moar to know which module is being deserialized? I'm trying to dig into github.com/MoarVM/MoarVM/issues/1276 | 17:31 | |
| Altai-man_ | vrurg, hi. Are you available for a bit? | 17:32 | |
| vrurg | Altai-man_: I think, yes, if nothing happens | 17:33 | |
| nine | vrurg: yes, look at the MVMCompUnit's file_name | ||
| vrurg | nine: thanks! | 17:34 | |
| Altai-man_ | vrurg, can you please say what do you think about the next release proposal (gist.github.com/Altai-man/433f3314...55533eb3)? If the solution suggested won't work for you, we can discuss it. | 17:35 | |
| vrurg | Altai-man_: gimme a few minutes. | 17:36 | |
| timotimo | i wonder if there needs to be any special consideration for slurpy arguments that can help us deal with extremely long "arguments" / argument lists when trying to slurpy a very long array | 17:37 | |
|
17:39
ChanServ left
17:42
ChanServ joined,
cherryh.freenode.net sets mode: +o ChanServ,
MasterDuke left
|
|||
| [Coke] | what do the trunc_xx opcodes do? | 17:43 | |
| nine | Truncate e.g. int64 -> int16 | 17:46 | |
| The opposite of extend | |||
| jnthn: oh, I just realized that this will finally get us super fast multi dispatch on constants like multi foo(1) { }; multi foo(2) { } by way of nqp::dispguardobj | 17:49 | ||
|
18:10
MasterDuke joined
|
|||
| [Coke] | nine: would it be correct to describe trunc/extend as casting? | 18:20 | |
|
18:57
farcas1982regreg left
19:20
sena_kun joined
19:22
Altai-man_ left
|
|||
| [Coke] | m: use nqp; dd trunc_i8 123456789 | 19:34 | |
| camelia | 5===SORRY!5=== Error while compiling <tmp> Undeclared routine: trunc_i8 used at line 1. Did you mean 'truncate'? |
||
| [Coke] | m: use nqp; dd nqp::trunc_i8 123456789 | ||
| camelia | ===SORRY!=== No registered operation handler for 'trunc_i8' |
||
| Geth | MoarVM: MasterDuke17++ created pull request #1277: Make the first page for some FSA bins bigger |
19:35 | |
| MasterDuke | m: use nqp; dd nqp::trunc_i8(123456789) | ||
| camelia | ===SORRY!=== No registered operation handler for 'trunc_i8' |
||
| MasterDuke | the above PR is to give something concrete to discuss, i'm open to changes | 19:36 | |
| [Coke] | Wonder if the test is misreading the nqp source and those aren't really opcodes. | 19:37 | |
| (or if they are QAST only) | 19:41 | ||
| MasterDuke | github.com/MoarVM/MoarVM/blob/mast...erp.c#L255 | 19:42 | |
| nine | Could be they're opcodes but not actually mapped to NQP ops | 19:43 | |
| They are used by the QAST compiler's coercions: github.com/Raku/nqp/blob/master/sr...T.nqp#L529 | 19:44 | ||
|
19:56
Kaiepi left
19:58
Kaiepi joined
|
|||
| [Coke] | I'll see if I can get them working in a QAST example. | 20:10 | |
| timotimo | you probably need to set a :returns(int16) in a qast node or something like that | 21:08 | |
|
21:12
patrickb joined
21:19
Altai-man_ joined
21:22
sena_kun left
22:04
patrickb left
|
|||
| Geth | MoarVM: MasterDuke17++ created pull request #1278: Fix some compiler warnings |
22:59 | |
|
23:12
Altai-man_ left
|
|||