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


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

Read again, i correct a typo about hash function collision and scalability..

Started byAmine Moulay Ramdane <aminer68@gmail.com>
First post2020-12-22 13:40 -0800
Last post2020-12-22 22:50 +0100
Articles 2 — 2 participants

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


Contents

  Read again, i correct a typo about hash function collision and scalability.. Amine Moulay Ramdane <aminer68@gmail.com> - 2020-12-22 13:40 -0800
    Re: Read again, i correct a typo about hash function collision and scalability.. Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-22 22:50 +0100

#6189 — Read again, i correct a typo about hash function collision and scalability..

FromAmine Moulay Ramdane <aminer68@gmail.com>
Date2020-12-22 13:40 -0800
SubjectRead again, i correct a typo about hash function collision and scalability..
Message-ID<ccf7026e-050f-45d7-9a07-8d8fadbe8382n@googlegroups.com>
Hello...


Read again, i correct a typo 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 implementation 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]


#6190

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-12-22 22:50 +0100
Message-ID<rrtpmf$ohj$1@dont-email.me>
In reply to#6189
> 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),

You have megalomania. There will never be a computer with 77.000 cores
in shared memory. NUMA won't scale to that extend, M(O)ESI won't scale
to that extent and the software also won't scale to that extent. sgi
has dropped is massively parallel shared memory system with its NUMA-
link-architecture because of that.

[toc] | [prev] | [standalone]


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


csiph-web