MasterDuke huh. why would changing github.com/rakudo/rakudo/blob/mast...qp#L11-L12 and github.com/rakudo/rakudo/blob/mast...qp#L11-L12 to `if nqp::atkey(<foo>, <bar>) -> $baz { ... }` cause this error: 00:15
`Bytecode validation error at offset 66, instruction 10:tried to take arg number 6 after checkarity with 5 at gen/moar/Metamodel.nqp:606 (blib/Perl6/Metamodel.moarvm:setup_finalization) from gen/moar/Metamodel.nqp:3907 (blib/Perl6/Metamodel.moarvm:compose)` 00:16
00:43 lucasb left 00:51 Altai-man_ joined 00:52 vrurg left 00:53 sena_kun left 00:58 vrurg joined 01:48 MasterDuke left 02:22 Xliff joined
Xliff m: $f = -> $a { $a == 1 ?? 1 !! $a * $*ROUTINE($a - 1) }; $f(6).say 02:23
camelia 5===SORRY!5=== Error while compiling <tmp>
Variable '$f' is not declared
at <tmp>:1
------> 3<BOL>7⏏5$f = -> $a { $a == 1 ?? 1 !! $a * $*ROUT
Xliff m: my $f = -> $a { $a == 1 ?? 1 !! $a * $*ROUTINE($a - 1) }; $f(6).say
camelia Dynamic variable $*ROUTINE not found
in block <unit> at <tmp> line 1
Xliff m: my $f = -> $a { $a == 1 ?? 1 !! $a * $?ROUTINE($a - 1) }; $f(6).say
camelia 5===SORRY!5=== Error while compiling <tmp>
Variable '$?ROUTINE' is not declared. Did you mean 'Routine'?
at <tmp>:1
------> 3my $f = -> $a { $a == 1 ?? 1 !! $a * 7⏏5$?ROUTINE($a - 1) }; $f(6).say
Xliff m: my $f = -> $a { $a == 1 ?? 1 !! $a * &*ROUTINE($a - 1) }; $f(6).say
camelia Dynamic variable &*ROUTINE not found
in block <unit> at <tmp> line 1
Xliff m: my $f = -> $a { $a == 1 ?? 1 !! $a * &?ROUTINE($a - 1) }; $f(6).say
camelia 5===SORRY!5=== Error while compiling <tmp>
Undeclared name:
?ROUTINE used at line 1. Did you mean 'Routine'?
Xliff m: my $f = -> $a { $a == 1 ?? 1 !! $a * &?BLOCK($a - 1) }; $f(6).say 02:24
camelia 720
02:44 Xliff left 02:52 sena_kun joined 02:54 Altai-man_ left 03:04 leont left 03:25 ZzZombo_ joined 03:27 ZzZombo left, ZzZombo_ is now known as ZzZombo 04:05 squashable6 left 04:09 squashable6 joined 04:51 Altai-man_ joined 04:53 sena_kun left 06:52 sena_kun joined 06:54 Altai-man_ left
lizmat Files=1305, Tests=111213, 219 wallclock secs (28.53 usr 8.64 sys + 2963.46 cusr 288.76 csys = 3289.39 CPU) 07:26
that's 10 seconds more than yesterday :-(
and 50 CPU seconds more than the last time 07:27
just reran the test without the type caching patch on a warm machine: 08:41
Files=1305, Tests=111213, 214 wallclock secs (28.44 usr 8.34 sys + 2969.00 cusr 281.17 csys = 3286.95 CPU)
so that tells me it is that patch
Geth rakudo: bbc4fff80d | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/MROBasedTypeChecking.nqp
Revert "Force publish type cache if found in the MRO"

This reverts commit bde8d37980aac6207fe6ea9981212b01705c1e66.
This causes a 5% slowdown on running the spectest, which is a lot, so reverting for now.		 08:43
nine Well it was worth a try 08:44
lizmat well, since MasterDuke had doubts about the patch anyways... 08:46
08:51 Altai-man_ joined 08:54 sena_kun left 09:31 ufobat joined
Geth rakudo: 79ca396ee6 | (Elizabeth Mattijsen)++ | src/core.c/Failure.pm6
Reduce number of PseudoStash lookups in Failure.new

  - use nqp ops
  - cannot use nqp::ifnull(nqp::atkey...)) trick as nqp::atkey on a
   PseudoStash dies if the key does not exist. Not sure why this is
   this way, but it feels like this is an unnnecessary different
   behaviour from general nqp::atkey behaviour.		 10:13
