Issues on paralyzation computation programming of xcore Topic is solved

[yuema]

Hi there!

I'm doing some research on computational control based on XE200 core, including online optimization and control allocation tasks. As my project is designed to highly embedded requirements, therefore, some high performance parallel computation methods,such as MPI, openMPI on general CPU, as well as CUDA based on GPU are not preferred. In my project, I plan to employ XE200 do some computation of matrix product and Singular Value in parallel, which would be key part of online optimization program.

My question is that:
According to the programming guide of XMOS, "task placement only occurs in the main function and is made by using the on construct within a par." in page 19. However, in my case, parallel task would be addressed to some sub tasks, not be in main function.

So, does anyone would like to share any instructions on my issues?

Regards

[Bianco]

You can create new parallel tasks from anywhere in XC using the par statement, not only in the main function. You can easily implement a fork/join that way. Any par statement not in a main function will only be able to create tasks on the same tile.

[yuema]

Cheers!

But, if my functions are assigned to the specific cores, say using "on tile[1] . core [0] " to "on tile[1] . core [7] " for function 1 to function 8 respectively, compile errors are reported such as:
can only specify 'on' in function `main'
combinable function must end in a `while(1){select{..}}' or combined `par' statement

So, is it to indicated that task assignment to the specific core is not permitted according to the grammar rules of XCORE ?

Regards

[Bianco]

Cheers!

But, if my functions are assigned to the specific cores, say using "on tile[1] . core [0] " to "on tile[1] . core [7] " for function 1 to function 8 respectively, compile errors are reported such as:
can only specify 'on' in function `main'
combinable function must end in a `while(1){select{..}}' or combined `par' statement

So, is it to indicated that task assignment to the specific core is not permitted according to the grammar rules of XCORE ?

Regards

You can't use the on specifier for a par statement not in the main function and in 99.9999% of the cases you don't care which xCORE is used on a tile, they are all the same

[yuema]

I'd like to explain my project in detail.

My first job is to calculate the matrix product in parallel. For example, I plan to divide each matrix into 8 parts, and use tile[1].core[0] to tile[1].core[7] to compute the product for each part of matrix. As each tile share the same memory, then, I can malloc a area for the intending result matrix, then, passing by reference, on finishing the calculation of each core, the total 8 parts will be carried out in parallel, thus, calculation time will be saved and subsequently, a super real-time control performance can be achieved.

[infiniteimprobability]

I'd like to explain my project in detail.

Sounds like fun!

if my functions are assigned to the specific cores, say using "on tile[1] . core [0] " to "on tile[1] . core [7] " for function 1 to function 8 respectively, compile errors are reported such as:
can only specify 'on' in function `main'
combinable function must end in a `while(1){select{..}}' or combined `par' statement

The .core[n] syntax is a fairly recent thing that was added as a way to instruct the tools to combine tasks. For example, two tasks par'ed on tile[1].core[0] will be flattened into a single big select by the tools.

Combining tasks is probably not useful in a compute application as they will compete for MIPS in a co-operative manner.

When forking tasks which are not combined, it's actually better to omit the .core[n] placement information. The physical thread number/id it gets run on does not matter and you will also guarrantee each task has it's own logical core (thread...register context.. etc.). The placement on a dedicated logical core is actually implicit in this case.

I think the errors you are seeing are the compiler trying to combine tasks, and with combinable tasks come constraints such as having the while(1){ select{ form.

SO try removing the .core[n] bit!