POV-Ray : Newsgroups : povray.off-topic : Interesting take on C++ vs others... : Re: Interesting take on C++ vs others... Server Time
5 Sep 2024 19:24:55 EDT (-0400)
  Re: Interesting take on C++ vs others...  
From: Warp
Date: 2 Jun 2009 15:59:05
Message: <4a258489@news.povray.org>
Darren New <dne### [at] sanrrcom> 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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.