Heap efficiency?

[TheCPUWizard]

. I think there's a very good reason why Alexandrescu devotes 20 percent of his much acclaimed Modern C++ Design book to efficient small object allocation and smart pointers.

One has nothing to do with the other. And 18 out of 314 pages is less than 6%. This means that 94% of the book has NOTHING to do will allocatrion. Even that 6% is related specifically to small object allocation, and not allocation in general. Even with in that chapeter the performance is referred to as a "bump in the road" (pg 78) and not as a major issue in the persuit of an efficient C++ program..

I realize my conclussions are based on hearsay and personal experience. Therefore I would wellcome an ambitious investigation from some independent party into how different allocators influence the performance of OO programs. If it turns out that standard (or maybe they should be called general) allocators are good enougth then fair enougth. But until then I prefer an allocator with the outspoken objective of performing well under the OO programming style. That's the "standard" allocator I want. I don't quite understand why there's such an opposition to such a wish. Why would it be so much better if I use the allocator that came with the compiler?

Because (Alexandrescu , Sutter, and Meyers agree) the relevance of this issue is specific to the type of application, the comparision has to be done for specific application.

YOU alread have a set of applications where you have used an alternate allocation.

You should have performance metrics (time and resources) of each application level action. For a GUI application (desktop or Web) this means response times for each possible user action (button click, menu selection, etc.) under a variety of conditions. [A typicall application will have anywhere from a few dozen sample points to a few hundred, and large applications may have a few thousand]. These should all be part of you normal testing process and proceedures.

Take your existing applications and simply disable the replacement allocator (should be commenting out just a few lines) , and re-run the same suite of tests. Compare the numbers as a percentage, relative to the specification for each item.

You will then have a documented case of how many places in your application your replacement allocator allowed you to meet a specification where the default allocator would have caused a failure.

And most importantly, the number will be based on your specific style of writing applications, and therefore likely be applicable to future works.

[_uj]

One has nothing to do with the other. And 18 out of 314 pages is less than 6%. This means that 94% of the book has NOTHING to do will allocatrion. Even that 6% is related specifically to small object allocation, and not allocation in general. Even with in that chapeter the performance is referred to as a "bump in the road" (pg 78) and not as a major issue in the persuit of an efficient C++ program..

I referred to small object allocation AND smart pointers. These two topics constitute approximately 20% of the book.

Although policy-based design may be the main message of the book it also carefully describes the design and implementation of an actual library called Loki. In my view the fact that 20% of the book is devoted to efficient small object management is a very strong indicator of the importance of these topics in modern C++ design.

And this is what Alexandrescu actually says about it (in 4.10 Summary):

---

"Some C++ idioms make heavy use of small object allocation on the free store. This is because in C++, runtime polymorphism goes hand in hand with dynamic allocation and pointer/reference semantics. <snip> This renders the default free store allocator unsuitable for allocating small objects because it is often slow and brings nonnegligible per-object memory overhead. <my emphasis>

The solution is to rely on small-object allocators - specialized allocators that are tuned for dealing with small memory blocks (ten to hundreds of bytes)"

---

To me it couldn't be clearer. If you're into the OO programming style and make heavy use of small objects (like smart pointers for example) then it's a very good idea to use a better allocator than the "standard". Nothing will convince me that this isn't what he says.

[TheCPUWizard]

To me it couldn't be clearer. If you're into the OO programming style and make heavy use of small objects (like smart pointers for example) then it's a very good idea to use a better allocator than the "standard". Nothing will convince me that this isn't what he says. So I stop here.

WHEN do you ever allocate SmartPointers as standalone objects on the Heap???? Smart pointers are 90%+ of the time...

1) Created on the stack.
2) Members of a larger allocation (ie the containing object).

If you have code that looks like:

smart_ptr *p = new smart_ptr();
//... use pointer
delete p;

Then you have a very unusual programming style.

Please post a histogram of the allocations from one of your programs (x-axis =size; y-axis=count).

