Thread: Advice on next steps - shifting to OOP

I excluded library collectors because I know nothing about them, not because I think they're better/worse.

I don't know, I just can't accept it... not cleaning up after yourself is a violation of programming fundamentals IMO. I think everything that is opened, must be closed, what is allocated must be deallocated, what is mounted must be unmounted and so on. Why do modern programmers fight against these obvious rules of universe?

Originally Posted by maxorator

I don't know, I just can't accept it... not cleaning up after yourself is a violation of programming fundamentals IMO.

If you can avoid explicitly cleaning up after yourself, why not? The same idea applies with the use of smart pointers and containers that perform RAII in C++: since the components you use clean up after themselves, you do not need to explicitly clean up afer yourself.

Originally Posted by maxorator

I think everything that is opened, must be closed, what is allocated must be deallocated, what is mounted must be unmounted and so on.

Yes, and ideally a garbage collector will also accomplish these tasks.

Programmers fight everything that is not part of their core job: solving a specific problem. Thus, when the problem is "write a data entry application", they'll fight everything that isn't directly part of this problem. Let's face it, memory management is not directly part of any problem except "performance snail" and "memory hog". Until these animalistic difficulties raise their ugly heads, programmers will be all too happy to shunt memory management as far to the side as possible.

Personally, I'm satisfied with the deterministic RAII capabilities of C++ in most situations, and annoyed by the lack of consistency in resource management in GCed languages. (Why is memory different from file handles?) But I don't have anything against garbage collection per se.

Originally Posted by CornedBee

In fact, builtin garbage collectors are better than library collectors, because they have more information they can use.

This seems like inefficiency.
First, the promotions. Although it is good that they are promoted so they are not sweeped as often, promotion takes time.

Due to the different generations, allocation must take more time, or, if not, then deallocation or sweeps must take longer because there must be time dedicated for managing the whole generations thingy.

And regardless if it's a small area or a big area, it must be swept, which takes time, along with the constant lookup of pointers. Even if it knows where they are, it must take linear time because they have to be stored somewhere.

And as you say, some allocations can abuse this.

All have its ups and downs, and this is why I don't like garbage collectors. I'm old-fashioned and like control over it myself.

And also, I don't really believe garbage collectors are faster. Not unless there is significant evidence of the contrary.

Originally Posted by Elysia

This seems like inefficiency.
First, the promotions. Although it is good that they are promoted so they are not sweeped as often, promotion takes time.

You really, really, really need to do research before making arguments.
Promotion of all objects at once is actually a single pointer assignment.

Due to the different generations, allocation must take more time, or, if not, then deallocation or sweeps must take longer because there must be time dedicated for managing the whole generations thingy.

No, and no. Allocation is not slowed down by generations at all. Deallocation isn't slowed down at all. Sweeping isn't slowed down at all. Compaction is the slowest part, but compacting isn't there because of generations; it's there because it's what allows the fast allocation and because it prevents memory fragmentation. Also, in the two typical cases (determined by the designers; I cannot vouch for their data collection methods), which are that nearly no objects survive and that nearly no objects are deleted, compaction is fast, too.

And regardless if it's a small area or a big area, it must be swept, which takes time, along with the constant lookup of pointers. Even if it knows where they are, it must take linear time because they have to be stored somewhere.

Yes. It takes linear time. Interestingly enough, though, it really doesn't take all that much time in comparison to managing heap data structures. N deallocations with M active memory blocks in a free list tree take N*logM time. N deallocations in a GC system take M time, but with M bounded by the size of Gen0, not all allocations.

And also, I don't really believe garbage collectors are faster. Not unless there is significant evidence of the contrary.

You can easily construct pathological cases either way. (The pathological case for the .Net garbage collector is to allocate a string of objects which have sizes that vary randomly between 1 and 60000 bytes, and giving each a 50% chance of being added to a global list that keeps it alive, or else being dropped immediately.)
Unless you really have the patience to create a big program twice, though, you can't measure real-world performance reliably. Even then, you'd need a team of experts to agree that yes, the program is otherwise a fair comparison.

I still suggest that a modern GC is faster than naive manual memory management in many, if not most, cases. By naive I mean that nothing beyond the native general purpose allocator is used.
You can always optimize manual memory management, something which is difficult (but not impossible) to do with a GC. You can use memory pools for mass deallocation, simple segregated storage for things like node-based containers, and all the other tricks to make memory use more efficient and less fragmented. But all this goes with significant effort.

Originally Posted by CornedBee

I still suggest that a modern GC is faster than naive manual memory management in many, if not most, cases. By naive I mean that nothing beyond the native general purpose allocator is used.

That's a very radical statement (what can be faster than just marking a memory page uncommitted after use?). About manual memory management - advanced programmers can make simple yet efficient memory management code in no time.

(what can be faster than just marking a memory page uncommitted after use?)

I was referring to the general-purpose allocator, i.e. malloc/free on Unix and HeapAlloc/HeapFree on Win32, not the highly specialized (even if more low-level) page allocator, i.e. memmap/memunmap on Unix and VirtualAlloc/VirtualFree on Win32.

Originally Posted by CornedBee

You really, really, really need to do research before making arguments.
Promotion of all objects at once is actually a single pointer assignment.

I'm not really trying to punch a hole through the whole theory or other arguments, just lying out my view of the whole.
And regardless, a bunch of conditions (even if just one) and pointer assignment is extra work, however small.

