Re: about new and delete
In article <cone.1253941921.491847.28315.500@commodore.email-
scan.com>, sam@email-scan.com says...
Jerry Coffin writes:
[ ... ]
Rather the contrary -- there's quite a lot wrong with it. First
of all, what you originally claimed was supposed to be done was
not just insert some data into the collection, but iterate over
the collection to print out the items. Your test doesn't iterate
over the items to print them out, OR do anything else with them.
Sure, Einstein. Since the overhead of dumping three million ints to
std::cout dwarfs the relative differences between the containers' methods=
,
that would make the entire comparison meaningless, nullifying everyone's=
arguments, including yours.
Reread what I said, and note (in particular) the emphasis on "OR do
anything else with them."
Next time, read what's there before you make yourself look like such
a complete idiot!
Second, since you've done nothing with the contents of the
collection, it's entirely possible (in fact rather likely, if you're
using a good compiler) that most of what you've done is being
optimized away completely.
Yea, it's so easy to dispense an endless stream of possibly this, and
possibly that, sitting in one's recliner. Coming up with actual data, to=
back up one's theoretical musings, is always the difficult part.
Yup -- you certainly seem to find it difficult anyway. So far, all
you've managed to show is that you're an idiot -- well, okay, that's
getting back to speculation -- you might be an asshole or a liar
instead!
I can't say exactly how much the
particular compiler you're using happens to do in that direction, but=
Yes. You have no idea. But that doesn't stop you from making affirmative=
conclusions, of course.
If it's impossible to tell for certain what was measured in a
benchmark, then yes, that supports an affirmative conclusion that it
doesn't produce meaningful results.
Third, you're creating an object (either the vector or list) inside
outer loop, so there's a good chance that the creation time is
affecting your results.
Yes. We all know how expensive allocation and initialization of 8 or 12=
bytes on the stack is.
The whole point of the benchmark is to find out how expensive the
operations involved are. It appears that you're starting with an
assumption about what the result should be, codifying that into your
"benchmark" and then expecting everybody to consider it a huge
revelation when those assumptions show up in the results.
Haaaa haaaa haaaa!
Fourth, you're measuring the time for the program as a whole instead
of even attempting to measure it for the part you care about.
You do realize, of course, that startup time is a fixed constant, so by=
subtracting the fixed constant startup time from the total run time, the=
relative performance differences would be even more pronounced.
Quite the contrary, I know perfectly well that startup time is NOT a
fixed constant. Startup time depends most obviously on code size, but
also (to some degree) on how the code is arranged in the file.
It's rarely as important anymore, but at one time I found it quite
useful to optimize startup times. At times I've improved startup
times by a factor of about three without changing the functionality
of the program at all (though I'll openly admit that's an extreme
case).
Especially
in the -O2 case. I can't wait to read your argument how the std::list
version's startup time is so much faster than the std::vector version's i=
s.
Yet again, you've got things backwards. I don't have to know that
there is a difference for the benchmark to be meaningless. Exactly
the opposite is true: I have to know that there's NOT a difference
for the benchmark to be meaningful. If there's any uncertainty, the
benchmark is meaningless.
Fifth, the total time taken by either program is small enough
that there's little certainty that the times you're getting mean
much of anything.
Right. Instead of three samples, you require at least three million, befo=
re
you finally become convinced.
Your "measurements" would remain meaningless no matter how often they
were repeated.
I'll get back to you.
Yes, when you get a clue, do that.
To mean much, you need to increase the total time taken by
(for example) increasing the number of iterations in your outer loop.
Sure thing, Einstein. After increasing the number of iterations by a fact=
or
of ten, the resulting run times for std::list are:
As the previous comments made obvious to anybody with an IQ higher
than a worm's, you need to do a LOT more than just increase the
number of iterations. Get back to me when you get a clue and at least
make some attempt at fixing the other problems with your "benchmark."
[ ... ]
Gee, that makes std::vector look so much better!
What it did was make you look even worse -- difficult though it was
to believe that such a thing was even possible!
Now, there is one minor problem: if we actually print out the
contents, that printing will almost inevitably dominate the overall
Right. What I said, above.
time -- to the point that what we care about will probably be lost in=
the noise.
? and which makes all arguments of std::vector's superioty moot.
If the OP simply wanted to write this one program, you'd be right.
Then again, it seems pretty obvious that a program that simply prints
out what it just asked you to type in is rarely useful in itself (and
even if you really wanted to do that, you could do it pretty easily
without any container at all).
This gets back to that "to anybody with an IQ higher than a worm's"
situation, where it's pretty clear that this program is not really an
end in itself. Instead, it's pretty obvious that (apparently unlike
you) the OP wants to learn at least a little but about how to
program.
That being the case, the difference between vector and list is both
meaningful and relevant.
n.clear();
Bzzzt. You just got caught cheating.
Yes and no. It's true that there is undoubtedly _some_ difference in
speed between emptying an existing vector and creating a new one.
On the other hand, consider the alternatives: if we define the
collection inside the loop, we've also restricted its scope to the
loop, so we have to move the accumulate inside the loop as well:
for (size_t j=0; j<900000; j++)
{
std::list<int> n;
for (size_t i=0; i<10; i++)
n.push_back(i);
total = std::accumulate(n.begin(), n.end(), 0);
}
The accumulate was added simply to assure that the contents of the
collection were used, so the manipulation of the collection wouldn't
be optimized away completely. In this code, however, it's become a
substantial part of what we're timing instead. Arguably, this still
makes some sense though -- it's pretty pointless to create a bunch of
collections we never use, so using the collection every time is at
least somewhat reasonable. It doesn't make a lot of difference though
-- running this a few times, vector still wins (albeit by a rather
smaller margin).
Another possibility would be something like this:
std::vector<int> *n = NULL;
for (size_t j=0;j<iterations; j++) {
=09delete n;
=09n = new vector<int>;
=09for (size_t i=0; i<10; i++)
=09=09n->push_back(i);
}
int total = std::accumulate(n->begin(), n->end(), 0);
In some ways this is great -- we're creating a new collection each
time, and still only accumulating once to prevent the loop from being
optimized away. Unfortunately, with this we'd also be timing a new
and a delete at every iteration, AND all the references to the
collection are via a pointer as well. This adds a lot of overhead to
what we originally cared about.
A quick test shows that with either of these, list is still slower
than vector though.
--
Later,
Jerry.