You are also ignoring the fact that (nearly) every reference you have provided uses terms such as "often","typical","common". Without a context, these are totally subjective. As an example 0.001% (1 in 10,000) is the definition of a "common side-effect" in pharmacuticals, and 1ppm (1 in 1,000,000) is the standard measure for a "typical presence" when measuring purity of bi-layered optics. I personally consider a software situation "often" if I encounter it 2-3 times over a 5 year period dealing with my clients.

Lastly, smart pointers, NEVER provide a performance improvement (in either size or time) over raw pointers. At best they impose a negligable performance penalty. Their purpose is to improve reliability and maintainability. As such they have no bearing on this discussion; yet (based on the length of material) Andre considered them more than twice as important.

[_uj]

WHEN do you ever allocate SmartPointers as standalone objects on the Heap????

I'm talking about non-intrusive reference-counting smart pointers, like the one in Boost that's suggested for the upcoming C++ standard. This kind of smart pointer is almost always implemented with the reference counter (typically a long) allocated on the heap.

This is why intrusive smart pointers may be of interest for performance reasons. Here the reference counter is made part of the class so when an object is allocated on the heap the counter is already part of it. This avoids an extra heap allocation for just the counter of the smart pointer managing that object.

Then you have a very unusual programming style.

No, my programming style is normal. It's just that I know how smart pointers work under the hood. This is also why I know to appreciate a small object allocator.

[TheCPUWizard]

There is a nasty implication in your last post, that I do not "know how smart pointers work under the hood". I am sure that would suprise the multiple vendors who utilize my firm and I for their pre-beta review and testing.

I am just going to wait for you to post (publically or privately) the comparitive performance and/or the distribution histograms that will provide evidence of your point of view.

[TheCPUWizard]

For other readers who are following this thread (based on the relatively high read count..)

Lets look at Boost and the implementation of shared_ptr.

“Boost is one of the most highly regarded and expertly designed C++ library projects in the world.”

— Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

This is a non-intrusive reference counting pointer (meaning the reference count is managed by the pointer system and not by the object itself).

The key declaration is:

class sp_counted_base
{
private:
    long use_count_;        // #shared
    long weak_count_;       // #weak + (#shared != 0)

public:
    virtual ~sp_counted_base() // nothrow
 //...
}

This means that the object size is going to be:

sizeof(sp_counted_base) = 2*sizeof(long) + sizeof(vptr).

Which means a fixed size on most (32 bit) machines of 24 bytes - the exact size is not important, the main points are:

1) ALL Instances are the same size
2) Instances do NOT reference other blocks of memory
3) The instance size IS (what nearly everyone would consider) SMALL
4) The instance size IS NOT the sizeof(T *) nor of sizeof(smart_ptr<T>).
5) There are likely to be a large number of thiese instances created and destroyed during application execution.

When combined these traits directly match the conditions where the standard allocator's performance is at its worst.

Yet the boost library DOES NOT REPLACE THE DEFAULT ALLOCATOR! because of this.

Rather it follows the approach of specifically (with various options based on preprocessor definitions of BOOST_SP_USE_STD_ALLOCATOR and BOOST_SP_USE_QUICK_ALLOCATOR) of overriding operator new for the specific class in question. (sp_counted_impl.hpp in the details subdirectory).

[_uj]

There is a nasty implication in your last post, that I do not "know how smart pointers work under the hood". I am sure that would suprise the multiple vendors who utilize my firm and I for their pre-beta review and testing.

I am just going to wait for you to post (publically or privately) the comparitive performance and/or the distribution histograms that will provide evidence of your point of view.

Well, pulling rank won't strengthen your argumentation. It's pretty obvious from post #34 that you're not aware of the fact that shared smart pointers allocate a reference counter on the heap (and that they therefore benefit significantly from a small object allocator).

I'm not into the "look at me" argumentation you seem to favour. You'll have to make do with public evidence. This for example are timings of different implementations of the the Boost Shared Pointer,

http://www.boost.org/doc/libs/1_37_0...smarttests.htm

Loser is "simple counted" which uses heap allocation. Winner is the intrusive pointer, but almost as good is "special counted" which uses the equivalence of a small object allocator.