No, and no. Allocation is not slowed down by generations at all. Deallocation isn't slowed down at all. Sweeping isn't slowed down at all. Compaction is the slowest part, but compacting isn't there because of generations; it's there because it's what allows the fast allocation and because it prevents memory fragmentation. Also, in the two typical cases (determined by the designers; I cannot vouch for their data collection methods), which are that nearly no objects survive and that nearly no objects are deleted, compaction is fast, too.

Of course there is. I'm not talking about a massive slow-down or so, but there must be some cpu time dedicated to managing the generations. Ie deciding to what generation it belongs. Deciding which generation to sweep, etc.
And add compaction to that list of expensive cpu cycles, too. Yes, it can be good. I do understand the principle and fragmentation, but sometimes it can be unnecessary, too. That is a trade-off, I suppose, so I would like to see some options to control that.

Yes. It takes linear time. Interestingly enough, though, it really doesn't take all that much time in comparison to managing heap data structures. N deallocations with M active memory blocks in a free list tree take N*logM time. N deallocations in a GC system take M time, but with M bounded by the size of Gen0, not all allocations.

That's good and all - but you admitted it. It's slower, even if not by much.

I still suggest that a modern GC is faster than naive manual memory management in many, if not most, cases. By naive I mean that nothing beyond the native general purpose allocator is used.

It sounds to me, after all this, that is might just be slower. Even if just a little, still slower.
Of course, this is speculation, but just as you suggest it is faster, I suggest it is slower.
But I actually might think that it might be faster or it might be slower, depending on the area of use.
Doesn't make me a fan, though :/

You can always optimize manual memory management, something which is difficult (but not impossible) to do with a GC. You can use memory pools for mass deallocation, simple segregated storage for things like node-based containers, and all the other tricks to make memory use more efficient and less fragmented. But all this goes with significant effort.

And that effort should rightfully be reduced. It is our responsibility to make the most out of your applications with C++, since it is a highly flexible and fast language, so I would dearly see tools for that appear.

Thinking of dotNet makes me think of VBA, which completely disgusts me with its speed. It's slow as a crawl!

Originally Posted by Elysia

I'm not really trying to punch a hole through the whole theory or other arguments, just lying out my view of the whole.
And regardless, a bunch of conditions (even if just one) and pointer assignment is extra work, however small.

I really think the point was that if someone tells you your viewpoint is ignorant regardless, you owe it to yourself to research. I'm distantly reminded of fundamentalist Christians reworking intelligent design when it's convenient, just to raise the same tired arguments against evolution.

That's good and all - but you admitted it. It's slower, even if not by much.


It sounds to me, after all this, that is might just be slower. Even if just a little, still slower.
Of course, this is speculation, but just as you suggest it is faster, I suggest it is slower.
But I actually might think that it might be faster or it might be slower, depending on the area of use.
Doesn't make me a fan, though :/

It sounds to me like we're making progress though. I don't want to make you a fan. But it was very annoying that (particularly max) had this illusion that new/delete was done in constant time.

I haven't done the research in a long time so I would appreciate cited corrections if anyone can offer them. new typically fragments its heap into manageable sizes, say 4K at the smallest. When you run out of little blocks it starts segmenting the bigger ones where appropriate. If you've fragmented the memory pool like this, things get interersting. It may be able to compact smaller blocks and send that to you. It can also just perform a "real" allocation, which is as slow as the OS API. But both of these operations take time. Introducing new memory to the heap structure is nontrivial.

The only scheme that I am really familiar with that can speed this up is the free list. The free list is a static linked list of memory blocks--appended to when you delete something. Instead, now new can traverse the free list for a block to return (after initializing it and stuff if delete didn't do that). If the free list doesn't have a block of the appropriate size or larger then it goes to the heap.

Of course, I'm not privy to which compiler vendors use the free list in their implementations. To get it the best thing to do is install some library maybe.

So new/delete is not a performance miracle. It's just often... not relevant to user time. You crack me up sometimes. You're the champion of ease of use, but when it comes to real performance tradeoffs, you defend every CPU cycle. Garbage collection is not an infinite loop at least. *laughs* CornedBee made the distinction that the real cost is only marginally slower. With the benefits it provides, you need to decide where to pick your battles, and get your core job done.

So hopefully this discussion was educational for some of you. Do whatever you want in practice, but don't become a fundamentalist without knowing the subject very well.

Originally Posted by whiteflags

So new/delete is not a performance miracle. It's just often... not relevant to user time.

Just so that you know... I'm trying to compare garbage collection vs manual allocation. Not necessarily new/delete. There are other ways of allocation, which may be faster than new/delete.
Additionally, I once created an array class that was faster than vector, and I'm not kidding. It was a simple matter of allocating virtual memory blocks after another linearly instead of deleting and reallocating and copying data everytime it had to grow.
So what we learn from that is that I will always prefer manual allocation before garbage collection. *shrug*

You crack me up sometimes. You're the champion of ease of use, but when it comes to real performance tradeoffs, you defend every CPU cycle.

Of course! That's why I chose C++ and not VB, or C# or Java.

Garbage collection is not an infinite loop at least. *laughs* CornedBee made the distinction that the real cost is only marginally slower. With the benefits it provides, you need to decide where to pick your battles, and get your core job done.

That old argument :/
I don't like it, but I know it's the truth and it hurts.

So hopefully this discussion was educational for some of you. Do whatever you want in practice, but don't become a fundamentalist without knowing the subject very well.

I actually got some insight into some garbage collectors, and while I do appreciate the work that goes into making them as efficient as possible, I still don't think they can beat manual allocation... *shrug*

I usually manage memory so that the amount of allocations is minimal - mostly only on loading data/save files/whatever and startup. If the amount of data grows a lot on runtime, then I allocate by very big pieces at a time - it's not too difficult to implement.