Vector Class Discussion

 
thread valarray class - Kyle Bentley - 2014-04-07
last replythread valarray class - Agner - 2014-04-08
last replythread valarray class - Kyle Bentley - 2014-04-09
last reply valarray class - Agner - 2014-04-10
 
valarray class
Author:  Date: 2014-04-07 19:40
Hello Agner (Dr. Fog?),

I just stumbled upon your vector class, and I must say it's a piece of art if there ever was one. Thanks for the hard work and many hours you've put into it. I was wondering if you had any plans to, or were interested in applying this class to a templated valarray type container?

Kyle B

   
valarray class
Author: Agner Date: 2014-04-08 01:27
No, I have no plans of making a valarray template.
Please see the discussion at stackoverflow.com/questions/1602451/c-valarray-vs-vector

Suppose you have a large array and you want to do a series of calculations on each element. A valarray would do the first operation on all elements, store the results in a new temporary array; then do the next operation on all elements of the second array, and so on. This is expensive in terms of memory and cache operations. The idea of my vector class library is that the vector size matches an internal register in the CPU. When you do a series of calculations on a large array, you take out the first slice of, say, 8 elements and do the whole series of calculations on that slice. The values will stay in CPU registers through the whole series of calculations and you don't need any arrays for storing the intermediate values.

My plans for the vector class library is to include standard mathematical functions (exp, log, pow, sin, etc.) as inline code. Expect this within a few months. The forthcoming AVX-512 instruction set will double the size of vectors of float, double, and 32-bit and 64-bit integers. I am expecting this in 2016. I think Intel have plans for a 1024-bit extension in a more distant future, but we cannot expect the vector size to keep growing beyond 1024 bits.

   
valarray class
Author:  Date: 2014-04-09 13:55
Thanks for the reply.

I have seen that answer in my search for a faster container, along with a few others. I've also done a lot of testing with std::vector, std::valarray, dynamic arrays (new[]), and all of the analogous boost containers that match. I really didn't notice any significant speed (when applying a single function to all of the elements) increase between any of the contiguous memory based containers. In fact, the valarray was often a few percent slower than its counterparts.

   
valarray class
Author: Agner Date: 2014-04-10 06:50
You are right. It makes little difference what container you are using, as long as the memory is contiguous. There may be a little overhead to iterators and bounds checking, but that's all. You may as well just make a simple array that is sure to be big enough, or use "new" if you need variable size.

The other containers in STL (lists, maps, etc.) are chopping up the memory in a lot of small allocated units, sometimes it has more allocated memory blocks than the number of elements in the container. These containers should be avoided where speed is critical.