6

In the vDSP functions of the Accelerate Framework, all the functions require you to input a result vector. Is it correct to pass the input vector (or one of the input vectors) as the result vector if I no longer need whatever was in the original input vector?

Example of what I mean:

vDSP_vsadd(input_vector,1,scalar_addition,input_vector,1,length);

This would take the input_vector and add a scalar_addition to all the elements. The result would be stored in the input_vector.

user1357607
  • 214
  • 4
  • 13

1 Answers1

5

The simple vector operations in vDSP all work correctly in-place (so long as they are strictly in-place; for instance you can't use &input_vector[length/2] for output and expect to get meaningful results). In fact, using them in-place will often give better performance, as it can reduce cache pressure.

Some of the more complicated vDSP operations do not support in-place operation with one or more of their arguments; this should be called out in the vDSP reference guide.

Stephen Canon
  • 103,815
  • 19
  • 183
  • 269
  • I take it that 'in-place' means exactly what I was describing - that the input vector is changed to be the output vector? I did a quick search of the vDSP Reference Guide and found the only times 'in-place' appeared in the document were in reference to sorting and fft algorithms, does this mean that the simpler functions do not support 'in-place' result vectors, or is it that the simpler functions so obviously support 'in-place' that it doesn't need to be documented? – user1357607 Aug 27 '12 at 23:54
  • 2
    Yes, "in-place" means what you're describing; it should be documented explicitly for the simple functions, but isn't. – Stephen Canon Aug 28 '12 at 01:18
  • @StephenCanon, could you please refer to vDSP documentation where it is said that some functions are safe for in place vector operations and some are not. I am really struggling to find this in documentation. – Valeriy Van Jul 17 '19 at 13:58
  • 1
    @ValeriyVan: as I said in the comment above yours, "it should be documented explicitly for the simple functions, but isn't." The closest thing is in the header, under const parameters: "If the specification of a routine does not state that it alters the memory that a parameter points to, then the routine does not alter that memory through that parameter. (It may of course alter the same memory if it is also pointed to by an output parameter. Such in-place operation is permitted for some vDSP routines and not for others.)" – Stephen Canon Jul 17 '19 at 14:27
  • (ctd) However, I was an engineer on the Accelerate team for 13 years, and I can confirm that in-place operation is officially supported and tested for all the simple vector operations. – Stephen Canon Jul 17 '19 at 14:30
  • @StephenCanon, Then it, firstly, raises question what a simple operation is. May I expect `vDSP_mtrans` to make transpose in place? Second, if in place operation isn't guaranteed for a function in documentation/specification, could this undocumented in place operation stop to work in future? – Valeriy Van Jul 18 '19 at 11:31
  • @ValeriyVan By "simple" in this context I mean specifically "result[n] depends only on input0[n], input1[n] ... inputm[n]". That's not a complete list; some of the other API also support in-place operation, but they're harder to characterize. These cases are all part of the test suite (and depended on by a lot of existing software), so no, they can't stop working in the future. – Stephen Canon Jul 18 '19 at 19:09
  • mtrans could be written to support in-place operation, but it does not currently, and it's relatively unlikely that would be added unless there was a clear need for it. The main exception to the lanewise dependence rule I mentioned is FFT / DFT / DCT functions that are explicitly documented to support in-place operation. – Stephen Canon Jul 18 '19 at 19:11