by nickoppen » Sun May 15, 2016 7:32 am
Hi dar,
I was doing a little experiment with the calls you described above by modifying the hello_world2 example.
I was testing out my assumptions about the calls. My understanding is that the call coprthr_get_thread_id() returns the logical thread id and will be between 0 and coprthr_get_num_threads() - 1. This allows your kernel to decide how to split up the task and what chunk each thread should take. The call coprthr_corenum() on the other hand will return a value from 0 to 15 depending on which core it is on thus it can be used to determine where the kernel is running in the mesh (thus be used to decide on nearest neighbours etc.). Is this on the money?
In hello_host.c you have a coprthr_dwait() call after the coprthr_dexecv() suggesting that the coprthr_dexecv runs asynchronously. I exported COPRTHR_DEVICE_NTHR=8 and called the kernel twice as is and using the call coprthr_dexecv(dd, "hello_device.e32", argv, COPRTHR_E_NOWAIT) but I found that each call runs sequentially. Having not seen any documentation on coprthr_dexecv() I'm wondering if this is a bug or if the coprthr_dwait() is redundant.
Also, I noticed that setting COPRTHR_DEVICE_NTHR to a value greater than 16 gives me a "thread pool too big" error.
nick
Sharing is what makes the internet Great!