POV-Ray : Newsgroups : povray.off-topic : Interesting take on C++ vs others... : Re: Interesting take on C++ vs others... Server Time
6 Sep 2024 01:25:32 EDT (-0400)
  Re: Interesting take on C++ vs others...  
From: John VanSickle
Date: 2 Jun 2009 20:54:47
Message: <4a25c9d7$1@news.povray.org>
Warp wrote:
> 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.

Does it do something simple, like anticipate future needs based on the 
current vector size?

Regards,
John


Post a reply to this message

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