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

Powered by Cro and the Raku® Programming Language.

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

Thank you!