topic Another way to do private in Software Archive

Cilk Plus's equivalent to firstprivate, threadprivate in OpenMP?

Minjang_Kim — Thu, 06 Oct 2011 02:39:17 GMT

The support of reduction variables in Cilk Plus is outstanding, comparing to OpenMP. However, I was unable to find equivalents to OpenMP's private, firstprivate, threadprivate.For example,

[cpp]#pragma omp parallel for firstprivate(accessor)
  for (int i = 0; i < trip_count; ++i)
  {
    work(accessor.GetWorkData(i));
  }[/cpp]

The above code has 'accessor', which is a simple struct with only POD types.

In OpenMP, it is very easy to allocate this 'accessor' per thread, by using firstprivate, or threadprivate. What would be an optimal approach in Cilk Plus?

Of course, I can write the code that allocates thread-private accessors by using thread id returned by __cilkrts_get_worker_number(), while avoiding false sharing.

I also think I might able to write a class based on reducer and hyperobject.

However, I just want to find a better and elegant solution proposed by Cilk Plus.

Cilk Plus's equivalent to firstprivate, threadprivate in OpenMP

Pablo_H_Intel — Fri, 07 Oct 2011 18:51:37 GMT

What you're looking for is a holder -- a different kind of hyperobject that works a little like firstprivate, lastprivate, and/or threadprivate. By default, a holder works like threadprivate:

[cpp]#include 

cilk::holder accessor_holder;
cilk_for (int = 0; i < trip_count; ++i)
{
    work(accessor_holder()); // separate view for each iteration
}
[/cpp]

Note that you need to put an empty pair of parenthesis after the holder name to cause it to yield its value. (A new syntax for holders and reducers is in the works that will make them look like pointers rather than like function objects.)

To get the effect of firstprivate, assign the holder a specific value at the start of each iteration:

[cpp]cilk::holder accessor_holder(accessor); // Initial value
cilk_for (int = 0; i < trip_count; ++i)
{
    accessor_holder() = accessor; // Initialized to value of accessor at each iteration
    work(accessor_holder());
}
[/cpp]

To get the effect of lastprivate, specify the "keep_last" policy for the holder. This policy causes the holder to retain its "last" value (i.e., the last value that would be set if the program were run serially) at the end of the parallel region:

[cpp]cilk::holder accessor_holder;
cilk_for (int = 0; i < trip_count; ++i)
{
    accessor_holder() = work();  // Modify a different view in each iteration
}
accessor = accessor_holder(); // get value of "last" view[/cpp]

Holders can do a lot more than this, however. Arch Robison wrote an excellent blog entry about holders (including how to create your own holder), although it was written before holders were added as a standard component in the Cilk Plus library. Documentation for holders is available in theIntel C++ Compiler XE 12.1 User and Reference Guides under "Key Features|Intel Cilk Plus|Holders".

At present, holders are available only in C++. A syntax for using holder in C is still under development.

Let us know how they work for you.

-Pablo

Cilk Plus's equivalent to firstprivate, threadprivate in OpenMP

Minjang_Kim — Fri, 07 Oct 2011 19:53:14 GMT

Thanks Pablo, it works as what I wanted to do!

Hi,

Sushek_Shekar — Thu, 11 Apr 2013 22:15:13 GMT

Hi,

I am getting the following error when I tried to do this.

error: missing template arguments before ‘accessor_holder

Another way to do private

Barry_T_Intel — Fri, 12 Apr 2013 13:36:00 GMT

Another way to do private variables in a cilk_for loop is simply to declare them inside the loop body. Then they are allocated on the stack inside the lambda function created out of the loop body and automatically private. The equivalent of a FIRSTPRIVATE variable would be something like

[cpp]

myclass init_value;

cilk_for(int i = 0; i < trip_count; i++)

{

myclass private_value(init_value);

work(private_value);

}

[/cpp]

Since init_value is never modified during the paralllel code, using it to initialize private_value is not a race.

- Barry

When I last tried it,

TimP — Fri, 12 Apr 2013 14:23:59 GMT

When I last tried it, compiling with icc didn't give a warning about the shared induction variable implied by

cilk_for(i=0; ...

while a warning was issued by icpc.

It's definitely important to compile in C99 or C++ mode so as to have a private induction variable, so as not to limit scaling to larger numbers of workers.

Cilkscreen (or Amplifier)

Barry_T_Intel — Fri, 12 Apr 2013 15:54:40 GMT

Cilkscreen (or Amplifier) should tell you about this, as well as any other races in your code. Anyone who writes parallel code should run a race detection religiously. If you haven't checked for races recently, you probably have them.

- Barry

It might be worth noting that

Jim_S_Intel — Fri, 12 Apr 2013 18:34:41 GMT

It might be worth noting that the code environment used in these forum posts sometimes has an ugly habit of swallowing text between "<" and ">" arguments. Notice that the name of the include file in #include < ... > has disappeared. Are you missing the object type in your declaration of a holder?

cilk::holder<ObjectType> accessor_holder(accessor);

Anyway, I have also attached a simple but complete test program that uses a holder, that may be of some use to you.
Cheers,

Jim