This year the event was held in Vienna and, for the first time, my wife accompanied me. We took a direct train from Zürich to Vienna and had a wonderful trip through the glorious Swiss and Austrian countrysides.

We arrived fairly late on Wednesday evening so didn't meet up with anyone then, but we saw a few of the other attendees at breakfast the next morning, and then I set off for the venue where I met up with everyone else, heard BooK's opening speech, took part in the introductions and then split off into a room with the MetaCPAN group with whom I spent about half of my time. Meanwhile, my wife set off to explore Vienna.

I came with a set of work needing to be completed and things I wanted to discuss with people there. The discussions were the most important part and are the raison d'être of the event, and over the four days I had plenty of useful discussions, both planned and non-planned. The first one started whilst walking to the venue on the first day with Paul Evans. We discussed the possibility of separating the behaviour of $^P and PL_perldb - perhaps by using another bit. Devel::Cover uses $^P but doesn't want the behaviour of PL_perldb.

I also discussed further integrating the cpancover infrastructure with that of MetaCPAN. Getting cpancover to run entirely within containers was one of my goals from last year's summit. It wasn't finished during the summit though the problems were solved and all that remained was finishing the implementation, which happened during the year. So now the discussion was more about how to use that. I had a good chat with Leo on that topic and we also sorted out the cpancover backups to MetaCPAN.

I didn't just speak to the English folk though. I spent a fair amount of time talking with Salve on topics primarily related to CPAN security and adjacent subjects. And I chatted with Merijn about life, the universe and everything. He also tested Devel::Cover 2.00 for me and gave me good feedback. We held our second annual CLI throwdown. Many of us live in the terminal so we have a (now somewhat formalised) tradition of sharing our favourite tools.

I had wondered whether I might be in a position to release Devel::Cover 2.00 during the summit but, whilst I was able to do a fair amount of work on it, I realised that there were more things to look at. Hopefully it won't be too much longer before I can put out a test release. This will be the first major (breaking) release since Devel::Cover became stable and it should bring speed improvements, a new criterion and a new report style.

There were plenty of talks and group discussions which I enjoyed, and the four days seemed to race by. It's an intense time which genuinely takes its toll. You can tell that by Sunday many folk are feeling the effects as things start to wind down. Nevertheless it's also extremely satisfying and productive. As usual I left with far more to do than when I arrived - plenty to keep me going until next year.

Beyond work and technical discussions it was lovely to meet up with old friends, to travel around the beautiful city of Vienna and sample some of its lovely cafés and restaurants.

The venue was excellent, die Hauswirtschaft. Our part was small enough that we weren't too far away from each other yet large enough that we weren't on top of each other and with enough space to hold group discussions without disturbing those not involved.

Huge thanks to the organisers. From my point of view, everything ran without a hitch though I'm sure an awful lot of effort went into making it seem that way. And thanks also to our generous sponsors without whom the event could never have happened:

• The Perl and Raku Foundation
• Grant Street Group
• Geizhals Preisvergleich
• Vienna.pm
• SUSE
• Trans-Formed Media LLC
• Ctrl O
• Simplelists
• HKS3 / Koha Support
• Harald Joerg
• Michele Beltrame (Sigmafin)
• Laurent Boivin

The 12 new color spaces are: LinearRGB, CIERGB, Adobe 98 RGB, Apple RGB, Pro Photo RGB, Wide Gamut RGB (Adobe), Rec.709, Rec.2020, Display P3, Display P3 Linear, DCI P3 and DCI P3 Linear. Most of them are or were relevant in (professional) photography, videography or for designers (This is what I meant by go pro). But almost none of these spaces have any CPAN support (until now). With the notable exception of PDL::Transform::Color which does know 7 of them. This makes GTC a "modern" color handling library, especially with GTC 2.3, when another such batch is supposed to land. And if you want to know more about all these spaces, just read our fine docs.

Are you good ?

The new spaces are more or less a variant of good old standard RGB. They have just slightly different white point or gamma value or transfer function. And many of them have a much wider gamut than SRGB. Gamut is just a fancy word meaning range - meaning there are colors you can normally describe in e.g. AdobeRGB, that would not be included (out of range) in standard RGB. When converting, GTC clamps just the values that stick out on an per axis basis. Because this is not ideal, it is planned for 2.4 to have professional gamut mapping (to the visually nearest color). All I can offer for now is the method: is_in_gamut. It allows you to know, if a color will be clamped just by the fact of being read or written by GTC. I also added the argument raw, which prevents such clamping (at your own risk of getting strange values or misbehaving operations). is_in_gamut is also available as standalone sub if you want to check values before creating an object.

Just trust me !

Another issue with these new spaces is that their values are in most cases normalized (0..1) but sometimes come as 16 or even 32 bit integer. Of course you should expect that GTC can read them all. For that scenario I extended the constructor with the option to have named arguments too:

my $color = Graphics::Toolkit::Color->new( color => ['ProPhotoRGB' => 523, 1000, 27 ], range => 2**16, raw => 1);

Output such values works the same way:

 $color->values( in => 'WideGamutRGB', range => 2**32, as => 'named_string', raw => 1);

Space Names

Another topic brought up by the new spaces is color space names. Take for instance linear Display P3. You might want to write Display-P3 Linear or linear_display_p3. Now you have such flexibility with all space names. It was always case insensitive but now you can insert or remove the 4 chars: ' ', '_', '-', '.'; Same is true for the equally valid alias name of a color space. That would be 'BT.2020' for the 'Rec.2020' or XYZ for the CIEXYZ space.

Adapt to the current Sun !

Then we got the new method apply to do gamma correction. The math behind it is trivial but it's there for convenience. And as always GTC tries to give you a little extra by being able to apply to each axis a different gamma value, if you want to. The method name is a bit vague on purpose so it can do more in the future.

Space inversion

Last but not least I expanded the possibilities of the invert method. You can now specify which axis to invert, which makes this tool much more powerful and perlish (TIMTOWTDI), since inverting 'hue' (in HSL, OKSL, LCH ...) is the same as computing the complement with the method of the same name.

Talking Machines

Of course nothing is written by an LLM. I tried it once for test rewrites, but I didn't like it and it wasn't even that much of a productivity boost. It's awful if you lose haptic contact with your mental model of the software. But I did use an LLM in two areas which made me a much better and faster developer.

First is planning. Research and evaluating possible features, grouping them, crafting a roadmap, are things that LLMs speed up. If you have concrete questions with answers that you can evaluate then it's not only a speedup but also a form of QA. If I have a well thought out roadmap much earlier in my head I can make much smarter decisions during development.

