Dev Stack Source

Answer : Both CPUs & GPUs provide SIMD with the most standard conceptual unit being 16 bytes/128 bits; for example a Vector of 4 floats (x,y,z,w). Simplifying: CPUs then parallelize more through pipelining future instructions so they proceed faster through a program. Then next step is multiple cores which run independent programs. GPUs on the other hand parallelize by continuing the SIMD approach and executing the same program multiple times; both by pure SIMD where a set of programs execute in lock step (which is why branching is bad on a GPU, as both sides of an if statement must execute; and one result be thrown away so that the lock step programs proceed at the same rate); and also by single program, multiple data (SPMD) where groups of the sets of identical programs proceed in parallel but not necessarily in lock step. The GPU approach is great where the exact same processing needs be applied to large volumes of data; for example a million vertices than need to be transform...

Answer : I believe that it's talking about a different detail. The unary_op takes an element of the sequence and returns a value. That value is stored (by transform ) into the destination sequence. So this unary_op would be fine: int times2(int v) { return 2*v; } but this one would not: int times2(int &v) { return v*=2; } But that's not really what you're asking about. You want to know if you can use the unary_op version of transform as a parallel algorithm with the same source and destination range. I don't see why not. transform maps a single element of the source sequence to a single element of the destination sequence. However, if your unary_op isn't really unary, (i.e, it references other elements in the sequence - even if it only reads them, then you will have a data race). To quote the standard here [alg.transform.1] op [...] shall not invalidate iterators or subranges, or modify elements in the ranges this forbids y...