Geth MoarVM: Kaiepi++ created pull request #869:
Set UV_TCP_IPV6ONLY flag when binding async IPv6 TCP connnections		 01:50
Geth MoarVM: fdaf8e0e7d | (Samantha McVey)++ | src/6model/serialization.c
Optimize MVM_serialization_read_int so as not to need memcpy calls

We only do this on CPU's that allow int64 unaligned memory accesses. Technically the switch works on any CPU since the compiler just optimizes it, but I think it may be faster to use memcpy in those instances.		 05:18
MoarVM: 7ea1b5c301 | (Samantha McVey)++ | src/platform/memmem32.c
Only use the 64 bit memory access code in memmem32 for supported cpus

The code accesses 64 bit integers aligned to 32 bits, so only use it on CPU's we've detected allow unaligned accesses.		 05:21
MoarVM: fa13c6d01f | (Samantha McVey)++ | src/core/interp.c
Optimize sp_jit_enter in interp.c a very small amount

The compiler seems to generate better code by declaring it as a variable due to the large number of pointer indirections involved.		 05:33
Geth MoarVM: a8507b8f07 | (Samantha McVey)++ | 2 files
Separate out code into MVM_string_buf32_can_fit_into_8bit

This is separated out so we can use it in the utf8 decoder to decide to create an 8 bit string or not. This will allow us to use this very fast code which vectorizes nicely.		 06:47
MoarVM: f0a837c413 | (Samantha McVey)++ | src/strings/utf8.c
Make MVM_string_utf8_decode 8% faster with vectorized 8bit check

Use the MVM_string_buf32_can_fit_into_8bit function added in the previous commit to allow us to check if the 32 bit buffer can fit in 8 bits using the vectorizable code. This is instead of keeping a running count of the max and min grapheme we see at all steps along the way.
nine .tell brrt yes, I came a cross the same discrepancy. It doesn't make sense, but apparently works. But I guess it does so only because of some happy accident in how the Perl 6 code is compiled 08:17
yoleaux nine: I'll pass your message to brrt.
2 Jun 2018 20:24Z <brrt> nine: i'm suspicious of encoderepconf. I know that's what interp.c does, but it is not what oplist says
2 Jun 2018 23:44Z <jnthn> nine: Well, it comes with the same caveats of using any nqp:: ops outside of core, which is that while they're often de facto stable, there's no promises made about them. There's a non-zero chance that the current multi cache mechanism will eventually be subsumed by my work on spesh plugins.
2 Jun 2018 23:49Z <jnthn> nine: So, effectively, you can commit it, but those ops might at some point go away, so there'd be some updating to do at that point. So long as you're good with that, I'm also ok.
nine .tell brrt The "good" news is that the JIT compiled version is not yet used anyway, since the getattr_* ops are still missing and I've hit another strange issue trying to implement them. 08:20
yoleaux nine: I'll pass your message to brrt.
nine .tell brrt note that the original encoderep op shares the same oddity which was introduced in a commit by jnthn titled "JIT-compile write_fhb and encode ops." 08:26
yoleaux nine: I'll pass your message to brrt.
Geth MoarVM: 89dee3be30 | (Stefan Seifert)++ | 3 files
Fix encoderep/encoderepconf returning value into wrong register

No idea why this worked before, as the return value is supposed to be written to register 0. My guess is that it's a lucky coincidence in how the Perl 6 code gets compiled. Oddity was introduced in commit 1bc55b7d728c8ce85599141bbdc65a30975e3582 and then copied into the encoderepconf implementation.		 08:55
nine jnthn, samcv: please have a look at ^^^
samcv nine: will check in the morning. night 09:26
jnthn nine: Looks sensible 12:26
Geth MoarVM: jstuder-gh++ created pull request #870:
Change getsignals output from hash to array 		17:08
samcv looks ok for me. not sure about the jit stuff as much but the rest look sgood 20:21

Powered by Cro and the Raku® Programming Language.

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

Thank you!