Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-04-15

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

All times shown according to UTC.

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

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