On Fri, 2007-06-15 at 14:45 -0400, Jason House wrote: > On 6/15/07, Phil G <[EMAIL PROTECTED]> wrote: > JIT didn't solve everything - the managed memory management in > Java (and C#) has overheard which JIT can not always optimized > away, for example. > > > The D programming language website argues in favor of garbage > collection... Even claiming that it could be faster than manual memory > allocation/deallocation. http://www.digitalmars.com/d/garbage.html
This is an age old argument applied to many things. The same argument in another context: C programs can be faster than assembly language programs. These arguments are based on the assumption that the human can't do as well as the computer for certain tasks. A custom designed memory manager by a person who knows what he is doing will be faster than an automatic generalized algorithm and assembler code written by a human who actually knows what he is doing will always be faster than C code written by a compiler. Of course the big variable here is how many programmers have the expertise to out-code the compiler. These statements are probably mostly true for most people and most programs. There is an argument that JIT could even outperform statically compiled code because it might be able to take advantage of dynamic information learned on the fly. There is also the object oriented issue. This is a small performance drag. This is not a natural thing to the computer hardware even if people like it. There really is no such thing as a fair benchmark. To me it comes down to how much effort to write a fast program and I think it's really difficult in Java if you want the code to remain beautiful. In C code isn't supposed to look beautiful :-) I think Java approaches the speed of C only in a few benchmarks. I think if you had a competition by super-experts in any language to write a very specific program, you would find that the Java program couldn't approach the C program in speed. For instance I would like someone to take Lukasz Lew's code base and come close to it's performance in Java. I would be really surprised if you could get half the speed in this case. - Don > > <venting> > I'm not yet sold on all the ideas... especially since D's GC crashes > when using the port to gcc. Arguments like "you don't have to debug > memory management code" (like on the website) are nice points, but > it's far more frustrating when the standard GC doesn't work. > </venting> > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
