lizmat Files=1239, Tests=76298, 317 wallclock secs (15.70 usr 5.32 sys + 2188.64 cusr 215.03 csys = 2424.69 CPU) 08:11
Zoffix Something wrong with hyper 12:27
c: 2018.03 (^∞).grep(*.is-prime)[1000].say; say now - ENTER now
committable6 Zoffix, ¦2018.03: «7927␤0.9982474␤»
Zoffix c: 2018.03 (^∞).hyper.grep(*.is-prime)[1000].say; say now - ENTER now
committable6 Zoffix, ¦2018.03: «7927␤0.6062973␤»
Zoffix ^ makes things faster on 2018.03
c: HEAD (^∞).grep(*.is-prime)[1000].say; say now - ENTER now
committable6 Zoffix, ¦HEAD(ceeb3a0): «7927␤1.0099107␤»
Zoffix c: HEAD (^∞).hyper.grep(*.is-prime)[1000].say; say now - ENTER now
committable6 Zoffix, ¦HEAD(ceeb3a0): ««timed out after 10 seconds» «exit signal = SIGHUP (1)»» 12:28
lizmat yuck :-(
Zoffix looks like it gets stuck or something... ohhh. Just crashed on my VM with "Type check failed in binding to parameter '$batch'; expected Rakudo::Internals::HyperWorkBatch but got Mu (Mu)" after 8 seconds
bisect: 2018.03,HEAD (^∞).hyper.grep(*.is-prime)[1000].say; say now - ENTER now 12:29
bisectable6 Zoffix, Using old=2018.03 new=HEAD in an attempt to DWIM
Zoffix, Bisecting by exit signal (old=2018.03 new=ceeb3a0). Old exit signal: 0 (None)
lizmat hmm... hangs for me
slowly eating memory at 370% CPU or so 12:30
bisectable6 Zoffix, bisect log: gist.github.com/6ab4c733c5b9078c55...94b4240bc4
Zoffix, (2018-03-20) github.com/rakudo/rakudo/commit/ec...ee886bbda8
Zoffix c: ec5416a9a33e582^1, ec5416a9a33e582 (^∞).hyper.grep(*.is-prime)[1000].say; say now - ENTER now
committable6 Zoffix, ¦ec5416a9a33e582^1: «7927␤0.5638864␤» ¦ec5416a: ««timed out after 10 seconds» «exit signal = SIGHUP (1)»»
lizmat m: (^∞).hyper.grep(*.is-prime).skip(1000).head.say; say now - ENTER now 12:31
camelia 7927
0.5274076
lizmat so looks like it's the positional handling that's the cause
[1000] I mean
m: (^∞).hyper.grep(*.is-prime).AT-POS(1000).say; say now - ENTER now # also hangs for me 12:32
jnthn nqp::clone(nqp::setelems($!current-items,$topush))
camelia (signal XCPU)
jnthn Is that really right in the patch?
At a first glance it looks like we want to mutate the thing that was cloned, not the original
Zoffix No idea, but setting it to nqp::setelems(nqp::clone($!current-items),$topush) doesn't fix the hang 12:36
lizmat the idea was that we have a local IterationBuffer that we nqp::splice onto the one we already have
perhaps we need to move the nqp::clone into IterationBuffer.append 12:37
lizmat tries
Zoffix Filed as R#1740 12:39
synopsebot R#1740 [open]: github.com/rakudo/rakudo/issues/1740 [ASYNC][⚠ blocker ⚠] .hyper.grep appears to hang
Zoffix This bug is blocking my Perl 6 **flyer** lol :P
Wonder if the fix would also fix R#1709 12:40
lizmat well, perhaps use .skip(1000).head ? :-)
synopsebot R#1709 [open]: github.com/rakudo/rakudo/issues/1709 [ASYNC][⚠ blocker ⚠] A race in HyperRace causing rare crash/hang
lizmat something else: 12:42
m: my @a = ^5; my @b = <a b c d e>; dd @a Z @b
camelia ((0, "a"), (1, "b"), (2, "c"), (3, "d"), (4, "e")).Seq
lizmat What I want is:
(0, "a", 1, "b", 2, "c", 3, "d", 4, "e").Seq
Zoffix m: my @a = ^5; my @b = <a b c d e>; dd flat @a Z @b 12:43
camelia (0, "a", 1, "b", 2, "c", 3, "d", 4, "e").Seq
lizmat yeah, yuck :-)
Zoffix :)
lizmat I was more thinking along the lines of @a Z| @b
or |Z 12:44
Zoffix m: my @a = ^5; my @b = <a b c d e>; dd @a Z[[&({|($^a,$^b)})]] @b 12:45
camelia (slip(0, "a"), slip(1, "b"), slip(2, "c"), slip(3, "d"), slip(4, "e")).Seq
Geth rakudo: 0579669879 | (Elizabeth Mattijsen)++ | src/core/Rakudo/Internals/HyperToIterator.pm6
Revert "Replace HyperToIterator.push-all by push-exactly"

