github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:10 fractal7 joined
jnthn sleep & 00:11
00:13 fractal7 left
timotimo rest well! 00:13
hope next day has less bad temperature
00:47 committable6 left, committable6 joined 00:52 committable6 left, committable6 joined 00:55 bisectable6 left, bisectable6 joined, evalable6 left, avar left, evalable6 joined 00:56 ChanServ sets mode: +o p6bannerbot 00:58 avar joined, avar left, avar joined, p6bannerbot sets mode: +v avar 00:59 p6bannerbot sets mode: +v avar 01:44 Char0n joined 01:45 p6bannerbot sets mode: +v Char0n, Char0n left 02:34 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo 03:18 harrow` left 03:30 harrow joined 03:31 p6bannerbot sets mode: +v harrow 04:08 avar left 04:09 avar joined, avar left, avar joined, p6bannerbot sets mode: +v avar 05:08 CeBe14 joined, pskosinski23 joined 05:09 p6bannerbot sets mode: +v CeBe14, p6bannerbot sets mode: +v pskosinski23, Tyrantelf25 joined 05:10 p6bannerbot sets mode: +v Tyrantelf25, CeBe14 left 05:11 Tyrantelf25 left 05:17 pskosinski23 left 05:25 cloe18 joined 05:26 p6bannerbot sets mode: +v cloe18 05:28 cloe18 left 05:39 brrt joined 05:40 p6bannerbot sets mode: +v brrt 05:47 avar left 05:51 avar joined, avar left, avar joined, p6bannerbot sets mode: +v avar 05:52 p6bannerbot sets mode: +v avar 06:02 Kaiepi left 06:25 fake_space_whale left 06:34 MasterDuke left 07:20 zakharyas joined, p6bannerbot sets mode: +v zakharyas 07:47 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build failed. niner 'Merge pull request #944 from MoarVM/jitcode-refcount 07:47
travis-ci.org/MoarVM/MoarVM/builds/418107213 github.com/MoarVM/MoarVM/compare/7...de10c42a61
07:47 travis-ci left 08:06 brrt left 08:32 ZzZombo left 08:34 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo 08:48 brrt joined 08:49 p6bannerbot sets mode: +v brrt 09:00 lizmat left 09:13 ZzZombo left, ZzZombo joined, p6bannerbot sets mode: +v ZzZombo, ZzZombo left, ZzZombo joined, p6bannerbot sets mode: +v ZzZombo
jnthn Really odd; after the add_I lowering I see ++ getting slower... 09:48
Or to be precise, I see a benchmark that goes through a big array and incrementing each Int in it get slower 09:49
brrt that is odd 09:57
RFC: make all JIT logging part of spesh logging (a lot of what is now in JIT logging will be cleaned up) 09:58
jnthn It's very odd. It's not wrongly calling the fallback path, the code generated in the spesh log looks right 09:59
brrt RFC: lets make master the main development branch, and have 'release' for a specific release branch, and continue working on topic-branches
is it JITted and if so, is it JITted well or badly
there was another thing I was thinking of, but it escapes me now
jnthn Yes, certainly jitted 10:00
The whole main loop ends up totally inlined. And MVM_JIT_DISABLE=1 makes things slower.
brrt frowns 10:01
oh, and another fun thing I can do; I can make a perf map of JIT compiled frames 10:02
jnthn OK, wow, I found an...interesting clue... 10:32
We do 212 GC runs with add_I lowering on, but only 117 with it off o.O
10:34 brrt left
jnthn ohh...I think I figured it out 10:44
8ffe71a51b7775a2a9 didn't update the write barrier in the lego JIT
So previously we'd use the expr JIT for this code
10:48 ZzZombo left
jnthn Hmm, but changing that still doesn't seem to help 10:53
11:15 nine_ is now known as nine, zakharyas left
jnthn Very confusing...the symptoms all fit the problem, the fix looks right, but it still doesn't help... 11:18
lunch &
jnthn back from lunch and still plenty confused :) 12:19
ohhh...I think I just realized what it is :/ 12:20
The new path doesn't try to use the integer cache for the result :/
And the benchmark I'm looking at would benefit very much from it
12:23 domidumont joined 12:24 p6bannerbot sets mode: +v domidumont
jnthn Darn, that measn I can't so nicely decompose the op into fastcrate and sp_add_I :( 12:25
*means
12:31 domidumont left 12:32 domidumont joined 12:33 p6bannerbot sets mode: +v domidumont
jnthn Pushed a few bits, will deal with the sp_add_I using the cache a bit later 12:38
Other stuff needs doing :) 12:39
12:48 Kaiepi joined 12:49 p6bannerbot sets mode: +v Kaiepi 12:59 zakharyas joined 13:00 p6bannerbot sets mode: +v zakharyas 13:32 domidumont left 13:40 domidumont joined 13:41 p6bannerbot sets mode: +v domidumont 14:07 domidumont left 14:11 brrt joined, p6bannerbot sets mode: +v brrt
brrt .tell lizmat we are seeing travis CI problems on OS X, and I don't have OS X, so maybe you could have a look? 15:03
yoleaux brrt: I'll pass your message to lizmat.
brrt e.g. travis-ci.org/MoarVM/MoarVM/builds/418107213
15:07 fake_space_whale joined 15:08 p6bannerbot sets mode: +v fake_space_whale
brrt what are people using the JIT log for? I'm using it mostly for debugging reasons 15:19
jnthn grep BAIL ... :) 15:20
brrt thought as much :-)
timotimo i'm using it mostly for bails, both of lego jit and what prevents an op i'm looking at from being picked up by the exprjit
brrt see, if that's 90% of usage, and the other 10% of usage is me, debugging something strange, then I see no reason *not* to merge it with the spesh log 15:21
timotimo you know, if we run the jit before dumping the spesh graph, the jit can add annotations on spesh nodes using the comments feature 15:22
so it wouldn't have to have its own section necessarily
like "exprjit sequence starts here", "exprjit sequence stops here
"
brrt that... 15:23
is a good idea
I like it
timotimo++
(but where does that leave my debugging purpose... hmm) 15:24
jnthn Maybe we need a verbosity level
brrt yeah, something like that 15:25
jnthn Otherwise it'll be very cluttered
timotimo well, we can still keep the jit log as is, optionally
jnthn I already have the problem of fitting as much as I want to look at vertically on my screen from the spesh log
timotimo and have it output exactly what it's outputting right now
oh, hm.
brrt hmm 15:26
timotimo i could imagine a folding plugin for your editor might get you part-way there, but it can only reduce a section of lines into a single line
i barely ever use folding in vim, but i think by default it displays that one line fully? 15:27
i have a custom one that puts "n lines:" in front
brrt an emacs spesh log mode. that'd be a thing
anyway
A verbosity level would be a good addition as well 15:28
timotimo sometimes the amount of annotations we have can be a bit much
also, i find it super annoying to be scrolling past the - sometimes ginormous - facts lists to get to the spesh slots; let's vote on moving the spesh slots in front of the facts :)
jnthn I tend to want the facts earlier... 15:29
timotimo well, that's fair
jnthn But...don't we annotate the type of thing in the spesh slot with a comment on the getspeshslot instruction now?
So would you actually look at it much any more? :)
brrt I have no opinion, other than, let's not overbuild this 15:30
timotimo there's more than getspeshslot, some of which don't yet have that
but i can add them no prob
jnthn *nod*
timotimo MVM_spesh_graph_add_spesh_slot_content_comment(tc, g, ins, sslot_idx_or_operand_or_something)
in that kind of function i could also put more intelligence for some specific reprs 15:31
like P6int, str, and num could have the value, maybe scalars, likewise.
brrt Hmmm
Will spesh comments work on specific opcodes? 15:32
Will spesh comments be noops if we aren't logging?
timotimo a spesh comment is just like the other annotations, so it depends on who does that
spesh comments don't exist outside of the spesh optimization phase
brrt I'm meaning, logging as in writing-a-log
timotimo oh
in cases where it does something "expensive" like encoding a string to cstring i put an if_spesh_debug_on(tc) around it 15:33
brrt I think I made a function once called MVM_spesh_log_is_active or so
timotimo but otherwise it won't even consume the va_args if spesh logs aren't on
yup
brrt ah, I see
yeah, then I'm a happy camper, that would work for my purposes
timotimo the lego jit functions, i.e. what we have in emit.dasc or graph.c, could under these circumstances also add comments 15:34
brrt right
timotimo meaning when the spesh graph dump comes after the jit attempt
i like this, this feels like a good unification
brrt but tbh, there isn't all that much interesting in it, if we also have the spesh log right aside
part of the reason it is as verbose as it is, is that we otherwise couldn't correlate them :-) 15:35
me too :-)
timotimo i was thinking of, for example, putting a "devirtualization successful" comment right on the reprops, for example
brrt +1 on that
timotimo a question: how would you implement "allow an MVMString * to be put in the varargs, and the spesh_add_comment function handles encoding and freeing for you"? i can imagine something like putting a very specific pointer as a marker "change the next argument" and then move every following argument over? 15:37
also, if we have that, we might want to add that to the MVM_exception_throw_adhoc functions, too
that could save a lot of boilerplate code
brrt me, I'd use a bitmap 15:49
timotimo oh, so put a value in front that tells me which arguments need that treatment
brrt yes 15:50
timotimo but that'll have to go everywhere, even when the feature is not used
brrt then it'll just be 0? doesn't seem like it's too expensive
timotimo i could annotate the function so that only literals are allowed there
brrt btw, I think we ought to have a void eMVM_string_utf8_encode_to_buffer(tc,string,size , buffer); 15:51
timotimo it does malloc for you? 15:52
oh
you do malloc for it
call it once with null buffer and null size and it'll give you the needed size? :)
brrt hmm, i'd really rather have a static buffer, but that's me
but yes, that's a possiblity as well 15:53
timotimo is that why the appendf function doesn't first ask sprintf how much space it'd need?
brrt well, it's just much simpler to do so? btw, I'd use a char[1024] there, as well 15:55
limits help :-)
timotimo what if you want to append a string that may be longer? :P 15:56
brrt appendf doesn't handle that case
and, more importantly, you'd be wrong :-P
the problem we're solving is 'provide information to someone debugging MoarVM', that doesn't need more than 1024 characters 15:57
1024 characters is..... 200 words? A minor essay?
timotimo ok, *shrug* :)
does va_list support editing arguments on the fly? :\ 15:58
brrt If we find that isn't enough, we up the limit
not sure what you'd wnat with that?
timotimo it isn't enough to tell the function that one or more of the arguments are MVMString
it also has to pass the char * result to sprintf
brrt ah, I see what you mean 15:59
hmmm
not sure if that is a thing supported by va_list, normally
timotimo yeah, some arguments are passed in registers, aren't they?
brrt i think that's not true if you're using va_list anyway 16:00
but
I'm not really, really sure
I skimmed over that part of the ABI
timotimo As an optimization, during a function call, %rax is required to hold the number of SSE registers used to hold arguments, to allow a varargs caller to avoid touching the FPU at all if there are no floating point arguments. 16:02
Because va_arg must tell determine whether the requested type was passed in registers, it needs compiler support, and canā€™t be implemented as a simple macro like on i386. The amd64 ABI reference specifies va_arg using a list of eleven different steps that the macro must perform. 16:03
blog.nelhage.com/2010/10/amd64-and-va_arg/
not sure if a post from 2010 is still sufficiently relevant, but i'd assume so
brrt you might be able to use va_copy
timotimo right, but what then? :) 16:04
brrt hmmm
you'd need at least one more layer of indirection
timotimo also, va_copy is C99, not C89
brrt šŸ˜’ 16:05
yeah, it's a pain
maybe you can declare printf helpers or something
ilmari are you actually targeting C89, or just msvc?
timotimo just msvc i think? 16:06
ok, register_printf_function exists in glibc
probably not in musl?
ilmari msvc 2013 supports va_copy 16:07
timotimo that's cool
do you know if a va_list will somehow allow me to change one value in the middle? 16:08
16:08 zakharyas left
brrt no, it doesn't allow it 16:08
that's not a thing
timotimo then we're just screwed :)
brrt not necessarily 16:09
hmmm
timotimo why not ship our own copy of some printf implementation that allows customization? 16:12
surely that's a fantastic idea
ilmari postgres does that, and are curretnly considering switching to that for all platforms, not just c99-deficient ones 16:17
they are also considering starting to require (a subset of) C99 16:18
timotimo switching to what exactly? bundling a printf implementation? 16:20
ilmari they already have their own pg_snprintf, but they only use it on c99-deficient platforms 16:22
timotimo i see 16:23
i'm not sure we should actually do that; libmoar is already big-ish; how big is that implementation? 16:24
ilmari 1162 src/port/snprintf.c 16:25
BSD-licensed 16:26
timotimo that's not that bad 16:28
and their custom formats are right in there, then? 16:30
ilmari yes, there's a 500-line "dopr()" function which does the hard work 16:37
git.postgresql.org/gitweb/?p=postg....c;hb=HEAD 16:39
timotimo doxygen.postgresql.org/snprintf_8c_source.html - looking here right now
dopr_outch, sounds painful
ilmari heh, I didn't realise they had a doxygen browser 16:40
timotimo i think it was the first google result i got %)
i hope nothing extra from c.h is required for this to work
16:44 domidumont joined 16:45 p6bannerbot sets mode: +v domidumont 16:46 domidumont left
brrt actually, i'm not against that...... but the next thing is it's going to be exposed to the world, and the thing after that is an exploit :-) 16:47
here's what you can do, though 16:48
you create a tinyish macro
16:48 domidumont joined
brrt S(x) which expands to MVM_string_decode(...) 16:48
16:49 p6bannerbot sets mode: +v domidumont
brrt and another macro for the bitmap (or whatever), and you do a va_copy, and after the sprintf, you iterate over the copied list and free everything that was in the bitmap 16:50
that's.. actually the cheap-and-cheerful option
the yak can keep his hair that way
16:57 brrt left 17:05 domidumont left 19:43 lizmat joined 19:44 p6bannerbot sets mode: +v lizmat 19:48 brrt joined 19:49 p6bannerbot sets mode: +v brrt 19:53 [Coke]_ joined, [Coke]_ left, [Coke]_ joined, p6bannerbot sets mode: +v [Coke]_, avarab joined, avarab left, avarab joined, p6bannerbot sets mode: +v avarab 19:54 p6bannerbot sets mode: +v [Coke]_, lizmat_ joined, p6bannerbot sets mode: +v avarab 19:55 p6bannerbot sets mode: +v lizmat_, avar left, [Coke] left, lizmat left 19:57 benchable6 left, releasable6 left, bloatable6 left 19:58 bloatable6 joined, releasable6 joined, benchable6 joined, undersightable6 left, squashable6 left, reportable6 left, p6bannerbot sets mode: +v bloatable6 19:59 p6bannerbot sets mode: +v releasable6, p6bannerbot sets mode: +v benchable6 20:25 lizmat joined, p6bannerbot sets mode: +v lizmat 20:28 lizmat_ left 20:31 fake_space_whale left 20:55 reportable6 joined, undersightable6 joined, squashable6 joined 20:56 p6bannerbot sets mode: +v reportable6, p6bannerbot sets mode: +v undersightable6, p6bannerbot sets mode: +v squashable6 21:03 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke 21:04 MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke
timotimo my next immediate task will probably be to separate GC stats into managed and unmanaged. after that, perhaps even tonight, sp_bool_I 21:19
i'd love to know if there's guarantees for the "used" value of mp_int. like, if it uses more than 1 entry, does that guarantee that the value is bigger than what fits into one mp_digit, and is therefore guaranteed to not be 0?
does mp_int ever have the sign set to MP_NEG if the value is 0? 21:20
that way, perhaps the function call fallback could be skipped entirely.
jnthn Don't know, guess would have to study the code some :) 21:36
Can if nothing else look at what the function you'd be calling does
timotimo right, that's mp_iszero 21:37
oh, it's a tiny macro
(((a)->used == 0) ? MP_YES : MP_NO 21:38
)
jnthn That's just shouting out "inline me into the JIT!"
timotimo indeed it is
jnthn I need to redo add_I and friends lowering to use the int cache :/
timotimo yes :(
how worthwhile do you consider the comparison ops, like lt_I? 21:42
brrt btw, I've been thinking on how to implement jump-on-overflow in the JIT 21:45
yoleaux 20:27Z <lizmat> brrt: if this is about t/spec/S32-io/file-tests.t, then yes it fails on MacOS
brrt .tell lizmat it's not, it's about the NQP build failure because git
yoleaux brrt: I'll pass your message to lizmat.
brrt but I guess you're not seeing it
jnthn brrt: I guess you mean "expression JIT", since I did a jo in the lego JIT a few days back :) 21:55
timotimo: Comparison ops are very likely worth it; we avoid in the best case a function call and the whole indirection around finding the offset of the bigint structure, and in the worst case still save the latter :) 22:00
timotimo the fallback ops also use the offset, yeah?
not ops, functions 22:01
jnthn Yes
timotimo will you be adding anything to the oplist? i'm considering adding the op and pushing the commit for it immediately to make conflicts less likely
jnthn I'll maybe change the signature of the sp_add_I and friends 22:02
timotimo that is probably a much lesser conflict for merging
so that wouldn't be a problem i don't think 22:03
i'm putting an empty line in between in the oplist %)
so there'll be bool_I and the comparison ops in their own little space
jnthn :) 22:04
Merge conflicts in that stuff are hardly a problem 22:05
You just run the update_ops.p6 script and add the re-gen'd thing and it's done
timotimo right
brrt yes, in the expression JIT :-) 22:13
jnthn Yeah, that's a blocker for porting my new bigint lowering :) 22:14
brrt so, thing is, this is an operator that branches not after a test, but after something yielding a value 22:15
so (if (overflow ...) ? ...) - that's not going to work
MasterDuke is there any reason we have the files generated by update_ops.p6 in git? 22:17
brrt yeah, we can't run perl6 before we have moarvm :-P
timotimo the val_offset is just "the smallbigint is 4 bytes away from the union", yeah? 22:18
jnthn Right, same reason we have the stage0 in NQP
Things should be easy to build
Optimizing for avoiding a totally trivial conflict resolution that happens maybe a couple of times a year makes no sense. 22:19
heh, so I open my terminal to look at the bigint ops and...waiting for me is the log guard merge issue that I diagnosed but didn't fix yesterday :P 22:25
timotimo hm, i think bool_I can't really share an implementation with any other ops inside spesh/optimize.c 22:31
since it's - iirc - the only op that takes one bigint and stores an int64 22:32
there's the comparison ops which take two bigints and store an int64, though
jnthn Correct 22:33
Yeah, I expected a small collection of optimize_bigint_blah functions
timotimo that'd be a third function, or maybe it steals the initial parts from binary_op, the one that checks if the facts all have a common type
jnthn Yeah, common type may be possible to factor out neatly 22:37
brrt in a nicer world, we'd have time to write a bootstrap nqp and could do without stage0 22:39
jnthn Geth: ?
What would be write the bootstrap NQP in? :P
timotimo write an nqp in C?
brrt yeah, something like that, I guess?
jnthn Ewwww
brrt update_ops.p6 too :-P
jnthn Rather you than me
timotimo doesn't sound like fun to me, either
brrt hehe
jnthn And bluntly, rather not at all if it's anything I'd ever have to maintain :)
brrt :-) 22:40
stage0 it is then
timotimo make a binary that contains libmoar and stage0 itself 22:41
jnthn Geth: y u no report commits?
timotimo that way noone will notice
jnthn: doesn't have +v
22:42 ChanServ sets mode: +o jnthn, jnthn sets mode: +v Geth
brrt geth's dead I think 22:42
22:42 jnthn sets mode: -o jnthn
timotimo not death, just silenced 22:42
is it just me or has the spam attack seemingly dissipated?
brrt timotimo: actually, that's something we'll need Any Day Now
either that or the defenses work
timotimo our users have been begging for it 22:43
well, i don't see so many joins + klines any more
oh
we had some yesterday (counting pre-midnight as still today)
fwiw, building the core setting is crashy for me at the moment :( 22:44
oh no
my computer is showing signs of serious trouble
jnthn timotimo: Yeah, it may be the log guard issue I recreated in NQP tonight. I'll perhaps try and fix that one tomorrow. 22:45
Doing the rather simpler bigint op changes tonight, which is what I've sufficient concentration/energy for
timotimo how do i test my changes :) 22:46
jnthn For bool_I?
timotimo aye
does nqp have it in its test suite?
jnthn Maybe
timotimo it does! 22:47
jnthn Pretty sure there's a bigints test
timotimo yups
needs a loop around it, sure, but that should do it
22:50 avarab left
timotimo OK, it jits bool_I now; next step is to actually make spesh/optimize call the function i just wrote %) 22:50
that'll test the interpreter version 22:51
hard to get it to spesh ... 22:56
ah dangit, it's building a P6bigint, not a P6opaque 23:04
i wonder how much work it is to construct a P6opaque with a box_target by hand 23:06
23:07 brrt left
timotimo i just realized i could just turn spesh off for the core setting compilation! 23:10
optimize_object_conditional needed a call to optimize_bool_op, but now it works. now to turn on the jit :) 23:14
fascinating, it seems to work. now for the bigint case 23:15
nice, it seems to work just fine 23:17
23:17 avar joined, avar left, avar joined, p6bannerbot sets mode: +v avar
timotimo i'll make a commit and push it :) 23:17
23:17 p6bannerbot sets mode: +v avar
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2018/08/20/...m-tyndrum/ 23:22
Geth MoarVM/postrelease-opts: d7df81385c | (Timo Paulssen)++ | 9 files
optimize bool_I to sp_bool_I

Like sp_fastbox_bi, sp_add_I, and friends, this calculates a fixed offset into a P6opaque's body where the bigintbody can be found and emits a spesh op that directly accesses the memory to do the extremely cheap nonzero check on the contents for both smallbigint and real bigints.		 23:23
23:34 lizmat left
timotimo it's not quite a gigantic win, or maybe my benchmark has just way too much overhead 23:44
my Int $a = 0; for ^500 { for ^100_000 { say "hi" if $a } }
m: 6.24 / 6.5
camelia WARNINGS for <tmp>:
Useless use of "/" in expression "6.24 / 6.5" in sink context (line 1)
timotimo m: say 6.24 / 6.5
camelia 0.96
jnthn Yeah, I'd not expect gigantic for that one 23:45
But still, it's a win
timotimo we are winners
jnthn I've got specialized add ops using the int cache again 23:46
timotimo bizzarre, using 100 ** 90 as the value is actually faster, though maybe it's just that there's a not_i in the 0 case?!
i think the difference in speed is even less pronounced for 100 ** 90 with unless rather than if 23:49
but ... *shrug*
keeps the code cache and branch predictor free to make other stuff better i suppose 23:50
and not having to look at the repr to find the offset is of course also stress removed from the data cache
jnthn Yeah, indeed 23:55
It all adds up :) 23:56
timotimo i somehow lost the tab with the project that can compile custom division operators if the RHS is known

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!