Perl 6 language and compiler development 2.0 | Logs at irclog.perlgeek.de/perl6-dev/today | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by moderator on 4 May 2018.
00:27 dalek joined, p6lert joined, Geth joined, synopsebot joined 01:13 cog_ joined 01:14 entonian joined 01:57 ilbot3 joined
moderator Perl 6 language and compiler development 2.0 | Logs at irclog.perlgeek.de/perl6-dev/today | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
02:24 softmoth joined 02:46 softmoth joined 02:59 softmoth joined 03:05 softmoth joined 03:16 softmoth joined 03:30 softmoth joined 03:31 softmoth joined 03:33 softmoth joined 03:46 softmoth joined 03:50 softmoth joined 04:06 softmoth joined 04:18 softmoth joined 04:33 cog_ joined 05:53 ufobat joined
samcv nine++ on your work trying to make builds reproducable again 07:21
07:53 cog_ joined
lizmat Files=1239, Tests=76248, 316 wallclock secs (15.57 usr 5.39 sys + 2171.06 cusr 219.15 csys = 2411.17 CPU) 08:07
08:38 stmuk joined
lizmat hmmm... export a multi sub candidate on an existing proto / multi should work, right ? 09:38
*exporting
10:25 Kaypie joined 10:26 Kaypie joined
stmuk p6weekly: www.meetup.com/San-Francisco-Perl/...249949377/ 10:52
11:13 cog_ joined 11:32 Ven`` joined 11:33 Ven` joined
robertle weekly: www.meetup.com/San-Francisco-Perl/...249949377/ 11:37
notable6 robertle, Noted!
12:00 ExtraCrispy joined
[Tux] Rakudo version 2018.04.1-37-g1447f41e6 - MoarVM version 2018.04.1-53-g1ef4aaf73
csv-ip5xs0.859 - 0.867
csv-ip5xs-208.541 - 8.605
csv-parser36.628 - 36.840
csv-test-xs-200.454 - 0.454
test8.922 - 9.001
test-t2.362 - 2.372
test-t --race0.998 - 1.018
test-t-2042.722 - 43.440
test-t-20 --race14.797 - 15.911
 12:03
2018-05-05 12:56:25 test-t 2.372
2018-05-02 14:17:19 test-t 2.372
2018-03-29 14:36:32 test-t 2.372
2018-05-05 13:00:58 test-t 2.362
2018-05-02 14:24:37 test-t 2.360
12:21 brrt joined 12:27 hankache joined
MasterDuke i thought there was an option to Configure.pl to make it use a particular branch? 12:36
timotimo --gen-nqp=bloop --gen-moar=bleep 12:45
MasterDuke ah, thanks 12:54
13:11 Tison joined 13:18 brrt joined 13:20 skids joined
MasterDuke .tell nine your make_builds_reproducible_again branches seem to have fixed it (assuming i tested correctly) 13:25
yoleaux MasterDuke: I'll pass your message to nine.
MasterDuke .tell nine i pulled latest rakudo, reverted a commit, `git reset --hard`, tried to rebuild and got errors in make test and install. then i rebuilt with nqp and moar on those branches, and tests passed and install succeeded 13:26
yoleaux MasterDuke: I'll pass your message to nine.
Geth roast: e1dddc4d5e | usev6++ | S02-types/num.t
[JVM] Fudge two tests for stringification
 13:37
skids m: my $f := gather { UNDO { 22.say }; KEEP { 32.say }; take 1; 42.say ; take 2; 1; }; $f[0].say; $f[1].say; $f[2].say; # expected behavior here? 13:55
camelia 1
42
2
22
Nil
skids Also, expected behavior if the clone gets GCd before the last take is tooken?
timotimo i'd not expect phasers to be run if a clone of a frame gets GCd 14:00
but that's just my implementor speaking
skids :-)
Geth nqp: 6debf3dbb4 | usev6++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/Ops.java
[JVM] Allow more combinations with underscores

Makes spectest for numification of '1_2_3E0_0' pass.		 14:03
14:33 cog_ joined 14:48 Kaiepi joined
MasterDuke fwiw, the java binary provided by graal can run `nqp -e 'say("hi")'` 14:56
jnthn Wonder if it runs it much faster :) 15:08
MasterDuke it's about .5s slower. ~2.6s for graal, ~2.1s for openjdk 15:11
jnthn Aww 15:12
And a fraction of a second for MoarVM, I presume :) 15:13
MasterDuke .03s
however, graal does calculate the 35th fibonacci number .5s faster. 9.75s versus 10.2s 15:20
15:23 stmuk_ joined
MasterDuke oh hey, both of those are faster than moarvm, which takes 17s 15:26
for this: `sub f($a) { if $a < 1 { 1 } else { f($a - 1) + f($a - 2) } }; say(f(35))`
timotimo that's nqp? 15:27
MasterDuke yeah
i just tried to build rakudo-jvm and after 30m or so i killed it, it was just sitting in stage parse. nearly had to restart the whole computer 15:28
timotimo 12s on my machine :)
MasterDuke wants to upgrade to ryzen+, but doesn't want to pay what it'll cost 15:29
timotimo it doesn't even spesh, it seems like 15:30
MasterDuke MVM_coerce_smart_numify is the second entry in a perf report (after MVM_interp_run)
timotimo yeah, how does that happen?
i don't see the f sub show up in the spesh log at all 15:32
jnthn: do we know anything about deeply recursive functions not being picked up by spesh in the spesh log? 15:38
jnthn Yeah, it pretty much blows up the stack simulation 15:41
timotimo ah, heh.
well, that probably explains why that's not very performant
but without spesh i can't even see the bytecode! :o
--target=mast is an approximation at least
jnthn Yeah, I figured deeply recursive code isn't what people write then they care about performance :) 15:42
timotimo haha
of course it's int vs num again 15:43
declare the argument to f as "int" and it'll run in 7.9s instead of the 12.2 i have
15:44 brrt joined
Geth nqp/pluggable-spesh: fb808f3fb1 | (Jonathan Worthington)++ | t/moar/52-pluggable-spesh.t
Add a test to exercise literal guard deopt
 15:44
timotimo declaring it to be num and putting e0 everywhere makes it run in ~8s as well
f is looked up via getlexstatic every time it seems like 15:45
it's boxing the literal value 1 it might return as an int, but it boxes the return value of the addition as a num 15:47
and it's smart-numifying the return value of each of the f calls and then coercing it from num to int
i can get 7.7s by using explicit nqp::*_i ops everywhere 15:51
MasterDuke `int $a` get moar down to 12.2s, graal to 8.8s, and openjdk to 9.8s 16:00
timotimo it's being heavily penalized by not being able to resolve &f actually statically 16:08
even though it uses nqp::getlexstatic, that would rely on spesh to do the translation to a constant value
MasterDuke huh. so deeply recursive functions lose spesh completely? 16:42
timotimo could be 16:43
MasterDuke how deep can it be before that happens?
timotimo by calling f(5) 10_000 times before calling f(35) i get it to run in 6.2s instead of ~8 16:47
that gets rid of the slow-path lookup, but the return value of f is still first coerced to num then back to int 16:48
MasterDuke even with `f(int $a)`?
timotimo yeah, the return value is the problem, not the argument 16:49
we don't have a "returns int" in nqp
MasterDuke i know jnthn has talked about switching nqp to defaulting operations to int instead of num, i assume the return is a place where doing that would help? 16:50
timotimo yeah
though now that it gets speshed, it could realize that it's first numifying then intifying and that could be done in a single operation instead? 16:51
which would be an operation that realizes "oh it's already int" and does nothing
i'm not sure why the return value isn't being logged by spesh, either 16:54
it's literally just the static frame, and then "type tuple:" with nothing
but it should have logged the return type? 16:55
MasterDuke what is MVM_frame_try_return? 16:56
timotimo it returns from a frame, if there is a caller to return t 16:57
MasterDuke that's now top of perf report
timotimo heh. 16:58
MasterDuke putting 10k calls to f(5) first
timotimo yeah, it also doesn't inline f into f
if it did, that'd reduce the amount of try_return calls
MasterDuke and yeah, drops moar down to 8.3s 16:59
17:11 SourceBaby joined, Undercover joined 17:40 stmuk__ joined 17:53 cog_ joined 18:17 brrt joined 19:58 awwaiid joined 20:04 squashable6 joined 20:17 brrt joined
Geth rakudo: ede507b734 | (Moritz Lenz)++ | src/Perl6/Actions.nqp
More robust code detection in subsets

only treats defined subset constraints as callable. Otherwise, subsets of Code throw an exception at compile time (#276).		 21:09
21:14 cog_ joined
Geth roast: 7745b00803 | cono++ | S02-types/subset.t
Add test to cover issue rakudo/rakudo#1799

Subset type on Code with arity check failed in use in sub/method signatures or class attributes.		 21:20
synopsebot RAKUDO#1799 [open]: github.com/rakudo/rakudo/issues/1799 [testneeded] Subset type used in Signatures fails with errors

Powered by Cro and the Raku® Programming Language.

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

Thank you!