How is it calculated? Within begin_t(), I see x,y,z,c are all set to 0. After begin_t(), it’s non-zero per threads. So, how would I calculate it? And should it be like this?
It’s something that is automatically estimated by the OpenMP library, and which can be hardly determined by advance, as the multithreading strategy possibly depends on environment variables that could be set and that are specific to OpenMP (see 6 Environment Variables).
Hmm, does this mean that in some cases, when you do 120000,1,1,1,:t, it doesn’t necessarily follow 0,1,2,3,4,5,6....? That would break my combinatorics commands because these operate under that assumption.
Yes.
When multiple threads are running at the same time, basically you cannot tell:
- If the index
0will be the first index processed. - If the image slots will be processed in a sorted order (each thread could process indices in increasing or decreasing orders, or even in an interleaved order).
- How many indices each thread will process.
The only things you know is you’ll process all image indices. But do never assume something about the order of processing.
1 Like
It’s the part of interleaved order that led me to find a new approach which doesn’t make that assumption.
120000,1,1,1,:t leading to something like 0,1,0,1… would break it.
So, what I did is something like this:
120000,1,1,4 => image_to_process
{$condition?$_cpus:1},1,1,1,whd#-1-(w-1-x)*int(whd#-1/w);
if $condition mode=: else mode=> fi
eval. $mode"
p=j(-1);
while(++p<i,
I[#-2,$image_to_process]=values_of_pixels;
);
rm.
This approach assure that the interleaving situation does not come up.
It also a little faster too.