futures-sort update

[Dominik Pantůček]

Hello Racketeers,

I am continuing my work on cleaning up our private source code and
publishing it as a part of my futures-sort[1] package. Current state of
the package is:

- configurable parallelism depth
- in-place parallel merge-sort of both vector and fxvector
- parallel merge-sort with results going to a freshly allocated vector
- support for calling a custom progress reporting function for all variants

The only missing piece to put this on par with vector-sort is probably
the support for start and end indices and the #:key argument (which we
are internally using). I am not entirely sure if key-caching is feasible
though.

Apart from that and some documentation improvements (mainly for the
progress reporting feature), it is basically complete. In the future I'd
like to investigate possible speedups by providing optimized code paths
for "small" ranges starting with 3 element ranges.

I would appreciate any suggestions and/or feature requests.

Btw, this is production code we are using to speed up tome tasks both on
Linux and Windows.

If you want to benchmark it, beware: it is necessary to first sort some
large dummy vector to ensure that JIT kicks in (1000 elements is enough
with 7.5 on my i7 running Linux).

Also I am curious about what is necessary to get the package to a higher
ring. There will be no backwards-incompatible changes from now.

Any suggestions are - of course - welcome.


Cheers,
Dominik


[1] https://pkgs.racket-lang.org/package/futures-sort

[Sam Tobin-Hochstadt]

On Sat, Dec 7, 2019 at 11:03 AM Dominik Pantůček
<dominik....@trustica.cz> wrote:
>
> Hello Racketeers,
>
> I am continuing my work on cleaning up our private source code and
> publishing it as a part of my futures-sort[1] package. Current state of
> the package is:
>
> - configurable parallelism depth
> - in-place parallel merge-sort of both vector and fxvector
> - parallel merge-sort with results going to a freshly allocated vector
> - support for calling a custom progress reporting function for all variants

Sounds awesome!

> Also I am curious about what is necessary to get the package to a higher
> ring. There will be no backwards-incompatible changes from now.

I don't know why your package is in ring 2, but then again I can't
tell why any particular package has Ring 1 or Ring 2. Maybe Jay can
answer?

Either way, I wouldn't worry about it -- rings are basically an
obsolete part of the pkg system.

Sam