which is faster? "vector of structs" or "a number of vectors"?

If a, b and c belong together and form an object together, why the hell would you split them? Go for clarity and readability first. Anything else comes after that. Also, I think v2 would be slower. More access on the vector. Didn't time it though. As always for questions about speed, time it.

A "struct of vectors" has a couple of advantages over a "vector of structs":

• If your inner loop doesn't use every element of the struct, then struct-of-vectors can save on memory bandwidth, as unused element vectors will not be loaded into cache.
• It is easier to vectorize. A struct-of-vectors may enable you to use the vector processing instructions of your processor (through assembly, intrinsics, or clever compilers) to speed up your inner loops.

On the other hand, premature optimization is the root of all evil:

• Using a struct-of-vectors is more difficult, awkward, and obscure.
• You generally don't know where your performance bottlenecks are until you've got your code up and running. Is it worth making your code more verbose, fragile, and difficult? You won't know until you actually profile it.
• The benefits of struct-of-vectors programming vary on a case by case basis. It doesn't always yield a speedup; you could actually end up with worse performance.
• In particular, if your access pattern is random (as opposed to sequential or otherwise localized) a struct-of-vectors organization could end up loading much more useless data from memory, if each cache line includes elements from multiple nearby objects...

So, my recommendation is to use vector-of-structs by default, but keep struct-of-vectors in mind as an alternative (i.e., make sure you can switch later, if you expect sequential/local access patterns and it doesn't cost much effort up front). Once your program is running, you can profile it to see where the performance-critical sections are, and try out struct-of-vector and vectorized operations where they'll do the most good.