[00:02] *** dalek joined [00:29] *** stmuk joined [00:35] *** stmuk_ joined [00:40] *** stmuk joined [00:48] *** stmuk_ joined [00:49] * japhb is finally catching up with the last couple weeks of patches [00:49] This looks bogus: #define MVM_ALIGN_SECTION(offset) ((offset) + (offset) % ALIGNOF(MVMint64)) [00:49] What if offset is, say, 3? [00:50] Unless I'm just really too tired, that gives 6, rather than 8, which I think is the intent. [00:50] * timotimo implements some more random functions for the jit [00:57] *** stmuk joined [01:28] it's frustrating to implement some ops in the jit only to find out that it causes a single frame across the whole rakudo build to be successfully compiled where it used to fail [01:28] all others now stumble over another unimplemented op [01:29] timotimo: Thankfully, there's only a finite number of ops .... [01:30] yeah [01:30] the thing is, only some of them can be translated into just a C function call. others have either a check for concreteness in front or are some simple getter that i'd have to write custom asm for [01:31] like captureposelems checks the right REPRID and throws if it's not right [01:34] Nodnod [01:34] Time was that I could have freehanded that asm for you, but I haven't been actively using that skill in far too long. [01:45] :) [01:45] i can cargocult sufficiently [01:46] https://gist.github.com/timo/3cdb32fb36d66229c58d/revisions - see what i mean? :) [01:52] just implemented gethllsym, that was very easy indeed [01:52] update to the gist will be in ... half a minute [01:53] yay [01:53] that was worth 9 frames. neat. [01:53] Little by little .... [01:53] yeah [01:53] i've done this dance already ... a long long time ago [01:54] when the JIT was still fresh and new [02:02] some parametric type ops implemented ... [02:05] huh! something's different now [02:06] all the numbers have changed [02:06] this is no good [02:07] also, gist doesn't let you kill revisions without going through a local clone [02:18] aaaaand captureposprimspec [02:21] as expected, 100% of those immediately turned into bails for captureposarg ... [02:23] and i bet when i implement captureposarg, it'll immediately want captureposarg_i, captureposarg_n and captureposarg_s ... [02:23] what a goose chase. [02:28] very dalek [02:28] * timotimo waves [02:29] well, dalek didn't get it [02:30] MoarVM: 77c84d5 | timotimo++ | src/ (3 files): [02:30] MoarVM: add reprconv for attribute inited and jit attrinited [02:30] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/77c84d5474 [02:30] MoarVM: ac3e0c3 | timotimo++ | src/ (3 files): [02:30] MoarVM: jit captureposprimspec [02:31] *** dalek joined [02:34] poor dalek [02:34] now i don't actually know how to do an unconditional branch to a label [02:35] jmp ->var_name does an unconditional branch to a memory position [02:35] oh, jmp does that, too [02:35] ok [02:45] ah, finally! [02:45] 51 bails kicked out [02:45] (potentially only one frame that's run by every invocation, but whatever.) [02:45] MoarVM: 3e7667b | timotimo++ | src/jit/ (2 files): [02:45] MoarVM: jit objprimbits for great justice. [02:45] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3e7667b73b [02:45] well, the file now has 63 lines where it used to have 67 [02:45] work has certainly been done. [02:47] *** ilbot3 joined [03:02] *** vendethiel joined [04:40] *** Guest1337 joined [04:59] Hi! Don't know where to report this, so here it goes: loop { 1+1;} - doesn't eat all memory, but [05:00] "watchdir".IO.watch; loop { 1+1;}; - totally does [05:01] Linux, rakudo-star, nqp and MoarVM version 2015.11 with JIT [05:03] Guest1337: see http://rakudo.org/tickets/ [05:04] I'd like someone to confirm it first [05:05] Guest1337: yes, it eats all memory here too. [06:46] *** domidumont joined [06:52] *** domidumont joined [07:18] *** FROGGS joined [07:29] *** stmuk joined [07:59] *** domidumont joined [08:11] *** virtualsue joined [08:37] *** brrt joined [08:43] MoarVM: 975be18 | brrt++ | src/jit/emit_x64.dasc: [08:43] MoarVM: Fold movzx into the load [08:43] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/975be18b8c [08:45] timotimo++ for great JIT work [08:46] timotimo: (whenever he's awake or backlogs): jmp ->foobar means jump to assm-global label foobar [08:46] like jmp =>(foobar) means jump to asm-dynamically-allocated label with number foobar [08:47] and jump >1 means 'jump to the next entry of local label >1' [08:47] jmp varname would jump to the memory location indexed by varname, but because dynasm takes 32 bit arguments, that won't work properly on x64 [09:03] *** zakharyas joined [09:13] *** brrt joined [09:23] japhb: you are entirely correct, thinko on my part [09:33] due to insufficient lunch? [09:38] *** domidumont joined [09:43] due to insufficient brane [09:43] * ilmari steals https://stackoverflow.com/questions/13122846/align-macro-kernel [09:44] * ilmari never thinks of bitmasking [10:02] * jnthn apparently had insufficient brane last night too... [10:03] Just disocvered I released unsinged registers into the signed registers pool...boy did that confuse the assembler :) [10:04] also... working with smaller-sized things in the JIT, well, that's something we'll be able to handle cleanly in even-moar-jit, but probably not today [10:05] Yeah [10:05] Well, I'm figuring that tree matching will let us do nice things [10:05] i've already implemented casting, but i don't have the float/int distinction coded in yet [10:06] casting as in, fixing size differences, because yes, that already caused problems [10:06] my int16 $i = ...; my uint32 $j = $i; # an extend_u16, coerce_iu, and trunc_i32 [10:07] oops [10:07] my int16 $i = ...; my uint32 $j = $i; # an extend_i16, coerce_iu, and trunc_u32 [10:07] *** domidumont joined [10:07] :) [10:07] I wrote it right the first time then wronged it... [10:31] MoarVM: a4cdfb6 | jnthn++ | / (6 files): [10:31] MoarVM: Coercion between num and unsinged int. [10:31] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a4cdfb64c1 [10:36] *** rurban_ joined [10:36] moar.obj : error LNK2001: unresolved external symbol snprintf [10:41] MoarVM: 466a616 | jnthn++ | src/moar.c: [10:41] MoarVM: Fix MSVC build. [10:41] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/466a616f90 [10:49] MoarVM: a49499a | jnthn++ | src/6model/reprs/P6int. (2 files): [10:49] MoarVM: Support boxing unsigneds in P6int REPR. [10:49] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a49499a542 [11:01] *** TimToady joined [11:10] *** virtualsue joined [11:59] MoarVM: 55222ed | jnthn++ | src/core/bytecodedump.c: [11:59] MoarVM: Fix dumping of unsinged register types. [11:59] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/55222edf0d [11:59] MoarVM: d8a3fa8 | jnthn++ | src/core/interp.c: [11:59] MoarVM: Fix thinkos in some coercion ops. [11:59] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d8a3fa8f48 [12:00] gah, typo again [12:12] https://github.com/MoarVM/MoarVM/pull/316 # fix for the alignment macro [12:12] japhb++ [12:25] .oO( jnthn can't stop singing :-) [12:26] m: my uint32 $a = 2**31; say $a + 1 [12:26] rakudo-moar d8f7e8: OUTPUT«-2147483647␤» [12:26] 2147483649 locally :) [12:29] MoarVM: 6b02fca | (Dagfinn Ilmari Mannsåker)++ | src/ (3 files): [12:29] MoarVM: Fix alignment macro definition [12:29] MoarVM: [12:29] MoarVM: Also consistently use MVMuint32 for the size and offset values. [12:29] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6b02fca263 [12:29] MoarVM: 4ab9121 | jnthn++ | src/ (3 files): [12:29] MoarVM: Merge pull request #316 from ilmari/fix-alignment [12:29] MoarVM: [12:29] MoarVM: Fix alignment macro definition [12:29] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4ab912119b [12:48] *** virtualsue joined [12:51] *** virtualsue_ joined [13:02] *** zakharyas joined [13:39] m: my uint32 $a = 2**31; say $a [13:39] rakudo-moar 2a2e9a: OUTPUT«-2147483648␤» [13:39] m: my uint32 $a = 2**31; say $a.Str [13:39] rakudo-moar 2a2e9a: OUTPUT«-2147483648␤» [13:43] MoarVM: 53e0a9a | jnthn++ | src/core/ext.c: [13:43] MoarVM: Recognize unsigned extop operands. [13:43] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/53e0a9a409 [13:43] MoarVM: 4e178ce | jnthn++ | / (8 files): [13:43] MoarVM: Add a (somewhat cheating) cheating decont_u. [13:43] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4e178cee8b [13:43] MoarVM: cc142d6 | jnthn++ | src/ (3 files): [13:43] MoarVM: Merge branch 'master' of github.com:MoarVM/MoarVM [13:43] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cc142d6f60 [13:43] MoarVM: c1f5abf | jnthn++ | / (7 files): [13:43] MoarVM: Cheating native ref ops for unsigneds. [13:43] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c1f5abf04f [13:43] oops [13:43] * jnthn spot that merge commit sneak in [13:43] *didn't [13:48] *** zakharyas joined [14:16] jnthn: can you explain readlineint_fh to me? [14:18] It was the op you used to do readline interactive, before we took linenoise support out of core [14:18] its implementaiton in inter.pc is ... empty :) [14:18] oh, i see [14:18] It shoudln't be used any more [14:18] yeah, that makes sense [14:20] MoarVM: cde6009 | jnthn++ | / (8 files): [14:20] MoarVM: Somewhat cheating unsinged parameter ops. [14:20] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cde6009be7 [14:21] * jnthn is popping these in to make stuff mostly work (which is a big step up from now) [14:21] i'm amazed that we're getting unsigned ints before butterflymas [14:21] (henceforth to be known as ymas) [14:21] Well, the cat was already out of the bag in some senses [14:22] Folks were using them in nativecall bindings [14:22] right [14:22] So I didn't really want to make them experimental [14:22] and getting confused about things [14:22] yeah [14:22] We'll have some rough edges [14:22] Mostly around uint64 [14:22] how about in native arrays? [14:22] i don't think there's anything in there yet? [14:22] They were already righter in there than in many places [14:23] But still the 64-bit edge case [14:23] We can clean those up after xmas too, I think [14:25] OK [14:26] - 7 BAIL: op [14:26] pure win \o/ [14:27] MoarVM: f3812e0 | timotimo++ | src/jit/graph.c: [14:27] MoarVM: jit say_fhs for free. [14:27] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f3812e0d22 [14:27] now the output of the command that generates my little summary fits on one screen [14:30] scgetobjidx is so popular on that list, i think i'll just write it quickly as a C function and see where that leads [14:31] i wonder if i should write little comments before the functions i've just introduced for the benefit of the jit [14:31] so that later when th exprtreejit has them "in-lined" we can just throw them out if they've not been adopted anywhere else [14:32] MoarVM: 7545aa9 | jnthn++ | src/core/bytecode.c: [14:32] MoarVM: Fix extop validation to accept unsigned operands. [14:32] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7545aa90f1 [14:32] Probably would be wise [14:34] MoarVM: af4c222 | timotimo++ | src/6model/reprs/MVMCallCapture.c: [14:34] MoarVM: point out capture_pos_primspec as a "jit-only" function [14:34] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/af4c222a89 [14:34] though i think repr_attribute_inited is also sort of interesting for reprconv in general [14:37] jnthn: does fopen_perhaps_with_pid look sane to you? i've put a bit of extra care in to make sure it isn't that easy to break [14:40] shopping, will look when I get back :) [14:41] sure, good luck! ;) [14:55] *** patrickz joined [14:59] wow, that was a "pure win" again [14:59] 75 bails gone [14:59] (though since that's combined from all of "make install" of rakudo, it may just be one frame or two frames that show up in every invocation) [15:00] arg_o could be worth a whole lot. [15:03] arg_o? I thought that was covered by invocation sequences...odd [15:03] Shopping was easy; I only needed red onions :) [15:12] oh, hmm. [15:12] may be something to ask brrt about [15:12] ah [15:12] it's supposed to [15:13] let's see. it's triggered by "prepargs" [15:14] seems like we end up without a prepargs sometimes? [15:26] oh [15:27] seems like somehow a guardconc + set + getspeshslot slipped in there?! but it also says there's an invoke_o before that, so ... huh?!? [15:30] i see the prepargs in the spesh dump, but it doesn't seem to exist any more by the time the jit hits it [15:30] o__O [15:32] i invoke the magical brrt. halp! [15:35] AHA! [15:35] looked at the first of two "Finished" outputs [15:35] in the seconde one the prepargs is missing [15:39] er ... not only the prepargs is gone, but also the invoke! [15:39] so there's probably something in there that takes care to remove a prepargs if an invoke disappears, but the args in between don't get kicked out perhaps? [15:41] except invoke isn't pure, so ... [15:41] oh, of course. it's inlined! [15:42] MoarVM: ae8f391 | jnthn++ | src/6model/reprs/P6bigint.c: [15:42] MoarVM: Fix size test to avoid corrupting big uints. [15:42] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ae8f391692 [15:44] looks a bit like if there's a mismatch between number of arg_* and getarg_* calls, arg_* ops get left in the dust [15:44] that looks easily fixable [15:59] MoarVM: c091b48 | timotimo++ | src/spesh/inline.c: [15:59] MoarVM: spesh inline: kick out remaining unused arg_*/argconst_* ops [15:59] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c091b48f77 [15:59] MoarVM: 3638da6 | timotimo++ | src/ (3 files): [15:59] MoarVM: jit scgetobjidx (via a _jit C function) [15:59] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3638da6be9 [15:59] since this also includes decreasing usage numbers for args, it could lead to more efficient bytecode, too. [16:00] and 170 bails across the rakudo compilation are gone, too. [16:00] (it looked like fresh_register was mainly afflicted) [16:18] i sure hope my many jit changes didn't actually break something ... i didn't actually spec test :| [16:19] *** virtualsue joined [16:20] *sigh* [16:20] Please always do it [16:20] I bump revisions on the assumption people will at least do that. [16:26] will do [16:26] thing is, spectests are damn dirty these days [16:27] and not reliably so [16:29] Yes, but they can still catch epic fail [16:30] should i be staying away from latest nqp for the spec test? or is the sizedness/unsignedness thing stable now? [16:31] Stable [16:31] I bumped Rakudo to use latest NQP also [16:32] understood [16:32] seeing lots of "ok" at least [16:36] *** virtualsue_ joined [16:41] *** zakharyas joined [16:43] i only get very few spec test failures [17:12] o/ #moarvm [17:12] \o [17:12] ilmari: did you get far with your moardump experiment? [17:12] hoelzro: I managed to get git to use it when diffing moarvm files [17:13] oh, nice [17:13] echo '*.moarvm diff=moarvm' >> .git/info/attributes [17:13] (echo '[diff "moarvm"]'; echo ' textconv = moardump') >> .git/config [17:14] (echo '#!/bin/sh'; echo 'exec moar --dump "$@"') >> ~/bin/moardump [17:14] chmod +x ~/bin/moardump [17:17] git log -p src/vm/moar/stage0/ [17:19] timotimo, jnthn: the function for allocation info (on glibc) is called mallinfo [17:19] (in the nqp repo) [17:19] ilmari: nice, I'll have to try that out [17:20] fwiw mallinfo is also part of System V (Solaris) malloc although the details are likely different [17:20] we could always track this information in MVM_alloc itself [17:21] I have patches for adding mallinfo to MoarVM here, if anyone's curious: https://rt.perl.org/Ticket/Display.html?id=126183 [17:25] or use something like Dtrace ? [17:26] for memory tracking? I didn't know dtrace could do that! [17:26] dtrace + lttng support would be nice [17:26] yes [17:26] or systemtap, or ktap [17:27] I don't know systemtap or ktap; do they have a userspace probe facility? [17:27] yes [17:28] well, systemtap is not easy on debian/ubuntu, you may want to try ktap if you are on these . [17:28] but it is easy to use on redhat [17:29] hoelzro: and you will like https://github.com/brendangregg/FlameGraph [17:30] hoelzro: http://www.brendangregg.com/FlameGraphs/memoryflamegraphs.html [17:31] coooool [17:33] what is lttng? [17:38] a linux tracer kind of like dtrace [17:38] I played with it a bit a little while ago, it's pretty cool [17:39] the above link is very good for memory leaks :) [17:43] ah [18:23] *** FROGGS joined [18:35] *** virtualsue joined [20:28] MoarVM: f8fe345 | FROGGS++ | / (4 files): [20:28] MoarVM: better check for _Bool to unbust newer MSVC [20:28] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f8fe3450fa [21:41] * diakopter applauds jnthn (& co.) for having extreme patience to do things *the right way* for long term optimizability [21:42] (with some leeway for immediate usability!) [21:42] (also, TimToady, of course) [21:42] (& co.) [21:43] * jnthn is rather looking forward to working on optimization in the new year [21:43] * diakopter is rather looking forward to building a proof engineering environment on top of Perl 6 [21:44] Wow :) [21:45] Getting to watch other people build stuff in Perl 6 is one of the best things about working on Perl 6 :) [21:46] well, we'll see if the long shot pans out [21:54] .oO( or Peters out.. ) [21:54] .oO( or Peter Pans... ) [22:07] or Peter Parkers out although that could get a bit webbly [22:37] jnthn: do you have a clear idea of what exactly makes moar with --profile and more than one thread explodey? [22:38] timotimo: Not sure about explodey, aside from maybe it fails to set up profilign data sturctures on the new threads [22:38] if that's the case, it could be easy enough to make it at least not crash [22:38] timotimo: But I didn't do anything about collecting the data from between the threads [22:39] The profiler is one of our various "jnthn half-wrote something neat in 2 days and hoped somebody would be inspired to do the rest" ;) [22:39] um [22:39] it doesn't actually explode? [22:39] Oh :) [22:39] Maybe it just ignores the data from other threads then :) [22:39] i suppose i need to find an explodey example then :) [22:40] i'm also not sure what things like the call graph would look like :D [22:40] and the overview [22:40] "yeah, we spent 300% of total time executing code and some 10% doing GC" [22:40] You'd have to have it per thread [22:40] yeah [22:41] (Not the whole profiler, but the call graph) [22:41] Of course, the *really* hard problem is profiling async code :) [22:41] Which migrates over threads :) [22:41] oh lord [22:41] yeah [22:41] i have absolutely no answer to that. [22:42] I mean, the call graphs could be merged, but you just have to be aware there's some cross-call-tree interactions going on [22:48] well, i was under the impression that profile on things using "start" would crash [22:49] that's not the case [22:49] that's quite good. [22:50] Well, I designed it so threads could collect data [22:50] In a thread-safe way [22:50] Just didn't wire any of the aggregation up [22:50] So I figured it'd not be anything too serious if it was explodey [22:51] i wonder what gave me the impression ... [22:52] I dunno, you profiled a thready thing that crashed for other reasons maybe :) [22:52] could be [22:53] 100% of people who confuse correlation with causation end up dying. [22:53] and some of them suffer a lingering death... [23:30] *** cognominal joined [23:50] *** flussence joined