|
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! :) | |||