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 » Community » Coffee corner » C++ FQA
Re: C++ FQA [message #12708 is a reply to message #12677] Tue, 13 November 2007 17:30 Go to previous messageGo to next message
exolon is currently offline  exolon
Messages: 62
Registered: July 2006
Location: 53'21N 6'18W
Member
mdelfede wrote on Mon, 12 November 2007 22:33

Well, also being absolutely not an expert of GC algorithms, I always think that to allocate a lot of memory just because there is enough of it it's not a great practice.
First thing, you must look to what does OS in respect of free memory.... If your OS tells you that you've got 1 GB free ram, even when it's already swapping out another GB on disk, what this behaviour does is slowing down your system.

IMHO a truly efficient GC should be hardware implemented, or at least have a strong hardware support. Doing it software you'll face everytimes with some sort of problem, as latency, memory inefficiency or both.
And it should also collect freed memory asap.

Well, these last two statements don't seem logical together. If you don't want latency, why collect freed memory ASAP, unless you're on a very constrained (hard real-time embedded board...?) platform always operating close to the limit of available memory or starting to thrash the swap? This implies doing GC runs _all_ the time.

mdelfede wrote on Mon, 12 November 2007 22:33

No doubt that manual memory allocation is more efficient than GC, even if it can be a bot slower on the short time.
And a good framework can help to keep things simple.

Id rather extend C++ (or make some more modern language, without GC) to include some helpful features, than switch to less efficient languages.

I think you should really look at some proper comparisons of real efficiency impacts of using GC, rather than automatically assuming that it kills your program's performance.

Also, you shouldn't just assume for sure that manual memory allocation must be more efficient than GC.
This FAQ is worth a read, with an open mind, rather than being a hardened C++ "oldskool all the (hard and error-prone) way" purist.

http://www.iecc.com/gclist/GC-faq.html

Folk myths
* GC is necessarily slower than manual memory management.
* GC will necessarily make my program pause.
* Manual memory management won't cause pauses.
* GC is incompatible with C and C++.
Folk truths
* Most allocated objects are dynamically referenced by a very small number of pointers. The most important small number is ONE.
* Most allocated objects have short lifetimes.
* Allocation patterns (size distributions, lifetime distributions) are bursty, not uniform.
* VM behavior matters.
* Cache behavior matters.
* "Optimal" strategies can fail miserably.
Re: C++ FQA [message #12711 is a reply to message #12708] Tue, 13 November 2007 18:24 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1283
Registered: September 2007
Senior Contributor
exolon wrote on Tue, 13 November 2007 17:30


Well, these last two statements don't seem logical together. If you don't want latency, why collect freed memory ASAP, unless you're on a very constrained (hard real-time embedded board...?)
platform always operating close to the limit of available memory or starting to thrash the swap? This implies doing GC runs _all_ the time.


When I say "I don't want latency", I mean "I don't want a big, unpredictable latency".
As I said, GC *can* globally be more performant, and *can* be in the very short time very performant too. What i can't is assure the performance *all* the time.
If I do a benchmark with a lot of allocations/deallocations, GC may behave wonderful. But then, if you stress benchmark beyond a threshold, you'll have your app stopping for maybe 2-3 seconds collecting stuffs. If you go forth, global app time *can* be shorter than with manual allocation, but in the middle you had the infamous stop.

Besides real-time tasks (on wich that's not acceptable), there are also many apps on which you couldn't accept such a behaviour, like multimedia, but even in a GUI a 3 second stop makes a bad feeling.

Quote:


I think you should really look at some proper comparisons of real efficiency impacts of using GC, rather than automatically assuming that it kills your program's performance.



As I said before, one must know what "killing program performance" means. if you accept that your app can lag for seconds, GC is the best for you.

Quote:


Also, you shouldn't just assume for sure that manual memory allocation must be more efficient than GC.
This FAQ is worth a read, with an open mind, rather than being a hardened C++ "oldskool all the (hard and error-prone) way" purist.


I'm surely not a purist, as I tried so many languages in the past. I'd prefere a more modern C++, but with no GC, but that's of course my opinion. I like very much C# syntax, for example, but you can't call him a fast or multipurpose language. When Java came out, it seemed to all people that it'd be the language of future.... but now I don't see many people thet like it. Nor it seems to me a quick lang, or a very error-free one. D language seems interesting, but I didn't test it.
Of one thing I'm quite sure : I don't want a C++ with memory management mixed between malloc() and GC.

BTW, in the faq you showed, the focus seems to be on "you program is surely buggy, it shourely have leaks, so GC is wonderful for you". I receive about 100 spam mails in this idiom each day Very Happy
Quote:


......
* Most allocated objects are dynamically referenced by a very small number of pointers. The most important small number is ONE.


for that, the best is pick_ behaviour, of course

Quote:


* Most allocated objects have short lifetimes.


And ? does it mean that GC is better or not ?

Max
Re: C++ FQA [message #12712 is a reply to message #12711] Tue, 13 November 2007 18:58 Go to previous messageGo to next message
exolon is currently offline  exolon
Messages: 62
Registered: July 2006
Location: 53'21N 6'18W
Member
mdelfede wrote on Tue, 13 November 2007 17:24

As I said, GC *can* globally be more performant, and *can* be in the very short time very performant too. What i can't is assure the performance *all* the time.
If I do a benchmark with a lot of allocations/deallocations, GC may behave wonderful. But then, if you stress benchmark beyond a threshold, you'll have your app stopping for maybe 2-3 seconds collecting stuffs. If you go forth, global app time *can* be shorter than with manual allocation, but in the middle you had the infamous stop.

Besides real-time tasks (on wich that's not acceptable), there are also many apps on which you couldn't accept such a behaviour, like multimedia, but even in a GUI a 3 second stop makes a bad feeling.

I find it hard to believe that modern GC implementations would cause a lag of 3 seconds in a normal GUI or even multimedia app.
You talk about a stress test, but surely this isn't really the general case?

So it looks to me like you're talking about special, extreme cases; the worst-case scenarios for a stopping GC (there are incremental GC schemes too, but I don't see that they exist in the real world).

Do you really prefer handling all the memory (de)allocation, when objects are being passed around and you don't know how many times a function will necessarily be called... in every case? In complex programs?
I respect your choice to favour whatever mechanism, manual or GC (and I certainly don't think you're stupid if your choice is different to mine - I make stupid choices all the time) but I really don't think the overhead is as bad as people make out.
If it turns out that GC is as good or nearly as good as manual management in 90% of cases, then I would definitely be going that route, unless we're dealing with cases where absolutely no unexpected latency can be introduced whatsoever... i.e. real-time with hard deadlines, in which case we'd probably be using something like C in uCOS or even assembly, anyway.

That said, I do understand that there's a non-performance-related problem with calling destructors during GC - namely that of two objects about to be collected, say FileReader and FileHandle, FileReader has a reference to FileHandle, and in its destructor calls handle->Close() or something, which will die if the FileHandle happens to be destroyed first (since the only reference to it is another 'dead' object), and I guess this might be what Luzr alluded to.
So I'm not sure what the best solution there is, without explicitly calling some "finalise" type method which would be just as annoying as deleting it anyway.

Oisín

[edit]
Afterthought... then again, why not just have Close() in FileHandle's destructor, rather than having the client object do the cleanup?
Anyway, I'm sure there are cases out there that are more valid than my crappy example.

[Updated on: Tue, 13 November 2007 19:05]

Report message to a moderator

Re: C++ FQA [message #12776 is a reply to message #12712] Fri, 16 November 2007 00:43 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

It looks like a temporal armistice.
Just to have fun, some words about C++ from The-God-Of-Free-Whatever-Anything-You-Know - Linus Torvalds Very Happy

[Updated on: Fri, 16 November 2007 00:46]

Report message to a moderator

Re: C++ FQA [message #12787 is a reply to message #12776] Fri, 16 November 2007 11:59 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13358
Registered: November 2005
Ultimate Member
Mindtraveller wrote on Thu, 15 November 2007 18:43

It looks like a temporal armistice.
Just to have fun, some words about C++ from The-God-Of-Free-Whatever-Anything-You-Know - Linus Torvalds Very Happy


Yep, I know that one.

Perhaps he could try to compete with idmap benchmark in C Smile

Mirek
Re: C++ FQA [message #12792 is a reply to message #12787] Fri, 16 November 2007 16:24 Go to previous messageGo to next message
waxblood is currently offline  waxblood
Messages: 95
Registered: January 2007
Member
Git looked interesting to me, but after reading 'that one', I *need* Uvs3. Really.

David
Re: C++ FQA [message #12793 is a reply to message #12776] Fri, 16 November 2007 16:37 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1283
Registered: September 2007
Senior Contributor
Mindtraveller wrote on Fri, 16 November 2007 00:43

It looks like a temporal armistice.
Just to have fun, some words about C++ from The-God-Of-Free-Whatever-Anything-You-Know - Linus Torvalds Very Happy


Well, I did read (a part of) that thread.... interesting stuff.
First of all, I got a not so good impression of Torwald´s answers, those seemed to me quite extremistic. I can agree that one likes a language more than others, but saying that others are bullshit IMO doesn't solve problems nor apports something constructive to the discussion.
Second, I think I'll give D language a shot Smile
Third, I think more and more that the usual argument of C supporters that "C++ is BS, because introduces hidden bugs" is more BS than argument itself. As I said before, I don´t like C++ at most, but I can say that if I need 2 lines of C++ code to do the same job as 30 lines of plain C I´ll get much spare time to check my code for bugs or to enhance it. Such arguments make me think that if one does all the job in assembler, it will be surely bug free Very Happy .

ciao

Max
Re: C++ FQA [message #12795 is a reply to message #12708] Sat, 17 November 2007 10:04 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13358
Registered: November 2005
Ultimate Member
exolon wrote on Tue, 13 November 2007 11:30


http://www.iecc.com/gclist/GC-faq.html

Folk myths
* GC is necessarily slower than manual memory management.
* GC will necessarily make my program pause.
* Manual memory management won't cause pauses.
* GC is incompatible with C and C++.
Folk truths
* Most allocated objects are dynamically referenced by a very small number of pointers. The most important small number is ONE.
* Most allocated objects have short lifetimes.
* Allocation patterns (size distributions, lifetime distributions) are bursty, not uniform.
* VM behavior matters.
* Cache behavior matters.
* "Optimal" strategies can fail miserably.



BTW, if you want to see some real data, U++ has quite good heap statistics feature, up to the point of simple GUI in CtrlLib: See MemoryProfileInfo.

Or, for example, in TheIde About dialog, press Alt+M.

Mirek
Re: C++ FQA [message #12855 is a reply to message #12692] Thu, 22 November 2007 05:43 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13358
Registered: November 2005
Ultimate Member
cbpporter wrote on Tue, 13 November 2007 04:14


Yet really knowledgeable C++ programmers are not that common, and managers often have teams formed of a little less experienced programmers. These are the people who introduce memory leaks and who misuse language features, not the guys who can perfectly understand were complex template code with multiple inheritance, virtual inheritance and some hidden macro-magic at the first glance. In such situations, GC can be a good alternative.



BTW, interesting anecdotal evidence from the current project I am involved in:

It is now medium sized U++ application being developed "under the pressure" by a team of now 5.

2 of us were hired two months ago, with C# background. They literally had *DAYS* to (re)learn C++ and to learn U++.

Despite that, they are productive (well, certainly not as me Smile, but they do deliver). And they have introduced the first "delete" statement yesterday, which will be removed, with explanation today (and thus will be the last "delete" in the project ever introduced).

So I guess, it is not as bad w.r.t. C++/U++ combo and less experienced programmers... and GC really not as important for productivity here.

Mirek
Re: C++ FQA [message #13271 is a reply to message #12515] Thu, 27 December 2007 14:47 Go to previous message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

http://shootout.alioth.debian.org/sandbox/benchmark.php?test =all&lang=gpp&lang2=dlang
Previous Topic: Tools or methodologies you use when developing software
Next Topic: About vista....
Goto Forum:
  


Current Time: Sat Jun 19 02:40:46 CEST 2021

Total time taken to generate the page: 0.01597 seconds