This reverts commit ec5416a9a33e5820802885eddc4af2ee886bbda8.
This appears to fix GH R#1740 and possibly GH R#1709		 12:48
Zoffix \o/
lizmat am in the middle of something else, so I thought I'd revert first and then look into why that opt caused the issues it caused
Geth roast: 9a6b6b6bc7 | (Zoffix Znet)++ | S07-hyperrace/stress.t
Cover hyper.grep perf regression

Closes github.com/rakudo/rakudo/issues/1740 R#1740		 13:02
synopsebot R#1740 [open]: github.com/rakudo/rakudo/issues/1740 [ASYNC][⚠ blocker ⚠] .hyper.grep appears to hang
Zoffix Yeah, can no longer repro either of those hyper issues. 13:08
AlexDaniel ok that's positive :) 13:23
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Revert "Replace HyperToIterator.push-all by push-exactly" 13:25
travis-ci.org/rakudo/rakudo/builds/368132728 github.com/rakudo/rakudo/compare/c...7966987937
buggable [travis build above] ☠ All failures are due to: failed make test (1 failure). Across all jobs, only t/04-nativecall/09-nativecast.t test file failed.
lizmat afk& 14:04
AlexDaniel committable6: uptime 14:31
committable6 AlexDaniel, 17 seconds, 187.28125MiB maxrss. This is Rakudo version 2018.03 built on MoarVM version 2018.03 implementing Perl 6.c.
AlexDaniel bisectable6: uptime
bisectable6 AlexDaniel, 17 hours, 52 minutes, and 35 seconds, 261.757813MiB maxrss. This is Rakudo version 2018.03 built on MoarVM version 2018.03 implementing Perl 6.c.
AlexDaniel hmmm
quotable6: uptime
quotable6 AlexDaniel, 17 hours, 52 minutes, and 50 seconds, 223.933594MiB maxrss. This is Rakudo version 2018.03 built on MoarVM version 2018.03 implementing Perl 6.c.
timotimo i've got a hacky sped up version of HYPER for array:D. it even pre-selects a candidate, though that's probably wrong if there's candidates of the operator that have where causes and such 14:40
2:18s instead of 5:30s for ^1_000_000 >>+<< ^1_000_000 with "my int8 @foo" 14:51
subtracting the time it takes to create the two arrays makes both faster, of course 14:52
1.86s vs 5s 14:53
m: say 5 / 1.86
camelia 2.688172
timotimo it now only selects the candidate based on the first element of each list alone if the operator is the same object as what you get from CORE if you supply the name of the operator
choosing the right nqp::push_* for the result object instead of calling .push on it gets it down to 1.4s 15:00
m: say 5 / 1.46
camelia 3.424658
timotimo 1.1s if i nqp::add_i instead of calling the sub i pulled out of the candidate list 15:02
Geth rakudo: 9e6ae276a9 | (Zoffix Znet)++ | src/core/operators.pm6
Do not sink taken values in SEQUENCE

Fixes unwated consumption of Seqs:
  irclog.perlgeek.de/perl6/2018-04-18#i_16061511		 15:13
roast: 9b51e66c2c | (Zoffix Znet)++ | S03-sequence/misc.t
Test … op does not prematurely cause consumtion of Seqs

