On 2011-01-18, geremy condra <debat...@gmail.com> wrote: > On Mon, Jan 17, 2011 at 4:02 PM, Tim Harig <user...@ilthio.net> wrote: >> I really question that you get Java anywhere even close to C performance. >> Google reports they get within the same order of magnitude as C for >> their long-lived server processes where the JIT has had time to optimize >> its results. For shorter term processes such as desktop applications, >> Java performance stinks -- even after you discount the JVM starup time. > > I'm sorry, but you're wrong on this. Java's performance can be > excellent, particularly when it comes to mathematical functions. I > recall reading a pretty smug paper a few years ago describing how they > managed to beat C on a number of numerical benchmarks.
I have no doubt that Java *can* occasionally beat *some* C for *some* benchmarks; but, overall, Java has a terrible reputation for performance. I worked with a company a few years ago that tried replacing a C VNC client with a Java one so that its technical support contractor's wouldn't need to have the VNC client installed on the agent's workstations. Several of the contracters had to upgrade their systems in order to use the Java version because it slowed down the machines so much that the agents could not perform their jobs effectively; and that is pretty typical from what I have seen with Java overall. Java performs very well with some select tasks. For others, it does exceedingly poor. That kind of hit or miss is pretty typical for JIT compilers in general. That isn't usually the case for fully compiled langauges where you are pretty much guaranteed to get decent, if not always the absolute top, performance. >> Ada is capable of C++ like performance *if* you compile it to remove *all* >> of runtime checking. Depending what checks you enable, it can run much >> slower. > > No idea, never used it. > >>> in line with the work of others. You can argue that it's good enough- >>> it is, for most cases- but taking a 20% performance hit rules it out >>> of a lot of systems work, and the C-Go gap in many cases is much >>> larger than that. >> >> I don't work anything that involves and absolute need for performance. > > Then don't argue about performance, it makes you look like a hack just > eager to shill for your language. What you don't seem to realize is there is often a performance level that is good enough. For many things, Python is good enough. Many others, where Python is insufficient, may still be acceptable to use Java. Some things require the absolute best performance and will probably always need C/C++ or equivilantly low level language. >> I could probably accept penalty several times that of C for higher >> level functionality; but, sometimes the penalty for Python is just >> too much. Many of my programs are very quick lived such that even >> loading an interpeter or VM can eclipse the actual runtime. Given less >> developmental effort required, I also find that I have more time to look >> for ways to optimize Go. There are many things (such as using alternate >> data structures rather then the build in slices and immutable strings) >> that can be used to accelerate Go when time permits and I suspect many >> more will be found as the language matures. > > This is inconsistent with your argument about PyPy. See my earlier comment. I can accept 2 to 3 times the overall performance of C for almost all of the problems that I deal with. When that multiple gets into the double digits, it can start to cause some real headaches for some problems. When that number reaches the upper double digits, it is acceptable for even fewer problems. Python is great for those problems where performance isn't critical and I make extensive use of it. Different methods of mixing Python and C (including manual, PyPy, SWIG, boost, etc) can extend Python's useful range; but, I have not seen the kind of speed improvements that bring it to less then an order of magnitude of C's speed overall. Even assuming that PyPy does actually manage to reach within a magnitude of C with the extra effort required to leverage two languages, why would I bother when I can do it with one? PyPy and similar methods where great when there was no other mid level alternative that supported Python like features. Now it just seems like using Python as a hammer for every problem whether or not it is the right tool for the job. >>> Go is also not an ideal language for enterprise development. It >>> provides no compatibility or support guarantees; in fact, the website >>> describes it as 'an experiment' and recommends it for 'adventurous >> >> There is no doubt that it is a young project and there are a number of >> things that will need to be improved to be effective for some branches >> of programming; but, that isn't a language restriction. > > It will nevertheless preclude its use in most enterprise software > development. That's most systems software. So you conclude that because it is not quite ready for prime time yet that it never will be? I can remember when people said C++ would never amount to anything either. >> Database bindings are another weak link outside of the more common >> open source databases. In both cases, Go readily capable of C library >> functions as a stop-gap until a native wrapper is available. Yes it will >> be nice once community has filled in the gaps; but, I am rather impressed >> at what is already available in less then a years time. There are a few >> libraries you may have missed here: > > Sounds like a two-language solution, ie, the thing you criticized Python for. Not quite. 1. My arguments for dual language solutions where never directed at Python proper. They were directed at PyPy. I am rather amazed at the number of things that can be accomplished in Python without having to bind to C. 2. There is a difference in binding to a solution that is already written in another language so as to not reinvent a wheel and implementing a *new* library in another language to be used exclusively with Python. -- http://mail.python.org/mailman/listinfo/python-list