I am not the biggest Java fan inside or outside of my company. But I detest being on the receiving end of a conversation that involves Sun (I am madly passionate about Sun). So when I met up with a few friends of my friends and heard the standard “Java is dog slow” complaint, I had to invent a (truthful) counterexample.
Is Google = Slow ? No ?
You would have seen infinite blogs that talk about Google using Python here and Python there. Excellent marketing by the Python community and I whole-heartedly agree. But Google uses Java, I repeat JAVA for most of their popular applications. And most tools that Google provides to developers are Java based. Java is Slow and Solaris is Slow are complaints that belong to the previous century. (With the intorduction of Matisse, I have even stopped complaining about the Java GUI elements that used to suck like a vacuum cleaner. Solaris got a facelift that makes it look so sexy that I dare call it the best looking operating system next to the Mac)
Coming back to the original topic of Java != Slow, here is an interesting study comparing Python and Java where Java is in some cases 30x faster than python even with Psyco enabled !
All said and done, I am still not going to stop programming Python and start off on Java. I’ve given some thought to where the future of Programming Languages is headed and I think it lies in the direction of Java. Not “Java” the programming language, “Java” – the virtual machine. You might be surprised to learn that the JVM can run 200 different languages ! That includes the most popular scripting languages including Python, Ruby and Perl !
The greatest fallacy of the new generation of scripting languages (IMHO) is that they are not aligned with where computing is headed towards – Multicore, Multithreaded architectures. Intel, Sun, IBM and AMD are all committed to multicore computing as their primary future strategy. What the hell is the Global Interpreter Lock still doing in Python and why in the name of heavens can it not be recursive ? Guido even refuses to acknowledge this as a problem and tells us to write non-multithreaded concurrent code. It is easier to write code that way, but that is not where the future is headed, unless he has a release of “Quantum Python” planned some time soon 
Ruby has the same fundamental problem – Only one ruby thread can be scheduled into the run queue at any instant.
So what is the solution ? The Java Platform already has the solution. Use JRuby or Jython or J{Favorite Language} – NO stupid Global Locks, complete threading support AND You get to use all the cool tricks that your language has AND you can now import all the amazingly rich classes that Java provides AND make use of the highly optimized JVM AND its frigging open source.
The Java Virtual Machine and the .NET common language runtime are amazing pieces of technology that are close to an entire operating system in complexity. Imagine the power of writing productive code in Ruby and deploying it on a powerful platform like Java. THAT is where the future is headed. And don’t bullshit me about “Java is Slow”. Its the fastest cross-platform open-source virtual machine lying around 
Filed under: Open Source, Sun
I absolutely agree with the comment about the global interpreter lock. Guido designed a great language in Python, but I think he is completely unrealistic about the GIL. Just because it’s hard to remove it doesn’t mean that it shouldn’t be attempted.
In the tests that I did, and which you kindly linked to, I found amazing loop performance with Java. I really hope to see Jython being able to keep up with the Python development a bit more, so that it can be considered for actual production code. I certainly would like to see the multi-threading support, combined with the performance of the JVM for Python…
Working on large scale distributed systems at Google could have only worsened Guido’s bias on lock-based shared memory programming paradigms !
I am really hoping someone comes up with a GIL-less CPython implementation because Jython, despite all the advantages I touted, has not kept up with Python releases. I wonder “Jython 3000″ will ever see the light of the day
[...] ask then, why not just base Python on the ubiquitous JVM? Just take a look at Ananth’s blog here where he discusses this. The problem with Jython of course is that – by the project’s own [...]
I have just written a blog entry about this myself. An open letter to Guido. I wonder if he’d read it…
http://blog.snaplogic.org/?p=94
[...] September 11, 2007 Posted by Ananth in Python, Programming, Rants. trackback Juergen Brendel who commented on my post, about the Global Interpreter Lock, wrote a open letter pleading Guido to consider [...]
How many of those 200 language implementations really exist in a meaningful way? The perl one doesn’t look very complete.
You should look at Scala if you want to see a good language on top of the JVM.
@ All Reddit Trolls:
Read the frigging article before you comment or keep your opinions to yourself. Useless comments that convey your vague frustrations with Java or Sex will be mercilessly deleted.
“Just because it’s hard to remove it doesn’t mean that it shouldn’t be attempted.”
Agreed. Go to it and let us know what you come up with. That is Guido’s position. He’s tried it before and it was painful, if someone can come up with patches that removes the GIL without breaking 10,000 libraries then he is all for it. Good luck
@ Ryan:
Read Guido’s Blog. People *have* come up with a CPython fork that removes the GIL and is functionally compatible with all existing libraries. The reason why this patch did not make the cut is because Single Threaded Performance suffered as a side-effect.
http://www.artima.com/forums/flat.jsp?forum=106&thread=214235
There is even one person who commented on it and says he has a Py3K branch without the GIL.
I hate that people continue to bitch about Python + GIL
as if the world is only limited to THIS….
cant we remove all blog comments with GIL?
I am not at all interested in the GIL! I wonder if i am the only one
@shes
You will need to know the difference between Friday and a fried egg. It’s quite a simple difference, but an important one. Friday comes at the end of the week, whereas a fried egg comes out of a chicken. Like most things, of course, it isn’t quite that simple. The fried egg isn’t properly a fried egg until it’s been put in a frying pan and fried. This is something you wouldn’t do to a Friday, of course, though you might do it on a Friday. You can also fry eggs on a Thursday, if you like, or on a cooker. It’s all rather complicated, but it makes a kind of sense if you think about it for a while.
Sun’s SPARC chips are slow relative to x86-64.
Java on takes up a lot of ram, it makes it look slow.
Well said. Unfortunately facts don’t always matter. I still hear guys who prefer to program in ruby bitching about java being slow. And if something then _that’s_ funny. A an ex-colleague of mine quite good at C++ (template magician type) and also prefer Ruby above anything. So he usually compares C++ in Java and based on that comparison he decides to learn RoR because java is slow anyway and Struts (think 1.2…) is lame.
.NET people also bitch java while .NET seems to eat a whole lot more memory than Java. (I’ve only seen a _.NET_ biased micro benchmark, but it probably couldn’t do much better memorywise.) However those 200 languages are pointed to for years but as somebody told almost nobody uses them. Jython is a shame. I used it once and I had to do a lot of type related tricks to pass arguments to Java from jython (usually fiddling with Arrays.asList). It’s way behind python to be usable and also very slow. And then let’s take a look at .net and IronPython. It’s up to date, it seems to have no problems with interfacing with other CLI code and it’s fast (0.5-2x as fast as CPython). And the whole thing is started by the same guy who started jython. OK, that’s an N+1 design of the same thing so it should be better, but still.
I also strongly agree with your opinion that the scripting languages should abandon their lousy VMs because there is the JVM (and the CLR of course) with a lot more effort and knowledge put in. When they started out like a decade ago the JVM was obviously not an option. But today, c’mon…
Bug in title: Should be
!Java.equals(Slow)
What is the definition of “fast”? If its numbercrunshing with a high value of input n, then Java is fast. If its about a fast startup, highly optimized libraries or even the developers time then CPython is way above Java and especially above Jython.
Guido’s point about not using threads wasn’t that one shouldn’t take advantage of multiple cores/processors. His position has generally been that one should use multiple processes rather than multiple threads. There are various different attempts at that: http://wiki.python.org/moin/ParallelProcessing
And Guido’s not stubbornly adverse to removing the GIL. He’s stated he would if the new implementation doesn’t hurt single threaded performance.
Let me rant:
1. You say: “Google uses Java, I repeat JAVA for most of their popular applications.”. Ok, I have Google Earth, Google Video, Google Desktop. No Java here. GMail, Google Pages, Doogle Docs. No Java there. I was wondering how you got there… Then I read the interview linked in. It said “Large parts of popular Google products are written in Java.”. Ok, now that’s a different thing. Blending a little, huh?
2. You say: “JVM can run 200 different languages”. I briefly looked at the list. Apart from the fact that most are esoteric, there are lots of language implementations in Java. So you have a Haskell/Lisp/Logo interpreter which was written in Java. This does not make this language run on the JVM. If you have a compiler for a language which emits java bytecode, then you have a language which runs on JVM. I doubt that there are 200 of them.
3. You say “The Java Virtual Machine and the .NET common language runtime are amazing pieces of technology that are close to an entire operating system in complexity”. Now this is strong. A virtual machine is a virtual machine, an OS is an OS. OK? Try writing a simple OS and try writing a simple VM. You’ll see the difference. Your VM can use the services the OS provides for resource management (memory, storage, processor, devices). Your OS will have to handle them. Have fun there.
Now, I don’t say that Java = Slow. I’m saying Your Arguments = Dubious.
Dixit.
@ Dixit
1. “Large parts of popular Google products are written in Java.”
You can interpret the statement in ways you think are meaningful. I don’t deny that a writer can bend words that might seem deviant of the truth, although that was not the intention here.
And as I quote at the beginning of the article, this was a marketing argument I used to convince my friends. It is only as “dubious” as the popular statement – “Google uses Python”.
2. “JVM can run 200 different languages”
I doubt if you read the preamble of the Robert’s list: “The following is a list of programming languages for the Java virtual machine aside of Java itself.”
*FOR* the JVM. And the 200 is not meant to Wow you. The point is that the JVM is flexible enough to be host for arbitrary scripting languages. And it *should* be the preferred host because its damn good at what it does – being a fast and flexible VM.
3. Try writing a simple OS and try writing a simple VM.
You can find my simple OS here: http://sarovar.org/projects/quark
My day job is writing code for the world’s most advanced OS – http://www.sun.com/solaris
The simple VM which I did not write but understand to some extent is the Ruby Interpreter. And I work at Sun. I am to limited extents aware of the incredible amount of intelligence that is present in the Java VM.
In some cases, it lets the JVM perform faster than C (Look for the Sun Tech Days 2007 demo on this topic – I don’t have the link handy).
I suspect you spent too much focus on nitpicking the article that you didn’t see what it was trying to say. Which is pretty simple:
THE JVM IS THE FASTEST AND MOST ADVANCED CROSS PLATFORM VM. MAKE IT THE PREFFERED HOST FOR YOUR SCRIPTING LANGUAGES.
Yeah. I have to scream because Reditt and Dzone trolls think they have an automatic right to comment without RTFA
1- Java is slow to develop in.
So java=slow.
2- http://www.artima.com/forums/flat.jsp?forum=106&thread=214235
Maybe you should RTFA you reddit troll you
I think python will have an interesting path over the next few years but not by adding more thready goo.
3- Yeah jython is pretty cool
@ Adam
1- Java is slow to develop in. So java=slow.
That is an argument I personally believe in. Which is why I prefer Python for most of my programming
2. http://www.artima.com/forums/flat.jsp?forum=106&thread=214235
FYI, Guido wrote the post you refer to AFTER Jurgen (the first commenter on this post) wrote an article that cites this blog.
3- Yeah jython is pretty cool
You bet
[...] lang gehanteerde argument dat de perfomance van Java niet goed zou zijn is voorgoed verleden tijd en dus is het wachten op nieuwe argumenten waarom men geen Java zou moeten [...]
Ananth,
Let me nitpick a little more, but first let me explain my motivation.
Whatever message you are trying to convey, I find it crucially important to make your presentation solid. This means getting the right facts out, presenting them in a clear way, build a decent argumentation, and draw reasonable conclusions.
Your way of presenting an otherwise sensible message failed to achieve this.
Maybe I am wrong, and I should not be so frustrated when I see flawed arguments. Unfortunately too much hot air is sold by too many using shallow and bombastic phrases. Then I get tired…
Back to nitpicking:
1. When one looks at a statement “Google uses Java, [...] for most of their popular applications”, there are very few ways one can interpret this. I believe we can agree that it means more or less this:
a) Google has applications, some of them popular, others not
b) Out of the popular applications Java is used in more than 50%
Now, I’m not aware of all of Google’s applications, but from what I see their popular applications do not use Java. If you can support your claim, please do it. I’ll apologize and eat my humble pie, humbly.
But if it is not so, please admit it. Don’t hide behind the word marketing.
2. If your dayjob is writing code for Solaris and you are aware of the internal complexities of the JVM, AND you say that the VM complexity is comparable to an OS’s complexity, would you care to elaborate?
I don’t write OSes or VMs every day, but my limited experience with them gives me the feeling that they are very different in complexity. I might be wrong. Again. If so, I’ll humbly eat my humble pie. Humbly, again.
But until you convince me otherwise, I’ll stick to my opinion: an OS and a VM cannot be compared in complexity.
3. Your message, that scripting languages should be hosted on JVM was more-or-less clear and understood. I don’t necessarily agree with it.
I was not taking on your opinion, but was pointing out what I consider fallacies in your arguments.
Facts, logic and reasoning will convince me that I was wrong, or at least will help me understand your position better. We should stick to them facts, logic and reasoning.
@ Csaba
> Your way of presenting an otherwise sensible message failed to achieve this.
Thanks for the feedback. Truly appreciated. I don’t fancy myself as much of a writer
> Now, I’m not aware of all of Google’s applications,
> but from what I see their popular applications do not use Java.
Please read about the Google web toolkit: http://code.google.com/webtoolkit/
That is what AJAX apps like Google Maps and Google Mail are built on. I think your resistance to accept google products using Java comes because you don’t see them on the client side and google is rarely communicative about what it uses on the server side. The link on the interview posted in the article is one of the few places (I could find) where Google openly admits about its collusion with Java.
Remember that Google is a very clever marketing organization too. They would never want anyone to associate their name with Java – which traditionally associated with Slowness. So they have driven their branding as such and I can see they have succeeded at it too
> But until you convince me otherwise, I’ll stick to my opinion:
> an OS and a VM cannot be compared in complexity.
I think anyone with common sense ought to recognize that fact that VMs and OSes are as different as Chalk and Cheese. And the original statement tells: “The JVM is an amazing piece of technology that is *close* to an entire operating system in complexity”.
I cannot derive a Partial Differential Equation of the third order and seventh degree to prove my statement. But, here is my attempt anyway
A very unscientific form of proof would be the number of lines of code, number of source files etc. FWIW the OpenSolaris source drop has 35000+ source files and the OpenJDK source drop about 27000+. If someone has a tool that could do a Function Point analysis, I would be curious to know the results as well !
In a Typical NUMA system, you have the notion of Memory Latency Groups. i.e. Different addreess ranges in memory can be accessed at different speeds by different CPUs depending on the memory controller and DIMM placement. It is advantageous for a thread bound to a CPU to operate on addresses that are “local” to the CPU. The JVM understands all this and optimizes the thread scheduler and the runtime memory allocator to function efficiently depending on the lgroup organization.
Another example: You can do a Dynamic Reconfiguration (DR) in solaris (and linux too IIRC) to Hotplug a CPU. The JVM can detect the hotplug and make use of the newly available CPU on the fly.
Another example: If two threads with similar stack traces get bound to the same CPU or cores that share the cache, they could start invalidating each other’s cache lines. For example, this is quite possible in a CPU with Hyperthreading technology. In such a case, the JVM will randomize the cache line index of these “hot” stack frames to avoid this problem.
Just take a look at the OpenJDK source and you will know how much of hardware it understands and what a misnomer the name – “Byte Code Interpreter” can be !
There are certain things that you “feel” as an engineer. I know DTrace is the most powerful tracing framework ever designed – but if you ask me to ‘prove’ it, I can do a pretty bad job of it. My cognition and experience are not wide enough for me to attempt it. But AFAIK, the JVM has been *hand-crafted* to behave optimally for a specific OS on a specific Platform with specific Hardware characteristics. Can you cite anything other than the .NET CLR which can claim to do something similar ?
Facts, Logic and Reasoning Please …
Well Can we say a VM is an OS for the OS??? Am way too ignorant about VMs to conclude about the complexity issues…… Would try to check up more on my free time….
Has been a java hater for quite sometime(converted early and have stayed so) But may be they have improved a lot, my curiosity has been roused enough to try java next time (Good work Ananth)…. But I keep my fingers crossed on conclusion till i try that..
For the part about feel as an engineer….. Well I agree with u Ananth…. There are many thing not as straightforward nd not easily given to proof.(Not that they can’t be… Just too hard nd smtimes pointless to try). Call it Implicit Association (courtesy : Blink)if you want….. And I am doing a MSc in cognitive science program(1st year though) hope that helps my credibility
M.Sc. in cognitive science – SEXY
Which university is that ? I would love to do it sometime !
Well that is in our own backyard… University of Allahabad, Allahabad….
And by the way do u know of a torrent seed link for solaris 10… Connection over here is hopeless for me download…
You wont believe how I landed here. I’ve been raking my head on ways to scale python applications on multi-core/multi-cpu architectures. Hopped from one place to another searching for answers, till here.
@ Joe:
In the last few weeks I have been looking at different solutions and parallel python is the most impressive. Its a framework written in about 1000 lines of python code and it lets you easily scale “submit-job, retrieve-result” kind of applications from NUMA systems to a distributed memory clusters. Context switches are a concern, but I will hold judgment until I get around to benchmarking it properly.
http://www.parallelpython.com/
IMHO:
You indicate that Guido is more or less saying “don’t use threads” and that he’s going in the wrong direction. I actually think he’s going in the right direction–
Threads make your program more complex and non-deterministic (and thus buggy.) I think the right direction is to use message passing concurrency.
Erlang is an interesting language that takes this idea to a high level:
http://www.pragmaticprogrammer.com/articles/erlang.html
Another interesting article on the problem with threads:
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
Instead of (shared-state) multi-threaded programming which, can make your program more confusing and non-deterministic, both Erlang and Google Gears take the approach of using very efficient and light message passing for communication between basically isolated processes.
I think it’s the future and the right approach. Afterall, it’s how the Internet works… and the brain — both very complex systems that seem to scale a lot better than the “traditional” shared-state multi-threaded software development model.
I think Google is actually on the right track and obviously at the forefront of exploiting massively parallel system taking advantage of things such as map reduce (http://labs.google.com/papers/mapreduce.html.)
I’m an old time Java guy and I agree that Java is king, but I think it’s becoming more of a “systems language” with simpler scripting languages such as Python and JavaScript now taking on the brunt of applications development (because it’s EASIER!)
Leave the complex shared state multi-threaded program in the systems domain, and let the masses code in simple scripting languages using message passing concurrency so their programs are easy to understand and deterministic.
Glad to see Sun moving in that direction with the new scripting support and all the languages you mention that can run on the JVM.
I guess the bottom line is there is room for both points of view as one can be built on top of the other.
[...] Java != Slow [...]
Java vs YourFaviouriteLanguage in multi-threaded tests to see how their application performs with more than one thread.
While many languages support course-grain parallel processing or even fine grain multi-threaded code, there seems to be any number of reasons this does not happen in real systems.
I imagine it will be a while before we see C# or Python running on 768 processor server.
http://www.azulsystems.com/products/compute_appliance.htm
Nowadays, it does not run slowly but it eats more memory than any languages and CLR too. This is old & new problem. I love Java but sometimes, I think about memory usages that Java and .NET use. I have designed the same program in #Dev and Netbeans, when I run them for comparing. So, .NET (3.0) use 6 MB but Java (6 update 10) use 21 MB. I think this is the current problem of JVM.
One thing is for shure: JAVA IS SLOW(er) on SPARC Solaris.
It’s quite funny to see that the inventor of Java is not able to make it run decently on it latest processors.
I experience 4x to 8x slower perf running Java servlets on a brand new 1.4GHz T2 than on a 3 years old dual core AMD 2.2GHz both running Solaris 10. They will tell you that T2 is meant to do a lot in parallel but my loadtests is that you shouldn’t give it more than 100 simulaneous requests.
Also, I’ve experienced a lot more instability on JVM-Tomcat platform than on any Apache-PHP configs.
The problem here is that one bad webapp can pull all the JVM down, whereas in PHP, each request has its own http process (and memory space) which can die without hurting its neighbours.
Hello webmaster
I would like to share with you a link to your site
write me here preonrelt@mail.ru
I’ve worked with Java frameworks for a number of years (Jserv, Spring, Tomcat) – they are definitely not performance dogs, but Java on the desktop? Forget it! Eclipse takes longer to start up than windows. I think the perception that Java is slow is warranted given the startup cycles, though once the application is in memory – not such a problem. Long standing processes such as application servers seem to perform favorably.