rakudo: 199888abed | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Some CompUnit::PrecompilationRepository streamlining

  - use binding where possible
  - some code esthetics		 10:36
lizmat I wonder if it would make sense to codegen something like *.defined as a call to &defined ? 10:40
jnthn I don't think so, that confuses "their language" and "our language" 10:42
And I think in most cases .defined would be inlined into the *.defined thunk anyway
So I'm not seeing a great win
lizmat m: my $a = 42; (*.defined)($a) for ^1_000_000
camelia ( no output )
lizmat m: my $a = 42; (*.defined)($a) for ^1_000_000; say now - INIT now 10:43
camelia 0.389419
lizmat m: my $a = 42; $a.defined.sink for ^1_000_000; say now - INIT now
camelia 0.04234609
lizmat that's almost 10x faster ?
jnthn Then we should look at why 10:44
lizmat ok
will do
jnthn I'm curious what *.defined code-gens into...
lizmat looks like the whatever code block takes 50% of time in a profile 10:45
the actual .defined call is 0 seconds in a profile 10:46
0ms even
gist.github.com/lizmat/65ea879b511...967a60f48f 10:48
seems to be some binding to a lowered lex of the parameter, and then passing that to the call ? 10:51
also the sink seems suspect ?
10:52 sena_kun joined
lizmat also: the $a.defined version has *no* garbage collections, whereas the *.defined one has 92 10:53
mostly caused by BOOTCode and WhateverCode allocations
10:53 Altai-man_ left
jnthn Umm, it's maybe allocating the closure every single look...even though the thing doesn't actually close over anything 11:01
That's an interesting general optimization :)
lizmat is unsure how to prevent such allocation
lizmat doesn't see any cloning going on in the codegen, right ? 11:02
jnthn perl6 --target=optimize -e '*.defined for ^100' 11:04
And this is a wtf
It clones and capturelex's it *twice*!
oh, not if we actually call it :) 11:05
But yeah, I see the clone per iteration 11:06
11:18 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Reduce number of PseudoStash lookups in Failure.new 11:18
travis-ci.org/rakudo/rakudo/builds/660555592 github.com/rakudo/rakudo/compare/b...ca396ee6a2
11:18 travis-ci left
lizmat restarts the one failing job 11:18
jnthn: should I make a ticket for the WhateverCode cloning ? 11:29
Geth rakudo: 95e8906c74 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Remove superfluous return statement
jnthn lizmat: Could do, so we don't forget there's an opportunity here 11:46
lizmat github.com/rakudo/rakudo/issues/3540 11:50
12:30 leont joined
Geth rakudo: 5271d122b8 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
De-hllize loaded hash in CompUnit::PrecompilationRepository

Reduce overhead of HLL access that will never be optimized away.		 12:33
lizmat nine: for the lifetime of a CompUnit::PrecompilationRepository object, can $*W or $*REPO change ? 12:44
12:44 lucasb joined 12:51 Altai-man_ joined 12:54 sena_kun left
lizmat I guess $*REPO can change... but $*W ? 12:55
Geth rakudo: f48b80c32e | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Make sure debugging message cannot blow up

By applying the same safeguard as a little down in the code		 13:03
vrurg lizmat: Optimizer defines own $*W. 13:15
lizmat aah,.. ok
but how would that affect CU::Precompilationrepository ? 13:16
*could
vrurg lizmat: It shouldn't, but I'm not well known in CU code. 13:17
lizmat is trying to grok it atm :-)
Geth rakudo: 954e545c0f | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationRepository.pm6
Only lookup %*ENV<RAKUDO_RERESOLVE_DEPENDENCIES> once