[ahoodin]

Guys I don't think all this is necessary.

Keep in mind whining will show up for years, unless the thread is reworked, and all this complaining is searchable from google.

How embarrasing for the two of you right?

[TheCPUWizard]

I'm not into the "look at me" argumentation you seem to favour. You'll have to make do with public evidence. This for example are timings of different implementations of the the Boost Shared Pointer.

What more public evidence do you wwant than my last post, were I showed (and the link you posted to the timing is based on), that the
DEFAULT ALLOCATOR for the application is not changed.

Specifing the use of a applicator based upon the characteristic of a class is something I am fully in support of, and do many times. It is your position (as I understand it), that replacing the DEFAULT ALLOCATOR on a global basis is a "good thing".

[_uj]

It is your position (as I understand it), that replacing the DEFAULT ALLOCATOR on a global basis is a "good thing".

Replacing the default allocator is neither good nor bad. The default allocator is just the allocator that came with the compiler. If I can find an allocator that is better suited to my programming style (OO) I rather use that as my "default". I have come to the conclussion that an allocator specialized in handling small object efficiently suits me better.

Why do you have this desperate need to stick with exactly the allocator that came with the compiler? Does the thought of replacing it give you separation angst? Or does it maybe have unknown divine properties you want to tell us about?

[TheCPUWizard]

Replacing the default allocator is neither good nor bad. The default allocator is just the allocator that came with the compiler. If I can find an allocator that is better suited to my programming style (OO) I rather use that as my default. I have come to the conclussion that an allocator specialized in handling small object efficiently suits me better.

But (Again to the best of my understanding), have done ZERO quantitaive measurements to support this. IF I believe that variables should never have the letter O in them, with absolutely no quantitative evidence to support this position. I dont see a difference.

Why do you have this desperate need to stick with exactly the allocator that came with the compiler? Does the thought of replacing it give you separation angst? Does it have divine properties you want to tell us about?

Very very simple. As soon as you replace the default allocator, you take on the full responsibility of testing EVERY piece of code that uses that allocator. This means testing the vendors runtime, support libraries (including STL implementation), application frameworks, everything. Considering that these items usually require a least few man-years to test comprehensively, this would price almost every application out of existance. Or do you believe in shippijng untested code?????

I will always choose a supported environment over a custom one, provided it can be used to meet the design specifications. From a professional point of view, it is more expediant to use something (that may take twice as much memory, and ten times as long to run) which has the full faith and support of a vendor than to over-"optimize" when that has no bearing on the application meeting the clients specifications.

I would not call these properties "divine", but they have served me very well, for a very long time.
===

One of the worst experience I had (over 25 years ago) was an application that used a custom B-Tree (this was long before commercial data management systems were available for PC type applications).

Occasionally (2-3 times per year with an installed client base of over 100 systems), the entire database would trash itself. More and more tests were written to test the library, but none of them found a problem, no matter how hard we tried.

Eventually one of us (ironically a high-school intern) found that with a certain combination of key length's and physical record numbers, an internal buffer was 1 byte too short.

A similar thing is possible [although hopefully very unlikely] when one alters the environment to vendor provided library. If I known that everything has been tested using the compiler supplied allocator, have no reason to believe they would have tested it with another allocator, and the performance is acceptable, where is the value in the increased risk?

[ahoodin]

Why do you have this desperate need to stick with exactly the allocator that came with the compiler? Does the thought of replacing it give you separation angst? Or does it maybe have unknown divine properties you want to tell us about?

Bravo!..... Excellent Whining!
Clap clap clap!

[_uj]

Bravo!..... Excellent Whining!
Clap clap clap!

That's not whining, that's plain-talk. It's a way to get to the gist of an argument and get it noticed. But thank you for your kind review of my posting style.

[cj-wijtmans]

Bravo!..... Excellent Spamming!
Clap clap clap! *im a retard, weeeee*

yeah...

[ahoodin]

The point is that it is possible to make your point in a matter of fact way without all the theatrics. Especially without all the useless insinuations and pointless nasty whinings.
Also please put some pants on if you are going to post here!