Java-Centric Grid Computing: Ibis 1.0 Released

rvannieuwpoort writes "Ibis 1.0 has been released. Ibis is a flexible and efficient Java-based programming environment for Grid computing. Ibis improves Java's serialization and RMI performance up to a factor of 10. It also extends Java with a range of communication paradigms, including group communication, divide-and-conquer and collective communication. An additional nice feature of Ibis is that it can communicate through firewalls, without opening ports, using TCP. Ibis is free software (BSD-style license). It runs on any platform that has a Java 1.4 or higher JVM."

Java is good for mathematical computation

[Anonymous Coward]

as long as the inner loops do not create objects. If you stick to operations on double[] and int[] arrays you'll be fine - it's the same speed as C. If you create garbage or use their Vector class - all bets are off - it will run 4 times slower than C.

Re:Java is good for mathematical computation

[Anonymous Coward]

Actually, object allocation isn't bad at all in Java. More to the point, object allocation and GC in Java is now faster than heap-based object allocation and deallocation in C++. Can't beat that stack allocation tho.

Re:Java is good for mathematical computation

[Anonymous Coward]

In toy programs you may be right, but for programs with 10s or 100s of megs of heap data in active use GC is far slower than malloc/free allocation. Why? The garbage collector touches most memory pages and completely defeats the CPU's L2 cache. Main memory is around 100 times slower to access than L2 cache. Java programs with large churning heaps are slower due to the fact that they hit slow main memory more than an equivalent malloc/free memory scheme.

Re:Java is good for mathematical computation

[Anonymous Coward]

It is also worth mentioning that Java can generate array accessing code that is as efficient as Fortran because its arrays (also) never alias each other. C array code has to be conservative and is slower - its pointers and arrays can alias each other under certain circumstances and the code generated has to be conservative to take that into account - i.e., array elements have to be loaded from memory each time if another array is modified.

Re:Java is good for mathematical computation

[karevoll]

Youre probably better off using an ArrayList instead of a Vector, as Vectors have the overhead of being synchronized. This means a lot of uneccesary locking and unlocking of objects, which of course will slow down your code a lot. :)

Included in Sun Java?

[0x461FAB0BD7D2]

Could this ever be included in the Sun's Java SDK or JRE/JVM?

It uses a BSD-style license, so it should be fine. Schwartz and McNealy claim to be open-source friendly. And given that it improves development for Java, would Sun consider adding it to their Java, in some form? This would definitely put it over .NET, IMO.

Re:Included in Sun Java?

[shodson]

No, Sun has its own grid computing product [sun.com] that I'm sure it would rather support.

Sample code?

[Saiyine]

They should include in the web some sort of example of a working distributed program, maybe something so simple as a "Hello world!" with every node writing a single chat in a array...

Just an idea!

As a developer I just love working examples.

Re:java?

[aled]

Nah, people likes more simple languages that allow this:

map{map{tr|10|# |;print}split//,sprintf"%.8b\n",$_}
unpack'C*',un pack'u*',"5`#8

But don't believe me, after all is your code.

Re: Java

[Refrozen]

Nah, people likes more simple languages that allow this:
map{map{tr|10|# |;print}split//,sprintf"%.8b\n",$_} unpack'C*',unpack'u*',"5`#8
But don't believe me, after all is your code. I believe you.
map{map{tr|10|# |;print}split//,sprintf"%.8b\n",$_} unpack'C*',unpack'u*',"5`#8 > *

A few bones to pick with the Ibis introduction...

[Anonymous Coward]

From the first page of the Ibis web site:

The Ibis project also addresses the lack of expressiveness of Java RMI, which provides only synchronous client-server communication.

It is trivial to implement any sort of distributed communications protocol you want on top of RMI. We have a system based on RMI that has both point-to-point and broadcast messaging.

As for client-server, you do need a registry somewhere to bootstrap the system, but it is perfectly possible for every agent to have a registry.

As f

Re:A few bones to pick with the Ibis introduction.

[rvannieuwpoort]

Hi,

True, and we did actually try this.
The CCJ library (dowloadable from the Ibis page) does exactly this. It offers asynchronous communication and group communication built on top of standard SUN RMI.

However, implementing this on top of RMI is very inefficient.
For instance, communication can be made asyncrhonous by just performing an RMI from a new thread. However, a thread switch is already more expensive than a one-way latency on a high performance network.
If you want efficient group communication this

Not another low-level grid product...

[dkf]

Looking at this, I see that Ibis is based on the GridLab project and is therefore going to be a set of very low-level operations. This lets you get something medium-sized up and going very quickly, but won't scale well to very big problems; the world in general is far too large, wild and wooly for any low-level approach to approach anything like efficiency (you just have to ship too much metadata around.)

I'm more of a high-level guy myself; I'd much rather tell a system what it is to do and let it pick wh

Re:Not another low-level grid product...

[rvannieuwpoort]

> Looking at this, I see that Ibis is based on the GridLab project and is therefore going to be a set of very low-level operations.

Not really. Ibis is not based on GridLab software at all. Two of the Ibis developers are also involved in GridLab (I am one of them), but that's it. The two projects are not really related otherwise. The GridLab software and Ibis can be used next to each other though, that is true.
Next to low-level communication primitives, Ibis offers several high-level programming models.
S