brrt \o 18:24
nwc10 p/ 18:30
ooh, off by one
brrt :-P 18:43
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
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
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...
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
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?
timotimo looking at the full commit messages tells me it's about file size 23:57
that's pretty damn good! :)

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!