Bug find: irclog.perlgeek.de/perl6/2018-04-18#i_16061511 Rakudo fix: github.com/rakudo/rakudo/commit/9e6ae276a9		 15:16
[Coke] Zoffix++ 16:09
japhb timotimo: Are you still playing with it, or have you wrung about as much performance out of it as you can? 17:29
timotimo i didn't continue working on it, but i'm not sure i've gotten the most out of it yet either 17:46
oh whoops 17:50
that's faster
using nqp::atpos_i to get each side's value out gets it about 3x faster
huh, i think it might actually be inlining the + operator here 17:51
i.e. the candidate 17:52
it can get faster still, because at the end of that routine it first boxes an Int object, then immediately unboxes it to push it onto the result list
i should up the size of the arrays, currently the bytecode specializer is active for 45% of the program's run time, which means - to me - that the program runs unoptimized code for a high percentage of its life 17:56
the profiler seems to think MYHYPER didn't even get speshed, not entirely sure why it doesn't have the OSR badge applied to it.
also, huh, tail on a native int array doesn't seem optimized at all? 17:58
like, LastValue takes 22% of the program's whole run time - i end the program by saying the .tail of the result to be sure it's not broken
m: say 44.03 / 1.7 18:00
camelia 25.9
timotimo so MYHYPER is now 26x faster than regular boring hyper
(for native int arrays)
japhb: ix.io/187t 18:02
what do you think?
obviously we need three variants of this function, or some other way to get the right push_* and atpos_* variant
interestingly, using 64bit integer arrays makes it no faster at all 18:04
i would have expected less memory traffic to mean faster execution
is something going wrong with spesh? o_O 18:21
japhb Well, the setup might be able to avoid recomputing left.elems and right.elems all the time. And in fact for native arrays, just switching to nqp::elems would help I would think.
timotimo 1000us isn't long, right? 18:22
japhb Also, I'm not used to seeing 'candidate.()', why not define candidate as my &candidate := ... and then 'candidate()'?
1 millisecond ... depends on whether you're an android, I suppose. ;-)
timotimo every 1ms, spesh receives spesh logs 18:23
japhb Given that's the least amount of time the Rakudo scheduler is willing to even think about, I'd say yeah, it's pretty short. :-)
timotimo that could be wrong
75us every 1000us shouldn't lead to this much cpu usage i don't think? :\ 18:25
japhb 7.5% 18:28
?
timotimo ah, yeah, a phase transition happened 18:29
where it's receiving a few logs back-to-back with 0 wait time, each time spending about 500us updating the statistics
seems like spesh isn't very happy about extremely tight loops? 18:30
there weren't any deoptimizations, i'm not sure why it even logs the osr hits in the jitted code 18:33
releasable6 Next release in ≈2 days and ≈23 hours. 7 blockers. Please log your changes in the ChangeLog 19:00
AlexDaniel optimistic releasable6 :) 19:03
releasable6: uptime
releasable6 AlexDaniel, 22 hours, 24 minutes, and 41 seconds, 266.027344MiB maxrss. This is Rakudo version 2018.03 built on MoarVM version 2018.03 implementing Perl 6.c.
timotimo so i don't see it actually enter the OSR'd code ... does that mean the performance i'm seeing is purely interpreter, not even speshed?! impossible 20:18
lizmat so, do I have a way to programmatically put a sub into a package at BEGIN time ? 21:26
jnthn Hm, not quite sure what you're after 21:27
`BEGIN ThePackage::<&foo> = anon sub foo() { }` ?
lizmat I have a bunch of our subs in a package (List::MoreUtils) and I want to copy these to a package List::SomeUtils 21:28
for List::MoreUtils::.grep(*.key.starts-with("&")) {
::.^add_sub(.key,.value);
}
is what I was trying
jnthn o.O 21:29
A package is just a hash
lizmat yeah, I think I got t 21:30
jnthn So you'd just assign into it
Well, that's not quite true
A package has a Stash, which isa Hash
ThePackage.WHO
You might even page to do something like `ThePackage.WHO ,= TheOtherPackage.WHO`
s/page/be able/ 21:31
...how did I type that wrong?!
lizmat hmm... I guess the simplest would be to alias the packages 21:37
guess I'm too tired to think straight, will revisit tomorrow 21:42
night!
jnthn 'night o/
Kaiepi PufferBot, all 22:44
PufferBot [openbsd] Configuring Rakudo...
[openbsd] Building Rakudo...
[openbsd] Build successful! 22:46
[openbsd] Testing Rakudo...
[openbsd] Tests passed! 22:47
[openbsd] Running Roast test suite... (this will take a while)
AlexDaniel that's very verbose :) 22:48
Kaiepi yeah, all's pretty noisy 22:54
i could probably refactor the logging so it just says 'done!' and whatever errors there were 22:55
on the other hand knowing what it's doing is kinda nice 22:56
timotimo could at least turn the messages that happen in the same second into a single line :) 22:58
PufferBot [openbsd] | t/spec/S02-names-vars/perl.rakudo.moar (Wstat: 256 Tests: 116 Failed: 1) 22:59
[openbsd] | t/spec/S03-operators/u2212-minus.t (Wstat: 256 Tests: 54 Failed: 1)
[openbsd] | t/spec/S17-supply/stable.rakudo.moar (Wstat: 256 Tests: 0 Failed: 0)
[openbsd] | t/spec/S12-meta/exporthow.rakudo.moar (Wstat: 139 Tests: 0 Failed: 0)
[openbsd] | t/spec/S32-io/IO-Socket-Async.t (Wstat: 256 Tests: 17 Failed: 0)
[openbsd] | t/spec/S32-exceptions/misc.rakudo.moar (Wstat: 0 Tests: 450 Failed: 0)
[openbsd] Roast tests failed. See the output at fpaste.scsys.co.uk/577095
AlexDaniel geez 23:00
Zoffix Kaiepi: it's not updating roast again. "*** Error 1 in target 'spectest_update' (ignored)" and at least one failure is due to outdated roast 23:03
looks like it has branch `proc` checked out instead of master 23:04
Kaiepi oh whoops
Zoffix Also "Inline::Perl5 not installed: not running Perl 5 integration tests" <-- you're not running some tests. Also "Files=1225, Tests=76143, 671 wallclock secs (18.66 usr 22.52 sys + 2357.63 cusr 2239.30 csys = 4638.11 CPU)" <---- you're running spectest, but the full test suite is a "stresstest".
ZOFVM: Files=1294, Tests=153319, 152 wallclock secs (21.50 usr 3.47 sys + 3235.12 cusr 155.06 csys = 3415.15 CPU) 23:05
Kaiepi All candidates are currently installed
?
Zoffix ^ that's the number of tests in full test suite with Inline::Perl5 installed
Kaiepi: you probably have it installed for "system" perl6, but not for the perl6 build you're using to test with. 23:06
Kaiepi: step 12 in this guide shows how to setup PATH and have Inline::Perl5 installed for local build of rakudo: github.com/rakudo/rakudo/blob/mast..._guide.pod
AlexDaniel shareable6: uptime 23:07
shareable6 AlexDaniel, 1 day, 2 hours, 29 minutes, and 18 seconds, 369.117188MiB maxrss. This is Rakudo version 2018.03 built on MoarVM version 2018.03 implementing Perl 6.c.
Kaiepi ah 23:08
AlexDaniel undersightable6: uptime
undersightable6 AlexDaniel, 1 day, 2 hours, 29 minutes, and 28 seconds, 336.136719MiB maxrss. This is Rakudo version 2018.03 built on MoarVM version 2018.03 implementing Perl 6.c.
AlexDaniel hmmmmmmmmmm
ok let's give that a few more hours…
but it sounds like the situation on HEAD isn't any worse 23:09
or at least not significantly
Zoffix R#1710 looks fixed now
synopsebot R#1710 [closed]: github.com/rakudo/rakudo/issues/1710 [⚠ blocker ⚠] New stresstest floppers
Zoffix releasable6: status
releasable6 Zoffix, Next release in ≈2 days and ≈19 hours. 6 blockers. 224 out of 241 commits logged
Zoffix, Details: gist.github.com/2eef6e3c9f9649c828...757abfd6e6
AlexDaniel so R#1686 is potentially a non-issue 23:10
synopsebot R#1686 [open]: github.com/rakudo/rakudo/issues/1686 [regression][⚠ blocker ⚠] New memory leak in whateverable
Zoffix So then there's just one bus-factor blocker and one LHF blocker that can be knocked out in an ~hour 23:11
jnthn Which is the bus-factor blocker? 23:12
Zoffix R#1689
synopsebot R#1689 [open]: github.com/rakudo/rakudo/issues/1689 [regression][⚠ blocker ⚠] SEGV when running t/90_csv.t in
jnthn Ah, that one 23:13
I can spend some time on that also, I think
Zoffix \o/
AlexDaniel that would be nice
jnthn It's less -Ofun than my LTM NFA plans, but more pressing. :-)
Sleep for now; 'night o/ 23:29
Zoffix \o 23:30
timotimo gnite jnthn 23:35
Kaiepi do the perl6 docs use british or american spelling? 23:53

Powered by Cro and the Raku® Programming Language.

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

Thank you!