for the lifetime of a CompUnit::PrecompilationRepository object.		 13:31
Tux__ Rakudo version 2020.02.1-126-gf48b80c32 - MoarVM version 2020.02.1-40-ga2782ad27 13:41
csv-test-xs-20 0.363 - 0.367
csv-ip5xs 0.711 - 0.738
test-t --race 0.964 - 0.965
test-t 2.011 - 2.028
csv-ip5xs-20 6.231 - 6.245
test 8.413 - 8.534
test-t-20 --race 9.653 - 10.242
csv-parser 25.269 - 26.371
test-t-20 32.341 - 33.195
Two days in a row over 2s
lizmat :-( 13:42
jnthn Sounds like a perf regression somewhere... 13:46
lizmat somehow I suspect 3583254015e0faddbc006 13:47
linkable6 (2020-03-08) github.com/rakudo/rakudo/commit/3583254015 Optimize symbol lookup at compunit creation time
lizmat I don't see a lot else between 6 and 8 March 13:48
*9 March
Tux__ could you retry with 75da4cfec5694ea841873 and 3583254015e0faddbc00 reverted ? 13:49
linkable6 (2020-03-09) github.com/rakudo/rakudo/commit/75da4cfec5 Remove $!unit_ready
Tux__ Rakudo version 2020.02.1-128-g0d8c78354 - MoarVM version 2020.02.1-40-ga2782ad27 14:07
csv-test-xs-20 0.365 - 0.367
csv-ip5xs 0.706 - 0.709
test-t --race 0.900 - 0.987
test-t 1.938 - 2.025
csv-ip5xs-20 6.348 - 6.396
test 8.102 - 8.190 14:08
test-t-20 --race 10.256 - 10.460
csv-parser 26.754 - 27.295
test-t-20 32.853 - 33.315
lizmat hmmm... that's not back on the values of 6 March 14:09
Tux__ and the machine is not where I am working on right now, so it is not eating resources for $work 14:11
lizmat Tux__ : could you try with 40d41a30045da01e8ae4de reverted ? 14:13
linkable6 (2020-03-08) github.com/rakudo/rakudo/commit/40d41a3004 Fix JVM build
Geth rakudo: ef2d7d84d3 | (Elizabeth Mattijsen)++ | t/02-rakudo/reproducible-builds.t
Use a real fake compilation ID for testing
 14:16
Tux__ still slow. /me tries a hard reset to 2020.02.1 14:26
Rakudo version 2020.02.1 - MoarVM version 2020.02.1-40-ga2782ad27 14:37
csv-test-xs-20 0.367 - 0.377
csv-ip5xs 0.721 - 0.722
test-t --race 0.829 - 0.883
test-t 1.842 - 1.859
csv-ip5xs-20 5.810 - 5.916
test 7.764 - 7.924
test-t-20 --race 9.756 - 9.910
csv-parser 23.501 - 23.978
test-t-20 30.528 - 30.943
what wonders me is that they all show the same version number. Should I force-reset something?
lizmat that just shows it was something in rakudo that spoilt performance, not Moar ? 14:38
Tux__ ah
as 21-02-2020 was in the 1.7's I'll try that too, jsut to prove it works as I hope it does (not meking severe errors that put you on the wrong tracks) 14:39
running for tag 2020.02 14:40
test-t 1.862 - 1.869 14:51
lizmat, my procedure was to git reset rakudo top-level to a point back in time. 14:52
$ perl Configure.pl --prefix=/pro/3gl/CPAN/rakudo/install --backends=moar ; make -j8 ; make install
14:52 sena_kun joined
Tux__ $ cd ..../CSV6 ; perl time-twice.pl 14:52
lizmat yeah, that should work
Tux__ rinse and repeat
14:54 Altai-man_ left 14:58 domidumont joined 15:04 leont left
Geth rakudo: 778ce3794b | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationUnit.pm6
Remove CompUnit::PrecompilationId caching

  - simplify check for valid ID (must be 40 hex chars)
  - remove lock and cache		 15:11
Tux__ lizmat, /me is now running tux.nl/Files/test-rakudo.pl 15:21
I'll take a while before I will be able to post the result 15:22
lizmat Tux__++
Tux__ maybe you can run the last part on a box that has all commits prebuilts available?
lizmat AlexDaniel` sena_kun ^^ ? 15:23
AlexDaniel` I mean, you can just pull any build you want 15:24
shareable6: HEAD^^^^^
shareable6 AlexDaniel`, whateverable.6lang.org/HEAD^^^^^
Tux__ look at the start: tux.nl/Files/rakudo.txt - maybe I just caught a bad moment for those 2+'s 15:25
AlexDaniel` I haven't tried yet, but I think latest builds are even relocatable
otherwise follow these instructions: github.com/Raku/whateverable/wiki/Shareable
Geth rakudo: 1a0cc94775 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationUnit.pm6
Make CompUnit::PrecompilationId a proper Value Type

Now that CompUnit::PrecompilationIds are no longer cached, it must be a proper value type to make things like .unique and QuantHashes work correctly.		 15:31
AlexDaniel` ideally we should just run that benchmark on every single commit 15:33
on some machine that is more or less stable
Tux__ So far:
187141af9100b0164704f3d2891511efd5b54c40 1.822 - 1.882
caad8beeecd22e45b6855286716b76f873f0bb81 1.876 - 1.917
bf9026884338576a7ddc5e510a80f41c0c751ad3 1.851 - 1.936
271d0b4bea3fd32e707ea0ecb84bbe0703d16732 1.850 - 1.870
858a0e3237e0f3055a5210776cbd670b7bb2bc93 1.824 - 1.837
linkable6 (2020-02-23) github.com/rakudo/rakudo/commit/187141af91 [release] Bump NQP revision to 2020.02
(2020-02-23) github.com/rakudo/rakudo/commit/caad8beeec Update release date
Tux__ 4064023cc1d318f2efeb5f20b13542e711ca0d89 1.839 - 1.860
linkable6 (2020-02-21) github.com/rakudo/rakudo/commit/bf90268843 Update changelog + announcement
(2020-02-22) github.com/rakudo/rakudo/commit/271d0b4bea Bump NQP to get native num fixes
(2020-02-22) github.com/rakudo/rakudo/commit/858a0e3237 Merge pull request #3506 from dumarchie/master
(2020-02-22) github.com/rakudo/rakudo/commit/4064023cc1 Revert workaround for issue with num
Tux__ 65ef7db198c412a20ebce5e0bea942ebe40fa742 1.866 - 1.871
linkable6 (2020-02-22) github.com/rakudo/rakudo/commit/65ef7db198 Temporary fix for R#3459
Tux__ Hmmm, looks like I started in February. Drat 15:34
lizmat nqp::join("\n",nqp::split("\r\n", $blob.decode)) # trying to grok the reasoning for doing this 15:46
shouldn't Blob.decode by itself not already do the right thing? 15:47
jnthn ^^ ?
Geth rakudo: 11b186c85e | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationUnit.pm6
Streamline CompUnit::PrecompilationUnit.is-up-to-date a bit

  - use binding where possible
  - remove unnecessary temporary variables
  - some code esthetics		 16:15
16:51 Altai-man_ joined 16:54 sena_kun left 16:57 entonian left, entonian joined 16:59 entonian left
Geth rakudo: dec40dc46f | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationUnit.pm6
Streamline CU::PrecompilationDependency::File.deserialize

  - specify attributes more strictly
  - use .new for new object, including serialized-spec		 17:13
17:22 Kaiepi left
[Tux] useful so far? gist.github.com/Tux/6f1aa9cfbb1d94...2d0ac08aae 17:36
17:42 domidumont left 17:52 Ven`` joined
Geth rakudo: d38d76d50a | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/DependencySpecification.pm6
Give CompUnit::DependencySpecification a smarter .raku

  - check if the attribute is default, then not generate it
  - gives the EVAL in CompUnit::PrecompilationDependency::File less
   to parse in the most common case.		 17:57
lizmat [Tux]: bde8d37980aac6207fe6ea9981212b01705c1e66 is already reverted 18:04
the other jump is 4e64c5946be763efff853d41b1e935b08b2d69a8 which is the next-dispatcher work by vrurg :-(
linkable6 (2020-03-01) github.com/rakudo/rakudo/commit/4e64c5946b Make dispatchers use nextdispatcherfor/takenextdispatcher
lizmat [Tux]: *very* useful :-) 18:05
vrurg lizmat: there is one PR for moar unmerged yet which might improve things: github.com/MoarVM/MoarVM/pull/1255 18:09
lizmat vrurg: that's spectest and test clean ?
vrurg But then again: it was monkey job of cloning what's been done for takedispatcher.
I was running with it locally for a while. 18:10
Yes, it did spectest.
Let me make sure nothing changed since.
lizmat: Yet, there is one location where I didn't get into. It's MoarVM/src/jit/graph.c. Somebody with better JIT understanding should take a look at it and add 'nextdispatcher's into it. 18:16
Geth nqp: d34a1bc117 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for the latest and greatest
 18:17
18:17 MasterDuke joined
Geth rakudo: a4680db173 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get the latest MoarVM goodies
 18:26
lizmat vrurg: looks like the MoarVM merge borked MoarVM builds: travis-ci.org/MoarVM/MoarVM/jobs/660744864 18:33
18:34 travis-ci joined
travis-ci NQP build passed. Elizabeth Mattijsen 'Bump MoarVM for the latest and greatest' 18:34
travis-ci.org/perl6/nqp/builds/660747203 github.com/perl6/nqp/compare/9e112...4a1bc1175f
18:34 travis-ci left
vrurg lizmat: I see. But it's confusing because the reason is not MoarVM not building but clang missing or something alike. 18:34
lizmat yeah, I wonder if it wasn't borked before already 18:35
vrurg lizmat: I would rather bet on this.
BTW, adding takenextdispatcher to graph.c breaks jitting. I suspect the new ops aren't jitted for now at all. 18:36
lizmat so the merge I just did will not make a performance difference
:-( 18:37
vrurg lizmat: Can promise nothing, but jitting and inlining are different things. 18:42
To my understanding, nextdispatchers were breaking inlining, the PR should fix it. 18:43
But that's mostly my guess. Anyway, it's should take ~15mins to get things sorted out for somebody knowing this part from inside out. 18:45
MasterDuke jnthn: is there a way to call `publish_type_cache` in `new_type` github.com/rakudo/rakudo/blob/mast...qp#L46-L64 ? i've tried `self.publish_type_cache($obj)`, `self.publish_type_cache($new_type)`, `$metaclass.publish_type_cache($obj)`, and `$metaclass.publish_type_cache($new_type)`, but they all won't build
jnthn Um....it should be called in compose? 18:46
Geth rakudo: f31bd5ba41 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/PrecompilationUnit.pm6
CU::PrecompilationDependency::File.serialize use private attrs

I don't think CompUnit::PrecompilationDependency::File will be subclassed any time soon, and if it were, it would probably need its own "serialize" method.
MasterDuke jnthn: something is going wrong. github.com/rakudo/rakudo/pull/3533 (which had to be reverted because it slowed down a spectest) 18:48
afk for a bit
jnthn Yeah, that PR is calling it in a completely arbitrary place 18:50
I'd check if the type in question is getting composed or not
I'm guessing it's maybe not, which could have other impacts too 18:51
18:52 ufobat_ joined, sena_kun joined 18:53 Altai-man_ left 18:56 ufobat left
Geth rakudo: 014d493abb | (Elizabeth Mattijsen)++ | src/core.c/Process.pm6
Only test for World once, not twice
 19:36
[Tux] gist updated with more measurements 19:41
19:45 [Coke] joined, [Coke] left, [Coke] joined
lizmat [Tux]++ 19:46
20:07 domidumont joined 20:09 domidumont left 20:24 Ven`` left 20:47 MasterDuke left 20:51 Altai-man_ joined 20:52 MasterDuke joined
MasterDuke jnthn: gist.github.com/MasterDuke17/eec3b...7040d19f36 has a patch i've applied and the output when running that example 20:53
20:54 sena_kun left 21:13 sena_kun joined 21:15 Altai-man_ left, Kaiepi joined 21:17 Kaiepi left, Kaiepi joined
MasterDuke reverting github.com/rakudo/rakudo/commit/05...9fa994c45b only has one spectest fail in t/spec/S06-advanced/dispatching.t, in a test added just a couple days ago github.com/perl6/roast/commit/17f7...eaec7dcdc5 21:54
that `:local` here github.com/perl6/roast/blame/maste...hing.t#L65 doesn't do/mean anything 21:55
jnthn, vrurg: ^^^ the `*%adverbs` in `find_method` doesn't seem to be needed anymore, any objection to changing the test and removing it? 21:58
jnthn I'm not aware of anything paying attention to the :local in find_method. As for the adverbs: what if somebody overrides it in a custom meta-class and passes extra arguments, then does callsame? Guess we'd break anything doing that. 22:01
And since spesh is good at throwing away these unused slurpy hashes anyway, it's not such a win to remove them
MasterDuke k 22:02
btw, did that gist from earlier provide any useful info?
jnthn Ah, it's array[int] itself that it's looking for...hmm 22:04
Not sure what that means without looking closer
Which I've no energy left to do today
But yeah, that looks odd
MasterDuke ok, hopefully inspiration will strike in your sleep 22:05
hm, could it be something about also doing `publish_(type|method)_cache` before mixing something in to something else? 22:09
[Coke] tells jnthn to go get some rest! 22:17
Geth rakudo: e1af740752 | (Elizabeth Mattijsen)++ | src/core.c/CompUnit/RepositoryRegistry.pm6
Streamline CU::RepositoryRegistry.resolve-unknown-repos
 22:32
lizmat does sleep&
22:38 Kaeipi joined, Kaeipi left, Kaiepi left 23:09 vrurg left, vrurg joined 23:13 Altai-man_ joined 23:15 sena_kun left

Powered by Cro and the Raku® Programming Language.

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

Thank you!