Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #6236 > unrolled thread

About hash function collision and scalability..

Back to article view | Back to comp.programming.threads

Contents

  About hash function collision and scalability.. Amine Moulay Ramdane <aminer68@gmail.com> - 2021-01-16 12:22 -0800
    Re: About hash function collision and scalability.. Bonita Montero <Bonita.Montero@gmail.com> - 2021-01-17 10:00 +0100
      Re: About hash function collision and scalability.. Amine Moulay Ramdane <aminer68@gmail.com> - 2021-01-17 07:20 -0800
        Re: About hash function collision and scalability.. Bonita Montero <Bonita.Montero@gmail.com> - 2021-01-17 19:36 +0100

#6236 — About hash function collision and scalability..

Hello..


About hash function collision and scalability..

About Birthday’s paradox(https://en.wikipedia.org/wiki/Birthday_problem): Wikipedia gives us an approximation to the collision probability assuming that the number of objects r is much smaller than the number of possible values N: 1-exp(-r**2/(2N)).

This is a so important result, since my good 32 bit hash functions
in my following software projects can attain only a probability of 50% for a collision at around 77000 cores and and 77000 threads, so it is good for scalability even if i am not using a good 64 bit hash function,
(but i will soon upgrade them to a good 64 bit hash function),
so here is my following software projects:

My scalable parallel varfiler here:

https://sites.google.com/site/scalable68/scalable-parallel-varfiler

And my parallel C++ and Delphi implementations of conjugate gradient sparse linear system solver libraries that scales very well here:

https://sites.google.com/site/scalable68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library

https://sites.google.com/site/scalable68/scalable-parallel-implementation-of-conjugate-gradient-sparse-linear-system-solver

And my scalable RWLock that works across processes and threads here:

https://sites.google.com/site/scalable68/scalable-rwlock-that-works-accross-processes-and-threads

And my Parallel HashList that scales well here:

https://sites.google.com/site/scalable68/scalable-parallel-hashlist



Thank you,
Amine Moulay Ramdane.

[toc] | [next] | [standalone]

#6241

> And my Parallel HashList that scales well here:
> https://sites.google.com/site/scalable68/scalable-parallel-hashlist

# "and my scalable RWLock in each bucket of the parallel hashtable"

What a nonsense. Parallel hash-tables have a lock per 2^N-section
of the hashtable and the number of sections has to be chosen that
there's low likehood of collision on that parts. But a lock per
bucket is a waste of resources.

[toc] | [prev] | [next] | [standalone]

#6243

On Sunday, January 17, 2021 at 4:00:59 AM UTC-5, Bonita Montero wrote:
> > And my Parallel HashList that scales well here: 
> > https://sites.google.com/site/scalable68/scalable-parallel-hashlist
> # "and my scalable RWLock in each bucket of the parallel hashtable" 
> 
> What a nonsense. Parallel hash-tables have a lock per 2^N-section 
> of the hashtable and the number of sections has to be chosen that 
> there's low likehood of collision on that parts. But a lock per 
> bucket is a waste of resources.

Take a look carefully at the source code, you also can set from the constructor 
how many of my scalable rwlocks  to use for the hashtable so that to not waste resources.


Thank you,
Amine Moulay Ramdane.

[toc] | [prev] | [next] | [standalone]

#6244

>> What a nonsense. Parallel hash-tables have a lock per 2^N-section
>> of the hashtable and the number of sections has to be chosen that
>> there's low likehood of collision on that parts. But a lock per
>> bucket is a waste of resources.

> Take a look carefully at the source code, you also can set from the constructor
> how many of my scalable rwlocks  to use for the hashtable so that to not waste resources.

There are three increments in wich people get close to your code.
1. The language is the same they use: they read the code for curiosity.
2. The language is the same they use: they read the code and build
    their own code derived from that.
3. The language is the same they use: they directly take your code
    and use it.
But they almost never would even read your code when it is written
in an abandonned language like Pascal.
So if you want to get noticed at least write your code in a more
commonly used language like C or C*+.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web