Re: Exception Misconceptions: Exceptions are for unrecoverable errors.
In article <hh491l$uig$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
Kaz Kylheku wrote:
On 2009-12-25, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
James Kanze wrote:
On Dec 23, 11:21 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
tanix wrote:
In article <hgskgk$kc...@news.albasani.net>, Vladimir Jovic
<vladasp...@gmail.com> wrote:
C++ would probably be benefited tremendously if it adopted some
of the central Java concept, such as GC, threads and GUI.
GC is heavy performance killer especially on multiprocessor systems
in combination with threads....it is slow, complex and inefficient...
Obviously, you've never actually measured. A lot depends on the
application, but typically, C++ with garbage collection runs
slightly faster than C++ without garbage collection. Especially
in a multi-threaded envirionment,
How that can possibly be?
How it can be is that surprising truths in the world don't take a pause
so that morons can catch up.
GC kills all threads when it has
to collect?
Big news: stopping threads using the scheduler is more efficient than
throwing locks or atomic instructions in their execution path.
Well, stopping threads by using scheduler or any other means
while they work is same or worse as throwing locks or atomic
instructions in excetion path....
Actually this is I said already. Simplest way to perform garbage
collection is to pause program scan references then continue program...
What's more efficient: pausing a thread once in a long while, or having
it constantly trip over some atomic increment or decrement, possibly
millions of times a second?
Atomic increment/ decrement costs nothing if nothing is locked....
So there is actually small probability that that will happen
because usually there are not many objects referenced from multiple
threads.
Or it can magically sweep through heap,stack,bss
etc and scan without locking all the time or stopping program?
The job of GC is to find and reclaim unreachable objects.
Exactly.
When an object becomes unreachable, it stays that way. A program does
not lose a reference to an object, and then magically recover the
reference. Thus, in general, garbage monotonically increases as
computation proceeds.
This means that GC can in fact proceed concurrently with the
application.
Oonly after it finds unreferenced objects...
The only risk is that the program will generate more
garbage while GC is running, which the GC will miss---objects which GC
finds to be reachable became unreachable before it completes.
But that's okay; they will be found next time.
So you will have 500 megabytes ram more used then with manual
deallocation.... ;)
This is hinted at in the ``snapshot mark-and-sweep'' paragraph
in the GC algorithms FAQ.
http://www.iecc.com/gclist/GC-algorithms.html
Explain to me how?
Go study garbage collection. There is lots of literature there.
It's not a small, simple topic.
Manual deallocation does not have to lock at all....
WTF are you stuipd?
Stupid?
Firstly, any comparison between GC and manual deallocation is moronic.
Of course, manual deallocation does not have to pause
complete program...
In order to invoke manual deallocation, the program has to be sure
that the object is about to become unreachable, so that it does
not prematurely delete an object that is still in use.
Hey. delete p just frees block of memory. That work is not that
complicated...
Yes it is.
What happens AFTER is has been "freed" as it looks to you?
Can you tell me?
Moreover,
the program has to also ensure that it eventually identifies all objects
that are no longer in use. I.e. by the time it calls the function, the
program has already done exactly the same the job that is done by the
garbage collector: that of identifying garbage.
What are you talking about?
/Both/ manual deallocation and garbage collection have to recycle
objects somehow; the deallocation part is a subset of what GC does.
Yup. GC does much more deallocation part can be done concurrently.
That's why manual deallocation will always be more efficeint
and faster.
Look when I say free(p) it is just simple routine....
But what is happening on the O/S level AFTER that?
What is your overall performance as a SYSTEM
and not just some local view of it?
You see, what counts is the END result.
How long does it take user to wait for response.
How long does it take for your program to continue its main operation.
And NOT how long does it take YOU to return from free() call.t
That is just a very local and a primitive view on the system
I'd have to say. I simply have no choice.
(Garbage collectors integrated with C in fact call free on unreachable
objects; so in that case it is obvious that the cost of /just/ the call
to free is lower than the cost of hunting down garbage /and/ calling
free on it!)
?
The computation of an object lifetime is not cost free, whether it
is done by the program, or farmed off to automatic garbage collection.
Your point about locking is naively wrong, too. Memory allocators which
are actually in widespread use have internal locks to guard against
concurrent acces by multiple processors.
Of course.
Even SMP-scalable allocators
like Hoard have locks.
Of course.
Well, so it means that you can not just look at the pinhole
(of free() call return time as overall performance)
See, the problem is that even if you shunt
allocation requests into thread-local heaps, a piece of memory may be
freed by a different thread from the one which allocated it.
I have written such allocator...
Thread A
allocates an object, thread B frees it. So a lock on the heap has to be
acquired to re-insert the block into the free list.
Lock operation is very short and collision between two thread may pause
one or two threads. But other will continue to work. unlike with
gc which will completely pause program for sure.
Well, too bad we are still at it.
You see, to me the program performance translates in to run time
of some more or less complex operation to complete.
What I care about is not how many time my program "frezes" for so
many microseconds, but how long will it take me to comple my run.
If it takes me 4 hours, it is one thing.
If it takes me 4 hrs. and 10 minues, that is nothing to even mention.
But if it takes me 5 hrs, I'd start scratching my cockpit.
But not yet.
But when it takes me 6 hrs vs. 4, I'd definetely start looking
at some things.
Greets!
--
Programmer's Goldmine collections:
http://preciseinfo.org
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.