|
02:53
MasterDuke joined
|
|||
| MasterDuke | timo, lizmat, et al.: that leibniz benchmark is interesting. i made some modifications (github.com/niklas-heer/speed-compa...bniz.raku) that sped it up, but across some of the different languages i get surprising results on x86 vs apple silicon | 02:57 | |
| on my laptop (apple silicon), raku takes twice as long as on my desktop (amd x86). but the python version reversed, it takes twice as long on the laptop | 03:00 | ||
| and just changing `$pi = $pi + $x / (2 * $i - 1).Num;` to `$pi = $pi + nqp::div_n($x, (2 * $i - 1));` speeds it up by at least 5x on both laptop and desktop | 03:03 | ||
| and a bunch of the savings is that now there are 0 GCs, where before there were ~8k (doing only 100000000 rounds instead of the default 1000000000, just to get results quicker) | 03:06 | ||
| it'd be great it spesh could figure out that it doesn't need to allocate a new Num each iteration, but can just reuse one | 03:08 | ||
| (oops, typoed the bit about python. it's twice as long on the *desktop*) | 03:09 | ||
| off to bed & | 03:11 | ||
|
03:16
MasterDuke left
05:48
melezhik joined
|
|||
| melezhik | I am going to post summary of fundings. But right now diff head vs 2025.11 does not show much | 05:48 | |
| brw.sparrowhub.io/report/brw-reporter/2957 | 05:49 | ||
| ab5tract | MasterDuke: so wuold spesh essentially install a state variable in the scope and reference that? That also sounds like the kind of thing I would expect a RakuAST based optimizer to be able to do as well | 07:32 | |
|
07:46
Voldenet left
07:47
Voldenet joined
09:27
melezhik left
09:28
melezhik_ joined
|
|||
| melezhik_ | update on yesterday run on Rakudo head to test PTY merge. I again have seen quite a few TAP related failures , which are pretty meaningless to me - gist.github.com/melezhik/599e7282c...b6359792cf | 09:29 | |
| many times those failures happen on patrickb: agent (happy-herschel-****) | 09:30 | ||
| maybe such a failures happen on other agents, I don't know, but what puzzles me more, if I rerun those tests one more time ( and sometimes not on happy-herschel-**** agent ) they all pass | 09:31 | ||
| what's so special about happy-herschel-**** agent ? I don't know , the only thing first come to my mind it runs 19 parallels jobs, in comparison with [Coke]: (4 parallel jobs ) and mine (1 parallel job), which makes me think maybe this is sort of high concurrency related issue ? I dunno š¤· | 09:33 | ||
| but the issue by itself is quite annoying as it cause some modules fails falsely and requires modules rerun ( and sometimes not on happy-herschel-*** agent ) | 09:34 | ||
| the latest commit to the agent gave added --debug flag for test runner, so hopefully it will get more details next time we encounter the issues, nevertheless it's still weird to have a such unpredictable behavior given we test the same rakudo version on the same container environment | 09:36 | ||
|
09:38
[Tux] left
|
|||
| melezhik_ | ok, other different between happy-herschel-*** and other agents - mine one at least on docker, [Coke]: which one do you have ? happy-herschel-*** is on podman ... | 09:38 | |
| other different -> other difference | 09:39 | ||
|
09:43
[Tux] joined
|
|||
| patrickb | easy test: I set the parallel jobs to 1 on the next run. Then we'll see if it's the parallelity or something else. | 09:46 | |
|
10:08
melezhik_ left,
melezhik_ joined
10:19
melezhik_ left,
melezhik_ joined
10:24
melezhik_ left
10:25
melezhik_ joined
10:30
melezhik_ left,
melezhik_ joined
10:35
melezhik_ left,
melezhik_ joined
10:41
melezhik_ left,
melezhik_ joined
10:46
melezhik_ left
10:47
melezhik_ joined
10:52
melezhik_ left,
melezhik_ joined
10:57
melezhik_ left
10:58
melezhik_ joined
11:09
melezhik_ left
11:31
librasteve_ joined
|
|||
| librasteve_ | lizmat: hi i saw your ping - just heading out to get a tree | 11:34 | |
| lizmat | ack | ||
| librasteve_ | iāll pong when im back | 11:35 | |
| lizmat | ok | ||
|
11:39
Geth left,
Geth joined
11:55
melezhik joined
|
|||
| Geth | rakudo/andthen-orelse: 11 commits pushed by ab5tract++ review: github.com/rakudo/rakudo/compare/e...d9987d7680 |
11:57 | |
| melezhik | [Coke]: would be interesting to compare results with blin if you have them | 13:26 | |
| [Coke] | * [ ] [Unicode::Security](raku.land/zef:jjmerelo/Unicode::Security) ā Fail, Bisected: [1e66a50](github.com/rakudo/rakudo/commit/1e...5809c85f2) | 13:38 | |
| * [ ] [Inline::Perl5](raku.land/cpan:NINE/Inline::Perl5) ā Fail, Bisected: [63bc8b8](github.com/rakudo/rakudo/commit/63...08207b510) | |||
| So just the one new issue, with Inline::Perl5 | |||
| ... and that bisected to the pty support merge | 13:39 | ||
| lizmat | Unicode::Security failure could be attributed to the move to Unicode 17 perahaps ? | 13:42 | |
| patrickb | Is there a link pointing to the error log? | 13:45 | |
| [Coke] | lizmat: its the same failure as the previous blin run, yes.' | 13:48 | |
| I didn't expect that one to start working. | |||
| github.com/JJ/raku-unicode-security/issues/6 | |||
| patrickb: sure, it's just on an azure box, have to ssh things around to get it visible. one moment. | 13:49 | ||
| lizmat | [Coke]: ah, that one | ||
| will look at it once I've written tomorrow's advent post :-) | |||
| [Coke] | gist.github.com/coke/0a5f70703ba4f...fd8de8332d - there's a failures.md there you can download. | 13:51 | |
| ... weird, my grep seems to have missed some failures. creating a shortened version without all the verbose output | 13:54 | ||
| Text::Markdown::Discount also had a failure. | 13:55 | ||
| gist.github.com/coke/4c32a56599bba...aeee9a909f | 13:57 | ||
| discount is on merging the release branch, so that's just weird. | |||
| lizmat | yeah... | ||
| [Coke] | Digging into the Inline::Perl5 failure in the long version... I don't see a failed test, but a moarvm issue: | 13:58 | |
| [Inline::Perl5] MoarVM oops: Internal error: unhandled dyncall argument type for str 46 | |||
| (there's a whole backtrace in there as well)( | 13:59 | ||
| lizmat | so maybe it's related to NativeCall varargs support ? | 14:01 | |
| [Coke] | maybe; something triggered by the pty change, though? | 14:02 | |
| so I'm guessing we can rule out T::M::D with a manual test, and I::P5 is the one I'm concerned about. | 14:03 | ||
|
14:07
finanalyst joined
|
|||
| Geth | rakudo/main: 6f557f1ec6 | (Elizabeth Mattijsen)++ | 2 files RakuAST: introduce =restart RakuDoc directive As suggested by finanalyst++ and thoughtstream++. May still need some fixups, but that's to be seen later |
14:19 | |
| ShimmerFairy | Could that be a Unicode 17 change issue, perhaps? I didn't have I::P5 installed when I was working on that. I don't think that upgrade should've hurt anything P5-related, and I think it would've been noticed before now, but I wanted to bring it up anyway. | ||
| [Coke] | that issue didn't show up on the blin run that just included the unicode 17 update, and bisects to the pty merge. | 14:36 | |
| seems unlikely to me. | 14:37 | ||
| but we definitely don't want to break inline::perl5 this release. | |||
| disbot6 | <melezhik.> Confirming Unicode::Security failure in brownie | 14:42 | |
| <melezhik.> Test::Async fails as well,( passed in 2025.11), but maybe this is flapper? brw.sparrowhub.io/file_view/brw-rep...:Async.log | 14:46 | ||
| [Coke] | are you using PERL6LIB anywhere? | 14:49 | |
| disbot6 | <melezhik.> Not confirming Inline::Perl5 test failure in brownie though | ||
| <melezhik.> brw.sparrowhub.io/report/job.1.report/3125 | |||
| [Coke] | Yup, seems like 50% of blin failures result in lizmat saying "can't verify the issue" | ||
| lizmat | hmmm... :-) | 14:50 | |
| disbot6 | <melezhik.> No usage of PERL6LIB in brownie setup on my memory | ||
| [Coke] | ok - your log error for async includes a bunch of references to that. Did we deprecate something we hadn't before? | 14:51 | |
| disbot6 | <melezhik.> Test::Markdown::Discount failure is confirmed though the report is a bit confusing ( the same link as for inline::perl5 ) | ||
| patrickb | the Inline::Perl5 issue is non repro able as well. Possibly a flapper | 14:52 | |
| disbot6 | <melezhik.> [Coke]: ahh ok , I need to check if perl6lib is set inside container | 14:54 | |
| <melezhik.> Let me check | 14:55 | ||
| <melezhik.> So , not set | 14:57 | ||
| <melezhik.> root@9bd616413a89:/app# env|grep PERL6LIB| wc -l 0 | 14:58 | ||
| [Coke] | github.com/vrurg/raku-Test-Async/b...kutest#L54 | ||
| melezhik | Test::Async report was made on Coke-bot btw | 15:01 | |
| disbot6 | <melezhik.> Heads up - all brownie links should be prefixed with http:// schema if clicked from irc logs site | 15:04 | |
| <melezhik.> Not sure why irclogs.raku.org render removes http:// | |||
| <melezhik.> ^^ lizmat: | |||
| lizmat | melezhik. please make an issue for that in App::Raku::Log | 15:12 | |
| [Coke] | the link is still there. | 15:14 | |
| <a href="brw.sparrowhub.io/report/job.1.repo...</a> | 15:15 | ||
| so clickthrough is fine. | 15:16 | ||
| (but yah, it's slightly confusing reading) | |||
|
16:12
finanalyst left
|
|||
| melezhik | Yeah, from regular irc client it works , but not from irclogs.raku.org logs , which remove http prefix supposedly | 16:19 | |
|
16:27
timo left
|
|||