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
brrt \o 18:24
nwc10 p/ 18:30
ooh, off by one
brrt :-P 18:43
18:51 vendethiel- joined
nwc10 jnthn: paste.scsys.co.uk/472570 -- livelocked at 400% CPU 19:02
no idea if it's "Real" (ie portable) or a Power64 bug 19:03
killed it because I wanted to do other things
timotimo 170440 grondilu │ m: (my %fifth){$_}++ for ^250 X** 5; say first { %fifth{[+] @$_ X** 5} }, combinations(250, 4); 19:04
oops
didn't mean to triple-click
three-finger-click, i mean 19:05
jnthn nwc10: What were you actually running to get that? 19:14
nwc10 spectest 19:15
but, sorry, don't know which
jnthn ah, ok, so there possibly were threads running.
nwc10 I infer 4 threads 19:16
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
but you're welcome to defer that until $future
jnthn Just in the master branch I should be looking? 19:20
nwc10 yes.
the other branches were useful places to stash logging code
should be obvious that the head of each is writing stuff to /tmp
and has nastly Linux assumptions 19:21
not even portable to real Unix :-)
jnthn Wow, 14 commits
nwc10 muhaahahaha
you didn't see all the rebasing and amending :-) 19:22
"code" of the version you see has just finished spectst on Power64 19:30
technically not the exact commit, as I force pushed one with another C comment 19:31
(you now see the current correct version)
it *can't* be PEBKAC because I'm not sitting on a chair 19:33
dalek arVM: d49f634 | nicholas++ | src/6model/serialization.c:
Bump the minimum serialization format version.

Following the recent NQP reboostrap, we can get rid of the code that supports the old varint format, and the 2 byte reference discriminator.
Remove read_int16(), which has been unused since commit 4f556793c7db5ce5, when the discriminator to 1 byte.
19:36
[Coke] it what now? 19:37
jnthn Problem Exists Between Kryptograms And Coke
[Coke] Coke has a lot of problems this week. 19:38
jnthn (actually, Keyboard And Chair :))
nwc10: In 5a2295e5b612c, why the re-ordering? 19:42
(As in, why is /* Make objects table entry. */ code moved downwards?)
It looks harmless to re-order
But also not especially important
nwc10 I wanted to get the two things I was going to keep into their final location 19:43
oh wait.
that one
jnthn Yeah, the next patch explains it.
nwc10 to be *sure* that it didn't matter that those calls to write_int32() wer edone at that point
(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
because the final code ends up writing data into two different sections of the under construction thing
jnthn *nod*
Yeah, I see now where you were heading. 19:45
nwc10 to "somewhere else" but very carefully, using lots of small steps :-)
(and a whole bunch of backtracking when I got something wrong. 19:46
it's very easy to get it wrong)
dalek arVM: c20c6d6 | nicholas++ | src/6model/serialization.c:
Extract code to get the STable for an object into read_object_table_entry().

This is the first step towards halving the size of the object table.
20:07
jnthn Look out dalek...
nwc10 I have compared the output from dumbbench and from cachegrind
I can't actually work out what effect it has 20:08
I refs are up
D refs are up
LL refs are down slightly
20:08 dalek joined
nwc10 LL misses down slightly 20:08
D1 misses IIRC up slightly
or was it I1 misses up slightly
jnthn That one was through to 49eefcf, fwiw
I'm guessing it's a bit more bit-fiddling, but less data..
nwc10 which IIRC you'rd looked at before 20:09
(the path to that commit)
yes, more bit fiddling
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
yes. :-)
that would be a good thing? 20:11
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
It did occur to me that it's beneath a headline (badness) threshold
you can't now berate it for being double-digit fat
(well, until someone cranks up the amount of built-in awesome in the setting)
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
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
?
jnthn Yeah 20:16
One notable thing about that number though
If you write "hello world" in Java and run it on the JVM, it uses *more* memory :)
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 :)
nwc10 that's why the JVM is so suited for embedded devices
er, not.
anyway, yes. that's a really nice comparison. 20:18
jnthn Not to mention NQP startup time wins :) 20:19
nwc10 actually, that reminds me of a use case
if it's possible to create a good enough fakecutable
such that it's a "one file" distribution
then it probably gets a foothold as a sysadmin preferred tool 20:20
20:20 vendethiel joined
nwc10 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
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
leedo that is one nice thing that node.js does
nwc10 Perl 6 has a bunch more for fre ein the core.
free in the core
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:22
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.
So did tuning spesh thresholds.
nwc10 however lazy deserialization means 20:25
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
so two obious routes for doing a bit more are out
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)
jnthn Aye
nwc10 or both of those two put together
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.
nwc10 yes. true. 20:28
jnthn Incoming... 20:29
dalek MoarVM: 2d15acc | nicholas++ | src/6model/serialization.c:
MoarVM: Extract code that reads SC ID,index pairs into read_locate_sc_and_index().
MoarVM:
MoarVM: This will make it easier to change the serialization representation for
MoarVM: ID,index pairs in more places in the data stream.
jnthn Oh noahs...
20:30 dalek joined
nwc10 was it something I said? :-) 20:30
jnthn++ # sanity checking my insanity 20:31
this will give timotimo some content for the next weekly 20:33
jnthn :)
I plan to produce him some more tomorrow also :) 20:34
nwc10 20% down, I *think*
jnthn \o/ 20:36
nwc10++
[Coke] nwc10: so is this easier than hacking on p5? 20:49
PerlJam bets "yes"
nwc10 it has fewer surprising consequences 20:51
however, it doesn't directly get us nearer to Christmas
jnthn Sleep time...NFG hackin' tomorrow :) & 20:58
PerlJam jnthn: sleep well! 21:03
japhb nwc10: It makes Christmas moar better. :-) 21:10
PerlJam and after-christmas t oo 21:19
21:49 pyrimidi_ joined 22:03 lizmat joined 22:07 vendethiel joined 23:07 JimmyZ joined
timotimo 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?
or perhaps even the ram usage of an almost empty perl6 script?
23:34 perlpilot joined, sivoais_ joined 23:40 ShimmerFairy joined
timotimo looking at the full commit messages tells me it's about file size 23:57
that's pretty damn good! :)