> 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...
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...
Our group actually has a paper in this years HPDC conference, that shows a method to do hole puncing with TCP. We call it TCP splicing. This way, you don't have to implement a reliability protocol on top of UDP.
You can find it at www.cs.vu.nl/ibis -> publications...
Alexandre Denis, Olivier Aumage, Rutger Hofman, Kees Verstoep, Thilo Kielmann, Henri E. Bal: Wide-Area Communication for Grids: An Integrated Solution to Connectivity, Performance and Security Problems, Accepted for publication, HPDC-13, June 2004, Honolulu, USA.
Slashdot Mirror
> 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.
:-) These services are not really intended for end users, although it is possible to use them directly...
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
Cheers,
Rob
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
Hi guys,
f
Our group actually has a paper in this years HPDC conference, that shows a method to do hole puncing with TCP. We call it TCP splicing. This way, you don't have to implement a reliability protocol on top of UDP.
You can find it at www.cs.vu.nl/ibis -> publications...
Alexandre Denis, Olivier Aumage, Rutger Hofman, Kees Verstoep, Thilo Kielmann, Henri E. Bal:
Wide-Area Communication for Grids: An Integrated Solution to Connectivity, Performance and Security Problems,
Accepted for publication, HPDC-13, June 2004, Honolulu, USA.
Here is a direct link:
http://www.cs.vu.nl/ibis/papers/hpdc2004-denis.pd
Cheers,
Rob