Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
00:09 Ven`` left 00:22 dct left 00:33 lucasb left 05:49 AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel 07:56 robertle_ joined 07:57 p6bannerbot sets mode: +v robertle_ 09:26 benchable6 left, coverable6 left, benchable6 joined, coverable6 joined 09:27 p6bannerbot sets mode: +v benchable6, p6bannerbot sets mode: +v coverable6
lizmat Files=1264, Tests=88010, 372 wallclock secs (20.06 usr 5.95 sys + 2651.01 cusr 229.49 csys = 2906.51 CPU) 09:53
AlexDaniel robertle: hello? :) 09:56
robertle_ hi, how's it? 10:07
AlexDaniel robertle_: I'm alirght! Wondering if there was any progress with rakudo package 10:23
or if there's anything specific that we can do
gfldex jnthn: a chain of .subst seams to have gotten a hell of a lot faster 10:50
jnthn gfldex: When? :) 10:51
(If you know...)
gfldex last 2 days of less 10:53
lizmat perhaps Daniel Green's NQP opts on NFA's ?
gfldex jnthn: (ungolfed) code: gist.github.com/a88776b16929d8817d...cc646762b8
timotimo those wouldn't use the NFA i don't think 10:56
it could very well be that .HOW.compose and such got faster instead
AlexDaniel c: HEAD gist.github.com/gfldex/a88776b1692...cc646762b8 11:03
committable6 AlexDaniel, ¦HEAD(cbc3e72): «1000000␤1000000␤0.524634␤» 11:04
AlexDaniel c: 2018.12 gist.github.com/gfldex/a88776b1692...cc646762b8
committable6 AlexDaniel, ¦2018.12: «1000000␤1000000␤0.5774985␤»
AlexDaniel gfldex: is there any reliable way to reproduce it?
ah wait
you said *faster*
nvm me I can't read 11:05
it's still within noise though
Geth rakudo: c45d2b82da | (Elizabeth Mattijsen)++ | src/core/Any.pm6
Provide some return types in Any signatures
 11:40
rakudo/lower-topic: a4c994f544 | (Jonathan Worthington)++ | 4 files
Don't lower $_ when in 6.c

Turns out the `is dynamic` markings alone are not quite enough, so simply don't perform this optimization when we are in 6.c. Gets the previous specs appendix test covering $CALLER::_ passing again.		 11:42
lizmat jnthn: OOC, how does it know it's in 6.c there ? 11:43
ah,: $*CAN_LOWER_TOPIC := 0 if $lang eq 'c';
jnthn Yes :)
I'm also planning to do a /^P5/ on the name of any module in `use` and set that too :) 11:44
lizmat (at the very end :-)
jnthn (Which is a total hack, but will keep the P5foo modules that want to do $CALLER::_ working until we figure out a better way)
lizmat jnthn: not sure that I follow that
aha.. ok 11:45
jnthn I hope they're all called P5foo :)
lizmat will keep calling them P5xxx :-)
yes, they are
fwiw, I could easily set something in those modules to make it less hacky 11:46
jnthn We'll provide a proper mechanism too, but...I realized that even if we do that, it'd still take time for it to be available.
lizmat if the proper mechanism is a pragma
jnthn Well, the problem is that we need the pragma to affect the using module
lizmat maybe introduce a non-functioning pragma now, so that I can update the modules
ah
ok
jnthn I've thought about an EXPORTPRAGMA (along the lines of EXPORTHOW) 11:47
lizmat hmmm... sounds like something that could work
jnthn I guess that also is a nice "progressive enhancement" in that it's just a package, and so quietly ignored by compiler versions that do't understand it.
*don't
The problem I'm left with is that, in all the discussion of making $_ non-dynamic, this case was missed: 11:48
lizmat yup... well as soon as you have the functionality sketched out, I could add it in the modules
jnthn m: $_ = 'abcd'; say so /ab/; /cd/; say $/;
camelia True
｢cd｣
jnthn What's quite incredible is that breaking that in some cases only manages to break a single spectest... 11:49
lizmat yeah, that functionality of $/ is a pain implementation wise as well, having to bind $/ for each call
jnthn: be glad it broke 1 spectest: I've had plenty of cases when I did some opts where no spectest broke
but it broke modules in the ecosystem :-( 11:50
jnthn Blin.
Anyway, I see two options...
1. We see the presence of a regex in the optimizer and refuse to lower $_ in that case. Pros: least invasive possible change. Cons: we lose the ability to lower $_. 11:51
2. We start storing the topic inside of an attribute on Regex, passing it in to the `clone` call. Then we use that rather than a dynamic lookup. Pros: we keep the opt and avoid a dynamic lookup. Cons: tiny bit more memory usage, maybe some problem I didn't think of yet. 11:52
lizmat that gets hairy if Regexes are passed around in untyped variables, no ?
jnthn Hmm
lizmat so my feeling would be 2. 11:53
jnthn m: my $rx = /bc/; $_ = 'abcd'; $rx; say $/;
camelia WARNINGS for <tmp>:
Nil
Useless use of $rx in sink context (line 1)
jnthn m: my $rx = /bc/; $_ = 'abcd'; so $rx; say $/;
camelia WARNINGS for <tmp>:
｢bc｣
Useless use of "so " in expression "so $rx" in sink context (line 1)
jnthn Hmmm...
That's awkward indeed. 11:54
(The second case with `so`)
Case 2 could result in subtle behavior changes also, in that we'd be capturing the $_ where the regex literal lives, but with the boolification caes you can apply it at a distance. 11:57
Oh, interesting, the sink case seems to be a special compiler form... 12:01
jnthn gives 2 a try 12:02
Actually, lunch first, then will :) 12:03
12:09 |Tux| joined
Geth rakudo: bb84b66ded | (Elizabeth Mattijsen)++ | src/core/Slip.pm6
Provide return type info for Slip
 12:09
