Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Core » Ptr improve
Re: Ptr improve [message #32537 is a reply to message #32528] Tue, 24 May 2011 09:25 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
mirek wrote on Mon, 23 May 2011 23:37

cbpporter wrote on Mon, 23 May 2011 07:52

Here is an idea that has been going around in my head for a while: what if we combine the U++ way with GC.

GC is great, but the cost of mark & sweep can be to much for some cases.

Traditional memory management is problematic, and we have a relatively big cost of allocation/deallocation.



Well, that is relative, average allocation/deallocation is about pretty fast in U++.... (about the same as link/unlink in double-linked list + a couple of simple loads)

Quote:


With the U++ we have everything belongs somewhere.



GC is quite incompatible with the concept of destructors.

Quote:


But what if we kept the principle intact for non heap allocated objects, but for heap allocated one, the destructor would only mark the object for deletion, and it would actually get deleted latter.



IMO results in unmaintainable mess.

Besides, GC AFAIK is still not a part of C++. And you cannot realistically add it by library - the best you can do is stochastic approach (Boehm), which works fine, unless you are processing white noise Wink

Still, what is unclear to my is why to complicate your code with heap if you do not have to? The whole mission of U++ is to eliminate universal shared heap as much as possible.

Mirek


Destructors are not generally incompatible with GC, just the normal GC scenarios and implementation we have now. What I am proposing is reversing the order of the GC flow.

Another additional advantage would be that it would eliminate one of the big disadvantages of conservative GC: false positives and inability to deal with extremely large heaps or data that looks like pointers.

With what I am proposing, only objects whose destructors have been called will be collected, or those that were marked by the API. It is not GC, it is the U++ memory management flow, with one single difference: data is not deleted immediately. It is delayed.

This would apply to all containers that allocate memory, so it is not about eliminating universal shared heap or not so it wouldn't contrast with our mission statement.
Re: Ptr improve [message #32553 is a reply to message #32537] Tue, 24 May 2011 17:46 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
cbpporter wrote on Tue, 24 May 2011 03:25

mirek wrote on Mon, 23 May 2011 23:37

cbpporter wrote on Mon, 23 May 2011 07:52

Here is an idea that has been going around in my head for a while: what if we combine the U++ way with GC.

GC is great, but the cost of mark & sweep can be to much for some cases.

Traditional memory management is problematic, and we have a relatively big cost of allocation/deallocation.



Well, that is relative, average allocation/deallocation is about pretty fast in U++.... (about the same as link/unlink in double-linked list + a couple of simple loads)

Quote:


With the U++ we have everything belongs somewhere.



GC is quite incompatible with the concept of destructors.

Quote:


But what if we kept the principle intact for non heap allocated objects, but for heap allocated one, the destructor would only mark the object for deletion, and it would actually get deleted latter.



IMO results in unmaintainable mess.

Besides, GC AFAIK is still not a part of C++. And you cannot realistically add it by library - the best you can do is stochastic approach (Boehm), which works fine, unless you are processing white noise Wink

Still, what is unclear to my is why to complicate your code with heap if you do not have to? The whole mission of U++ is to eliminate universal shared heap as much as possible.

Mirek


Destructors are not generally incompatible with GC, just the normal GC scenarios and implementation we have now. What I am proposing is reversing the order of the GC flow.

Another additional advantage would be that it would eliminate one of the big disadvantages of conservative GC: false positives and inability to deal with extremely large heaps or data that looks like pointers.

With what I am proposing, only objects whose destructors have been called will be collected, or those that were marked by the API. It is not GC, it is the U++ memory management flow, with one single difference: data is not deleted immediately. It is delayed.

This would apply to all containers that allocate memory, so it is not about eliminating universal shared heap or not so it wouldn't contrast with our mission statement.


Well, very unlikely to happen, but for the fun of theoretical debate:

How do you plan to implement GC? are you going to write your C++ compiler? How would it handle typical C++ inconsistencies like pointer casts

In the past, I was experimenting with such library based GC approach, where only specific objects were subjects of GC. I was able to get it working, and it was quite optimal, however the whole thing collapsed the moment you have started mixing such objects and regular ones. I have not found a way out. Since then I consider the whole point of GC in C++ moot - perhaps Boehm or is good for fixing leaky code, but my conclusion is that you can either have reliable destructors or GC. There is nothing in between.

Mirek
Re: Ptr improve [message #32556 is a reply to message #32403] Tue, 24 May 2011 18:28 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
Once you have reliable destructor call, what's the point to not free also memory? QED what Mirek said.
Re: Ptr improve [message #32560 is a reply to message #32556] Tue, 24 May 2011 22:44 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
Well, I guess you don't like my idea Smile. It has been on my mind for some time. I am wondering if we could get a best of both worlds scenario out of this.

There is no need for writing compilers or libraries. Allocating memory without a container or a smart pointer and not freeing it would still be a memory leek. What I want is to delay the free operation. It does not have anything to do with pointer casting.

GC proponents have been hyping at least three things: no memory leaks, the advantage on parallel computing caused by a functional style combined with GC enabled more frequent allocations done to enable immutable data structures and and the responsiveness of allocation and deallocation. I was wondering if we could get some of that final point with what we have in U++ and test if it does bring an advantage or not. Seems like a fun experiment. We would need a very fast allocator, even at the price of a very slow deallocator.

And yes, my approach would need the use of Shared or a similar "rich pointer". Just using normal C pointer would be as bad of an idea as using them in normal U+ code to manage memory.
Re: Ptr improve [message #32567 is a reply to message #32403] Wed, 25 May 2011 09:34 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
"I am wondering if we could get a best of both worlds"

The problem with me is, that I don't see anything good about GC, except that you can be careless about where are your data.

As most of the SW task is to manipulate data, I don't find that idea attractive at all, I prefer to know exactly what my data do and where they sit and why. From there I never really wished for GC, gives me goosebumps to never know exactly when the memory is freed.

edit:
"What I want is to delay the free operation"
and why?? What's the advantage? I see plenty of problems with it, but no single advantage.

[Updated on: Wed, 25 May 2011 09:36]

Report message to a moderator

Re: Ptr improve [message #32569 is a reply to message #32567] Wed, 25 May 2011 10:27 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
the strong typed nature of C++ and especially U++ leaves you with a lot of control and responsibility. imho constructing object without care (like it is in C#) is both easy and wasting performance, inviting for careless handling with ressources. knowing what's up and needed is best practice to keep apps reactive. beeing that said, i go along with mr_pen & mirek.

this does not mean that Shared<> is just bad per se. it is merley a helper. but seeing it as an invitation to go GC is a bit too far i think. as mirek said, GC is compiler support. either have it or dont. there is no safe way in between.

some more info about shared_ptr usage, which clearly shows that it brings a lot of hassle as well. hassle one can spare when investing the thinking power in a correct model. a lot of work to save work is cumbersome.
http://www.codeproject.com/KB/stl/boostsmartptr.aspx#Example : Using shared_ptr in containers

[Updated on: Wed, 25 May 2011 10:28]

Report message to a moderator

Re: Ptr improve [message #32573 is a reply to message #32567] Wed, 25 May 2011 12:09 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
mr_ped wrote on Wed, 25 May 2011 10:34


edit:
"What I want is to delay the free operation"
and why?? What's the advantage? I see plenty of problems with it, but no single advantage.



Well the advantage is that you could have normal program flow without allocating and deallocating breaking up you execution. Deallocation would happen as a bulk operation only once in a while, either naturally or under the control of the programmer, i.e. before opening up a dialog and waiting for user input.

While I can routinely prove that C++ is considerably faster than a GC language, there are a few scenarios where C++ looses, and almost all of them involve allocating and freeing a huge number of objects.

I do not agree that we need compiler support, but here is the thing: with what I am proposing we do have compiler support. The destructors.

But I'll drop the subject now since nobody thinks this is a good idea.
Re: Ptr improve [message #32574 is a reply to message #32573] Wed, 25 May 2011 12:19 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
Quote:


But I'll drop the subject now since nobody thinks this is a good idea.


not nesseccary. why not provide a proof-of-concept?
Re: Ptr improve [message #32619 is a reply to message #32560] Sat, 28 May 2011 20:57 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
cbpporter wrote on Tue, 24 May 2011 16:44


GC proponents have been hyping at least three things: no memory leaks, the advantage on parallel computing caused by a functional style combined with GC enabled more frequent allocations done to enable immutable data structures and and the responsiveness of allocation and deallocation.



I would say that the partial problem here is that there was huge development invested in GC, but much less in traditional malloc/free.

That said, I believe that the current iteration of U++ allocator is close to optimal and is able to beat any GC easily...

BTW, cross-thread free's are already deferred in U++ allocator - but that simply happens "behind the scene"... Smile In-thread deallocation is usually about as 'complex' as one simple test, one load from memory and linking single element to the the double-linked list...

Mirek

[Updated on: Sat, 28 May 2011 21:05]

Report message to a moderator

Re: Ptr improve [message #32621 is a reply to message #32573] Sat, 28 May 2011 21:10 Go to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
cbpporter wrote on Wed, 25 May 2011 06:09

mr_ped wrote on Wed, 25 May 2011 10:34


edit:
"What I want is to delay the free operation"
and why?? What's the advantage? I see plenty of problems with it, but no single advantage.



While I can routinely prove that C++ is considerably faster than a GC language, there are a few scenarios where C++ looses, and almost all of them involve allocating and freeing a huge number of objects.



I have only experienced this in scenario where there are only allocations and garbage collection is never invoked.

That said, in C++ you would need to keep the track of freed blocks (for bulk free) and that would likely be as expensive as current U++ allocator free...

Mirek
Previous Topic: FIX: UPP::Scan returns int64 for INT_V
Next Topic: GetCurrentDirectory() Doesn't contain the \ is this a bug?
Goto Forum:
  


Current Time: Thu Mar 28 13:52:47 CET 2024

Total time taken to generate the page: 0.01560 seconds