[02:04] *** colomon joined [06:43] *** FROGGS joined [06:48] *** Ven joined [07:29] *** vendethiel joined [08:12] *** zakharyas joined [09:04] *** FROGGS joined [09:49] *** hoelzro joined [10:29] *** Ven joined [11:38] *** dalek joined [14:14] *** FROGGS[mobile] joined [14:19] *** Ven joined [17:53] *** brrt joined [17:57] *** brrt joined [18:24] \o [18:30] p/ [18:30] ooh, off by one [18:43] :-P [18:51] *** vendethiel- joined [19:02] jnthn: http://paste.scsys.co.uk/472570 -- livelocked at 400% CPU [19:03] no idea if it's "Real" (ie portable) or a Power64 bug [19:03] killed it because I wanted to do other things [19:04] 170440 grondilu │ m: (my %fifth){$_}++ for ^250 X** 5; say first { %fifth{[+] @$_ X** 5} }, combinations(250, 4); [19:04] oops [19:04] didn't mean to triple-click [19:05] three-finger-click, i mean [19:14] nwc10: What were you actually running to get that? [19:15] spectest [19:15] but, sorry, don't know which [19:15] ah, ok, so there possibly were threads running. [19:16] I infer 4 threads [19:17] I believe that my pushed MoarVM stuff is good. [19:17] certainly, the first commit that removes the v13 serialisation code is good for review [19:17] but you're welcome to defer that until $future [19:20] Just in the master branch I should be looking? [19:20] yes. [19:20] the other branches were useful places to stash logging code [19:20] should be obvious that the head of each is writing stuff to /tmp [19:21] and has nastly Linux assumptions [19:21] not even portable to real Unix :-) [19:21] Wow, 14 commits [19:21] muhaahahaha [19:22] you didn't see all the rebasing and amending :-) [19:30] "code" of the version you see has just finished spectst on Power64 [19:31] technically not the exact commit, as I force pushed one with another C comment [19:31] (you now see the current correct version) [19:33] it *can't* be PEBKAC because I'm not sitting on a chair [19:36] MoarVM: d49f634 | nicholas++ | src/6model/serialization.c: [19:36] MoarVM: Bump the minimum serialization format version. [19:36] MoarVM: [19:36] MoarVM: Following the recent NQP reboostrap, we can get rid of the code that supports [19:36] MoarVM: the old varint format, and the 2 byte reference discriminator. [19:36] MoarVM: [19:36] MoarVM: Remove read_int16(), which has been unused since commit 4f556793c7db5ce5, when [19:36] MoarVM: the discriminator to 1 byte. [19:36] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d49f634384 [19:37] <[Coke]> it what now? [19:37] Problem Exists Between Kryptograms And Coke [19:38] <[Coke]> Coke has a lot of problems this week. [19:38] (actually, Keyboard And Chair :)) [19:42] nwc10: In 5a2295e5b612c, why the re-ordering? [19:42] (As in, why is /* Make objects table entry. */ code moved downwards?) [19:42] It looks harmless to re-order [19:42] But also not especially important [19:43] I wanted to get the two things I was going to keep into their final location [19:43] oh wait. [19:43] that one [19:43] Yeah, the next patch explains it. [19:43] to be *sure* that it didn't matter that those calls to write_int32() wer edone at that point [19:44] (sorry, explanation was getting confused with something else where I re-ordered) [19:44] for that one, wanted to be sure that I wasn't tripping up over something strange [19:44] because the final code ends up writing data into two different sections of the under construction thing [19:44] *nod* [19:45] Yeah, I see now where you were heading. [19:45] to "somewhere else" but very carefully, using lots of small steps :-) [19:46] (and a whole bunch of backtracking when I got something wrong. [19:46] it's very easy to get it wrong) [20:07] MoarVM: c20c6d6 | nicholas++ | src/6model/serialization.c: [20:07] MoarVM: Extract code to get the STable for an object into read_object_table_entry(). [20:07] MoarVM: [20:07] MoarVM: This is the first step towards halving the size of the object table. [20:07] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c20c6d6bef [20:07] Look out dalek... [20:07] I have compared the output from dumbbench and from cachegrind [20:08] I can't actually work out what effect it has [20:08] I refs are up [20:08] D refs are up [20:08] LL refs are down slightly [20:08] *** dalek joined [20:08] LL misses down slightly [20:08] D1 misses IIRC up slightly [20:08] or was it I1 misses up slightly [20:08] That one was through to 49eefcf, fwiw [20:08] I'm guessing it's a bit more bit-fiddling, but less data.. [20:09] which IIRC you'rd looked at before [20:09] (the path to that commit) [20:09] yes, more bit fiddling [20:10] Wow, we get to under 9MB with the rest. [20:10] but I'm not sure why some of the other cachegrind numbers bounce (by very small amounts) in the direction that they do [20:10] yes. :-) [20:11] that would be a good thing? [20:12] Well, it's getting it down to a single digit which is nice :) [20:12] we store a lot of references to objects [20:12] It did occur to me that it's beneath a headline (badness) threshold [20:12] you can't now berate it for being double-digit fat [20:12] (well, until someone cranks up the amount of built-in awesome in the setting) [20:14] A fully loaded NQP including setting, having run "hello world" at the REPL, now is under 10MB of private memory. [20:14] oh OK. I had no idea that that was something to measure [20:15] It's not an especially important one, but I look at it now and then [20:15] this is because all the files are read into memory, and as they're now a bit smaller, the process size is a bit smaller [20:15] ? [20:16] Yeah [20:16] One notable thing about that number though [20:16] If you write "hello world" in Java and run it on the JVM, it uses *more* memory :) [20:17] And that's not even including the fact that NQP pulls the *compiler* into memory. [20:17] Meaning the JVM should have an unfair advantage there :) [20:17] that's why the JVM is so suited for embedded devices [20:17] er, not. [20:18] anyway, yes. that's a really nice comparison. [20:19] Not to mention NQP startup time wins :) [20:19] actually, that reminds me of a use case [20:19] if it's possible to create a good enough fakecutable [20:19] such that it's a "one file" distribution [20:20] then it probably gets a foothold as a sysadmin preferred tool [20:20] *** vendethiel joined [20:20] because there are (understandable) grumbles that Perl 5 wants to dynamically load bits of the core library at runtime [20:20] which fails if you're in a chroot [20:21] and so on, for all the other reasons that your files aren't on disk where you expect them to be [20:21] so, Perl 5/Python/Ruby/whatever (I assume) end up being programmed "in the core" without any 3rd party libraries [20:21] that is one nice thing that node.js does [20:21] Perl 6 has a bunch more for fre ein the core. [20:21] free in the core [20:22] perl6-m is 11.7MB private when you open the REPL, but jumps to 60MB after loading CORE.setting. Some work to go. :) [20:23] it's not clear to me whether any structural changes at the MoarVM level might even exist that would make any significant dent inthat [20:23] Lazy deserialization helped a bit. [20:23] So did tuning spesh thresholds. [20:25] however lazy deserialization means [20:26] a) you can't unmap (or otherwise release/free) the bytecode file [20:26] b) you can't even losslessly compress the serialization blob (as a single stream) because it needs random access [20:26] so two obious routes for doing a bit more are out [20:27] Well, if our CORE.setting loading touched less sutff, we'd get a bunch more benefit out of the lazy too. [20:27] (Lazy deserialization is clearly a bigger win than either of those two) [20:27] Aye [20:27] or both of those two put together [20:27] And unmap is very much a perception win rather than an actual one, I guess. As soon as you have two perl6-m's running, then you only pay for it in memory in one place. [20:28] yes. true. [20:29] Incoming... [20:29] MoarVM: 2d15acc | nicholas++ | src/6model/serialization.c: [20:29] MoarVM: Extract code that reads SC ID,index pairs into read_locate_sc_and_index(). [20:29] MoarVM: [20:29] MoarVM: This will make it easier to change the serialization representation for [20:29] MoarVM: ID,index pairs in more places in the data stream. [20:29] Oh noahs... [20:30] *** dalek joined [20:30] was it something I said? :-) [20:31] jnthn++ # sanity checking my insanity [20:33] this will give timotimo some content for the next weekly [20:33] :) [20:34] I plan to produce him some more tomorrow also :) [20:34] 20% down, I *think* [20:36] \o/ [20:36] nwc10++ [20:49] <[Coke]> nwc10: so is this easier than hacking on p5? [20:49] * PerlJam bets "yes" [20:51] it has fewer surprising consequences [20:51] however, it doesn't directly get us nearer to Christmas [20:58] Sleep time...NFG hackin' tomorrow :) & [21:03] jnthn: sleep well! [21:10] nwc10: It makes Christmas moar better. :-) [21:19] and after-christmas t oo [21:49] *** pyrimidi_ joined [22:03] *** lizmat joined [22:07] *** vendethiel joined [23:07] *** JimmyZ joined [23:14] nwc10, jnthn: i appreciate content for the weekly ;) [23:14] so ... 20% of what went down? number of cpu instructions during startup or the size of the core setting? [23:14] or perhaps even the ram usage of an almost empty perl6 script? [23:34] *** perlpilot joined [23:34] *** sivoais_ joined [23:40] *** ShimmerFairy joined [23:57] looking at the full commit messages tells me it's about file size [23:57] that's pretty damn good! :)