[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/bbcode.php on line 112: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4688: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4690: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4691: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4692: Cannot modify header information - headers already sent by (output started at [ROOT]/includes/functions.php:3823)
Parallella Community • View topic - COPRTHR 2 Discussion

COPRTHR 2 Discussion

Discussion about Parallella (and Epiphany) Software Development

Moderators: amylaar, jeremybennett, simoncook

Re: COPRTHR 2 Discussion

Postby nickoppen » Wed May 04, 2016 10:56 pm

Thanks DAR,

Also, am I correct in assuming that C++ support in COPRTHR2 is not complete at this point?

Without and extern "C" {} the linker can't find any of the coprthr calls but when I put an extern "C" {} around the coprthr include files I start getting weird problems with the std namespace.

I'm happy to stick with C for now if that's the case but if it should work I'll stick with it and let you know how I go.

nick
Sharing is what makes the internet Great!
User avatar
nickoppen
 
Posts: 266
Joined: Mon Dec 17, 2012 3:21 am
Location: Sydney NSW, Australia

Re: COPRTHR 2 Discussion

Postby dar » Thu May 05, 2016 2:26 am

All of the testing right now is with C code. There may be some things that require sorting out with C++ since so much was redesigned, and we will try to get to that, but for now stick with C.
dar
 
Posts: 90
Joined: Mon Dec 17, 2012 3:26 am

Re: COPRTHR 2 Discussion

Postby DonQuichotte » Mon May 09, 2016 10:05 am

Hi

Seems to be some nice piece of work to try ; as soon as I can, maybe next week-end.

I'm interested in a minimalist SPMD style of coding.
After initial success with the official e_write() / e_read() from e_lib.h
I encountered severe issues with the -msmall16 gcc 4.8.2 option from the SDK 2015.1, headless 7020 image.
When you have only 32 Kb/core such an option should not be an option but a mandatory optimization imo ; but that's another post.

So I wondered if Coprthr 2 is compatible with the -msmall16 feature without breaking the host/device communication ?
User avatar
DonQuichotte
 
Posts: 46
Joined: Fri Apr 29, 2016 9:58 pm

Re: COPRTHR 2 Discussion

Postby dar » Mon May 09, 2016 1:58 pm

-msmall16 has not been tested but here is my guess. It should not break host/device communication since the hostcall table is kept within the 32k. The issue I see is in making calls to code stored in global memory, but this would be a minor issue that could actually be fixed using the dynamic call table support. So there cold be problems initially but they should be solvable.
dar
 
Posts: 90
Joined: Mon Dec 17, 2012 3:26 am

Re: COPRTHR 2 Discussion

Postby nickoppen » Tue May 10, 2016 10:39 am

Two questions if I may...


The files coprthr_xdevice.h and sl_engine.h define get_global_id(void) but calling:

unsigned int gid = get_global_id();

or what I used before:

unsigned int gid = get_global_id(0);

returns: /home/parallella/Work/passing/ringTopo16.c:6: undefined reference to `get_global_id'.

If I don't want to use MPI (i.e. MPI_Comm_rank()) how can I determine the core id?

And

barrier(int kind) is defined in e32path_if_needham.h which seems to be found by the compiler. However:

barrier(CLK_LOCAL_MEM_FENCE | CLK_GLOBAL_MEM_FENCE);

returns:

/home/parallella/Work/passing/passCL.c:61:21: error: ‘CLK_LOCAL_MEM_FENCE’ undeclared (first use in this function)
/home/parallella/Work/passing/passCL.c:61:43: error: ‘CLK_GLOBAL_MEM_FENCE’ undeclared (first use in this function)

I can't fine any sort of *FENCE* definition anywhere. What should I use here?

nick
Sharing is what makes the internet Great!
User avatar
nickoppen
 
Posts: 266
Joined: Mon Dec 17, 2012 3:21 am
Location: Sydney NSW, Australia

Re: COPRTHR 2 Discussion

Postby dar » Tue May 10, 2016 2:22 pm

dar
 
Posts: 90
Joined: Mon Dec 17, 2012 3:26 am

Re: COPRTHR 2 Discussion

Postby 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!
User avatar
nickoppen
 
Posts: 266
Joined: Mon Dec 17, 2012 3:21 am
Location: Sydney NSW, Australia

Re: COPRTHR 2 Discussion

Postby dar » Sun May 15, 2016 12:56 pm

dar
 
Posts: 90
Joined: Mon Dec 17, 2012 3:26 am

Re: COPRTHR 2 Discussion

Postby nickoppen » Sun May 15, 2016 10:47 pm

It seems that I was wrong.

I changed my code. I put a printf in the host code before each coprthr call and a big wait loop in the kernel with the number of iterations increasing as the the logical id increased. The host output appeared first, then the output of the first kernel call and then the second call.

So, on the host side, the calls to the kernel were being executed asynchronously and the coprthr_dwait was waiting. The kernels were being executed sequentially even though they could have run in parallel given that both were executed 8 times. I assume that this is the expected behaviour?

To do my experiment then I'll try coprthr_dnexec(...).
Sharing is what makes the internet Great!
User avatar
nickoppen
 
Posts: 266
Joined: Mon Dec 17, 2012 3:21 am
Location: Sydney NSW, Australia

Re: COPRTHR 2 Discussion

Postby nickoppen » Thu May 19, 2016 1:31 am

I wrote a little program using coprthr_dnexec but cldebug tells me that this call has been "temporarily disabled".

Is there a call that I can use that will launch two different kernels at the same time?
Sharing is what makes the internet Great!
User avatar
nickoppen
 
Posts: 266
Joined: Mon Dec 17, 2012 3:21 am
Location: Sydney NSW, Australia

PreviousNext

Return to Programming Q & A

Who is online

Users browsing this forum: No registered users and 10 guests

cron