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