12:10 p6bannerbot sets mode: +v |Tux| 12:11 AlexDani` joined 12:12 p6bannerbot sets mode: +v AlexDani`, AlexDani` left, AlexDani` joined, hitchcock.freenode.net sets mode: +v AlexDani`, p6bannerbot sets mode: +v AlexDani`, AlexDaniel left, AlexDani` is now known as AlexDaniel
robertle_ AlexDaniel: I will have a look again theis evening and over the weekend, my current understanding is that the big-endian problems are sorted, but that we have flappers on two little-endian archs, and that they are not immediately reproducible... 12:30
12:30 AlexDani` joined 12:31 p6bannerbot sets mode: +v AlexDani` 12:32 AlexDaniel left, AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined, barjavel.freenode.net sets mode: +v AlexDaniel, p6bannerbot sets mode: +v AlexDaniel
lizmat m: say now + now # I think the error on this is LTA, agree ? 12:39
camelia Ambiguous call to 'infix:<+>(Instant, Instant)'; these signatures all match:
:(Instant:D $a, Real:D $b)
:(Real:D $a, Instant:D $b)
in block <unit> at <tmp> line 1
Geth rakudo: 50f0bb2b73 | (Elizabeth Mattijsen)++ | src/core/Instant.pm6
Provide return types for Instant
 12:54
13:03 |Tux| left 13:05 |Tux| joined, p6bannerbot sets mode: +v |Tux|
Geth rakudo: 93b5e2ef2d | (Elizabeth Mattijsen)++ | src/core/Rakudo/Internals.pm6
Streamline R:I.get-local-timezone-offset a bit

  - 1 scalar alloc less because of binding
  - use positional interface to DateTime.new, instead of named
FWIW, it feels to me this should be easier to do, e.g. by looking at the gmtime and localtime C functions and the difference in their value.		 13:06
rakudo: e58e376417 | (Elizabeth Mattijsen)++ | src/core/Rakudo/Internals.pm6
Use return signatures for R:I.PRECOMP-(EXT|TARGET)
 13:18
rakudo: e48712a30a | (Elizabeth Mattijsen)++ | src/core/Instant.pm6
Give Instant + Instant a more helpful error message
lizmat m: say now + now
camelia Ambiguous call to 'infix:<+>(Instant, Instant)'; these signatures all match:
:(Instant:D $a, Real:D $b --> Instant:D)
:(Real:D $a, Instant:D $b --> Instant:D)
in block <unit> at <tmp> line 1
lizmat becomes: Adding two Instant values has no meaning, did you mean to subtract?
timotimo could it also suggest to .Numeric both before continuing? 13:24
(rather than .Num which will numify, Numeric would more likely ratify?)
lizmat still, what would that mean ? 13:25
timotimo "i have numbers. i want to work with these numbers"?
lizmat how about: Adding two Instant values has no meaning. 13:26
Did you mean to subtract? Perhaps you need to convert to .Numeric first?
timotimo sounds good to me
Geth roast: 73eb90d847 | (Elizabeth Mattijsen)++ | S02-types/instants-and-durations.t
Make test for Instant + Instant less picky

In light of github.com/rakudo/rakudo/commit/e48712a30a		 13:29
roast/6.c-errata: 2bec1d8808 | (Elizabeth Mattijsen)++ | S02-types/instants-and-durations.t
Make Instant + Instant test less picky

In light of github.com/rakudo/rakudo/commit/e48712a30a
lizmat the difference in performance on these surprises me: 13:31
for ^100_000 -> int $_ { my ($a,$b) = (1,2) }; say now - ENTER now'
m: for ^100_000 -> int $_ { my ($a,$b) = (1,2) }; say now - ENTER now'
camelia 5===SORRY!5=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> 3y ($a,$b) = (1,2) }; say now - ENTER now7⏏5'
expecting any of:
infix
infix stopper
postfix
statement end
…
lizmat m: for ^100_000 -> int $_ { my ($a,$b) = (1,2) }; say now - ENTER now
camelia 0.239366
lizmat m: for ^100_000 -> int $_ { my ($a,$b) := (1,2) }; say now - ENTER now
camelia 1.3546617
timotimo does one go through the slow-path binder perhaps?
lizmat yeah. looks like 13:32
bind_one_param in RED at the top in a profile
timotimo time to figure out how to generate good code for a limited set of signatures in this situation
lizmat the reason I was looking at this, is that we have some methods in core that return a List of some values 13:33
e.g. Instant.to-posix
so: my ($posix,$leap) = now.to-posix 13:34
generally means that you don't want to change the $posix / $leap values
so I figured that: my ($posix,$leap) := now.to-posix 13:35
would not only make them constants, but would also be faster
as it wouldn't have to create Scalars etc etc etc...
or create iterators
anyways.. should I make an issue for that, timotimo? 13:36
afk&
jnthn Hmm, it looks like we might have been compiling a throw-away QAST::Block duplicating all the hash construction logic 14:12
No partiuclar runtime cost, but certainly extra compilation work and extra stuff in the precomp 14:13
lizmat jnthn++ # leaning up compiling
jnthn Discovered this 'cus the duped up nodes confused the optimizer 14:14
14:15 |Tux| left, |Tux| joined 14:16 p6bannerbot sets mode: +v |Tux|
jnthn m: sub foo() { $_ = 'wat'; bar(); dd $/; }; sub bar() { /at/; dd $/ }; 14:21
camelia ( no output )
jnthn m: sub foo() { $_ = 'wat'; bar(); dd $/; }; sub bar() { /at/; dd $/ }; foo()
camelia Nil $/ = Nil
Match $/ = Match.new(pos => 3, made => Any, hash => Map.new(()), list => (), orig => "wat", from => 1)
14:21 titsuki joined
jnthn This is weird. We look down the call stack for a defined $_ and then update the $/ where that is 14:22
Which means action at a distance
So `given surprisingly-undefined-thing() { if /foo/ { } }` would be setting some $/ in some caller somewhere
14:22 p6bannerbot sets mode: +v titsuki
jnthn I'm quite sure this is not intended behavior... 14:23
14:24 |Tux| left
lizmat jnthn: perhaps this is from the time where each frame always had a $_ ? 14:24
jnthn Every frame still does have a $_
timotimo but not necessarily a defined one, yeah
lizmat ah, ok, :-)
jnthn Right, that's what I'm saying :)
What I am quite worried about, however, is what actual problem this might have been covering... 14:25
I suspect I'm about to find out, and I suspect it's going to be ungood... :S
lizmat :-(
jnthn runs spectest
14:26 |Tux| joined
jnthn Into S05 and already 4 failing tests :/ 14:27
14:27 p6bannerbot sets mode: +v |Tux|
Geth rakudo: 59bafb832d | (Elizabeth Mattijsen)++ | src/core/Instant.pm6
Augment the Instant + Instant error message, timotimo++
 14:29
rakudo: f2ed3db750 | (Elizabeth Mattijsen)++ | src/core/Instant.pm6
Bind tai to Instant.tai, rather than assigning

Since Instants are value types, there is no point wasting a Scalar on each created Instant. This makes Instant:D.SET-SELF() about 5x as fast, and saves one Scalar allocation per Instant.
rakudo/lower-topic: 31c8fda287 | (Jonathan Worthington)++ | src/Perl6/Actions.nqp
Empty the unused QAST::Block if { ... } is a hash

We take the contents of the QAST::Block and use it as the hash. However, we then failed to clear out the entries inside of that QAST::Block. This means we would compile that part of the tree twice, which is both a waste of compilation time and a bunch of bytecode we'll never run. Furthermore, it turns out this tree duplication in separate blocks could confuse the optimizer (which is how I discovered it).		 14:41
jnthn OK, got my regex topic hanlding changes down to just two spectest files. Let's see how bad they are... 14:42
Aha 14:45
We were relying on it for `not /foo/`, using the lack of a defined $_ inside of the `not` as the hint to keep looking. D'oh. 14:46
And the other case is this: 14:49
$var = rx/<&abc>/;
ok("aaabccc" ~~ m/aa <{ $var ?? $var !! rx{<.null>} }> cc/, 'Rule block first');
What on earth...
This second one pretty much does demand the "skip over undefined $_" semantics 14:56
Guess I'd better try solution #1
lizmat jnthn: is that something specced ? 14:57
jnthn Yes, it's straight out of a spectest file
lizmat how old is that test :-)
jnthn 2009 or 2012, depending which git blame line you pick 14:58
Ah, the 2012 commit was keeping up with a semantic change 14:59
So, 2009. Nearly 10 years :)
lizmat wonders if that test is esoteric enough to wind up in 6.c-errata 15:00
jnthn I dunno...I fear if it's in spectest it'll be elsewhere in the wild too 15:01
Let's see if plan 1 works out at all 15:02
lizmat let's hope :-)
jnthn At least we got the hash code-gen improvement out of attempt 2... :) 15:05
lizmat indeed
timotimo i wonder how much better the core setting's filesize becomes from that; i don't think we have that many literal hash blocks in there? 15:07
15:07 |Tux| left
jnthn I don't think so, no 15:08
lizmat m: role A { has Int $.a }; class B does A { method b(\a) { $!a := a } }; B.new.b(42) # this feels like a bug
camelia Type check failed in binding; expected NQPMu but got Int (42)
in method b at <tmp> line 1
in block <unit> at <tmp> line 1
15:09 |Tux| joined
lizmat m: class B { has Int $.a; method b(\a) { $!a := a } }; B.new.b(42) # this works 15:09
camelia ( no output )
jnthn Yeah, that looks a bit wrong
15:09 p6bannerbot sets mode: +v |Tux|
lizmat m: role A { has $.a }; class B does A { method b(\a) { $!a := a } }; B.new.b(42) # regardless of type on the attribute 15:10
camelia Type check failed in binding; expected NQPMu but got Int (42)
in method b at <tmp> line 1
in block <unit> at <tmp> line 1
jnthn Hurrah, clean spectest... 15:11
lizmat :-)
jnthn Now to make sure it still actually optimizes stuff it should...
15:11 |Tux| left
jnthn Apparently yes 15:13
lizmat R#2581 15:14
synopsebot R#2581 [open]: github.com/rakudo/rakudo/issues/2581 Cannot bind to an attribute from a role
Geth rakudo/lower-topic: 17bf7415e4 | (Jonathan Worthington)++ | src/Perl6/Optimizer.nqp
For blocks containing regexes, don't lower $_

Since we need to look it up when doing `/foo/` in sink or boolean contexts. Unfortunately, the current semantics of that rely on some action at a distance (find the nearest defined `$_`, and update the `$/` in that block); these probably want revisiting. I did attempt to try, when we closure-clone a regex, to copy the appropriate `$_` into it; this mostly works, but the case of `not /foo/` depends on it to skip over the `not` frame, and there is another test which even further relies on the current behavior. So for now, just don't optimize those cases.		 15:16
rakudo/lower-topic: 8aa733062b | (Jonathan Worthington)++ | src/Perl6/Optimizer.nqp
Poison lowering if we see a quasi quote

It might refer to variables outside of itself, and we can't yet easily track if that is the case. Macros are used very little, and will probably be completely re-done based on the 007 work, so for now just do the easiest thing possible to fix things like OO::Monitors that make use of them.		 15:28
rakudo/lower-topic: 11884e032d | (Jonathan Worthington)++ | src/Perl6/World.nqp
Don't lower $_ when using a P5* module
 15:31
15:37 |Tux| joined, p6bannerbot sets mode: +v |Tux|
Geth rakudo: 9f28a42357 | (Elizabeth Mattijsen)++ | 3 files
Streamline creation of Date/DateTime

  - bind attributes to objects, as they are immutable
  - saves 3 Scalars per Date / 5 Scalars per DateTime
  - makes Date.new(y,m,d) about 60% faster
  - makes DateTime.new(y,m,d,h,m,s) about 15% faster		 15:40
15:49 lucasb joined, p6bannerbot sets mode: +v lucasb
jnthn Seems the various perf regressions I'm seeing are things being pushed a tad over the inline limit and/or the $_ allocation happening unconditionally now (and without PEA we can't kill it off in spesh). But maybe now it's not dynamic I can do something about that... :) 15:50
timotimo you know ... 15:55
not could return a modified regex and rely on it being boolified "the next step down"
actually
forget that
that'd only ever work for places that already boolify themselves, or sink for that matter
jnthn Yeah :S 15:59
16:16 SqrtNegInf left
AlexDaniel not ok 28 - accessing Seq from multiple threads does not segfault 16:24
uh huh
ahhhh that's fudged, ok… 16:25
Geth roast: 3bc17b6b97 | (Aleks-Daniel Jakimenko-Aleksejev)++ | integration/weird-errors.t
Add tests for a weird segv issue

Resolves rakudo/rakudo#2486.		 16:31
synopsebot RAKUDO#2486 [closed]: github.com/rakudo/rakudo/issues/2486 [Moar][regression][testneeded] New SEGV issue in Moar
16:43 robertle_ left
[Tux] Rakudo version 2018.12-139-g9f28a4235 - MoarVM version 2018.12-13-g473324ee3
csv-ip5xs0.943 - 1.017
csv-ip5xs-207.166 - 7.269
csv-parser23.471 - 24.707
csv-test-xs-200.433 - 0.442
test7.039 - 7.356
test-t1.910 - 1.921
test-t --race0.840 - 0.845
test-t-2031.236 - 31.692
test-t-20 --race9.735 - 9.844
 16:56
Geth rakudo/lower-topic: 87fcda819b | (Jonathan Worthington)++ | src/Perl6/Optimizer.nqp
More aggressive unused $_ deletion

Now that $_ is lexical (at least, under 6.d), we can in most cases better understand its usage, and delete it when we see there is no use of it at all. This recovers the performance we lost in the lowering of
  $_, caused by the fact that the reliance on lazy lexical initialization
went away, and we were thus always initializing it.		 17:03
jnthn So, do I dare merge this... :) 17:07
With this, even *including* our high startup time, we're now winning `for 1..10_000_000 { }` against my system Perl, Python, and Ruby :) 17:09
dogbert11 why not :)
jnthn It passes test, spectest, and even has a fix for an issue in master that I accidentally introduced a few days back 17:10
dogbert11 I'd say go for it 17:11
jnthn Just throwing the test suite of a sizable/complex $dayjob project at it to get another measure of how it handles
(complex in that it has quite a lot of deps that are themselves quite involved)
Yay, all passed 17:12
dogbert11 cool
Geth rakudo/master: 17 commits pushed by (Jonathan Worthington)++
review: github.com/rakudo/rakudo/compare/9...3bb59e924f		 17:15
AlexDaniel releasable6: status
releasable6 AlexDaniel, Next release in ≈15 days and ≈1 hour. 3 blockers. 0 out of 139 commits logged
AlexDaniel, Details: gist.github.com/d2b1c3685a1f09de2a...56441e8946
AlexDaniel jnthn: looks like a perfect time to merge it
jnthn There we go. \o/
AlexDaniel: Yeah, I figured it's a good time for me to work on these opts :) 17:16
Enough testing time.
Next week, I'll look at more aggressive block flattening 17:22
And then after that, back to the EA 17:25
17:59 lucasb left 22:01 SqrtNegInf joined 22:02 p6bannerbot sets mode: +v SqrtNegInf

Powered by Cro and the Raku® Programming Language.

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

Thank you!