The second area where LLMs are very helpful are concrete calculations combined with research. Most helpful was being able to throw a conversion matrix at Claude and ask it how many decimals of precision this thing had and which white point it used. And my ProPhotoRGB conversion matrix needed a CAT Bradford adaptation. Claude reminded me of that fact on its own and computed after I asked for it a combined CAT and conversion matrix and told me the white point of it. It already knew it should use only values from the standard, colour-science or Lindbloom. All things I could potentially do too, but that would take me an extra half an hour at least. Of course I wrote the tests for that matrix by hand, but this was the real eye-opener to me.

If you look into the GTC internals, you see instantly that the most common none OO data structure is a 'tuple' with the values of one color in one color space (usually three values). Since we do not have a native tuple type in Perl - it is an ordinary Array, one could also say a value vector. In the GTC test suite they get checked very often. Each time I have to ask:

1. Did I get an Array ?
2. Does it have the right amount of values ?
3. Check every value of the tuple for equality.

These are usually 5 lines that could and should have been one line. In practice this means 200 rows of test code will shrink to 40 - neat. Less to type, less to read - wonderful. And the assertions will be more to the point telling WHAT I want to test and WHY not just two values match, which is also good for readability and clarity on the other end. If running the tests, the ok - messages will tell me what is actually tested and not that two values matched. But the most important improvement comes to light when something goes wrong. Let's say the function we test collapses and returns undef. The first test will tell us that we got no ARRAY, good, but the next who checks the lengths of the array will crash in a hard syntax error. You have to fix the causing bug in order to see the next test results because your test suite crashed. Wouldn't it be so much nicer the test suite could run to the end and the error messages tell you about all the bugs at once, so you could theoretically hunt them in one go.

You see: less code, clearer code, better error message, only relevant error messages and no hard crashes. These are more than enough motivating reasons to write custom error functions, so let's do it, let's write a variant of

is( $got, $expected, $test_name );

(which is a test function you all used at some point) and name it:

is_tuple( $got, $expected, $axis, $test_name );

You notice I needed one more argument for the axis names. So I can get the nice error message: "the red value was 13 but I expected 15".

The Solution

The Module you need to create that is Test::Builder. So the smart ones among you have guessed you need to:

use Test::Builder;
my $tb = Test::Builder->new;

You can also subclass Test::Builder but this works as well, since ->new will give you the only instance of $tb anyway. And to start our test function we need just:

