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

Re: Robin Hood Hashing for the perl core

Thread Previous | Thread Next
From:
Darren Duncan
Date:
August 6, 2021 07:42
Subject:
Re: Robin Hood Hashing for the perl core
Message ID:
4ed6983a-2c6a-bfaa-f4e3-8d7fbee35b0c@darrenduncan.net
On 2021-08-06 12:20 a.m., Martijn Lievaart wrote:
> 
> Op 06-08-2021 om 03:13 schreef Darren Duncan:
>> On 2021-08-04 1:01 a.m., Smylers wrote:
>>> 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.
>>
>> I fully agree.
>>
>> As the saying goes, the perfect is the enemy of the good.
>>
>> The current discussion should just focus on whether the current proposed new 
>> solution is significantly better than what Perl has now and thus whether Perl 
>> switching to it would be an improvement.
>>
>> Consideration of other algorithms can be their own separate discussions if or 
>> when someone comes up with a specific example and makes a case it is better 
>> than the winner of the current discussion, including that someone has already 
>> committed to do the work etc.
> 
> Yes, but a question that may be asked is, can this be generalized to support 
> different algorithms easily, so programmers can choose the hashing algorithm at 
> runtime. And if it can, is it worth to take such a broadening of the scope on at 
> the same time as handling the current proposal. If it is easy to implement, it 
> should be looked at.
> 
> I suspect the answer to this is a firm no, but it never hurts to look at this. 
> Anyone who knows the internals who can say something about that?

I would say that at this stage the best argument for having that feature of 
hashing algorithm choice is:

1. If it turns out from measuring that some common use cases perform way better 
with the current algorithm and others perform way better with the new one, and 
users would then benefit from being able to choose to tune their scenarios.

2. Also implementing the ability to choose isn't too much effort or has too poor 
trade-offs of is own.

3. If going forward the added maintenance cost of two algorithms rather than one 
is worth it.

-- Darren Duncan

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