|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> > even if your algorithms are ok. (OTOH this is not really a problem exclusive
> > to C++, as C and many other "low-level" languages will have the exact same
> > problems.)
> I think that's probably true of pretty much every language.
I was more referring to some things which in theory one shouldn't have
to worry about, and which in many languages *are* things you don't have to
worry about, but in C++ they can bite you if you don't know about them.
One concrete example which is a real shame with most C++ compilers is
memory allocation/deallocation speed. For some reason most compilers (and
very especially gcc) do a very poor job at this, even though they could
demonstrably do it much better.
For example, consider this simple program:
//-----------------------------------------------------------------------
#include <set>
int main()
{
std::set<int> numbers;
for(int i = 0; i < 10000000; ++i) numbers.insert(i);
}
//-----------------------------------------------------------------------
It does nothing else than add 10 million consecutive integers into a
balanced binary tree, and then destroys it and ends.
Compiling this program with "g++ -O3 -march=native" in my system creates
a program which in my computer takes a bit over 15 seconds to run.
Is this time spent into inserting elements and rebalancing the tree?
No. It's mostly spent in allocating memory!
Let's change the 'number' definition a bit:
std::set<int, std::less<int>, FSBAllocator<int> > numbers;
FSBAllocator is a memory allocator I have made. From a functional point
of view it doesn't change anything significant: The program still does the
exact same thing as before, and it even consumes about the same amount of
memory.
However, when I run the modified program, it only takes 2.9 seconds.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |