Quote from: kTimesG on June 02, 2025, 03:49:55 PM

Quote from: AlexanderCurl on June 02, 2025, 12:50:26 PM

Okay. Will break it down to you.
Tests for bloomfilter creation were made in terms of final binary image being equal for one thread and multiple threads creation.
In both cases the resulting binary image was equal.
.

Not sure what you're trying to explain, I didn't see a mention that the insert method is thread-safe (that would have been sufficient, but also required). It's your code after all, so I guess when you get burned, you're doing it in a very assumed way. Bugs of these type can show up after executing many trillions of cycles, or instantly, depending on the input. Having identical outputs after thousands of runs means nothing, since the core issue is unaddressed.

The bloomfilter binary images are identical for one thread approach and for multiple threads.
So what is hard for you to grasp. The two have identical bits in every byte.
Mutex locks are necessary when multiple threads read, write and modify the same value. And order of their actions matters.

At the beginning all bits of a bloomfilter are off (set to 0).
The insert function sets some bit to 1 according to hash_value modulo bloomfilter size.
The race condition may happen very often. But which one thread will set the bit to 1 first does not matter.
The bit will be set to one as a result. If you are so worried about that feel free to use mutex lock on bloomfilter insert action.
It is easy to test when collision situation will happen. But I do not feel it necessary.

The whole principle of open-source code is that anyone can download and modify to the extent he desires.
Be my guest to present the improved version in your github. But I do not know what for.
It is not a puzzle-solver. RetiredC has already shown what is needed for that.
Array of GPUS and a SOTA method. Grin

Since I have doubts that someone will ever find what is needed for inverse function to SCALAR_MULTIPLICATION.