github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo gist.github.com/timo/d84b2ea40ac0e...b4c01c8a44 - has an example of decont now 00:14
nwc10 good *, #moarvm 07:14
Geth MoarVM: c0ed9e32b4 | (Timo Paulssen)++ | 2 files
make extop marks reachable again in MVM_op_get_mark
 14:24
MoarVM: 7a2881a85b | (Timo Paulssen)++ | src/debug/debugserver.c
debugserver: implement simplest decont operation

only when no code has to be run (like for Proxy)
timotimo there's one single op in moarvm that has "all" 8 operands 22:59
that's asyncwritebytesto
there's a few others, but all of them are DEPRECATED_* ops 23:00
the MVM_op_infos blob is like 29 kbytes big
shaving one operand off of every op would free up 922 bytes 23:01
MasterDuke heh. looks like between nqp and rakudo it's used exactly once 23:02
timotimo once we have dispatch, we could turn at least this one op into a dispatcher 23:03
now, which ops have 7 operands?
aha a couple more 23:04
sp_add_I, sp_sub_I, sp_mul_I, nativecallbuild, and asynclisten
and asyncudp 23:05
i assume @values in MAST/Ops.nqp is the operand values 23:13
and there are plenty above 128, so it's definitely using all 8 bits in there
m: say 1656 R- 3735 23:16
camelia 2079
timotimo m: say (1656 R- 3735) / 824
camelia 2.523058
timotimo ^- the average op uses 2.5 operands
m: say 824 * 8 - (1656 R- 3735) 23:17
camelia 4513
timotimo m: say 824 * 8
camelia 6592
timotimo that's not the right way around 23:18
m: say 824 * 8 R- (1656 R- 3735)
camelia -4513
timotimo could save 4 kbytes if the operands were var-len, though then they'd have to live in a separate array and have an index into that in the op info itself 23:18
m: say 1656 R- 3735 23:19
camelia 2079
timotimo it'd have to be 16 bit at least, so as big as 2 operands still 23:19
m: 4513 - 824 * 2
camelia WARNINGS for <tmp>:
Useless use of "-" in expression "4513 - 824 *" in sink context (line 1)
timotimo m: say 4513 - 824 * 2
camelia 2865
timotimo so actually only 2.5 kbytes saved after all 23:20
i'm looking at this mostly because bytecode validation costs quite a few cycles during startup 23:21
and that has to go through the op info and grab some things out
oh? there's a 6 bytes big hole between opcode and op name 23:26
22128 bytes big now 23:29
that's significantly better!
so i ran nqp-m -e '' three times with callgrind and got a sum of 236_895_057 Ir 23:31
MVM_validate_static_frame was 75_439_617 of that 23:32
now it's 237_461_358 in total, interesting! 23:33
so that looks kind of like it got worse
76_055_621 Ir on MVM_validate_static_frame, too

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!