Re: Vectors vs Arrays performance
"James Kanze" <james.kanze@gmail.com>
That's bullshit. You have to dereference a pointer in both
cases. In the case of indexing, you have to calculate the
address (both for stack based and for std::vector), and
because these calculations are hidden in some functions with
std::vector (and probably do bounds checking as well), it's
harder for the optimizer to get its hands on them. On the
other hand, if you're using iterators, your code with
std::vector is basically what the optimizer will do with
indexing into a built-in array.
It is not bullshit, in the case of the stack array it is
simply an offset from the current stack pointer, no
dereference required,
You can't access the value without having its address. And the
value is in memory, so accessing it involves dereferencing the
address.
Come on, the difference must be evident with any stack-using
implementation -- that is the most common. For direct array on the stack
tha base address is already in the stack or frame poitner, and need no
extra load. For the other, the base is at arbitrary locaton that must be
loaded in a register with an extra register.
The assy presented shows exactly that. Whether that single extra load, and
associated new area in cache actually measures in an application is a
different question, the difference may get masked entirely by a stall, but
it may as well show.
take a look at assembler output if you do not believe me, you
should see an extra instruction for the dereference of vector
operator[] compared to the stack array []. If you are using a
pointer/reference to the array then they will be the same.
int main()
{
volatile int output;
int a[10];
std::vector<int> v(10);
_asm int 3;
output = a[0];
_asm int 3;
output = v[0];
_asm int 3;
}
What on earth is the volatile doing in there? And the _asm?
Irreelvant to the point, but without such tricks tMSVC would just generate
an empty return for main and remove all the code.
Notice the extra instruction?
I noticed a lot of extra instructions: a volatile, and some
_asm, to begin with.
it's
mov eax, DWORD PTR _a$[esp+72]
vs.
mov ecx, DWORD PTR _v$[esp+76]
mov eax, DWORD PTR [ecx]
If there is an offset calculation, it would add to the last line
respectively, one extra fetch is mandatory.
If you'd have read the rest of my posting, you'd have seen that
I explained what is actually relevant, not some hypothetical
case which doesn't correspond to anything.
Your above-quoted reafoning is simply flawed.
The need to dereference *a* pointer in both cases does not imply that
dereference can be made with the same aount of instructions/code. And it in
not a hypothesis, just the simple fact of life.
TANSTAAFL, extra indirections generally comes with some cost. That we
probably accept for the benefits on the other side, and should not deny.