Interesting reduce (add) case with Array Notation: is it possible ?

[Zvi_D_Intel]

I have the following code part already using CILK+ Array Notation constructions: out[0:Length] += (p_in_gains[0]*p_ins[0].blks[0][0:Length] + p_in_gains[1]*p_ins[1].blks[0][0:Length] + p_in_gains[2]*p_ins[2].blks[0][0:Length] + p_in_gains[3]*p_ins[3].blks[0][0:Length] + p_in_gains[4]*p_ins[4].blks[0][0:Length]); As you can see, the right part is the sum of arrays located in the array of structures with appropriate coefficients located in the array as well. The expression above is compiled and works in right way. I tried to to simplify it by use of __sec_reduce_add() function as following: out[0:Length] += __sec_reduce_add(p_in_gains[0:5]*p_ins[0:5].blks[0][0:Length]) Compiler reports about "ranks mismutch", and I guess that it cannot understand, what indexes I want to sum-up in reduce operation. Could we give some hints to compiler, what we want to do in this specific case - to make him use reduce operation to sum-up these arrays, instead of performing it manually ?

[Pablo_H_Intel]

Hello Zvi,

The problem is that whay you are looking for is a cross-product but array notation is not designed for that.  In other words, by using p_in_gains[] with an array section, you are trying to increase the rank by one and then use the reduction to reduce the rank again.  Perhaps you were an APL programmer in a former life?

The only thing I can suggest off the top of my head is to use a loop and hope that the auto-vectorizor figures out the reduction.  I don't think there's a way to use a #pragma simd because I don't think there is any way to do a reduction into an array section.

-Pablo

[Zvi_D_Intel]

Hi Pablo,

I don't think that your interpretation is right: even if I will not use (eliminate) p_in_gains[0:5], there is another [0:5] section - I mean p_ins[0:5] in the second factor at the right. How can I hint to compiler, that I want to reduce for this section ?

- Zvi

[Nick_M_3]

Bluntly, you are using the wrong language - this is something that Fortran handles vastly better.  The trouble with CilkPlus is that it starts from C++, and C/C++'s array handling is not brilliant.  It wouldn't be elegant in Fortran, but it could be done cleanly and simply.  This is almost exactly Pablo's point, incidentally - you can do anything in any Turing-complete language, but some tasks fit better in some languages than in others.

I have thought of how to handle your class of problem in a possibly extended C++, fairly recently, and was defeated.  Either it is infeasible, or it needs someone smarter than me.

[Pablo_H_Intel]

I'm not sure I would go as far as Nick in saying that you are using the wrong language.  If you find that you need to do this kind of thing a lot, then, yes, a different language might be more appropriate.  If this is just one small piece of a program that really benefits from C or C++ language features, or if you are simply more comfortable in C or C++, then it probably makes sense to simply accept that this little computation cannot be expressed any more eligantly in Cilk Plus than what you already have.  I do think writing it as a loop might make the code easier to follow, less error prone, and possibly more vectorizable.

-Pablo

[Nick_M_3]

Oh, yes - what I meant that it is the wrong language to achieve that particular objective.  As you say, the effect can be achieved in another way with a bit more complication, and that is quite likely the easiest solution.  A third solution is to use Fortran's C interoperability to call a Fortran procedure that does those tasks but, again, that could well be more complicated than just writing alternative C++ code.  And there are yet other viable solutions ....