Weekly Edition
Return to the Development page
| |||||||||||||
Galaxy in-memory data grid released
Parallel Universe has announced
the release of its Galaxy
distributed memory system under the Lesser GPL. "What makes Galaxy
different from other IMDGs is the way it assigns data items to cluster
node. Instead of sharding the data on one of the keys using a consistent
hashing scheme, Galaxy dynamically moves objects from one node to another
as needed using a cache-coherence protocol similar to that found in
CPUs. This makes Galaxy suitable for applications with predictable data
access patterns, i.e. applications where the data items behave according to
some proximity metric, and items that are 'closer' together are more likely
to be accessed together than items that are 'far' apart."
(Log in to post comments)
Galaxy in-memory data grid released Posted Jul 10, 2012 18:11 UTC (Tue) by robert_s (subscriber, #42402) [Link]
I'll just say here as it's not mentioned anywhere in the announcement:
Java.
Galaxy in-memory data grid released Posted Jul 11, 2012 8:17 UTC (Wed) by man_ls (subscriber, #15091) [Link] Thanks for saving me a trip.
Galaxy in-memory data grid released Posted Jul 11, 2012 11:55 UTC (Wed) by geertj (subscriber, #4116) [Link]
+1
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.
Galaxy in-memory data grid released Posted Jul 11, 2012 12:24 UTC (Wed) by robert_s (subscriber, #42402) [Link]
It's not so much about the language itself. Although I find that unbearable too.
Galaxy in-memory data grid released Posted Jul 11, 2012 13:05 UTC (Wed) by augustl (subscriber, #75060) [Link]
The question about which programming language to choose is eerily similar to which guitar a guitar player should choose.
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. :)
Galaxy in-memory data grid released Posted Jul 11, 2012 18:51 UTC (Wed) by daniel (subscriber, #3181) [Link]
Then recode it in C++. I'm sure you will have some takers.
Galaxy in-memory data grid released Posted Jul 11, 2012 19:43 UTC (Wed) by zlynx (subscriber, #2285) [Link]
When a component is written in Java it isn't that the language is Java. It's that if you want to use it, you need to do everything in Java.
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.
Galaxy in-memory data grid released Posted Jul 11, 2012 19:54 UTC (Wed) by nix (subscriber, #2304) [Link]
Rather, it is the virtual machine trap. Emacs is just the same: if you do one thing in Emacs you tend to have to do *everything* in Emacs. (The difference is, Emacs is also a text editor, thus comes with a religion built in, so that most of us Emacs users don't mind this restriction. Java is merely a language, with no faith-based help.)
Galaxy in-memory data grid released Posted Jul 12, 2012 22:40 UTC (Thu) by pron (guest, #85696) [Link]
Author of Galaxy here.
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) [Link] What do you think about these issues, and are they relevant to your project?
Good opportunity for Java update Posted Jul 15, 2012 19:30 UTC (Sun) by bjartur (guest, #67801) [Link]
Well, you could compile Common Lisp to JVM bytecode.
Good opportunity for Java update Posted Jul 16, 2012 5:09 UTC (Mon) by pron (guest, #85696) [Link]
> the JVM comes with its own memory allocation scheme, which often is at odds with the memory management of the host operating system
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.
Good opportunity for Java update Posted Jul 16, 2012 6:10 UTC (Mon) by wahern (subscriber, #37304) [Link]
How do you go from writing an apologia with explicit admissions that the JVM is suboptimal to "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."
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.
Good opportunity for Java update Posted Jul 16, 2012 9:07 UTC (Mon) by man_ls (subscriber, #15091) [Link] Can you elaborate?Sure. The virtual machine allocates memory in chunks, for efficiency; but this means that the host operating system is often not able to optimize its use of pages. For example, allocations done using mmap on Linux can be tracked and optimized, but the JVM is a black box as far as the Linux kernel is concerned. 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.Not really true; Java forces the generic semaphore implementation, which cannot compete with things like spinlocks. IIRC using synchronized imposed a penalty of about 100ms.
But the JVM gives you access to low-level synchronization like memory fences and CAS-es, and fork-join is plain awesome.Thanks, didn't know that. From what I've read fork-join is a variety of map-reduce, which is available for other languages, right? I've used it in JavaScript on MongoDB on a completely different context. Having easy access to the fork and join functions is interesting. Of course, the devil is in the details. 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.Are you actually using Azul, which is a proprietary implementation? And, are you actually using Clojure or Scala? 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.This point of view is quite common in the Java world, and I can understand why some people complain about it (e.g. the "virtual machine trap" mentioned by nix). Paraphrasing, it goes like this: "the JVM ecosystem solves all problems: first concern is addressed by [x proprietary system], second concern by [y weird functional-only language], third by [z optional Oracle-only feature], fourth by [w optimization on a proprietary operating system]. And the JVM is open source and has several Free implementations!" So on paper "Java" (or rather the JVM) solves all problems. But in reality, those concerns cannot be all solved at the same time. What you usually have is a Java monoculture using tens or hundreds of Apache libraries and a few proprietary ones on the Oracle JVM, running on just one operating system for fear of having it all crumble upon you. That is not what we are used to in the Free software world. Perl, Python, C, C++ (and even stepchildren like PHP or JavaScript) are fiercely free and include everything needed for development, from day one. If one optimization is available on one platform, it is usually available on all of them. The languages solve only one subset of problems, but that subset is always solved. The toolchain is also free, and there are no proprietary augmentations. Or rather, people do not use them as arguments that "C++ is great (with Intel's compiler)" or "Python rules (with Apple's extensions)". Or rather, a subset of people use these arguments but they are quickly disregarded. 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.
Good opportunity for Java update Posted Jul 16, 2012 10:55 UTC (Mon) by jezuch (subscriber, #52988) [Link]
> Not really true; Java forces the generic semaphore implementation, which cannot compete with things like spinlocks. IIRC using synchronized imposed a penalty of about 100ms.
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.
Good opportunity for Java update Posted Jul 16, 2012 11:01 UTC (Mon) by man_ls (subscriber, #15091) [Link] I did my own benchmark, and I am citing from memory. It was a long time ago, things have probably improved a lot since 2004 or so...
Good opportunity for Java update Posted Jul 16, 2012 16:58 UTC (Mon) by raven667 (subscriber, #5198) [Link]
Probably 8-)
One thing to point out is that the environments with the most optimization effort being put into them are the JVM and the various JavaScript runtimes. All the resources spent on research and implementation shows, in the different benchmarks I've seen Java and JS tend to bubble up around the top closer to compiled languages than other VM environments like Perl, Python, PHP or Ruby.
Good opportunity for Java update Posted Jul 16, 2012 21:33 UTC (Mon) by man_ls (subscriber, #15091) [Link] I think that my results might have been 100ns per synchronization, not 100ms. Sorry about the confusion; funny how memory can make you twist things around to suit your arguments. So let's check out how things behave in practice.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
Good opportunity for Java update Posted Jul 17, 2012 4:29 UTC (Tue) by wahern (subscriber, #37304) [Link]
Azul's technology explodes the amount of RAM used. For example, the minimum memory spec is 32GB:
http://www.azulsystems.com/products/zing/specs
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.)
I don't understand why people keeping buying into Java and JavaScript hype hook, line, and sinker. How many JIT implementations have HotSpot and V8 chewed through? Remember a couple of years ago when Google brought aboard Lars Bak? There was a huge media campaign--highly technical-- describing all the awesome and revolutionary techniques being applied to accelerate JavaScript. Then a year later half of those techniques were silently discarded. People rarely talk about the costs, just the benefits. Benefits are easy to describe (fast!), costs are more difficult to describe (both technically and because it deflates egos and expectations).
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.
Good opportunity for Java update Posted Jul 17, 2012 5:47 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Azul uses dirty VM tricks to achieve incredible performance feats. They're incredibly inefficient on x86-based hardware, so that's why it requires a lot of RAM. And since most of their customers are financial institutions - they don't care much about it.
Azul also produces their own hardware with a hardware acceleration of garbage collection. It works MUCH better.
Good opportunity for Java update Posted Jul 17, 2012 8:16 UTC (Tue) by man_ls (subscriber, #15091) [Link] Throwing memory at problems is always a good way to speed them up. That is essentially what IBM does with WebSphere and its many frankenstenian by-products: initialize everything in advance, take ages to start and consume lots of RAM. After that it goes fast. It looks like a good idea until you find out that dev machines also have to be top of the line machines with 4 GB RAM -- it may not look much today, but not everyone can buy hardware every two years. Or provide VMs with so much memory.
Good opportunity for Java update Posted Jul 17, 2012 8:24 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
It's not like they need a lot of ram, it's just that their GC algorithms have very high overhead. In fact, large amounts of ram on normal GCs is a receipt for failure because of lengthy pauses during full collections.
Good opportunity for Java update Posted Jul 17, 2012 8:29 UTC (Tue) by man_ls (subscriber, #15091) [Link] Yes, GC can be a problem if you allocate and free large amounts of RAM (especially in a lot of objects or string manipulations). The IBM trick is to never release the objects (i.e. keep object references around) so the GC does not have to work.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?
Good opportunity for Java update Posted Jul 17, 2012 8:44 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Nope, they need a lot of ram to make their GC pauseless(in tech speak: to allow the mutator work in parallel with the collector). They do this by simulating forwarding pointers using vm.
Galaxy in-memory data grid released Posted Jul 13, 2012 2:42 UTC (Fri) by cmccabe (guest, #60281) [Link] > When a component is written in Java it isn't that the language is> Java. It's that if you want to use it, you need to do everything in Java. 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.
Galaxy in-memory data grid released Posted Jul 13, 2012 23:12 UTC (Fri) by wahern (subscriber, #37304) [Link]
I don't think that was his point. His point, I believe, is that Java is a veritable nightmare regarding system administration and interoperability.
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.
Galaxy in-memory data grid released Posted Jul 16, 2012 7:40 UTC (Mon) by cmccabe (guest, #60281) [Link]
There are some things about Java that could be improved. However, at the end of the day, Java is a very popular language for big data applications, and there are very good reasons for that.
Disclaimer: I work on Hadoop, which is written in Java.
|
|||||||||||||