Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-06-01

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:14 colomon joined #moarvm
01:17 vendethiel joined #moarvm
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:22 colomon joined #moarvm
02:45 colomon joined #moarvm
04:09 flaviusb joined #moarvm
06:18 FROGGS joined #moarvm
07:26 zakharyas joined #moarvm
08:09 FROGGS_ joined #moarvm
09:16 Ven joined #moarvm
09:53 Ven joined #moarvm
10:39 colomon_ joined #moarvm
12:08 brrt joined #moarvm
12:08 brrt \o
12:09 brrt timotimo: for all cases of non-jitting, bindexception* to sp_bind_* ops is a pessimization
12:09 brrt which is probably why they haven't been implemented
12:09 brrt yet
12:09 brrt hadn't
12:10 brrt anyway
12:11 brrt i'd appreciate it if we split the question 'why does this not inline' from the question 'lets implement JIT ops'
12:11 brrt so as to keep the patch set as small as can be achieved
12:12 timotimo yes, sorry, i got a bit carried away putting all my stuff into the same branch ;)
12:13 timotimo why is sp_bind_* a pessimization?
12:17 brrt because (in the interpreter) when you do, e.g. bindexmessage, the compiler already knows the offset of ex->body.message, hence it does not need to be encoded, much less interpreter
12:17 brrt interpreted
12:17 brrt the JIT eliminates that difference, of course
12:17 brrt but for the interpreter it increases bytecode size
12:17 timotimo oh
12:17 timotimo so i shouldn't jit these into sp_bind_*, instead i should do it directly in the jit?
12:18 brrt and runtime
12:18 brrt no
12:18 brrt i'm just explaining why it probably had not been done yet
12:18 timotimo "i shouldn't spesh"*
12:18 timotimo ah
12:18 timotimo well, what i was really asking for was why the sp_bind_* ops have not yet been implemented at all :)
12:18 brrt although, one could indeed implement the conversion in in the jit only
12:18 Ven joined #moarvm
12:20 timotimo not sure what you mean
12:24 brrt the translation from bindexmessage to sp_bind_* could be implemented in src/jit/graph.c, (in jit graph building step) rather than in src/spesh/optimize.c
12:24 timotimo hm
12:24 timotimo is that convenient?
12:24 brrt but, it doesn't matter much now, since i'm supposed to start translating it all to a magic optimisation format two weeks from now
12:24 brrt no
12:25 timotimo right
12:25 timotimo and we also jit the majority of frames directly after speshing
12:25 brrt if we can, we do
12:25 timotimo we should can
12:27 brrt yes
12:27 brrt anyway
12:27 brrt my question is
12:28 brrt what would it take to turn the jit_throw_ops into something mergeable
12:28 timotimo the branch, yeah?
12:29 timotimo i'll cherry-pick some stuff out of it and possibly rebase -i the stuff out of the branch itself
12:50 brrt yes, if you could, that'd be very nice :-)
12:50 brrt also, to resume (haha) the discussion of a few days back
12:51 brrt i think somebody who can, in fact, dive into a complex codebase and apply fixes and changes and consider their whole impact
12:51 brrt as you (timotimo) have surely proven to have
12:51 brrt then yes, that is certainly a valuable skill indeed
12:52 timotimo fair enough i suppose :S
12:52 brrt on the flip side of that is that simply stating 'i've worked on the perl6 optimization infrastructure' is very likely not to convince recruiters, or at least to be answered with 'but how many years of .NET/PHP/Java experience do you have?'
12:52 timotimo fair enough
12:53 brrt us techies know that this is an irrelevant question, but one that will be asked anyway
12:53 timotimo but i'm a de techie :P
12:53 brrt these days i consider a resume (cv) to be a tool to get interviews, no more no less
12:53 timotimo mhm
13:03 brrt and, lastly, and i wonder why i even have to say it :-P
13:03 brrt the *difficulty* of any job is not (directly) related to its *value*
13:03 brrt least of all the difficulty to you
13:04 timotimo i know it's logical, but it doesn't make sense to my brain
13:07 brrt no one is asking you to be mr spock :-)
13:07 timotimo mhm
13:11 brrt by the way, 'Fair enough' is not shorthand for 'You may be right, but I don't believe you anyway' :-P
13:12 timotimo haha
13:12 timotimo i can only speak for one part of my understand-machine
13:13 timotimo the other part(s?) are famously broken in some respects :)
13:19 brrt well... :-)
13:19 brrt anyway, i can't help you too much with that from this distance
13:19 timotimo of course
13:19 timotimo there's no emergency yet ;)
13:21 brrt fair enough :-)
13:22 timotimo i have some violently spammy debug output code for spesh inlining; i wonder if i should throw it out?
13:23 brrt it shouldn't go to master, no
13:23 timotimo of course not
13:23 brrt but for debugging, why  not
13:23 timotimo actually, the spesh dump could highlight ops that prevent inlining, so that part could go (and you can also see what would prevent a frame from being inlined even if nothing tries to inline it at all
13:23 timotimo i'm afraid i'm adding and adding to the spesh dump
13:23 brrt that's ok, for what it's worth
13:24 timotimo no clue if others would find the things helpful
13:24 * brrt thinks it likely that someone will
13:24 brrt better to have a bit too much information than a bit too little
13:24 timotimo at least through the table of logged values i figured out that something sidesteps the int cache
13:27 * brrt wonders
13:27 timotimo feel free to wonder with me; this issue seems to stump me
13:27 brrt if one is implementing a printf-style or string-cat thing
13:27 timotimo something builds P6int-repr'd things without using MVM_box_int
13:28 timotimo oh, you're wondering about something else entirely
13:28 brrt is it better to a): pre-calculate the required length and write everything in a single buffer
13:28 brrt or b): just go ahead and use a dynamic-growing array
13:28 brrt yes
13:28 brrt haha :-)
13:28 timotimo damn. i thought we were a team! :P
13:28 brrt hmmm
13:28 brrt that is a bit weird, yes
13:29 brrt and you're certain these are P6Int objects?
13:29 timotimo it surely prevents spesh from realizing that the logged values are *actually* equivalent
13:29 timotimo well, they have that repr and i've also extracted the numerical values
13:30 brrt how.. large is this intcache thing, anyway
13:30 brrt maybe something like inc?
13:30 brrt or arithmetic in general
13:30 timotimo inc works on int register
13:31 brrt inc_i
13:31 timotimo the intcache has 14 slots or something; it has its own .h and .c file
13:31 brrt lemmesee
13:32 timotimo on my laptop i have the code that prints out a P6int's value, i believe
13:33 timotimo BBIAB
13:33 brrt ok
13:41 Ven joined #moarvm
14:20 timotimo so it was really 16 slots for 4 different types
14:20 timotimo in the intcache
14:20 timotimo but you probably also figured it out yourself already
14:43 brrt yes, that i did :-)
14:43 brrt anyway
14:43 brrt possibly different type objects?
14:44 brrt possibly a question of cache-too-small?
14:44 timotimo the cache caches values 0 through 15 i think
14:44 timotimo so no, cache too small isn't it; especially since the values i saw were mostly 0 and 1
14:47 brrt hmmpf
14:47 brrt many frustrate
14:48 timotimo agreed
14:48 timotimo maybe the logic of returning integer values that get boxed go around MVM_box_int?
14:52 brrt possibly, yes
14:52 timotimo that'd be a very big source for this, if it is that case
14:52 timotimo can you take a quick look?
15:08 timotimo we might also be forgetting to record allocations for the profiler in this regard
15:13 brrt hmm i can not really take much of a look right now
15:14 timotimo that's okay
15:14 timotimo i'll be out and about getting food and doing other errands for the next hour(?)
15:22 brrt arithmetic ops don't do any intcaching, i think
15:22 brrt see src/math/bigintops.c
15:22 brrt my suspicion is that that is your problem
15:22 brrt but /me afk
15:22 brrt left #moarvm
15:40 [Coke] integration/advent2013-day14.t failed on the last daily run on non-jit, but worked on JIT.
15:42 FROGGS it is a flapper
16:32 vendethiel joined #moarvm
17:56 FROGGS joined #moarvm
17:57 vendethiel joined #moarvm
17:58 timotimo brrt, i found a gist with the p6int situation: https://gist.github.com/timo/1883a8c4287650f38925
18:00 dalek MoarVM/jit_throw_ops: 643c0fd | timotimo++ | src/spesh/dump.c:
18:00 dalek MoarVM/jit_throw_ops: [speshdump] in log table, show p6int value and concreteness
18:00 dalek MoarVM/jit_throw_ops: review: https://github.com/MoarVM/MoarVM/commit/643c0fdec3
18:00 dalek MoarVM/debugspam_inlining: 8f4a9d1 | timotimo++ | src/ (3 files):
18:00 dalek MoarVM/debugspam_inlining: lots of logging for inlining (and what prevents it)
18:00 dalek MoarVM/debugspam_inlining: review: https://github.com/MoarVM/MoarVM/commit/8f4a9d13d4
18:08 timotimo i have to teach all the bigint ops about intcache, eh?
18:08 timotimo at least many of them are implemented with macros
18:17 Peter_R joined #moarvm
18:18 timotimo hum.
18:19 timotimo when i want to defer the allocation of the p6int after deciding whether or not the ints are big ints or small big ints ...
18:19 timotimo i'll have to get_bigint_body twice in a row :\
18:19 timotimo because what if the object has moved
18:19 timotimo would it be sane to check the gc sequence number before and after the allocation?
18:31 timotimo and now i have something for autoboxing ints
18:34 timotimo can't get it to work properly :\
18:37 timotimo ah, unexpected unions
18:37 timotimo now i kind of wish for a slot for -1 in the int cache
18:39 timotimo i'll run a spec test and push
18:39 timotimo this includes a bunch of cherry-picks from jit_throw_ops
18:39 timotimo (onto master)
18:40 timotimo since this is about unboxing a return_i into an invoke_o, i suspect the spec tests would blow up extremely early if there was something wrong
18:41 [Coke] pushed.
18:41 [Coke] ww
18:42 timotimo i'm glad you routinely check #moarvm :)
18:44 brrt joined #moarvm
18:48 timotimo cool, spec tests only have the long-known flappers
18:49 dalek MoarVM: cf42d3d | timotimo++ | src/spesh/dump.c:
18:49 dalek MoarVM: [speshdump] show argument guards directly below callsite
18:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cf42d3d595
18:49 dalek MoarVM: f0d721b | timotimo++ | src/spesh/dump.c:
18:49 dalek MoarVM: output number of spesh & log slots and a log table in spesh dump
18:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f0d721b712
18:49 dalek MoarVM: 1512f6d | timotimo++ | src/spesh/optimize.c:
18:49 dalek MoarVM: since spesh slots are immutable pointers, we can re-use them
18:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1512f6d1e8
18:49 dalek MoarVM: b79854e | timotimo++ | src/spesh/optimize.c:
18:49 dalek MoarVM: remove debug output
18:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b79854efc3
18:49 vendethiel joined #moarvm
18:56 timotimo huh. MVM_bigint_div calls get_bigint_body twice, then roots the objects it gets the bodies from and then allocates
18:57 masak when I stringify -0e0 in Rakudo-on-Moar, what code is it that runs in MoarVM that creates that string?
18:57 masak closest I get to finding it is an .add_core_moarop_mapping in src/vm/moar/QAST/QASTOperationsMAST.nqp:QAST
18:57 masak er, s/:QAST//
18:57 timotimo what's the name of that op?
18:58 timotimo quite possibly coerce.c's MVM_coerce_n_s
19:04 timotimo ah, boxing ints for slurpy positionals doesn't go through the int cache yet
19:14 vendethiel joined #moarvm
19:16 dalek MoarVM: 9da66bc | timotimo++ | src/core/intcache.c:
19:16 dalek MoarVM: sacrifice 15 for -1 in the int cache. -1 is very popular!
19:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9da66bcc47
19:16 dalek MoarVM: 45381f0 | timotimo++ | src/core/args.c:
19:16 dalek MoarVM: ints for slurpy positional go through int cache
19:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/45381f010d
19:17 timotimo still some leaks, though i more or less don't want to give all bigint ops intcache treatment
19:21 brrt at this point i should probably note that i was wrong just now
19:21 brrt bigints don't go to the cache
19:21 brrt but bigints aren't P6int but P6bigint
19:22 FROGGS src/core/args.c:578:17: warning: passing argument 3 of ‘MVM_intcache_get’ makes integer from pointer without a cast [enabled by default]
19:22 FROGGS box_slurpy_pos_int(tc, type, result, box, arg_info.arg.i64, reg, int_box_type, "int", set_int);
19:22 FROGGS ^
19:22 FROGGS src/core/intcache.h:7:12: note: expected ‘MVMint64’ but argument is of type ‘struct MVMObject *’
19:22 FROGGS MVMObject *MVM_intcache_get(MVMThreadContext *tc, MVMObject *type, MVMint64 value);
19:22 FROGGS ^
19:22 FROGGS timotimo: ^^
19:22 timotimo no! what did i do?!
19:22 timotimo i built it locally ... whaaaat?
19:22 FROGGS it is just a warning
19:22 timotimo thank you
19:22 timotimo yes, but it's very wrong
19:22 FROGGS aye
19:22 timotimo i must have confused the argument order
19:23 FROGGS dump.c also warns
19:23 dalek MoarVM: b71f428 | timotimo++ | src/core/args.c:
19:23 dalek MoarVM: very, very wrong variable in this case
19:23 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b71f4286d3
19:24 timotimo yes, it does
19:24 timotimo because i was too lazy to cast things i know are the right type. i'll fix that now
19:24 FROGGS if all goes well I'll create a new branch today
19:25 timotimo oh, it's the const/not const thing
19:26 dalek MoarVM: 3377c87 | timotimo++ | src/spesh/dump.c:
19:26 dalek MoarVM: get rid of a warning in dump about constness of strings
19:26 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3377c87bcb
19:27 timotimo a new branch for the restricted thingie?
19:29 FROGGS aye
19:33 timotimo cool
19:56 vendethiel joined #moarvm
19:59 dalek MoarVM/restricted: 4f660d6 | FROGGS++ | src/ (4 files):
19:59 dalek MoarVM/restricted: add VM level op restrictions for safe code evaluation
19:59 dalek MoarVM/restricted:
19:59 dalek MoarVM/restricted: The goal is to safely evaluate foreign code, without fearing that this
19:59 dalek MoarVM/restricted: code can read your data from disk or create or delete files etc.
19:59 dalek MoarVM/restricted: To enable these op restrictions either declare a contextual called
19:59 dalek MoarVM/restricted: $*RESTRICTED or set the environment variable MVM_UNSAFE_DISABLE=1.
19:59 dalek MoarVM/restricted: review: https://github.com/MoarVM/MoarVM/commit/4f660d6d4c
20:00 FROGGS $ perl6 -e 'sub foo { use nqp; say nqp::open("sekrit", "r") }; { my $*RESTRICTED; foo() }'
20:00 FROGGS Operation 'open_fh' is not allowed in a restricted environment
20:00 FROGGS in sub foo at -e:1
20:11 masak timotimo++ # MVM_coerce_n_s
20:16 masak I think the gist of that one is that it delegates to sprintf, which in turn knows 0e0 from -0e0
20:19 masak so my question becomes: in C, what's a good way to tell (n64) -0 from 0?
20:22 vendethiel joined #moarvm
20:38 hoelzro does MoarVM mmap bytecode files for some reason?
20:39 hoelzro I have a hunch on why panda install JSON::Tiny gets angry
20:43 brrt possibly, yes, hoelzro
20:43 hoelzro hmm, maybe that's why there's a segfault when the panda mbc files are being overwritten...
20:43 cygx joined #moarvm
20:44 cygx o/
20:44 cygx masak: math.h comes with a signbit macro
20:45 masak ooh
20:45 masak what would that mean in code?
20:46 cygx if(n == 0 && signbit(n)) puts("n is a negative zero");
20:46 masak perfect. I can work with this.
20:46 masak cygx++
20:46 cygx masak: what's the use case, if I may ask?
20:48 masak https://rt.perl.org/Ticket/Display.html?id=125216
20:48 masak though I may have a solution in pure Perl 6, so I'm asking mostly out of interest.
20:49 cygx what about <TimToady> eqv and === on floaters should probably just compare chunks of memory
20:49 masak that aligns with what I want to do.
20:49 masak there's still the small issue of translating it into actual implementation.
20:49 masak (also see nwc10++'s later warning)
20:51 cygx masak: I don't think MoarVM supports long double, so not an issue
20:51 cygx IIRC, the x86 MS CRT dropped support for them altogether
20:52 cygx *x64
20:54 dalek MoarVM/jit_throw_ops_2: fc28f88 | timotimo++ | src/ (3 files):
20:54 dalek MoarVM/jit_throw_ops_2: jit throw[cat]{dyn,lex,lexotic}
20:54 dalek MoarVM/jit_throw_ops_2:
20:54 dalek MoarVM/jit_throw_ops_2: currently hangs execution.
20:54 dalek MoarVM/jit_throw_ops_2: review: https://github.com/MoarVM/MoarVM/commit/fc28f88392
20:54 cygx or more precisely: they dropped support for the x87 stack in favour of SSE and map long double to double
20:54 brrt very rebase
20:54 brrt as rightly they should cygx
20:55 dalek joined #moarvm
20:56 cygx brrt: it's not as clear cut - there are users who relied on that extra precision...
20:56 brrt timotimo: do you know anything we want to do before we merge jit_throw_ops_2
20:56 brrt always users and their requirements :-P
20:56 timotimo dunno
20:56 timotimo i think it's all right
20:56 brrt although i'd think sse could do 128bit?
20:59 brrt i'm kind of reluctant to merge because i'm not *quite* ready to deal with any fallout this night
20:59 vendethiel joined #moarvm
21:00 timotimo k
21:01 timotimo i totally forgot to start on the blogpost!
21:01 timotimo glad it's not yet 3am :)
21:01 timotimo though i feel sufficiently tired already
21:04 cygx brrt: doesn't SSE just do vector operation, ie no extended precision?
21:05 brrt hmm, wikipedia says you're right
21:08 brrt anyway, i'm off for tonight
21:08 brrt \o
21:08 brrt left #moarvm
21:08 brrt joined #moarvm
21:47 cygx left #moarvm
22:26 ggoebel joined #moarvm
22:42 colomon joined #moarvm
23:19 timotimo oh, you didn't post on your blog about the grant application yet
23:20 timotimo i was about to check if it's beginning, middle or end of this month (or was it next month?) when you'll start on the grant work
23:20 timotimo so it could go into the weekly
23:20 timotimo oh well, it'll be fine regardless

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary