Execution failure

Execution failure

Here's an unlikely failure when a closure is executed after ArBB compilation.

It's a simple sparse-matrix dense-vector multiply, resulting in a dense vector. The sparse matrix has at least one non-zero entry in each row, which is generally true for realistic problems, so it can be thought of as a flattened nested container (i.e. dense vector)withcompanion dense vectors forsegment length and coefficient column index. This exampleincludes a dense vector for segment offset, as it helps illustrate the failure.

The closure function is...

void foo(dense &Ans, const dense &Vec, const dense &Spm,
const dense &Len, const dense &Idx, const dense &Off)
{
dense tmp = Spm*gather(Vec, Idx);
Ans = add_reduce(reshape_nested_lengths(tmp, Len)); // fails
// Ans = add_reduce(reshape_nested_offsets(tmp, Off)); // works
}

...we can use this data...

dense idx = dense::parse("{0,1,2,1,2,3}");
dense len = dense::parse("{1,2,2,1}");
dense off = dense::parse("{0,1,3,5}");
dense spm = dense::parse("{1.,.5,.5,.5,.5,1.}");
dense vec = dense::parse("{1.,2.,3.,4.}");
dense ans;
// answer will be {1, 2.5, 2.5, 4}

...and compile this...

const closure &, const dense &, const dense &,
const dense &, const dense &, const dense &)>bar = capture(foo);
bar(ans, vec, spm, len, idx, off);
bar(ans, vec, spm, len, idx, off); // 2nd call fails, executable dies

But if we comment out the 2nd line of foo() using the 3rd line instead, it works as expected (but is much slower, by the way,which is unexpectedas segment offsets are merely the running sum of the segment lengths).

- paul

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

PS: the failure seems to come when "tmp" infoo()is any calculation, not fixed data.

PPS: just FYI, if the sparse matrix does have a row with no non-zero entries simply install a zero (in any column).

Paul,

Thanks for reporting the problem. I need to run the code myself and do some investigation. I'll get back to you as soon as possible.

Thanks,
Zhang

Hi Zhang,

Thank you for your attention, this is important to me and should be to others: the add_reduce( reshape_... (dense * gather(...), shape_info)) is the"one liner" for ArBB sparse-matrixdense-vector multiply. It would be good to optimize the heck out of this idiom.

In general for beta 4, it seemsall the other reshape_... functions have some difficulty. I've tried them all, creating required arguments, and get execution failures, illegal memory access exceptions, etc.

Will there beanother beta release soon?

Thank you,
- paul

PPPS: gather(Vec, Idx) may also be written Vec[Idx], which gets converted in dense_impl.hpp line 385.

Paul,

Thanks for your patience. We really appreciate your concise sample code. It makes it very easy to reproduce the problems you reported. It turns out ArBB currently has multiple issues with nested containers. We have found many operations involving nested containers do not work well, for example:

  • scatter and gather
  • repeat
  • reduction and scan
  • parse

We understand that the ability to write "one-liners" is important to you and many other ArBB users. The engineering team is working on revamping the entire interface for nested containers. The first step of this effort is to focus on correctness. The second step is to improve performance.

As to the next release, we will inform you and the forum as early as possible when a new release is coming. Meanwhile, please let us know whether this issue is blocking you make any progress. In other words, do you have a workaround for this issue?

Thanks,
Zhang

Hi Zhang,

Yes, I'm covered. My (ab)use of nested was toreplace a map() technique that works, but is slower.(How do I know this? Nested still worked for fixeddata, soIused that for timingtests.) I'll revisit this code when things get fixed.

What does "revamping the entire interface" mean? Something internal to ArBB, or will the calls change?

Best regards,
- paul

Paul,

We may introduce some new functions to make the nested container easier to use. Changes to the existing interface will be minimum. We will also clarify the usage of some functions, for example, reductions and scans on nested containers.

Zhang

Leave a Comment

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