Nick, When I engage in complex multi-threaded distributed processing, I have found Java to give me the most value for my limited personal time buck. I am not claiming that Java is competitive in performance with hand crafted assembly (or C or C++). I am claiming that I have experienced a many fold increase in my productivity by exploiting the much easier to use the language, libraries, the distributed computing ability and JVMs of Java than attempting to reliably reproduce the same results in hand crafted assembly (or C, or C++, or equivalents in terms of raw machine performance). For me, the primary constraint I am attempting to optimize is my own personal productivity. I am willing to give up small percentages of computation performance in trade for being vastly more productive in generating experiments. And at this point, JVM efficiencies have become so effective, we are talking about small percentages of performance difference. They are close enough for me to easily choose away from the less portable, flexible and shareable implementations of libraries I have seen for pretty much any other implementation system (Java is more than a language, it is also libraries, JVM implementations, standards for inter-system communication, distributed computing, etc.).
I still contend that breakthroughs in programming Go are going to come from creative experimental algorithms as opposed to a couple percent optimization around current algorithms. As such, I will remain wanting to favor implementation flexibility over computational efficiency. Once we have breakthroughs worth optimizing (and from what I am reading here, there aren't any yet), I will carefully reconsider my choice of Java. Recall there was a member of this forum who reported as his team went from Java to C/C++ to make things more efficient for his own implementation. He described the resulting loss of coding efficiency was not worth the minimal gain in execution performance. That member has since moved his team back to Java acknowledging there are efficiency benefits in C/C++, but that Java keeps them able to experiment with alternative approaches more rapidly. As to Java taking over the world - that is kind of too late. It's everywhere. Last calculation is that it is running on over 3 billion machines and devices (PCs, mainframes, mobile phones, smart cards, etc.). And now that it is GPLed, it will find many more homes. And I find it difficult to believe that the core reason there are so many machines and devices running Java to be the fact that Java has garbage collection. I will grant you that it is likely an influencer, but not near the magnitude you seem to believe it is. Java garbage collection is just one of many benefits collaborating with other language and library features which also influence the choice to implement in Java. I sense you think that a gain for Java is a loss for C/C++. I don't see it that way. The market continues to expand adding more and more software engineers/developers/programmers. So while C/C++ may not have the same growth rates it had in the '90s, there is still growth. Why does it matter to you that Java is growing? If you are happy with what you have chosen, why is what other people are recommending and choosing important to you? What are you defending? What are you trying to achieve? Jim ----- Original Message ---- From: Nick Apperson <[EMAIL PROTECTED]> To: computer-go <computer-go@computer-go.org> Sent: Tuesday, November 13, 2007 12:07:10 AM Subject: Re: [computer-go] Language WARNING: This digresses into a rant by the end... You've been warned. If you like to have your garbage collected for you then use one of the management strategies present in C++. If you like delayed freeing, overload new or use a library that does this. Really, the difference between C++ and most other programming languages (that are strongly typed) is that C++ doesn't make any assumptions about what you are going to do with it because of its most basic principle: you don't pay for what you don't use. If you want garbage collection, you can have it: it's not like C++ prevents this. By the same token, Java and C# don't allow you to make any decision here which might be best in certain circumstances, but it certianly isn't always ideal. If you want the subset of features that say java has, you are welcome to create these restrictions in C++ all while remaining more portable. I personally use garbage collection every once in a while in my C++ code. It is not usually the right tool for me, but there are circumstances where it makes sense. I generally use it when I have data that isn't really owned by any object. It is data that many parts of the program reference and some wish to keep a copy for themselves. This is how the std::string class is implemented in C++. Reference counting and copy on write. But I'll be damned if Java takes over the world because there are programmers that don't know when they need to use garbage collection. If you can't avoid memory leaks, fine, don't use C++ or C, but don't blame the language. You could use garbage collection if you need it; don't make us all stoop to your level of competency and don't try and claim that your language is just as fast when it isn't. - Nick On Nov 12, 2007 11:55 PM, Hellwig Geisse <[EMAIL PROTECTED]> wrote: On Mon, 2007-11-12 at 20:17 -0800, steve uurtamo wrote: > C > garbage collection: free(). Well, that's not garbage collection. You will begin to notice that if you are using shared data structures with different lifetimes. The question that comes up again and again is "can I free this structure here or does any part of my program hold a private pointer to this piece of data?" It is sometimes possible to group freeing objects ( e.g., a compiler can free data structures it needs to compile a function when the end of the function is reached - this is called "arena freeing") but not always. > very fast. And it's not fast either. Free() has a reputation of being slow, and that's not surprising if you look at the way it is almost always implemented: scanning a list of addresses in order to amalgamate the newly freed memory with adjacent free areas. My personal experience is: if you can tolerate the 5-10% loss in execution speed, a real garbage collector is invaluable. Hellwig _______________________________________________ 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/
