|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:00
lucasb left
00:11
sena_kun joined
00:12
Altai-man_ left
02:09
Altai-man_ joined
02:12
sena_kun left
02:25
sena_kun joined
02:27
squashable6 left,
Altai-man_ left
02:29
squashable6 joined
03:09
Altai-man_ joined
03:12
sena_kun left
05:10
sena_kun joined
05:11
Altai-man_ left
07:09
Altai-man_ joined
07:12
sena_kun left
09:10
sena_kun joined
09:12
Altai-man_ left
09:17
zakharyas joined
09:53
zakharyas left
09:54
zakharyas joined
|
|||
| timotimo | imgur.com/TSTDsGd - entropy of CORE.c.setting; brighter means more entropy, the bytes are hilbert-curve-ordered | 10:16 | |
| it's sooo pretty | 10:19 | ||
| it randomly occurs to me that maybe there's value in having really really short constant strings live literally in the bytecode rather than as a reference to the string heap; means less re-use of string objects, though | 10:22 | ||
| hey brrt, how hard would it be to allow hot (or cold at first) replacement of jitted functions? if we could replace individual jitted functions with hand-optimized versions we could figure out how much more performance we could gain from implementing specific optimizations, and what's still slow after optimizing the crap out of some jitted code | 10:23 | ||
| okay what are those multiple kilobytes of 00 80 00 80 00 80 00 80 near the start of CORE.c.setting.moarvm | 10:29 | ||
|
10:36
robertle joined
|
|||
| nine | timotimo: is gist.github.com/niner/63a718023aba...c1ccd84e32 helpful for finding that out? | 10:38 | |
| timotimo | probably! | 10:39 | |
| nine | I guess I really ought to put this into a proper module | 10:40 | |
| The ByteReader as well | 10:41 | ||
| timotimo | ok ill introduce a new string heap storage type: number | 10:42 | |
| theres like 16k numbers in the string heap | 10:43 | ||
| from 0 up by ones probably | 10:44 | ||
| nine | Makes one wonder where we actually need stringified numbers in the setting? | ||
| timotimo | ids | ||
| cuuids maybe | |||
| cannot type well atm | 10:45 | ||
| cat stole one of my hands | |||
|
10:58
zakharyas1 joined
10:59
zakharyas left
|
|||
| timotimo | hum. this seems to be frames data | 11:02 | |
| frames data includes handlers, maybe that's where a lot of space goes | 11:07 | ||
| C8: <unit-outer> (cuid: 16383), bytecode at 85F480 | 11:08 | ||
| 106: <unit> (cuid: 16384), bytecode at 85F4B8 | |||
| 5F4E: (cuid: 1), bytecode at 8764E0 | 11:09 | ||
| m: say 0x5f4e - 0x106 | |||
| camelia | 24136 | ||
| timotimo | that's one enormous frame | ||
|
11:09
Altai-man_ joined
|
|||
| timotimo | it does have boatloads of lexical vars | 11:10 | |
|
11:12
sena_kun left
|
|||
| lizmat | perhaps some unicode related data ? | 11:17 | |
| or the magic increment table ? | |||
| timotimo | i think that'd be a lot smaller than anything we see here | 11:22 | |
| lizmat | ah, interesting... | 11:24 | |
| timotimo | btw that entropy picture was generated with binvis.io, a very pretty tool | 11:32 | |
| so all these 0080 (really 0008) values are definitely present in the "local variable types" data segment; it just says "all those registers are obj typed" | 11:41 | ||
| that one frame has 5264 locals, each of which take 2 bytes | 11:42 | ||
| that's already 10 kilobytes | |||
| there's also 753 lexicals, which first get a list of names (string references, which are 4 bytes each) and then entries of 6 bytes each | 11:43 | ||
| so 10 bytes times 753 is 7530 bytes, another ~7 kilobytes | 11:44 | ||
| and then there's the 94248 bytes of bytecode | 11:45 | ||
| they live in another region, though | 11:49 | ||
| as i understand it, the bytecode of the unit frame is a long row of getcode + capturelex or something like that | 11:50 | ||
| OK, first a long row of getcode + capturelex, then a long row of getcode + takeclosure | 11:52 | ||
| after that it gets less monotonous; getcodes to store frames in locals, some calls to "resolve" methods, stuff being called, stuff having sink called on it, ... | 11:53 | ||
| may be interesting to have a look what all of these frames are that are just called in void context | 11:54 | ||
| lizmat | indeed... :-) | 11:56 | |
| timotimo | i see some empty class bodies | 11:57 | |
| the code on the other hand is not empty :) | 11:58 | ||
| it generates a getcode + takeclosure for another frame (that's even emptier), then checkarity, paramnamesused, then saves the outer $_ to a register and returns after that | 11:59 | ||
| the inner frame that's even emptier does just checkarity, paramnamesused, wval (for what i assume to be Nil) and return_o on the value | |||
| there's also a frame full of "getcode, push_o" for a whole bunch of frames, perhaps all of them | 12:02 | ||
| it's called by the "<dependencies+deserialize>" frame | 12:03 | ||
| nine | Sounds like the static optimizer could do some good work here | 12:06 | |
| timotimo | i wonder if we can figure out "this class body is completely empty" much earlier | 12:07 | |
| nine: what do you think of the idea to allow users (only meant for devs, really) to supply moar with hand-optimized assembly for frames? | 12:08 | ||
| nine | I kinda like it | 12:09 | |
| timotimo | just make it hard to use in production :D | 12:18 | |
| lizmat | hmmm... I smell some XS here | 12:19 | |
| timotimo | no, not for users! | 12:20 | |
| bad liz! :) | |||
| lizmat | www.reddit.com/r/rakulang/comments...m_sockets/ # isn't that what Kaipei is working on ? | 12:21 | |
| users will find out :-) | |||
| timotimo | we have to make the tool clumsy enough so that it's not even worth attempting | ||
| but still usable for a core dev | 12:22 | ||
| torture the implementors for the sake of the users :) :) :) | |||
| lizmat | and you think XS is not clumsy ? | ||
| :-) | |||
| timotimo | could be clumsier | ||
| lizmat | I'm just saying, let us be careful what we're doing here | ||
| I'm not against it :-) | |||
| timotimo | it'll be a compile-time option that's off by default, at the very least | 12:23 | |
| so, storing the types of local variables in some more efficient format will make skipping through frames (so that lazy deserialization can skip some work) a little more complex, as it's got to figure out the size of the local var types blob somehow | 12:26 | ||
| of course, the local var type blob can start with a size | 12:27 | ||
|
12:28
zakharyas1 left
|
|||
| timotimo | highly scientific waffling gives me the following data point: there's 187_803 locals in total in core.c.setting | 12:35 | |
| only 29_578 of those are not obj typed | |||
| m: say 187803 * 2 / 1024; say (187803 - 29578) * 2 / 1024 | 12:37 | ||
| camelia | 366.802734 309.033203 |
||
| timotimo | if there were zero overhead to storing non-obj locals, this is how much smaller core.c.setting.moarvm could become | 12:38 | |
| (though my rakude is a little out of date) | |||
|
13:10
sena_kun joined
13:12
Altai-man_ left
13:55
benchable6 left
13:56
greppable6 left,
shareable6 left,
nativecallable6 left,
unicodable6 left,
evalable6 left,
tellable6 left,
notable6 left
13:57
reportable6 left,
quotable6 left
13:58
squashable6 left,
bisectable6 left,
releasable6 left,
committable6 left,
sourceable6 left
13:59
statisfiable6 left,
coverable6 left,
bloatable6 left
14:11
lucasb joined,
zakharyas joined
14:20
shareable6 joined,
greppable6 joined,
nativecallable6 joined,
benchable6 joined
14:37
quotable6 joined
14:38
tbrowder joined,
unicodable6 joined,
reportable6 joined,
notable6 joined
14:40
evalable6 joined
14:41
tellable6 joined
|
|||
| Guest78373 | libuv 1.34.1 is out: github.com/libuv/libuv/blob/v1.x/ChangeLog | 14:51 | |
|
14:56
bloatable6 joined,
coverable6 joined
14:57
statisfiable6 joined,
bisectable6 joined,
sourceable6 joined
14:58
releasable6 joined,
committable6 joined,
squashable6 joined
15:09
Altai-man_ joined
15:12
sena_kun left
|
|||
| timotimo | dang, getting serialization not to blow up is ... a thing | 16:06 | |
|
16:35
domidumont joined
|
|||
| timotimo | nine: you don't happen to want to help debug my dreck? :) :) | 17:03 | |
|
17:08
zakharyas left
17:10
sena_kun joined
17:11
Altai-man_ left
17:13
zakharyas joined
|
|||
| nine | timotimo: ah, sorry, I'm on my way out | 17:13 | |
| timotimo | that's no problem | 17:18 | |
| i'll take a nap, maybe things will look clearer after that | |||
|
17:24
zakharyas left
18:01
zakharyas joined
18:23
sena_kun left
18:24
MasterDuke joined
|
|||
| MasterDuke | i now have nqp building and passing `make m-test` (minus one test where a negative value is no longer allowed in the libtommath function, but that's an easy fix) with my use_libtommath_v1.20 moarvm branch. rakudo builds and passes most spectests, but only if i set MVM_JIT_DISABLE=1 | 18:26 | |
|
18:29
SmokeMachine left
|
|||
| MasterDuke | if i don't disable the jit, i get a segv in MVM_p6bigint_store_as_mp_int, at github.com/MasterDuke17/MoarVM/blo...int.c#L107 | 18:30 | |
| anybody up for helping to debug | |||
|
18:31
kawaii left
18:33
sena_kun joined,
Geth left,
zakharyas left
18:34
kawaii joined
|
|||
| MasterDuke | i assume it must be one of my changes to the mp_(g|s)et_* functions, but i haven't figured out which one yet | 19:06 | |
|
19:11
sena_kun left
19:26
sena_kun joined
|
|||
| MasterDuke | also, timotimo++, glad to see you're back | 19:30 | |
|
19:51
domidumont left
20:37
Geth joined
20:42
zakharyas joined
20:55
AlexDaniel left
21:05
MasterDuke left
21:12
sena_kun left
21:27
sena_kun joined
21:38
lucasb left
21:45
zakharyas left
22:01
AlexDaniel joined,
AlexDaniel left,
AlexDaniel joined
22:40
sena_kun left
22:56
sena_kun joined
|
|||