|
00:19
iwuvmika joined
05:34
ShimmerFairy left
05:59
finanalyst joined
06:06
kjp left
06:25
kjp joined,
ShimmerFairy joined
06:34
iwuvmika left,
iwuvmika joined
07:46
ShimmerFairy left
08:20
ShimmerFairy joined
|
|||
| lizmat | bisectable6: dd *[0;0] | 08:31 | |
| bisectable6 | lizmat, Will bisect the whole range automagically because no endpoints were provided, hang tight | ||
| lizmat, Output on all releases: gist.github.com/1d0bdb492874fb650e...c5b64047d2 | 08:32 | ||
| lizmat, Bisecting by output (old=2026.08 new=2026.09) because on both starting points the exit code is 0 | |||
| lizmat, bisect log: gist.github.com/ddc2a534951bcad82a...2ff3c1b443 | |||
| lizmat, (2026-09-22) github.com/rakudo/rakudo/commit/f0...b3348dbcb0 | |||
| lizmat, Output on all releases and bisected commits: gist.github.com/8e1f69ca4cdf663393...690e0e77e3 | |||
| lizmat | hmmm | ||
|
10:09
iwuvmika left
10:14
iwuvmika joined
11:03
iwuvmika left
11:04
iwuvmika joined
11:40
finanalyst left
11:46
iwuvmika left
11:47
iwuvmika joined
12:36
iwuvmika left
12:38
iwuvmika joined
12:57
iwuvmika left
12:58
iwuvmika joined
15:09
Pixi` joined
15:12
Pixi left
|
|||
| apogee_ntv | github.com/rakudo/rakudo/issues/6881 | 15:20 | |
| Geth | rakudo/lizmat-98: 0d946b2f66 | (Elizabeth Mattijsen)++ | src/core.c/List.rakumod Make List.join upto 12% faster - Streamline a bit by losing outer nqp::stmts, no longer needed - Use lowered lexical instead of nqp::getattr most of the time FWIW, many other approaches were tried, but alas none of them succeeded in providing better performance |
16:24 | |
| rakudo/lizmat-98: 2fc2499629 | (Elizabeth Mattijsen)++ | src/core.c/List.rakumod Use presized IterationBuffer for better performance Turns out dealing with HLL Str values, it's better to put them into an Opaque list rather than in a native str list |
|||
| rakudo: lizmat++ created pull request #6882: Make List.join upto 40% faster |
16:26 | ||
| rakudo: m-doughty++ created pull request #6883: #6881 - Read %*ENV<COMSPEC> when %*ENV<ComSpec> is not present (i.e. MSYS2) |
17:06 | ||
| linkable6 | RAKUDO#6881 [open]: github.com/rakudo/rakudo/issues/6881 Windows: `shell()` fails when the environment contains `COMSPEC` instead of `ComSpec` (MSYS2) | ||
| Geth | rakudo/lizmat-100: ae28ce18ae | (Elizabeth Mattijsen)++ | src/core.c/List.rakumod Make List.tail about 13% faster - Use lowered lexical instead of repeated nqp::getattr - Reduce bytecode size 406 -> 346 for faster inlining |
17:47 | |
| rakudo: lizmat++ created pull request #6885: Make List.tail about 13% faster |
|||
| rakudo: m-doughty++ created pull request #6886: (#6884) Account for difference between windows cmd & POSIX shell behavior in deparser test |
17:51 | ||
| linkable6 | RAKUDO#6884 [open]: github.com/rakudo/rakudo/issues/6884 Windows: Deparser test presumes same shell behavior between Windows & POSIX | ||
| japhb | lizmat: From comments on your various PRs, I can't tell what the actual current rules are for bytecode inlining. For example #6877 says it gets "neatly inlined" at 472, #6878 calls 364 -> 340 "slightly easier to inline", and #6885 talks about reducing bytecode from 406 to 346 for "faster inlining". What's the rule? | 19:18 | |
|
19:51
finanalyst joined
|
|||
| lizmat | well, maybe "faster" would be incorrect: more likely maybe better | 19:52 | |
| my understanding is that both the size of the thing that could be inlined, and the size of the block where it could be inlined to, matter | |||
| my most recent example: my @a = (^10).eager; @a.FLATTENABLE_LIST for ^5000000 | 19:54 | ||
| that currently does not inline FLATTENABLE_LIST | |||
| (374 bytes) | |||
| sorry, 388 bytes | 19:55 | ||
| with 2 small tweaks, I've been able to get it down to 374 bytes, and now that example inlines | |||
| japhb | Huh. Interesting | 20:00 | |