sub is_tuple {
my ($got, $expected, $axis, $name) = @_;
my $pass = 0;
my $diag = '';

Well if you are reading this blog, you know about Perl argument handling. $pass is the pseudo boolean than holds the information if the test was successful, we pass it on to the Test::Builder method at the end. Same is true for $diag, which is the error message we maybe have to drop. This is not the way you have to do it. Calling the diag method several times is also an option, but i prefer to have short error messages that fits in one line and only tells me what exactly went wrong. Let's skip the testing logic, since a bunch of nested if statements with some basic value checks isn't that impressive and educational. I just like a clean separation between out test logic and the part where I talk to Test::Builder. That is why I declared the variables at the start, fill them when i need to, so I only call the following once at the end of the subroutine:

$tb->diag( $diag ) unless $pass;
$tb->ok( $pass, $name );

Yes that is all. Do not forget to:

require Exporter;
our @ISA = qw(Exporter);
our @EXPORT = qw(is_tuple);

But this was really it. It didn't even hurt and we didn't have to see Detroit.

The Tests

More challenging I found it to write the test file that checks the logic code I didn't show in the above example.

use v5......;
use warnings;
use lib '.',...;
use Test::More tests => ...;
use Test::Builder::Tester;
use Test::Color;

This is mostly your usual start template of any test file. The lib pragma needs to receive the directory where the module lives, that contains is_tuple, which would be in my case Test::Color. And we need Test::Builder::Tester to test what we built with Test::Builder (the module names fit).

test_out("ok 1 - is_tuple runs");
is_tuple([1,1,1], [1,1,1], [qw/red green blue/], 'is_tuple runs');
test_test("simplest is_tuple case runs");

Our first little smoke test seems trivial. We call is_tuple with the the result values of some operation ($got) and the values to check them against ($expected), then the axis names and at last the test name (the name of the test is_tuple performs). But BEFORE that you HAVE TO tell Test::Builder::Tester what output to expect from the test function is_tuple on STDOUT. The last line tells Test::Builder::Tester the name of the test we did by testing the test function. That HAS to come AFTER calling is_tuple.

Now we are ready for the juicy bit. How to test a failing test? I mean by that: is_tuple will fail because we gave it bad data by purpose. And if is_tuple tries to give the right error message to STDERR (standard error output), Test::Builder::Tester should intervene and call it a successful test to STDOUT. The code to do this is:

test_out("not ok 1 - C");
test_err("# failed test: C - got values that are not a tuple (ARRAY ref)");
test_fail(+1);
is_tuple(1, [1,1,1], [qw/red green blue/], 'C');
test_test("is_tuple checks if got values in an ARRAY");

First we tell via test_out again what STDOUT suppose to receive. Then we tell via test_err what error message should land in STDERR. And when a test fails Test::Builder will create an additional error message telling where it happened. In order to not have to chase line numbers we got the convenience function: test_fail(+1); You can translate it to: "Hej Test::Builder::Tester, the next line (+1) will cause an error, this is fine, please do not create this additional error with the line number". What actually happens is, this call gets forwarded to a test_err call with the appropriate string that contains the right line number. Then we finally call the test function we want to test and at the very end again - the name of this (meta) test.

One last useful hack. You noticed I called the test that is_tuple does in the last example just uppercase C. This is not a nice and telling name for any test and brutally counterproductive - However - since we testing the test and the name of the inner test is part of the STDOUT and STDERR check string in the outer test, it is nice to trace easily what substring comes from where and this is also rather educational for this demo. What this (inner) test suppose to do is documented anyway by the name of the outer test.

The open source world is actively debating whether to accept AI-assisted contributions. QEMU, NetBSD, and Gentoo have said no. A lot of CPAN maintainers haven't written down a policy but have a reflex — if a PR looks AI-assisted, close it without a real review.

Two very different concerns sit underneath that reflex, and they usually get mashed together:

• Quality. AI can produce plausible-looking code that doesn't actually work, hallucinates APIs, or subtly misunderstands the problem. This wastes reviewer time.
• Copyright. AI might reproduce memorized training material the contributor has no right to relicense. The output itself may not even be copyrightable. The contributor may not actually own what they're submitting.

This article is about the second one. The quality concern is real, but you already know how to handle it — you read the PR, you run the tests, you ask questions. It's the same concern you have about any contributor. The copyright concern is the structurally novel one, and it's the question where CPAN's particular history matters.

I maintain CPAN modules, and for a while I've been running AI-assisted modernization tools (koan is one example of the category) against the modules I care for. Across the cpan-authors GitHub organization — a collection of repositories where many CPAN modules are collaboratively maintained — hundreds of those PRs have been merged, every one with a human in the loop: a maintainer reading the diff, running the tests, and taking full responsibility. My argument isn't that nothing has ever been wrong. It's that the copyright concerns people raise about AI-assisted contributions are not a new kind of concern for CPAN. They are the same concern CPAN has always carried, under a different name.

The reflex to reject AI-assisted PRs on copyright grounds quietly smuggles in an assumption: that human-authored CPAN contributions came with a clean bill of provenance, and AI is the thing threatening to pollute the water. That assumption does not survive five minutes of honest thought about how CPAN actually works.

What CPAN actually verifies

CPAN's rule for accepting new code is, in full: the author uploads a tarball, declares a license, and we trust them. Many modules pick "same terms as Perl," but plenty use Artistic 2.0, MIT, Apache 2.0, or something else — and a surprising number ship with an ambiguous or missing license line.

There's no DCO. There's no CLA. PAUSE confirms that you are who you say you are. It does not confirm that you own what you just uploaded. When the license is "same terms as Perl" — still the most common declaration on CPAN — it points to a moving target: Artistic 1.0 plus GPL 1-or-later. That pair has been tested in U.S. court basically once, in Jacobsen v. Katzer (Fed. Cir. 2008), and never that I know of outside the U.S. The part of Artistic that reliably works is the warranty disclaimer — and every common CPAN license (Artistic 2.0, MIT, Apache 2.0, GPL) has a disclaimer of its own. Those disclaimers appear, to me, to be doing most of the real legal work for CPAN today.

If you've maintained a module for a while, you already know the quiet risks sitting in the index:

• Code an employer actually owns, uploaded by an employee who never got permission. Some of this has been in widely-used distributions for decades.
• Code copied from a book, a paper, or a reference implementation, with the original copyright never mentioned.
• Modules ported from another language without telling — or asking — the original author.
• Abandoned modules whose authors can't be reached and whose ownership chain is, in practice, lost.
• License tags like "same terms as Perl 5.6.1" that point at a license text nobody has read in twenty years, and whose present-day legal force I personally wouldn't want to bet on.

None of this has blown up into a real copyright fight. That's not because CPAN is clean. It's because the licenses CPAN actually uses — Artistic/GPL, Artistic 2.0, MIT, Apache — are all permissive enough that, as I read them, a plaintiff would have a hard time showing they lost anything. It's because every one of those licenses comes with a warranty disclaimer that blocks most ways of suing in the first place. And it's because the culture of the ecosystem does not go looking for that kind of fight.

This is not a knock on CPAN. It's the cost of a thirty-year-old volunteer archive that chose breadth over lawyering. The trade has held up fine.

But it's the baseline you need to admit before you reject an AI-assisted PR on sight, on copyright grounds alone.

AI is not a new kind of copyright risk

Once you look honestly at how CPAN handles contributions, the AI copyright debate stops being about whether to let something dirty into a clean system. It becomes about whether to add one more flavor of provenance uncertainty to a system that has always run on several.

The copyright concerns people raise about AI are real:

• The model might reproduce copyrighted code it was trained on, without attribution.
• Parts of the output may not be copyrightable at all, which weakens the contributor's ability to license it to you.
• The contributor may not have a clear legal claim to what they're granting.

Now compare those to the copyright concerns that have always been there for CPAN:

• The contributor's employer might own the code under a work-for-hire arrangement and never agreed to release it.
• Part of the module might be a near-copy of a GPL-incompatible reference implementation from a textbook or another project.
• Ported-from-another-language code may have the original author's copyright still attached to it in ways the contributor never addressed.
• Abandoned modules may have copyright holders who are unreachable and whose heirs could, in theory, assert rights tomorrow.

It's the same shape. We're not sure the human who signed for this code had the legal authority to grant the license they claimed, and if they didn't, we have no efficient way to find out. The source of that uncertainty has changed — it used to be a textbook or an employer, now it might also be a training set — but the failure mode is the same, and the way CPAN handles it is the same: the human takes responsibility, the warranty disclaimer catches what falls through, and the permissive license protects downstream users.

That's why the pragmatic camp in open source — Linux kernel, Red Hat, Apache, GitLab, OpenInfra — has landed where it has: allow AI-assisted contributions with commit-trailer disclosure (GitHub-native projects commonly use Co-authored-by:; the kernel uses Assisted-by:) and full human responsibility. The strict-ban camp — QEMU, NetBSD, Gentoo — quietly assumes the pre-AI baseline was clean. For projects with DCOs and CLAs, that assumption is at least defensible. For CPAN, it isn't.

What actually changes: volume

There is one thing AI genuinely changes about the copyright picture, and it's the thing every CPAN maintainer should care about: volume.

CPAN's background rate of problematic code — borrowed from a book, copied out of work-for-hire, lifted from an incompatible-license reference implementation, and now potentially reproduced from a model's training set — has never been zero, and systematic provenance review has never been the norm on CPAN. What AI changes is that one contributor with a decent model and a decent tool can produce PRs at a rate no individual ever could before. Ship more, roll the dice more.

That's the change worth naming. Not a new kind of risk. Just more throws of the same dice — which justifies some proportional vigilance, not a categorical rejection.

How to actually evaluate an AI-assisted PR

When an AI-assisted PR lands on your module, the quality checks are the ones you already know how to run — does the change make sense, do the tests pass, does the style match the repo, does the contributor engage when you ask questions. None of that is AI-specific.

The copyright-specific checks are small and cheap:

• Look for the obvious copy tells. Anything with copyright headers, SPDX tags, or author-name strings in it should bounce — those are signs of memorized training material. A quick GitHub search for any distinctive identifier or string literal will catch the worst cases. This scales with the volume.
• Expect disclosure. Ask contributors to mark AI-assisted commits with a Co-authored-by: trailer — the standard GitHub convention, and one Red Hat names alongside Assisted-by: and Generated-by: as an acceptable option in its Nov 2025 analysis. The point is transparency: a reader of the log should be able to see which commits had AI help. Only humans should appear in Signed-off-by: lines; an AI has no standing to certify the DCO.
• Hold the human accountable, not the tool — and be clear about which human. Who is asserting the license grant depends on the workflow. When an external contributor opens a PR, they are the one claiming the right to license their submission; the merge accepts that claim. When you are running an AI tool yourself against modules you maintain, the assertion and the acceptance collapse into a single merge click, and you are the accountable human on both sides. Third-party AI-assisted PRs sit in the normal contributor-plus-maintainer model; self-operated tools compress it. Either way, a human with legal standing is accountable somewhere. If you can't explain what you're merging — because you didn't review it, or because the contributor can't explain it either — don't merge it.

The difference between a PR you merge and one you reject, on copyright grounds, isn't whether a model was involved. It's whether a human with legal standing to grant the license took responsibility for doing so — at submission, at merge, or both. That test is the same test CPAN has been running, implicitly, for thirty years.

One argument to retire

"CPAN was in the training data, so AI output is CPAN-compatible." Let it go. We don't know what's in Claude's training data, or GPT's, or anyone else's. We do know these models have read Perl from all over GitHub (including incompatible licenses), from Stack Overflow (CC BY-SA), from books, blogs, and anywhere else crawlable. "Trained on CPAN" is a comforting story, but we can't confirm it, and resting an argument on it makes the argument weaker, not stronger.

The honest claim is smaller and more useful. The contributor has reviewed the output. The contributor is accountable. The warranty disclaimer catches the residual risk the same way it has for three decades. That is what the kernel, Red Hat, Apache, and OpenInfra policies all quietly say. It's the claim you can defend — and it holds whether the tool in the contributor's hand is Claude, GPT, a generous colleague, or a textbook.

Closing

The copyright concern with AI-assisted contributions is real, but it isn't new. CPAN has been running on the same legal structure for thirty years — permissive licenses, warranty disclaimers, contributor accountability — and that structure handles AI-assisted contributions the same way it handles every other kind of provenance uncertainty CPAN has quietly carried since the beginning. The risk profile is the same. Only the volume is new.

Do the copyright-specific checks when the volume warrants them. Look for the obvious copy tells. Ask for Co-authored-by: disclosure. Hold the contributor accountable for the license grant they're making. Trust the warranty disclaimer that's been doing the heavy lifting the whole time.

And update your own internal picture of CPAN while you're at it: it was never a clean room on provenance, and pretending otherwise was always a story we told ourselves.

Two weeks ago we posted "PDL in Rust - A Native
Reimplementation of the Perl Data Language". At the time the
score was 45 tests, all green. That was enough to say "it compiles,
it runs, here is the arithmetic surface." It was not enough to say
"you can use this."

We are now on the second number. The current PDL implementation in pperl covers roughly 3,000 assertions end-to-end: about 1,400 on the Perl-facing connector side and about 1,600 on the engine side. As of this writing roughly 98% of the connector assertions match upstream PDL 2.103 exactly, and most of the remaining couple of dozen we already know why they fail. By the time you read this the numbers will have drifted a little in our favour - give or take - but the shape is the point, not the decimal.

Everything described below is shipping, today, at https://perl.petamem.com.

Part One was a flag-planting exercise. Someone on Reddit asked whether pperl would support PDL; we said yes; we then had to actually do it. Forty-five tests covering construction, arithmetic, reductions, a handful of transcendentals, and operator overloading. The point was to prove the mechanism - that a pure-Rust engine behind a pperl native module could stand up to Perl-side code that expects `use PDL; my $x = pdl([1,2,3]);` to just work. It did. But forty-five tests is not a usable PDL.

This post is about what happened when we turned the heat up.

What's in the Box

The Perl-facing module hierarchy now mirrors upstream PDL's own, file-for-file where it matters:

PDL              - top-level boot, exports pdl/zeroes/ones/...
PDL::Core        - constructors, accessors, DESTROY, magic
PDL::Ops         - arithmetic, comparison, bitwise, unary
PDL::Ufunc       - reductions, sorting, statistics
PDL::Math        - trig, hyperbolic, Bessel, erf, special functions
PDL::Primitive   - matmult, which, where, clip, append, convolve
PDL::Slices      - slice, xchg, mv, reshape, clump, dummy, range
PDL::Basic       - sequence, xvals, yvals, zvals, rvals, linvals
PDL::MatrixOps   - det, inv, LU, eigens, trace, norm
PDL::Bad         - bad-value flags, setbadat, copybad, locf
PDL::FFT         - Cooley-Tukey radix-2 FFT/IFFT
PDL::NiceSlice   - source filter: $x(:,0) syntax
PDL::Lite        - lightweight import variant
PDL::LiteF       - lightweight import with fewer functions

Fifteen data types. Broadcasting. Bad values. Dataflow. Affine slicing. Storable round-trip. FFT. 2D image convolutions. Matrix decompositions. Source-filter support for PDL::NiceSlice's $x(:,0) syntax. Operator overloading for ~40 operators. It is PDL, not a demo subset. Whether it walks quite like the grown-up yet is for the user to judge.

The Connector, in One Example

Part One described the split at a high level - a standalone Rust crate for the engine, a pperl native module for the bridge. This time let us walk one operation end to end, because the connector is where the Perl audience will want the detail.

Consider $A x $B, the matrix-multiply overload:

use PDL;
my $A = pdl([[1,2],[3,4]]);
my $B = pdl([[5,6],[7,8]]);
my $C = $A x $B;

Here is what the x overload looks like on our side. The handler is a plain Rust function registered into the PDL stash at boot. No use overload block, no BEGIN-time aliasing, no XSUB wrapper file:

// At boot, overload entries go straight into the PDL stash.
let overloads: &[(&[u8], unsafe extern "C" fn(*mut CV))] = &[
    (b"(+\0",    xs_plus_overload),
    (b"(*\0",    xs_mult_overload),
    (b"(x\0",    xs_matmult_overload),   // matrix multiply
    // ~40 more operators …
];
for &(name, func) in overloads {
    newXS(/* PDL::(X */, Some(func), file);
}

The handler itself extracts the PDLs from their SVs, validates dimensions, calls into the engine, wraps the result:

unsafe extern "C" fn xs_matmult_overload(_cv: *mut CV) {
    let mark  = xs_pop_mark();
    let items = xs_items(mark);
    let (a_sv, b_sv, _swap) = binop_args(mark, items);
    xs_sp_set(mark);
    let mut a_temp = false;
    let mut b_temp = false;
    let a = sv_to_pdl_or_scalar(a_sv, &mut a_temp);
    let b = sv_to_pdl_or_scalar(b_sv, &mut b_temp);
    let a_dims = core_vtable::pdl_dims(a);
    let b_dims = core_vtable::pdl_dims(b);
    if a_dims[0] != b_dims[1] {
        Perl_croak(b"PDL: matmult: dimension mismatch\0".as_ptr() as *const c_char);
    }
    let c = core_vtable::pdl_alloc_output();
    // --- THE ENTIRE DISPATCH ---
    // One call into Rust-PDL. No XS wrapping, no interpreter
    // round-trip, no hidden allocations.
    let err = rust_pdl::primitive::pp_matmult
                 ::pdl_run_matmult(a, b, c);
    if a_temp { core_vtable::pdl_destroy(a); }
    if b_temp { core_vtable::pdl_destroy(b); }
    xs_push(sv_2mortal(pdl_to_sv(c)));
}

Three things about this example are worth drawing out for a Perl audience.

The overload dispatch is a function-pointer table. $A x $B resolves as: stash lookup → function-pointer call → Rust. Upstream PDL's equivalent path is: use overload table lookup → dispatch to a Perl sub → XSUB boundary → PP-generated C → inner kernel. pperl removes the two middle layers entirely, because the handler is the kernel-caller, compiled into the interpreter binary.

sv_to_pdl is a magic walk, not a method call. PDL SVs in pperl store the engine's *mut c_pdl as PERL_MAGIC_ext on the inner SV - the same mechanism Perl itself uses for tied variables, dualvars, and a dozen other features. Extracting the pointer is a flag check plus a linked-list walk. No method dispatch, no can(), no string comparisons:

let flags = SvFLAGS(inner);
if flags & (SVs_GMG | SVs_SMG | SVs_RMG) != 0 {
    let mut mg = (*sv_any).xmg_u.xmg_magic;
    while !mg.is_null() {
        if (*mg).mg_virtual == &PDL_MAGIC_VTBL {
            return (*mg).mg_ptr as *mut c_pdl;  // ← the c_pdl pointer, raw
        }
        mg = (*mg).mg_moremagic;
    }
}

So $A->at(0) in pperl is: one stash method lookup, one magic walk, one pointer-arithmetic offset inside a Rust function. We did not invent a new mechanism for binding Rust objects to Perl variables - we reused Perl's own magic infrastructure, because that is what it is for.

Type promotion: upstream's rule, reimplemented from scratch. Matrix multiply with mixed types - long x float - must promote to double for numerical stability. Upstream's rule is "an NV scalar forces minimum promotion to double; an NV PDL keeps its wider type if already ≥ double." We ported the rule verbatim; the implementation is thirty lines of Rust match arms. No C preprocessor switch tables. No .xs file. No PDL::PP code-generation templates. When we discovered that pperl was keeping float instead of promoting to double for float + 0.2 - the fix was two match arms, one rebuild, twenty-five tests recovered. In the upstream world the equivalent change would touch PDL::PP's templates and trigger a rebuild of forty op files.

pd2multi - We build a Compiler

Upstream PDL has PDL::PP: a macro/template processor that weaves .pd definitions with C fragments and hands the output to cc. It has served PDL for thirty years. It works. But the output is always C, and it is a text-substitution engine, not a compiler.

We could not extend it. We needed something that could emit Rust today, and potentially other targets later - a C backend to validate against upstream's own output, a GPU backend for OpenCL, a Perl backend to let pperl's JIT see through the operation into the surrounding loop. So we built a proper parser → AST → emitter pipeline. pd2multi ingests the same input language, builds an explicit intermediate representation, and delegates output to pluggable backend emitters.

This is internal infrastructure. Nothing user-facing ships from it yet; it is the scaffolding under the engine. It is roughly two orders of magnitude more work than the template-substitution approach it replaces. The payoff is optionality: when we want to add a GPU backend, it is one more emitter walking the AST, not a new compiler.

Correctness

The connector test suite runs every assertion against both upstream perl5+PDL and pperl+Rust-PDL, compares outputs, and categorizes each result. A representative snapshot from the harness at the time of writing:

Tests: ~1380 matched, ~25 mismatched, ~110 extra / ~1400 total

Matched - the large majority, give or take: pperl produces the same output as upstream.

Mismatched - on the order of two dozen: pperl differs from upstream. Most of these are real work in progress and we know where the gaps are. The biggest cluster is in forward-flow dataflow - when a parent PDL is mutated, downstream slice children should see the update eagerly. Our implementation is currently lazy, which catches most cases via dirty-flag refresh but misses the paths that read child data without going through the normal accessor. A handful of tests in 220-broadcasting fail on that. The rest are distributed drift: error message text, one edge case in unbroadcast, STL round-trip issues. None are conceptual; all are bounded.

Extra - around a hundred: tests that pperl passes and upstream does not. Some of these are test-surface coverage - we wrote more thorough tests for overload dispatch, import semantics, and native-function dispatch than upstream did. Others are legitimate behavioural differences where we produce a correct result and upstream does not; the precision and diagnostics subsections below cover the interesting cases.

There is a separate, smaller number worth singling out.

Where pperl and Upstream Disagree, and pperl is Right

A handful of tests produce different results between the two implementations where pperl's result is more correct. Six in the first sweep; we are no longer surprised when we find another. Three patterns are worth naming.

Precision. pctover computes the k-th percentile along a dimension:

my $x = pdl(0,0,6,3,5,0,7,14,94,5,5,8,7,7,1,6,7,13,10,2,101,19,7,7,5);
my $r = $x->pctover(0.9);
printf "%.20f\n", $r->at();

Upstream says 17.00000000000000710543. pperl says 17.00000000000000000000. Both stringify to 17, so to the eye they are identical. But $r->at() == 17 is false on upstream (the 7e-15 drift catches the numeric comparison) and true on pperl. The test was written as a plain == 17 assertion, assuming the kernel would return an exact integer.

Why does pperl get it right? Same numerical recipe, different float accounting. Upstream's PP-generated C coerces intermediates into PDL_Double early and rounds once per sample. The Rust kernel, passing through LLVM's optimizer, keeps a wider accumulator and rounds once at the final divide. It is not cleverness on our side - it is what the modern toolchain does with the same numerical recipe when nothing in the code forces early narrowing. The same pattern appears in xlogvals and a couple of other reductions.

Perl context. lgamma returns two values: the log-gamma value, and the sign. Upstream's PP-generated XS returns both as a two-element list regardless of context. In scalar context, Perl takes the last element - so my $y = lgamma($x) assigns the sign (always 1), not the actual gamma. That is not what a Perl programmer expects. pperl respects GIMME_V: scalar context returns the value, list context returns the pair.

This is not a numerical-methods win. It is a Perl-semantics win - the kind that only a Perl-aware reimplementation can notice. We didn't set out to behave differently from upstream; we set out to behave the way Perl specifies.

Diagnostics. pdl("nonsense blurb") should reject its input. Upstream does reject it - but the error message reads found 'e' as part of a larger word in nonsense blurb, because the parser is reporting that it saw e (Euler's constant) embedded in a longer token, and that is what it complains about. pperl reports found disallowed character(s) 'nonsense,blurb', which is what an actual user wanted to know. A smaller case of the same pattern: $x->slice('0:-14') on a 10-element PDL silently returns a garbage view upstream; pperl croaks with an out-of-bounds error. Good diagnostics are a correctness property.

And in the interest of honest accounting: we have also found places where our implementation was wrong and upstream was right, and we conformed. The float + 0.2 promotion rule mentioned earlier was one of those: we were returning float, upstream correctly promoted to double, we fixed ourselves to match. The flow of corrections is bidirectional and that is the point - two independent implementations of the same spec are a stronger guarantee of correctness than either one alone.

Performance

The startup story from Part One holds and has tightened up. Here is the harness output from the current connector test suite, picking a representative sample:

PDL/010-constructor.t     ... ok  (17/17)   perl5: 84ms  / pperl: 9ms
PDL/110-core.t            ... ok  (121/121) perl5: 88ms  / pperl: 13ms
PDL/120-ops.t             ... ok  (75/75)   perl5: 94ms  / pperl: 12ms
PDL/150-primitive.t       ... ok  (60/60)   perl5: 86ms  / pperl: 11ms
PDL/190-matrixops.t       ... ok  (35/35)   perl5: 90ms  / pperl: 11ms
PDL/260-pdl-from-string.t ... ok  (60/60)   perl5: 86ms  / pperl: 13ms
PDL/300-niceslice.t       ... ok  (30/30)   perl5: 137ms / pperl: 75ms
PDL/330-flexraw-fastraw.t ... ok  (30/30)   perl5: 96ms  / pperl: 20ms

Across the full PDL suite, pperl's per-test wall time sits at 9–13ms for the typical path and climbs to 20–75ms for tests that do real I/O or source filtering. Upstream's corresponding numbers are 82–137ms. The typical startup advantage is 8–10×; the fastest cases reach 13×. This is not a compute-throughput benchmark - it is the cost of use PDL plus a few operations. And it holds because the entire PDL stack is compiled into the pperl binary. There is no module loading, no PP compilation, no dynamic linking.

Compute-throughput numbers are what most readers will actually care about, so here is a table from the current benchmark suite - release build, microseconds per call, averaged over a warm loop. Worth stating up front: these are dry numbers. No JIT loop-fusion, no Rayon parallelism, no GPU offload - none of the mechanisms that define pperl's architectural advantage are engaged here. What is being measured is the raw kernel-versus-kernel cost and the per-call dispatch overhead. The ceiling is considerably higher than what these numbers show; the floor is what they are.

op                    size    upstream µs    pperl µs    ratio
---------------   --------    -----------    --------    -----
pdl_from_str            10           66.6         3.4    20x
pdl_from_str           100          583.4        18.3    32x
pdl_from_str          1000         6667.7       183.4    36x

stringify               10            8.6         1.5     5.6x

stringify              100           60.0        13.1     4.6x

stringify             1000          620.6       140.8     4.3x

add_scalar             100            3.4         1.2     2.8x

matmult_sq              10            5.4         2.3     2.3x

slice                  100            2.0         1.3     1.5x

slice                10000            2.1         1.3     1.7x

slice              1000000            2.2         1.4     1.5x

add_vec            1000000         1860.4      1939.1     0.96x

mul_vec            1000000         1879.3      1790.6     1.05x

sum                1000000         1468.3      1344.1     1.09x

exp                1000000         8174.9      8110.6     1.01x

matmult_sq             200         6329.4      7070.6     0.90x

sumover            1000000         4723.4     13214.5     0.36x

Three things stand out.

Parsing and formatting win cleanly. pdl_from_str - the pdl("1 2 3; 4 5 6") literal parser - is 20-36× faster because ours is a native Rust tokenizer where upstream's is a pure-Perl regex chain. Stringify is 4-6× faster for the same structural reason: a native formatter rather than Perl-side string assembly. These gains are not tuning artefacts; they will persist.

Small-op dispatch wins. On small arrays (100-element add_scalar, 10×10 matmult), pperl is 2-3× faster because the XS overhead is gone. This is the function-pointer overload dispatch from the connector walkthrough, now with numbers: Perl → stash lookup → Rust kernel, no intervening XSUB layer. On large arrays the kernel dominates and the dispatch win disappears into the noise - which is the correct outcome, not a disappointment.

Slice is zero-copy and measurably so. A slice operation on a 1M-element PDL takes about 1.4 µs on pperl, independent of input size - a constant-time affine view construction, as it should be. Upstream is within the same order of magnitude (about 2 µs); both implementations do the right thing here.

Outliers do happen. sumover at 1M elements is currently slower than upstream; it was detected, it is understood, and it is being worked on. That is the expected shape of a young engine against a thirty-year-old one.

These numbers are just a baseline. The "dry" performance without JIT, Autoparallelization or GPU. Autovec by the compiler happens for both. The numbers for JIT+Rayon and/or GPU will land in a dedicated post once the relevant parts of the JIT are ready.

How pperl PDL Compares to Upstream

On Compatibility

Our commitment is to upstream PDL's specified behaviour. When the specification and the current implementation disagree, we side with the specification. lgamma in scalar context is the cleanest illustration: Perl's GIMME_V contract is unambiguous; upstream's PP-generated XS happens not to honour it; ours does. We did not set out to deviate - we set out to mirror Perl.

Everywhere else, upstream is the reference. Thirty years of PDL carry numerical decisions and edge-case wisdom that the documentation does not always explain. Whenever we disagreed with upstream during implementation, our default assumption was that we were missing context. The float + 0.2 promotion case earlier in this post is exactly that: we thought we were right. However, upstream was right - we conformed.

What's Next

Three threads, in rough priority order.

Rayon-based parallelism. First prototypes are running: PDL operations inside pperl's JIT-compiled while-loops distribute across cores via work-stealing. Early results look promising. Mandelbrot-scale workloads already parallelize cleanly; the interesting work is in making parallelism show up for realistic PDL pipelines without per-call overhead eating the win.

OpenCL / GPU acceleration. This is a priority goal, and it is the reason pd2multi exists as a proper compiler rather than a template system. A GPU backend is one more emitter walking the AST, not a separate codegen project. The engineering cost is real but bounded.

JIT fusion across PDL boundaries. Cranelift compilation of surrounding Perl loops that call PDL operations, so the JIT can see through the op and fuse it with the loop body. This is the structural payoff of having a pure-Rust engine - the JIT can look inside - and it is the thing that will make the case for reimplementation in performance terms, not just compatibility terms. Serious work on this is pending the Rayon and GPU threads stabilizing.

No dates. We will post numbers when there are numbers to post.

In the meantime: use PDL; in pperl, today, at https://perl.petamem.com. Roughly three thousand assertions of work, about ninety-eight per cent of them matching the upstream beacon, a double-digit startup win, and a handful of cases where independent implementation caught things that a single implementation had missed.

- Richard C. Jelinek, PetaMem s.r.o.

Perl has solid options here, and they've been around for a while. File::Map gives you clean zero-copy access to mmap'd files - substr, index, even regexes run directly on mapped memory. LMDB_File wraps the Lightning Memory-Mapped Database - mature, ACID-compliant, lock-free concurrent readers via MVCC, crash-safe persistence. Hash::SharedMem offers a purpose-built concurrent hash with lock-free reads and atomic copy-on-write updates. Cache::FastMmap is the workhorse for shared caching - mmap-backed pages with per-page fcntl locking, LRU eviction, and optional compression.

These are all good, proven tools. But they have something in common: they're about storage. You put data in, you get data out. They don't give you a queue that consumers can block on. They don't give you a pub/sub channel, a ring buffer, a semaphore, a priority heap, or a lock-free MPMC algorithm. They don't do atomic counters or futex-based blocking with timeouts.

That's the gap the Data::*::Shared family fills - fourteen Perl modules that give you proper, typed, concurrent data structures backed by mmap. Not better storage - concurrent data structures that happen to live in shared memory. Queues, hash maps, pub/sub, stacks, ring buffers, heaps, graphs, sync primitives - the works. All written in XS/C, all designed to work across fork()'d processes with zero serialization overhead.

Let me walk you through what's in the box.

The Approach

Every module in the family uses the same core recipe:

• mmap(MAP_SHARED) for the actual shared memory - no serialization, no copies, just raw memory visible to all processes
• Linux futex for blocking/waiting - when a queue is empty and you want to wait for data, you sleep in the kernel, not in a spin loop
• CAS (compare-and-swap) for lock-free operations where possible - no mutex, no contention, just atomic CPU instructions
• PID-based crash recovery - if a process dies holding a lock, other processes detect the stale PID and recover automatically

Requires Linux (futex, memfd), 64-bit Perl 5.22+. A deliberate tradeoff - portable it isn't, but fast it is.

Three ways to create the backing memory:

# File-backed - persistent, survives restarts
my $q = Data::Queue::Shared::Int->new('/tmp/myq.shm', 1024);

# Anonymous - fork-inherited, no filesystem footprint

my $q = Data::Queue::Shared::Int->new(undef, 1024);

# memfd - passable via Unix socket fd, no filesystem visibility

my $q = Data::Queue::Shared::Int->new_memfd("my_queue", 1024);

The Modules

Here's the full roster, grouped by use case.

Message Passing

Data::Queue::Shared - Your bread-and-butter MPMC (multi-producer, multi-consumer) bounded queue. Integer variants use the Vyukov lock-free algorithm; string variant uses a mutex with a circular arena. Blocking and non-blocking modes, batch operations, the whole deal.

use Data::Queue::Shared;

my $q = Data::Queue::Shared::Int->new(undef, 4096);

# In producer

$q->push(42);

$q->push_multi(1, 2, 3, 4, 5);

# In consumer

my $val = $q->pop_wait(1.5);    # block up to 1.5s

my @batch = $q->pop_multi(100);

Single-process throughput: ~5M ops/s for integers. That's roughly 3x MCE::Queue and 6x POSIX message queues.

Data::PubSub::Shared - Broadcast pub/sub over a ring buffer. Publishers write, subscribers each track their own cursor. If a subscriber falls behind, it auto-recovers to the oldest available message. No back-pressure on writers.

my $ps = Data::PubSub::Shared::Int->new(undef, 8192);
$ps->publish(42);

my $sub = $ps->subscribe;

my $val = $sub->poll_wait(1.0);

Batch publishing hits ~170M msgs/s for integers. Yes, really. It's just writing to mapped memory.

Data::ReqRep::Shared - Request-response pattern with per-request reply routing. Client acquires a response slot, sends a request carrying the slot ID, server replies to that specific slot. Supports both sync and async client styles.

# Server
my ($request, $id) = $rr->recv_wait(1.0);
$rr->reply($id, "processed: $request");

# Client (async)

my $id = $rr->send("do something");

my $response = $rr->get_wait($id, 2.0);

Around 200K req/s cross-process - competitive with Unix domain sockets but with true MPMC support.

Key-Value

Data::HashMap::Shared - This is the big one. Concurrent hash map with elastic capacity, optional LRU eviction (clock algorithm with lock-free reads), optional per-key TTL, atomic counters, sharding, cursors. Eleven type variants from II (int-int) to SS (string-string).

use Data::HashMap::Shared::SS;

my $map = Data::HashMap::Shared::SS->new('/tmp/cache.shm', 100_000);

$map->put("user:123", "alice");

my $name = $map->get("user:123");

# LRU cache with max 10K entries

my $cache = Data::HashMap::Shared::SS->new('/tmp/lru.shm', 100_000, 10_000);

# TTL - entries expire after 60 seconds

my $ttl = Data::HashMap::Shared::II->new('/tmp/ttl.shm', 100_000, 0, 60);

# Atomic counter (lock-free fast path under read lock)

$map->incr("hits:page_a");

Cross-process string reads: 3.25M/s. Integer lookups hit ~10M/s. And you get built-in LRU and TTL without an external cache layer.

Sequential & Positional

Data::Stack::Shared - Lock-free LIFO stack. Push, pop, peek. ~6.4M ops/s.

Data::Deque::Shared - Double-ended queue. Push/pop from both ends. Lock-free CAS. ~6.3M ops/s.

Data::RingBuffer::Shared - Fixed-size circular buffer that overwrites on wrap. No consumer tracking - you just read by position. Great for metrics windows and rolling logs. ~11.7M writes/s.

Data::Log::Shared - Append-only log. Unlike Queue (consumed on read) or RingBuffer (overwritten), Log retains everything until explicitly truncated. CAS-based append, cursor-based reads. ~8.9M appends/s.

Resource Management

Data::Pool::Shared - Object pool with allocate/free. CAS-based bitmap allocation, typed slots (I64, I32, F64, Str), scope guards for automatic cleanup, raw C pointers for FFI integration. PID-tracked slots are auto-recovered when a process dies.

my $pool = Data::Pool::Shared::I64->new(undef, 256);
my $idx = $pool->alloc;
$pool->set($idx, 42);
# ...
$pool->free($idx);

# Or with auto-cleanup

{

    my $guard = $pool->alloc_guard;

    $pool->set($$guard, 99);

}  # auto-freed here

Data::BitSet::Shared - Fixed-size bitset with per-bit atomic CAS operations. Good for flags, membership tracking, allocation bitmaps. ~10.5M ops/s.

Data::Buffer::Shared - Type-specialized arrays (I8 through F64, plus Str) with atomic per-element access. Seqlock for bulk reads, RW lock for bulk writes. Think shared sensor arrays or metric buffers.

Graphs & Priority

Data::Graph::Shared - Directed weighted graph with mutex-protected mutations. Node bitmap pool, adjacency lists, per-node data. ~3.9M node adds/s, ~13.3M lookups/s.

Data::Heap::Shared - Binary min-heap for priority queues. Mutex-protected, futex blocking when empty. ~5.3M pushes/s.

Synchronization Primitives

Data::Sync::Shared - Five cross-process sync primitives in one module: Semaphore, Barrier, RWLock, Condvar, and Once. All futex-based, all with PID-based stale lock recovery, all with scope guards.

use Data::Sync::Shared;

my $sem = Data::Sync::Shared::Semaphore->new(undef, 4);  # 4 permits

{

    my $guard = $sem->acquire_guard;

    # at most 4 processes here concurrently

}

my $barrier = Data::Sync::Shared::Barrier->new(undef, $num_workers);

$barrier->wait;  # blocks until all workers arrive

my $once = Data::Sync::Shared::Once->new(undef);

if ($once->enter) {

    init_expensive_thing();

    $once->done;

}

At a Glance

Type Specialization

Most modules come in typed variants - Int16, Int32, Int64, Str, and so on. This isn't just for type safety. An Int16 queue uses half the memory of an Int64 queue, which means double the cache density on the same hardware. When you're doing millions of operations per second, cache lines matter.

Event Loop Integration

Every module supports eventfd() for integration with event loops like EV, Mojo, or AnyEvent:

my $fd = $q->eventfd;
# register $fd with your event loop
# on readable: $q->eventfd_consume; then poll/pop

Signaling is explicit ($q->notify) so you can batch writes before waking consumers.

Playing Nice with Others: PDL, FFI::Platypus, OpenGL::Modern

One thing I want to highlight is that these aren't isolated islands. Because everything lives in mmap'd memory with known layouts, you get natural interop with other systems that work with raw pointers and packed data.

PDL is the obvious one. If you're doing numerical work in Perl - signal processing, image manipulation, statistics - PDL is your workhorse. The Buffer module's as_scalar returns a zero-copy scalar reference directly over the mmap'd region. Feed that to PDL and you've got an ndarray backed by shared memory:

use Data::Buffer::Shared::F64;
use PDL;

my $buf = Data::Buffer::Shared::F64->new('/tmp/signal.shm', 10000);

# one process fills the buffer with sensor data...

# another process reads it as a PDL:

my $pdl = PDL->new_from_specification(double, 10000);

${$pdl->get_dataref} = ${$buf->as_scalar};

$pdl->upd_data;

printf "mean=%.4f stddev=%.4f\n", $pdl->stats;

For typed arrays you can also use get_raw/set_raw for bulk transfers - a single memcpy under the hood, seqlock-guarded for consistency. That means you can build a multiprocess image pipeline where one process captures frames into a shared U8 buffer, another runs PDL convolutions on it, and a third renders the result - all communicating through shared memory with eventfd notifications, no serialization anywhere.

FFI::Platypus works just as naturally. Pool and Buffer both expose ptr() / data_ptr() - raw C pointers as unsigned integers, ready to hand to any C function through FFI. Need to call libc qsort directly on your shared data? Go ahead:

use Data::Pool::Shared;
use FFI::Platypus;

my $pool = Data::Pool::Shared::I64->new(undef, 1000);

# ... alloc and fill slots ...

my $ffi = FFI::Platypus->new(api => 2);

$ffi->lib(undef);  # libc

$ffi->attach([qsort => 'c_qsort'] =>

    ['opaque', 'size_t', 'size_t', '(opaque,opaque)->int'] => 'void');

c_qsort($pool->data_ptr, 1000, 8, $comparator);

# slots are now sorted in-place, visible to all processes

Pool slots are contiguous in memory (data_ptr + idx * elem_size), so any C library that expects a flat array works out of the box.

OpenGL::Modern is where it gets fun. Buffer::F32 is essentially a shared vertex buffer. One process computes positions, another renders them - connected by a shared mmap region and eventfd:

# Compute process:
my $verts = Data::Buffer::Shared::F32->new('/tmp/verts.shm', 30000);
$verts->set_slice(0, @new_positions);
$verts->notify;

# Render process:

my $ref = $verts->as_scalar;

# on eventfd readable:

glBufferSubData_p(GL_ARRAY_BUFFER, 0, $$ref);  # zero-copy upload

Pool goes further - it's a natural fit for particle systems. Particles are dynamically spawned (alloc) and despawned (free), each with a fixed-size state struct. A spawner process allocates particles, a physics process updates them, and the renderer uploads the live slots to a VBO via ptr(). The raw pointer goes straight to glBufferSubData_c - no packing, no intermediate copies.

The common thread here is that the data is already in the format the consuming library expects. F32 buffers are packed floats. I64 pools are packed int64s. There's no Perl-side serialization layer to bypass because there was never one to begin with.

Optional Keyword API

If you install XS::Parse::Keyword, several modules expose lexical keywords that bypass Perl method dispatch entirely:

use Data::Queue::Shared;

q_int_push $q, 42;

my $v = q_int_pop $q;

Zero dispatch overhead. The XS function gets called directly. It's optional - the method API works fine - but it's there when you need every last microsecond.

The Big Picture

Here's how the pieces fit together in a typical system:

• Data::Queue::Shared distributes work from producers to a pool of workers
• Data::HashMap::Shared acts as a shared cache or config store that all workers read from
• Data::PubSub::Shared broadcasts events or status updates to whoever's listening
• Data::Sync::Shared coordinates startup (Barrier), limits concurrency (Semaphore), and protects shared initialization (Once)
• Data::Pool::Shared manages reusable resource slots
• Data::RingBuffer::Shared or Data::Log::Shared holds recent metrics or audit trails

All of this running across fork()'d processes, communicating through shared memory at millions of operations per second, no serialization overhead.

Getting Started

Values are typed C scalars or fixed-length strings - no automatic serialization of arbitrary Perl structures. That's by design: raw mmap'd memory is what makes everything fast and FFI-friendly, but it means you won't be sharing hashrefs or blessed objects directly.

All modules follow the same pattern:

use Data::Queue::Shared;

# Pick your backing: file, anonymous, or memfd

my $q = Data::Queue::Shared::Int->new(undef, 4096);

if (fork() == 0) {

    $q->push($$);  # child pushes its PID

    exit;

}

my $child_pid = $q->pop_wait(5.0);

say "Child reported in: $child_pid";

The modules are on GitHub under the vividsnow account. Each one has its own repo, test suite, and benchmarks you can run yourself.

If you've ever wished Perl had something like Go's channels and sync primitives but for fork()'d processes - well, now it does. Fourteen of them, actually.

Happy sharing