Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-04-10

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

All times shown according to UTC.

Time Nick Message
01:48 colomon joined #moarvm
04:04 FROGGS_ joined #moarvm
05:39 lizmat joined #moarvm
05:39 nwc10 what do I need to copy/update to replace the stage0 bootstrap files?
05:40 nwc10 (Not that I'm about to send a patch for this. I want to test that it won't break when someone next really needs to do it)
06:56 Ven joined #moarvm
07:06 lizmat joined #moarvm
07:14 FROGGS joined #moarvm
07:32 brrt joined #moarvm
07:34 brrt nwc10 - iirc you copy the stage2 output from nqp to the stage0 dir
07:35 FROGGS nwc10: make m-bootstrap-files or so
07:40 nwc10 FROGGS: I don't see that target anywhere in the Makefile
07:41 FROGGS nwc10: you are talking about nqp@moar, right?
07:41 nwc10 FROGGS: Well spotted. The problem was between the keyboard and the chair
07:41 FROGGS :o)
07:42 * FROGGS submits nickbug
07:43 lizmat joined #moarvm
08:04 zakharyas joined #moarvm
08:09 nwc10 If I look at the profiles for ./perl6-m -e 1
08:09 nwc10 I see stuff from a GC run (And top)
08:10 timotimo hum? top?
08:10 nwc10 oh, on "called"
08:10 nwc10 not on time I think
08:11 nwc10 yes, Problem continues to exist between keyboard  and chair
08:11 nwc10 anyway, the question is, is that GC run avoidable?
08:11 nwc10 (ie can/should we tweak some sizes to defer the pain until after minimal startup)
08:11 nwc10 or is that a daft idea for subtle reasons?
08:14 timotimo IIRC we made the nursery size as big as the l3 cache for a Good Reason™
08:15 nwc10 that's probably the answer that I was missing
08:15 jnthn We should avoid the GC run by allocating less objects at startup.
08:15 timotimo or by making the objects we allocate smaller
08:16 nwc10 <masak>fewer</masak><ducks/>
08:16 jnthn Note that all the deserialized stuff goes directly into gen2
08:16 timotimo though that's not necessarily still possible for all of them
08:16 jnthn So we're talking about the work that CORE.setting does in its mainline.
08:17 timotimo and all the things the parser and compiler do before and after the given program
08:17 timotimo i wanted to call that "boilerplate", but that's not quite fitting
08:17 lizmat joined #moarvm
08:17 jnthn True, though for a small program that ain't loads.
08:19 nwc10 jnthn: OK, I was wondering that - is this runtime work? And all runtime work that can be avoided is faster startup
08:19 jnthn I'd hope that it can be avoided, yes.
08:19 timotimo nwc10: since a not so long time we also do a json parse at startup for the CompUnitRepo
08:19 jnthn Mostly, at least.
08:20 timotimo JSON::Fast does less gc than JSON::Tiny, so there's a start
08:20 timotimo but it could be loads better
08:20 nwc10 that's at "-e1" sort of startup?
08:21 timotimo that's how i understood it
08:21 timotimo i thought it could be deferred by a well-placed //=, but i haven't looked into it yet
08:21 nwc10 ah OK
08:21 jnthn Still didn't backlog yet fully on #perl6; did JSON::Fast get used already?
08:21 nwc10 this might sound daft (but all benchmarks and stats are, to some degree)
08:22 timotimo no, JSON::Fast has no users yet, but its interface is a drop-in replacement for JSON::Tiny
08:22 nwc10 but I think that perl6 -e0 time matters (if we can reduce it without predudicing other things)
08:22 jnthn I'm surprised we need to read the JSON until somebody does a "use" or "need" fwiw.
08:22 nwc10 because it's something people will try, and it's an immediate first impresison
08:22 nwc10 jnthn: that was my thought
08:22 nwc10 actually, strictly, I think it's "command line hello world" that probably matters
08:22 jnthn Given how much is built in to Perl 6 anyway, plenty of one-liners and simple scripts and REPL sessions will never need to load a module.
08:22 nwc10 which needs a bit more parsing
08:23 jnthn Parsing hellow world doens't use a module.
08:23 nwc10 good. that was my assumption
08:23 nwc10 so it feels like a somewhat reasonable benchmark
08:23 timotimo FWIW, the json parse isn't a meant-to-stay solution anyway
08:23 nwc10 I might have a branch that reduces it by about 1% CPU
08:24 lizmat jnthn: I *tried* many times to defer the initialization of @*INC
08:24 lizmat it always seems to break panda, though
08:24 nwc10 sad panda not good
08:24 lizmat last time I tried it, it took bare startup time from 0.15 to 0.1 on my machine
08:24 nwc10 OK, 0.75%
08:25 nwc10 will that do?
08:25 jnthn lizmat: Hm, I'd been thinking more that the CUR inside @*INC would not load the database until it had to.
08:25 lizmat I'm pretty sure it doesn't, but FROGGS would know for sure
08:25 * timotimo tries hacking that in
08:26 Ven joined #moarvm
08:26 lizmat the 0.05 is just for initializing @*INC and %*CUSTOM_LIB
08:26 jnthn lizmat: I'm pretty sure it must be givne people have been reporting increased startup time when they have lots of modules installed.
08:27 FROGGS look at Inc.pm
08:27 * jnthn sees in the bit of backlog he just got to that FROGGS++ is also working on getting rid of the JSON
08:27 lizmat the first time I tried was with d05d411e968b3408420bbc7b02c1248f3dc005de on Sep 8, 2014
08:28 lizmat that patch should basically still all that's needed
08:28 lizmat *be
08:28 jnthn my $abspath := "$prefix/share/libraries.json";
08:28 jnthn if IO::Path.new-from-absolute-path($abspath).e {
08:28 jnthn my $config = from-json( slurp $abspath );
08:28 jnthn Is that the from-json in question?
08:28 FROGGS no
08:28 timotimo it's in CompUnitRepo/Installation
08:29 timotimo inside BUILD
08:29 FROGGS aye
08:29 * FROGGS wasnt fast enuff
08:30 FROGGS instead of "from-json $manifest.slurp" I tried "$manifest.slurp.EVAL" bt that end up horrible
08:30 FROGGS probably because we precompile lib.pm which has it hands on @*INC
08:32 lizmat is there a simple way to re-apply a particular patch without committing immediately ?
08:32 FROGGS I dunno
08:33 jnthn git cherry-pick --no-commit sha1-here
08:33 lizmat jnthn++
08:34 jnthn If you want to try a revert without committing, exact same trick works, fwiw. :)
08:35 FROGGS lizmat: can you reboostrap panda and install a random module as a sanity test?
08:37 lizmat doing that just now  :-)
08:38 lizmat hmmm...  different error now, lemme double check
08:39 lizmat wrong branch, rebuilding
08:44 jnthn lizmat: Backlogging #perl6 still, but making the exception behavior of however-we-spell-nqp::eqat-in-Perl-6 consistent with substr feels rihgt to me.
08:45 lizmat hmmm... getting Missing or wrong version of dependency 'src/gen/m-CORE.setting' (from 'lib/File/Find.pm') now  :-(
08:45 lizmat grrr... I have no tuits to figure that out now  :-(
08:46 FROGGS lizmat: can you push to a branch?
08:46 FROGGS then I'll take a look
08:46 lizmat git cherry-pick --no-commit d05d411e968b3408420bbc7b02c1248f3dc005de
08:46 nwc10 lizmat: if mberends is there, please say Hi!
08:46 lizmat should do the trick
08:46 FROGGS or that :o)
08:47 jnthn Ah yes, greetings to NLPW too. I'll try to make it next year. :)
08:47 lizmat mberends is here, will say hi (Tea minus 2)
08:48 timotimo say hi from me, too!
08:48 nwc10 thanks
08:48 nwc10 enjoy tea
08:48 nwc10 enjoy whisky later
08:48 nwc10 enjoy the excuse for gathering for tea, conversation, whisky and fluxx
08:49 timotimo with my changes i get "possible version skew detected" :\
08:50 FROGGS timotimo: changes to what? I did get the too yesterday
08:50 timotimo and without my change it works. great.
08:51 timotimo https://gist.github.com/timo/0856734414bc1a53fb7b
08:52 FROGGS ahh, I got that error when tring to .EVAL an empty MANIFEST in BUILD
08:52 * FROGGS likes to SHOUT today
08:52 timotimo let me make sure the manifest gets loaded properly
08:56 timotimo huh
08:56 * jnthn caught up backlogging just in time to make brunch :)
08:57 timotimo bon brunch, jnthn!
08:57 timotimo (or is that spelt "bonne"?)
08:58 nwc10 jnthn: I have baked you two "branches". They use 0.75% CPU in startup
08:58 nwc10 but you should eat first and review them carefully (please) because the changes to the varint serialisation code are a bit funky
08:58 timotimo there is *some* data ...
08:59 nwc10 (but have been tested on Power64 and Power32, including a reboostrap)
08:59 timotimo https://gist.github.com/timo/0856734414bc1a53fb7b#file-gistfile2-txt
08:59 nwc10 er, that's not correct
08:59 nwc10 they use 99.25% CPU in startup
08:59 nwc10 rather than 100% :-)
08:59 nwc10 this chair needs a new occupant
09:00 FROGGS hehe
09:00 timotimo FROGGS: i'm not 100% sure how the data is written back to disk, maybe that's the problem?
09:01 timotimo maybe write-back isn't triggering the data to actually be read or something?
09:01 FROGGS timotimo: in Installation.pm method install at the end
09:01 FROGGS writing back does not mean it gets re-read, correct
09:01 timotimo not re-read
09:02 FROGGS but since panda spawns a perl6 to to install stuff, it should not matter
09:02 timotimo just un-lazy'd
09:03 timotimo huh
09:03 timotimo the first "possible version skew" error happens in testing Shell::Command, where Shell::Command shouldn't even be in the MANIFEST yet
09:03 timotimo oh
09:04 timotimo but it's looking for File::Find anyway
09:05 timotimo well, the gist has an up to date diff, maybe you can look into it, as you know better what to expect at what stage of the process
09:06 FROGGS the installation process is quite hairy...
09:18 lizmat joined #moarvm
09:26 timotimo i'm out of ideas regarding this patch
09:33 FROGGS yeah, I gave up yesterday too
09:34 timotimo mhh
09:46 oetiker joined #moarvm
09:55 jnthn nwc10: Turns out we're going for walk/shopping now, so I'll look at the patches later on :)
09:55 * jnthn is having his "weekend" today/tomorrow, so Sunday will be the next big NF* hacking day :)
09:56 jnthn bbl
09:57 nwc10 have fun. No hurry
11:45 lizmat joined #moarvm
12:13 Ven joined #moarvm
12:14 raiph joined #moarvm
12:32 zakharyas joined #moarvm
13:01 lizmat joined #moarvm
13:15 Ven joined #moarvm
13:18 lizmat joined #moarvm
13:32 Ven_ joined #moarvm
14:04 lizmat joined #moarvm
14:15 brrt joined #moarvm
14:36 lizmat joined #moarvm
14:47 zakharyas joined #moarvm
15:41 nwc10 jnthn: historically, was there an assumption that the MoarVM "byte"code files needed to be 2 byte aligned (everywheere)
15:42 nwc10 hence all stuff in the serialisation blob had to be 2n bytes long?
15:42 nwc10 (obviously not true now there are varints)
15:48 Ven joined #moarvm
15:55 jnthn nwc10: For the bytecode segment and annotations segment I think it matters, for the serialization blob I don't think we're sensitive to that.
16:06 jnthn Hmm, what on earth...
16:07 jnthn I *think* "make test" on my laptop got a bunch slower...
16:07 jnthn NQP make test, that is.
16:07 jnthn oh duh duh duh...I have a --debug --no-optimize build of Moar. :)
16:32 nwc10 jnthn: if you use --asan regularly, then it's all wow superfast when you build --optimise
16:33 nwc10 it's a bit like walking for a day with a large rucksack, then taking it off in the evening
16:33 nwc10 instant diet!
18:00 FROGGS joined #moarvm
18:13 zakharyas joined #moarvm
18:45 synbot6 joined #moarvm
18:51 PerlJam joined #moarvm
20:53 vendethiel joined #moarvm
21:41 dalek MoarVM: 575c486 | FROGGS++ | src/core/coerce.c:
21:41 dalek MoarVM: tweak istrue_s, every non-empty string is true now
21:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/575c486e5e

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