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