In article <8cadf38f-8554-462e-9d2e-0510e77ff918@26g2000yqo.googlegroups.com>, James Kanze <james.kanze@gmail.com> wrote:
On Dec 24, 1:03 am, Branimir Maksimovic <bm...@hotmail.com> wrote:
Kaz Kylheku wrote:
On 2009-12-23, 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
Is not.
Hm, explain to me how can any thread, access or change any
pointer in memory without lock while gc is collecting....
There is no way for gc to collect without stopping all threads
without locking.... because gc is just another thread(s) in
itself...
Maybe. I've not actually studied the implementations in
detail. I've just measured actual time. And the result is that
over a wide variety of applications, garbage collection is, on
the average, slightly faster. (With some applications where it
is radically faster, and others where it is noticeably slower.)
in combination with threads....it is slow, complex and
inefficient...
Religious belief.
Of course. GC is complex program that has only one purpose.
To let programmer not write free(p), but programmer
still has to write close(fd).
What's the purpose of that?
Less lines of code to write.
If you're paid by the line, garbage collection is a bad thing.
Otherwise, it's a useful tool, to be used when appropriate.
GC is very efficient from an SMP point of view, because it
allows for immutable objects to be truly immutable, over
most of their lifetime. No book-keeping operations have to
be performed on objects that are just passed around
throughout the program (such as bumping refcounts up and
down).
Refcounts are negligible in comparison to what gc is doing.
Reference counting is very expensive in a multithreaded
environment.
And in the end, measurements trump abstract claims.
[...]
No storage reclamation strategy is free of overhead. Even if
your program correctly manages memory by itself with
explicit new and delete, there is a cost.
Manual memory deallocation is simple, fast and efficient.
Nothing so complex like GC. Cost of new and delete is nothing
in comparison to GC.
That's definitely not true in practice.
[...]
GC cannot be implemented efficiently since it has to mess with
memory...
What you mean is that you don't know how to implement it
efficiently. Nor do I, for that matter, but I'm willing to
accept that there are people who know more about the issues than
I do. And I've measured the results of their work.
[...]
I don't want to discuss this, but it is obvious that nothing
in java is designed with performance in mind. Quite
opposite....
You don't want to discuss it, so you state some blatent lie, and
expect everyone to just accept it at face value. Some parts of
Java were definitely designed with performance in mind (e.g.
using int, instead of a class type). Others less so. But the
fact remains that with a good JVM, Java runs just as fast as C++
in most applications. Speed is not an argument against Java
(except for some specific programs), at least on machines which
have a good JVM.