#raku-dev on 30 January 2025 - Raku Programming Language Log

🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.

00:19 librasteve_ left 04:53 ab5tract left 04:56 ab5tract joined 10:48 nebuchadnezzar joined

Geth

roast: 2a85a8a7ec | (Elizabeth Mattijsen)++ | S03-metaops/reduce.t
Fix [\orelse] test

The test incorrectly expects Any to be produced, rather than Nil.

10:58

rakudo/main: ba2431f445 | (Elizabeth Mattijsen)++ | src/core.c/metaops.rakumod
Streamline list triangle metaop

Use a proper iterator instead of gather / take. Makes it up to 45% faster, and fixes a bug that produced Any instead of Nil.
Part of research into #1705

11:03

11:15 sena_kun joined 11:59 finanalyst left

Geth

rakudo/main: dbc7bfc84e | (Elizabeth Mattijsen)++ | src/core.c/metaops.rakumod
Streamline list infix reduction

Create an IterationBuffer with decontainerized values, then slip that in the argument list. Makes [Z+] about 10% faster. Part of work on #1705

12:05

12:06 [Tux] left 12:09 [Tux] joined

ab5tract

Hmm… is there any hope for improving gather/take performance?

12:20

(Question inspired by the massive performance improvement in lizmat++’s commit)

12:21

lizmat

if we can find out in RakuAST that gather / take can be reduced to a push to an IterationBuffer, then these opts would be automatic

but throwing an exception for each "take", and returning from it is just expensive

12:22

ab5tract

That sounds promising

lizmat

although I believe jnthn already did a lot to optimize that

12:23

12:33 nebuchadnezzar left

ab5tract

Is that the “normal” way to implement coroutines?

13:14

lizmat

afaik gather / take are basically Raku's way of hiding coroutine sheninagans

13:18

timo

once we know that the gather will be consumed eagerly, we know we don't have to do coroutiney stuff

13:20

but if the list is actually being iterated over in any meaningful way, where the code in the "gather" has some side-effects between the individual "take"s, we can't just throw that away

ab5tract

Yeah, but I don’t know many other languages with coroutines that are marked “do not use, too slow”

lizmat

they're not marked: do not use, too slow

13:21

it's just that in these cases that I'm working on, they were not necessary

timo

at least we don't have these fun very-deep call trees with lots of "reify" in them any more :)

ab5tract

Culturally their use has been discouraged

timo

well, for internals code it's a little bit of a different story than for user code

13:22

lizmat

well, I'd say that's true: use them only if you really need them, or if you don't care that much about efficiency

timo

we usually want to give the user the fastest implementation for things that are going to be used "commonly"

ab5tract

Sure, I’m not intending to conflate the two. I just mean that IME gather/take is often written off for user space as well

13:23

timo

i use gather/take every now and then, it's very handy if you're going through nested stuff for example

ab5tract

So my line of questioning is just to ask: do they need to be implemented this way?

13:24

But probably the answer is yes

timo

doesn't have to be coroutines, could be threads instead. though of course that's worse, not better

lizmat

I don't think generally people realize that gather / take is lazy

I often see things like: my @a = gather { ... take, take, take }