Copy link to clipboard
Copied
I am trying to use iterate_generic to perform iteration.
It seems to be working, but I have one question.
As the name suggests, thread_indexL seems to represent the index of the thread. But what is i?
When I try (thread_indexL == i) within iterate_generic, it is TRUE every time.
When I use another iterate_generic within iterate_generic, it is TRUE every time.
I want the thread number to start from zero, but is it possible that either thread_indexL or i will not do so?
"i" is the iteration index.
you can call iterate_generic for 1000 repetitions. it will be called on all available threads, but not with sequential values of "i".
the first passed value of "i" may very well be 500, followed by 200. the reason for this is to minimize cpu cache conflicts. sometimtes it's helpful, the rest of the time it's benign.
so say AE has 4 threads and are have requested 8 repetitions. the calling sequence may look like:
thread 3, i 6.
thread 0, i 0.
thread 1, i 2.
thread 3 i 7
...good question...
to the best of my knowledge, the number of available threads doesn't change throughout the AE session.
the decision on PF_Iterations_ONCE_PER_PROCESSOR is more of an optimization decision highly relying on your algorithm.
for image processing, i almost never use PF_Iterations_ONCE_PER_PROCESSOR. why? becuase if working one chunk pre processor, some threads are bound to fininsh processing before the others, and then these processors don't lend a hand with the remainig work on the
...Copy link to clipboard
Copied
"i" is the iteration index.
you can call iterate_generic for 1000 repetitions. it will be called on all available threads, but not with sequential values of "i".
the first passed value of "i" may very well be 500, followed by 200. the reason for this is to minimize cpu cache conflicts. sometimtes it's helpful, the rest of the time it's benign.
so say AE has 4 threads and are have requested 8 repetitions. the calling sequence may look like:
thread 3, i 6.
thread 0, i 0.
thread 1, i 2.
thread 3 i 7.
thread 2, i 4.
thread 2, i 5.
thread 0, i 1.
thread 1, i 3.
the thread number CAN be the same as the thread index (for example when calling 8 repetitions on 8 threads it could happen by chance), but if that's always the case for you, then something is wrong.
also, calling iterate_generic from within an iterate_generic call sound like a mistake... in any case, you shouldn't call that suite from any thread other than therad 0...
Copy link to clipboard
Copied
Wow! Thanks for the quick reply.
I understand!
I have set iterationsL to PF_Iterations_ONCE_PER_PROCESSOR so it seems that number of iterations == number of threads (i == thread_idxL).
The reason I nested iterate_generic is for experimentation!
I don't use it in the actual code.
May I ask a related question?
Since I have set iterationsL to PF_Iterations_ONCE_PER_PROCESSOR, I am using height/AEGP_GetNumThreads to determine y that one thread is responsible for.
Between AEGP_GetNumThreads and iterate_generic I do the following
Height/AEGP_GetNumThreads
making refCon for arguments
Can the actual number of AEGP_GetNumThreads change during this time?
If it can be changed, instead of using PF_Iterations_ONCE_PER_PROCESSOR, I might be better off iterating line by line.
Copy link to clipboard
Copied
good question...
to the best of my knowledge, the number of available threads doesn't change throughout the AE session.
the decision on PF_Iterations_ONCE_PER_PROCESSOR is more of an optimization decision highly relying on your algorithm.
for image processing, i almost never use PF_Iterations_ONCE_PER_PROCESSOR. why? becuase if working one chunk pre processor, some threads are bound to fininsh processing before the others, and then these processors don't lend a hand with the remainig work on the other threads. so working with n iterations assures minimal loss of available cpu power for almost all of my image processing algorithms.
Copy link to clipboard
Copied
I see!
I'd like to explore the appropriate way to divide it.
Thank you for your accurate and helpful advice!