Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Galaxy in-memory data grid released
Posted Jul 11, 2012 8:17 UTC (Wed) by man_ls (subscriber, #15091)
Posted Jul 11, 2012 11:55 UTC (Wed) by geertj (subscriber, #4116)
When i started programming, i thought the choice of programming language was very important. This view was very instinctive. Basic didn't do it for me, but Pascal gave me this warm and fuzzy feeling, which later i also got from C and C++.
Then i bought into this "whatever works" crap. Language doesn't matter, as long as it does the job. And Java for sure does the job. If i create a Java job ad tomorrow, i get many people who respond. So it's safe, and functional. Because software doesn't have to be beautiful. It just has to work.
But now i'm firmly back into the language matters camp. I believe that great (as opposed to mediocre) software requires a language that contains "beauty". This is because great software require passionate programmers to create it. And a passionate programmer is not willing, at least not for long, to compromise on his/her primary means of expression. And in my view, Java does not have this elusive quality.
Posted Jul 11, 2012 12:24 UTC (Wed) by robert_s (subscriber, #42402)
Posted Jul 11, 2012 13:05 UTC (Wed) by augustl (subscriber, #75060)
When you're a beginner, only the overall big picture matters. Electric or acoustic? That's about it. Doesn't really matter if you get this or that electric guitar, at least to some excent.
When you're an expert, you want a guitar with [insert lots of domain specific guitar jargon here] because you know how play better by optimizing tiny details.
The paralell to programming languages should be obvious. :)
Posted Jul 11, 2012 18:51 UTC (Wed) by daniel (subscriber, #3181)
Posted Jul 11, 2012 19:43 UTC (Wed) by zlynx (subscriber, #2285)
Sure, *theoretically* you could use it through JNI. But seriously now. Would you?
So it isn't the Java language that is the problem. It is the entire Java environment.
Posted Jul 11, 2012 19:54 UTC (Wed) by nix (subscriber, #2304)
Posted Jul 12, 2012 22:40 UTC (Thu) by pron (guest, #85696)
Let me explain the choice of Java (or rather, the JVM) for the project. For large-scale high-performance software, the JVM is almost the only reasonable choice. First, the number of available high-quality component, esp. open-source, is unparalleled. Second, the JVM has excellent concurrency support, from low-level (memory barriers, CAS) to high-level (thread pools and tasks), and incredible parallelism support through the fork/join framework (that our commercial product built on top of Galaxy uses), that's available for C/C++ only if you use Cilk, and very few projects do. Java gives you all this fine-tuned concurrency on all processors and OSs. Finally, for large enough systems, the JVM provides better performance than anything else out there, including C++ in most cases. In addition, some interesting concurrent data-structures require garbage collection, and Java's GC is without rival. All of these reasons combined make the JVM the most practical and responsible choice for a large class of software systems.
Good opportunity for Java update
Posted Jul 15, 2012 17:24 UTC (Sun) by man_ls (subscriber, #15091)
Posted Jul 15, 2012 19:30 UTC (Sun) by bjartur (guest, #67801)
Posted Jul 16, 2012 5:09 UTC (Mon) by pron (guest, #85696)
I'm not entirely sure what you mean. Can you elaborate?
> there is still a cost associated with the first execution of code
Sure, JVM applications' startup time is not stellar, but for server apps that are seldom re-started, what's the problem?
> Also, there are no low-level optimizations possible.
Here you're wrong. For most common cases, low level optimizations are better with Java than with C. That's because CPUs are so advanced these days, and there are optimizations that can only be done at runtime. The only low-level optimization not currently available for Java is SSE (though that will change).
> synchronization between threads is effective, but usually very slow
Simple thread synchronization is just as slow as on other platforms. But the JVM gives you access to low-level synchronization like memory fences and CAS-es, and fork-join is plain awesome.
> the garbage collector induces noticeable delays and unpredictabilities in performance
True, but modern garbage collectors are more predictable. Azul even has what they call a "pauseless" GC, that has a (quite low) upper bound on GC pauses.
As for functional programming - the Java language doesn't have that, but plenty of JVM languages do, some of them (particularly Clojure) are quite elegant.
So when you add everything up and also consider JVM monitoring, I think that for most large, performance-wary application, choosing anything but the JVM requires explanation. The JVM is pretty much the default choice.
Posted Jul 16, 2012 6:10 UTC (Mon) by wahern (subscriber, #37304)
I've nothing against the JVM and Java per se, notwithstanding integration and compatibility issues, just like I've nothing against using Perl or Fortran.
But it's worth pointing out that people who use proprietary systems--which unfortunately must include Java since the only high-performance examples are proprietary--perceive only the very best inside the black box they're presented. They're handed a bunch of, say, atomic or threading primitives and think, "hey, my vendor chose this so it must be the best algorithm, and they must have implemented it in the sanest, more performant manner possible". And you _have_ to think that way because the only alternative is to become bitter and unenthusiastic about something you have to use day-in and day-out.
The biggest pain regarding Java is GC and unix integration. Neither of those will ever be better than plain C or C++. It's not even worth arguing about. Either they matter or they don't matter, for the most part.
Posted Jul 16, 2012 9:07 UTC (Mon) by man_ls (subscriber, #15091)
Can you elaborate?
The same goes for all other low-level optimizations, but it is most noticeable for memory allocation. For example there was talk here on LWN about making Xen guests communicate better with the host operating system about their memory necessities. Having a (virtual) operating system inside another is bad enough; having a (virtual) machine inside another will have higher costs regarding memory. Of course, if you are not worried about memory then it is no problem; but e.g. big data applications will have to be concerned (since they eat memory up like crazy).
Simple thread synchronization is just as slow as on other platforms.
But the JVM gives you access to low-level synchronization like memory fences and CAS-es, and fork-join is plain awesome.
Azul even has what they call a "pauseless" GC, that has a (quite low) upper bound on GC pauses. As for functional programming - the Java language doesn't have that, but plenty of JVM languages do, some of them (particularly Clojure) are quite elegant.
So when you add everything up and also consider JVM monitoring, I think that for most large, performance-wary application, choosing anything but the JVM requires explanation.
For me, strong typing, compilation and the lack of functional programming are enough to rule Java out, and the other functional JVM languages are not interesting (there is a limited pool of developers). I suspect many other people are in the same situation, as it is not usual to see startups use Java as their primary platform. But I am intrigued about e.g. Twitter using Scala. Perhaps the cost of entry is high but (as you say) for large applications the JVM is a good choice. But as such, it would be positioned as a replacement for C++, not for server-side web applications, if I am reading the situation correctly.
Posted Jul 16, 2012 10:55 UTC (Mon) by jezuch (subscriber, #52988)
I'm curious: where did you get this number? I'm pretty sure that if it was true, I would have noticed it by now.
Posted Jul 16, 2012 11:01 UTC (Mon) by man_ls (subscriber, #15091)
Posted Jul 16, 2012 16:58 UTC (Mon) by raven667 (subscriber, #5198)
Posted Jul 16, 2012 21:33 UTC (Mon) by man_ls (subscriber, #15091)
This bit of data seems to suggest that things have improved about 4-fold since then. My own results are a bit higher than those on the page (core i5; IcedTea6): 0.035s vs 0.002s for 1M synchronizations, suggesting a cost of about 30ns for each synchronization. Calling a synchronized method is even cheaper, about 20ns. Not too shabby...
My updated code yields:
1M computations: 0.035s
1M synchronized code blocks: 0.004s
1M synchronized method calls: 0.023s
Posted Jul 17, 2012 4:29 UTC (Tue) by wahern (subscriber, #37304)
If Azul Zing were as magical as they say it is, the company would have been scooped up by Sun, Oracle, IBM, HP, or even Microsoft long ago, instead of perpetually taking in millions from investors. The company originally implemented their technique in hardware. They specially designed processors with a unique memory architecture. Emulating this architecture on commodity hardware is, clearly, quite expensive.
Zing (like many other techniques with serious downsides ignored by the cult) is just a crutch for Java/JVM zealots eager to believe that Java is the perfect language. (I mean, I'm sure it's amazing work, just not in the way people think it is.)
Which is not to imply that HotSpot and V8 don't have incredibly powerful and performant JIT compilers. They're amazing feats. Just not quite as amazing as people think they are. Their language specifications impose costs that can't just be willed away, no matter how many engineers you throw at the problem, and no matter how many graduate thesis papers get written.
Posted Jul 17, 2012 5:47 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Azul also produces their own hardware with a hardware acceleration of garbage collection. It works MUCH better.
Posted Jul 17, 2012 8:16 UTC (Tue) by man_ls (subscriber, #15091)
Posted Jul 17, 2012 8:24 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Posted Jul 17, 2012 8:29 UTC (Tue) by man_ls (subscriber, #15091)
I understand that what Azul does is keep lots of object references so GC doesn't have to do much work. It might be inferred that object allocations must also be penalized, right?
Posted Jul 17, 2012 8:44 UTC (Tue) by Cyberax (✭ supporter ✭, #52523)
Posted Jul 13, 2012 2:42 UTC (Fri) by cmccabe (guest, #60281)
Not true. There are plenty of JVM languages.
Anyway, before you rush in to micro-optimize things by re-coding them in C, maybe you should figure out what exactly the software is doing and whether it could benefit from this micro-optimization. Although that might ruin the fun.
Probably the worst thing you can say about Java is that since it's garbage-collected, it will never be suitable for certain realtime problems (unless you use something like Azul). But this guy never said he was solving those realtime problems.
Posted Jul 13, 2012 23:12 UTC (Fri) by wahern (subscriber, #37304)
It's sort of like a Windows developer posting his project to a Linux group. Cool, but not of much use.
It's a very apt analogy, I think. Unix, Windows, Java--three different development and execution environments with very little commonality and drastically different developer ecosystems.
Posted Jul 16, 2012 7:40 UTC (Mon) by cmccabe (guest, #60281)
Disclaimer: I work on Hadoop, which is written in Java.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds