C++ AMP: When may a lambda falsely appear to execute correctly? RRS feed

  • Question

  • Hi!

    I wanted to ask the C++ AMP developers a general question prompted by the issue in thread "C++ AMP const array accelerator_view member and broken lambda result without exception".

    Can you please provide an exhaustive list of all situations known to you (due to bugs, design, driver issues, or programmer error not caught by compiler warning) where a C++ AMP lambda may falsely appear to execute correctly, i.e., without any kind of exception or otherwise obvious indication to the programmer (or user) that something went wrong?

    I am interested in both VS 2012 and VS 2013 targeting x64 on Windows 7, 8 and 8.1 (and corresponding server versions). Also, if you already know of any such issues due to design in VS 2014 I would be interested in that too.

    Am I correct in assuming that your intention is that all issues preventing a lambda from executing as written should be reported as exceptions to the programmer?

    Tuesday, March 11, 2014 12:31 PM

All replies

  • Hi TwoPointSevenOh,

    Regarding your last question -- yes, the intention is that every fault in the system should be diagnosed either by a runtime exception, or in the worst case result in a crash. Silently giving bad results is one of the worst categories of bugs, and we are intending to fix such issues with the highest priority.

    Having said that, sometimes the things are outside of our control, especially when it comes to drivers or even hardware defects (although the latter are nowadays uncommon unless one engages in pushing the hardware outside of its factory recommended operating conditions, "overclocking").

    The practice that cannot be underestimated is to rigorously test the software before rolling out to production in both functional and stress testing aspects. This approach should not only uncover issues with the implementation, but with the underlying system, down to the hardware level, as well.

    Monday, March 31, 2014 8:43 PM
  • Hi Łukasz,

    What you say about testing is of course true. We are already running tests of functionality based on C++ AMP as part of our continuous integration framework, as well as more comprehensive nightly tests (including stress testing). Furthermore, each release is preceded by about a month of intensive functional testing. Each GPU model we support will be individually tested (we'll try to avoid OC stuff :-)). In addition to this we will also run a few tests at application startup (1-3 s) to try to determine if the user is using broken drivers (we estimate that it is unlikely that the user will have full control over driver updates).

    The general idea behind testing is to mitigate the risk of a possible problem occurring to a manageable level, and while no individual test can do this it should be accomplished by the total sum of all mitigations (tests, labeling, instructions for use, etc).

    I believe one useful type of mitigation would be to briefly review the problems a manufacturer of a third party component (in this case C++ AMP) already is aware of...

    So, would it be possible to have a look at an (appropriately edited) list of problems you are aware of that may cause a lambda to falsely appear to execute correctly?

    If you feel this is not the correct forum for this, please PM me at

    Best regards,


    Monday, April 7, 2014 10:19 AM