github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:13 sena_kun left 00:14 lucasb left 02:06 discord63 joined 02:09 discord6 left, discord63 is now known as discord6 02:43 Garland_g[m] left, Garland_g[m] joined 08:00 domidumont joined 10:12 sena_kun joined
timotimo i hate looking at update_ops.p6 10:39
:)
nine Same here 10:44
timotimo fish: “pahole -C MVMOpInfo -P -R -S ~/…” terminated by signal SIGSEGV (Address boundary error) 11:51
lmao, what
12:14 Geth_ joined
timotimo sent patch 12:18
12:39 Geth left 12:40 Geth joined
timotimo i just uploaded some commits to moarvm; one removes the mark field from MVMOpInfo, another uses bitfields instead of full bytes for the flags we have 12:55
tbf, the marks could have lived in the 6 byte hole that is left because of the char *name pointer
in the last commit i point out that perhaps name wants to be stored somewhere else, but then we'll have to have API to get the name of an instruction, which is more work than ins->info->name ... 12:56
typing work, mostly
jnthn: how do you feel about keeping the name of an op directly inside MVMOpInfo as a char pointer? i'd like to move it out to a different datastructure because it costs 14 bytes of storage; the 8 bytes for the pointer and 6 extra bytes of padding 12:57
jnthn Hm, I guess if there's some nice function/macro to get the name, we can 14:34
15:56 Geth left 15:58 Geth joined 16:54 Geth left 16:55 Geth joined 17:31 MasterDuke joined, MasterDuke left, MasterDuke joined 17:44 domidumont left
kawaii hi! I plan on bumping rakudo and nqp to 2019.05 tomorrow, is someone here able to bump moar to the same please? :) 17:46
MasterDuke samcv: ^^^ 17:53
samcv kawaii, what time zone are you 17:58
kawaii samcv: I'm in GMT+0, in the UK
samcv kawaii, uk is +1. i'm +2. unless some places don't get summer time 17:59
but yes that works for me
timotimo if there's a release tomorrow, why did i just push changes to master %) 18:05
kawaii samcv: oh, you're right :) 18:08
forgot we have summer in the UK
timotimo hey samcv, do you know why the coverage report up on moarvm.github.io/coverage is from 2018-07? 18:11
i mean, it's the first time since before that that i needed it 18:12
samcv oh 18:13
ah yeah
err. i guess it should upload maybe. let me see
timotimo it's not super high priority if you've got other stuff to do RN
samcv hmm
this shows last 5 hours ago github.com/MoarVM/coverage
so that's weird 18:14
timotimo hm, it only updated index.html?
samcv i'll check the travis logs 18:15
cp -Rf '/home/travis/staging/*' . 18:17
cp: cannot stat ‘/home/travis/staging/*’: No such file or directory
they must have changed the permissions or something 18:18
err actually continuing to go up the log
timotimo anyway, i've started a spectest and if i had messed up something about the MVMOpInfo data, it'd have blown up spectacularly by now, surely 18:22
samcv timotimo, the lvm options changed 18:27
timotimo, travis-ci.org/samcv-MoarV
err
can i not link lines in the travis log?
here it is travis-ci.org/MoarVM/MoarVM/jobs/5...8704#L1888 18:28
timotimo ah, well that'd surely explain it 18:31
MasterDuke has anyone tried moarvm with gcc9 yet? 18:43
timotimo nein 18:48
AlexDaniel MasterDuke: that didn't even reach debian unstable… 19:32
last I remember there were some warnings even with gcc 8 19:33
20:43 dogbert11 left
timotimo oooh there's a sizeable chunk of op names that end with another op's name 20:44
continuationreset set
randscale_n le_n
uniisblock lock 20:45
these are funny
20:49 Geth left 20:50 Geth joined 20:59 zakharyas joined
jnthn I won't ask how you discovered this :P 21:53
timotimo well, i was thinking if we're already looking for ways to store things more compactly, a 16bit value would be smaller than a full pointer, and if we put all strings one after the other into one buffer (with null bytes to separate them so they stay regular c strings) we can index directly into the middle of a longer string if we find a match 21:55
it looks like it'd save about 693 bytes, which is about 9% of the 7657 bytes it'd normally take 21:57
oh, i didn't count the +1 for null bytes
another oh, i believe i got them mixed up and the savings are actually just 4% 21:58
no, i definitely got the counts wrong :) 21:59
the 4% savings number is the right one, sadly 22:00
going from const char *name; inside MVMOpInfo to MVMuint16 name_offset; gets it to shrink from 32 to 16 bytes, so that's nice 22:07
lizmat timotimo: how about storing offset (16bit) + length(8bit) 22:09
timotimo then we can't use regular, boring C string functions
lizmat you could then use the fact that some strings are inside other strings to further reduce the overall size
timotimo we have a whole lot of places where we fprintf("the op is: %s\n", ins->info->name)
lizmat ok 22:10
but still: for "le_n" you could index into the string "randscale_n" and share the null byte :-)
ah, that's what you already said 22:11
timotimo yeah, but the savings are tiny
lizmat goes to sleep&
timotimo good night and rest well!
22:18 zakharyas left
timotimo ugh, did i commit too much of update_ops.p6 22:21
ooh, but changing that makes it more difficult to deal with extops 22:28
all the more reason to get rid of extops :) :) :) 22:36
a friend once suggested to use varints for everything in the bytecode format ... i wonder if the extra computation to read the values will be completely dwarfed by the improved throughput from smaller code? and the hottest code gets jitted to machine code anyway? 22:57
23:09 Kaiepi left, Kaiepi joined 23:55 sena_kun left

Powered by Cro and the Raku® Programming Language.

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

Thank you!