Like Tree1Likes

Advice on next steps - shifting to OOP

This is a discussion on Advice on next steps - shifting to OOP within the A Brief History of Cprogramming.com forums, part of the Community Boards category; I excluded library collectors because I know nothing about them, not because I think they're better/worse. I don't know, I ...

  1. #46
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    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?
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  2. #47
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,660
    Quote 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.

    Quote 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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #48
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  4. #49
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,554
    Quote Originally Posted by CornedBee View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #50
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by Elysia View Post
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  6. #51
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Quote Originally Posted by CornedBee View Post
    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.
    Last edited by maxorator; 12-01-2008 at 10:34 AM.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  7. #52
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    (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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  8. #53
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,554
    Quote Originally Posted by CornedBee View Post
    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!
    Last edited by Elysia; 12-01-2008 at 12:12 PM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #54
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,673
    Quote Originally Posted by Elysia View Post
    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.
    Last edited by whiteflags; 12-01-2008 at 12:22 PM.

  10. #55
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,554
    Quote Originally Posted by whiteflags View Post
    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*
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #56
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    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.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

Page 4 of 4 FirstFirst 1234
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. OOP flu
    By Hussain Hani in forum General Discussions
    Replies: 15
    Last Post: 06-27-2009, 02:02 AM
  2. Data Mapping and Moving Relationships
    By Mario F. in forum Tech Board
    Replies: 7
    Last Post: 12-14-2006, 09:32 AM
  3. Logical errors with seach function
    By Taka in forum C Programming
    Replies: 4
    Last Post: 09-18-2006, 05:20 AM
  4. recommendation for a good OOP book
    By Mario F. in forum C++ Programming
    Replies: 2
    Last Post: 06-15-2006, 04:28 PM
  5. Folding@Home Cboard team?
    By jverkoey in forum A Brief History of Cprogramming.com
    Replies: 398
    Last Post: 10-11-2005, 08:44 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21