Howto Fix - [CnC] Warning: multiple assignments to same item element

Howto Fix - [CnC] Warning: multiple assignments to same item element

Hello,

I have an application where I am trying to change the step granularity of my computation steps by reducing the number of unique tags and having each tag compute over a "tile" of elements every step. What used to be a single-instance step now has a for loop that iterates over a range and does the same work over multiple sets of data. However, when running, I keep getting the warning - "[CnC] Warning: multiple assignments to same item element". The thing is, the final answer is still correct regardless of how many warnings I get. I am pretty sure the warning is due to the loop, since there are puts that occur before gets. I have also tried using the depends clause, and that has not helped the issue at all.

Is there a way to remove this warning? The answer is correct, but having the flood of warnings is skewing my performance timings (i think). I have a version of the application code where all gets occur before all puts, but I am intentionally using this "naive" tiling method to compare performance impact. Any feedback is appreciated.

Thanks,

Chenyang

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi Chenyang,

from your description I read that your loop has gets and puts. This will naturally lead to gets before puts. Without depends this usually causes the warning message since an unsuccessful get will imply the step to restart once the item becomes available. An implication is that all puts that have been issued before will get duplicated and you get the message.

As long as your computation is free of side-effects and deterministic it doesn't matter how often you put an item as its value should always be identical. The runtime will only issue the warning but not overwrite the value. That's probably the reason why your results are the same.

You can always "hack" the "runtime" to get rid of the warning (just look for the error string in cnc/internal/item_collection_base.h), but the additional puts will decrease your performance in any case. You might prefer to correct the steps instead (and keep this nice checking capability).

If your depends method implements *all* gets of the corresponding step, the messages should not appear. However, if the gets depend on item retrieved by previous gets the depends method cannot specify all dependencies. Such data-dependent gets are very rare, so I am not sure if that's what's happening. If you can share (parts of) the code (publicly or privately), I'd be happy to look at it. Maybe there is something else happening.

Maybe a better approach is to split the loop into a get-loop and a put-loop. This might require intermediate storage but is otherwise cleaner (from the CnC perspective).

Another observation: you seem to adjust the grain-size of the steps, but not the data. It is usually more efficient and less error prone to adjust the data-size with the step-granularity. Also, the API comes with so called "ranges" to adjust the granularity of the steps only. You might want to look at this API in the documentation (maybe a good start is here: http://icnc.github.io/api/tag_ranges.html)

Hope this helps

frank

Thank you for your feedback Frank. Turns out, I hadn't correctly instantiated the tuners in the step collections to enable the my dependencies, but I managed to figure it out after looking back at the tutorial page. It was a small detail that I had failed to notice the first few times. I did not have to change the internal system and the warnings disappeared as expected.

In response to your observation. I am actually attempting to vary both the grain sizes of the steps AND data. From what I've seen, increasing the granularity of the steps gives some benefit, but as you said, increasing the data-size granularity yields the best improvements. However, I'm not certain how to use the tag ranges with my application. The application initializes an arbitrarily sized mesh with node and element numbers. Prior to prescribing the steps, I've manually created tiles, similar to the way the default tag ranges work. However, my ranges are not default strides, but instead an array of the node/elements numbers that are adjacent to each other. The tags then become the tile index, and the work performed in my steps are on all the elements or nodes specified by my tile array. I'm not sure how this might differ from using the tag ranges, but maybe tag ranges would be able to allow me to experiment more with the grain size if I can write one function for each separate tag and have a tuner to partition the sets of tags I want per step. Are there any examples on the advance range features?

 

Thanks,

Chenyang

Hi Chenyang,

good to hear you could resolve the warning messages.

 

Unfortunately there are no public examples of advanced uses of ranges/partitioners. I might be able to recover some of my own artificial experiments, but maybe not. In any case, the concept is very simple:

  1. A range is actually a set with only 2 features (see here)

    1. it can be split (by the split-constructor)
    2. it provides an iterator
  2. A partitioner implements how a range is split into sub-ranges providing only 2 things:
    1. divide_and_originate (splitting the range and providing new sub-ranges to CnC by calling originate_range)
    2. and the split type which you can probably ignore for the time being

It is up to you how you store the items in your container-type and how it splits of another range/set. Similarly, it's up to the partitioner to decide how many splits it does per divide_and_originate, whether it operates recursively or not and if it requires an additional interface to the range/set it is operating on (e.g. the default_partitioner requires the range/set to provide an additional method size()). The CnC runtime will take care of everything else.

 

Hope this helps. Let me know if you want me to look for one of my (probably weird) experiments.

frank

Leave a Comment

Please sign in to add a comment. Not a member? Join today