Re: question on implementing an atomic operation in GP Pari

["Ruud H.G. van Tol" <rvtol@isolution.nl>]

On 2025-08-21 22:04, American Citizen wrote:
> [...] some of the processors are climbing up the list faster than others.
> Currently I have
> n:88181
> n:90889
> n:87145
> n:88285
> n:88633
> n:89245
> [...]
> I can use an alternate scheme, having all 6 cores access an atomic 
> operator and receiving just one unique number from the list, then 
> incrementing the index to the list, this would insure that all numbers 
> are bunched closely together.
> [...]

It's less than 5%, is that really worth any effort?


My favorite pattern is Map-Reduce-Merge:

Map: partition the source data into independent chunks;
Reduce: have W concurrent workers (W is typically between 8-12) each 
process a chunk, then exit with a simple status like 0=completed, and 
start a new worker when needed;
Merge: optionally post-process all results.

The main trick is always to make this lock-free, normally by making sure 
from the start that the reducers can only use "exclusive" resources.
Another is to keep the overhead small, so no big W, etc.

-- Ruud