Slashdot Mirror


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."

18 comments

  1. Included in Sun Java? by 0x461FAB0BD7D2 · · Score: 4, Interesting

    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.

    1. Re:Included in Sun Java? by shodson · · Score: 3, Informative

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

  2. AAAAHHHH!!! by Fizzl · · Score: 0, Offtopic
    paradigms

    I demand this word to be banished from every language. When I find a word which my english-finnish dictionary only offers [word]-ma explanation, I want to scream.


    2:FEF> paradigm paradigms,['pÔrÉ,daÈm],formal, paradigma (muotosarja), kaava (malli) .


    If it doesn't mean what you want to say, don't use it.

    kaava(form) or malli (model) would have been perfectly acceptable and would sound less retarded.
  3. Sample code? by Saiyine · · Score: 2, Insightful

    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.

    --
    Hosting 20G hd, 1Tb bw! ssh $7.95
  4. Re:java? by aled · · Score: 0, Troll

    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.

    --

    "I think this line is mostly filler"
  5. Re:java? by Anonymous Coward · · Score: 0

    petty you didn't fully copypaste it... your version doesn't work

  6. Java is good for mathematical computation by Anonymous Coward · · Score: 1, Insightful

    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.

    1. Re:Java is good for mathematical computation by Anonymous Coward · · Score: 1, Informative

      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.

    2. Re:Java is good for mathematical computation by Anonymous Coward · · Score: 1, Informative

      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.

    3. Re:Java is good for mathematical computation by Anonymous Coward · · Score: 1, Informative

      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.

    4. Re:Java is good for mathematical computation by karevoll · · Score: 1

      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. :)

  7. Re: Java by Refrozen · · Score: 1

    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 > *

  8. A few bones to pick with the Ibis introduction... by Anonymous Coward · · Score: 1, Informative
    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 for "expressiveness", I'm not sure what they mean by this. You can pass any serializable object, and exceptions come back over the wire. That seems pretty expressive to me.

    Just because something isn't handed to you in the java libraries doesn't mean you can't do it.

    -- ac at home

  9. Re:A few bones to pick with the Ibis introduction. by rvannieuwpoort · · Score: 1

    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 becomes even worse.

    We are using Java for high performance computing on fast networks (Myrinet), so this is really not an option for us...

    Cheers,

    Rob

  10. Not another low-level grid product... by dkf · · Score: 1
    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 whether to use Ibis for particular components of my workflows, depending on whether it is actually cost-effective. YMMV...

    --
    "Little does he know, but there is no 'I' in 'Idiot'!"
    1. Re:Not another low-level grid product... by rvannieuwpoort · · Score: 1

      > 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.
      So in that sense, it is not really low-level.
      In fact, in one of the models, (Satin) communication is completely hidden from the user.

      Moreover, the most important piece of GridLab software is the GAT (Grid Application Toolkit).
      This is an API specifically designed for grid programmers. It is *very* highlevel. In fact, it is the most high-level grid toolkit I know of.
      The rest of the GridLab software is more low-level, because it implements services needed for the GAT :-) These services are not really intended for end users, although it is possible to use them directly...

      Cheers,

      Rob