develooper Front page | perl.perl5.porters | Postings from August 2021

Re: Robin Hood Hashing for the perl core

Thread Previous | Thread Next
From:
Smylers
Date:
August 4, 2021 08:01
Subject:
Re: Robin Hood Hashing for the perl core
Message ID:
20210804080123.GA737647@stripey.com
Philip R Brenan writes:

> If the proposed new hash function is "better" than the existing function
> then the existing hash function is not "the best" which raises the
> possibility that there might be other "better" hash functions to choose
> from.  One such possibility might use multi way trees:

It might. But then again, Nicholas has a proof-of-concept of his
specific proposal, which is different to the possibility of other
algorithms.

> May I therefore propose that if hash functions are in fact in play:

I don't think it works that certain categories of changes are “in play”
or not: more that any proposal is considered on its merits.

> there should be a competition to find the best hash functions
> currently available today and that the best of the best should be made
> available to all Perl programmers via a "use' clause that gives each
> Perl programmer the opportunity to choose the best function for their
> specific needs?

You're suggesting that even if the proposed new hashing algorithm (with
a working proof-of-concept, a list of the fall-out from switching to it
and what needs patching, and an experienced Perl 5 developer seemingly
offering to do the work involved) is agreed to be an improvement on the
current one, that we should decline this proposal for the aspiration of
a competition and switchable algorithms?

A competition that would take effort to run and oversee (and to come up
with entries for), and then further effort implementing each of the
chosen algorithms, and their switching method?

I'm not saying there wouldn't be any advantages in that happening. But
even if volunteers were found to do all that (and those were additional
volunteers, not taking time away from doing other things on Perl) and it
ran very smoothly, it would clearly take longer to do than making the
proposed hash algorithm switch.

And there's the chance that it wouldn't go well, or efforts would fizzle
away without reaching completion.

At which point it'd be several years later and we'd still be on the
current hashing algorithm.

Let's debate a specific proposal on its own merits, and not discard it,
or derail the discussion, in the hope of something bigger and vaguer
that possibly could happen in the future.

> This would provide a powerful argument for using Perl - the only
> language that puts the needs of its application programmers first and
> unambiguously ahead of the needs of the programmers supporting the
> language.

I can think of dozens of ways in which languages' designs prioritize
their users over their own developers. I'm not sure that switchable
hashing algorithms is one that would occur to most users, nor that it's
such a key feature that it would bring hoards running to Perl. One could
even argue the opposite: that users are best served by being freed of
such low-level considerations, trusting the implementation to do
something sensible without their having to even think about it.

But that's largely irrelevant anyway: even if I'm wrong and user-
switchable hashing algorithms is just what Perl needs, that still isn't
a reason to drop the specific proposal being made in this thread.

Smylers



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About