Home » Community » Coffee corner » C++ FQA
| Re: C++ FQA [message #12708 is a reply to message #12677] |
Tue, 13 November 2007 17:30   |
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 |
mdelfede
Messages: 1307
Registered: September 2007
|
Ultimate 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 
| 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 |
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 #12793 is a reply to message #12776] |
Fri, 16 November 2007 16:37 |
mdelfede
Messages: 1307
Registered: September 2007
|
Ultimate Contributor |
|
|
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 
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 .
ciao
Max
|
|
|
|
| Re: C++ FQA [message #12795 is a reply to message #12708] |
Sat, 17 November 2007 10:04 |
 |
mirek
Messages: 13975
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 |
|
mirek
Messages: 13975
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 , 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
|
|
|
|
|
|
Goto Forum:
Current Time: Thu Apr 18 17:52:52 CEST 2024
Total time taken to generate the page: 0.01557 seconds
|
Members
Pages
Help
Register
Login
Home
