* On intended use cases of the distributed annex
@ 2014-09-24 9:37 Alejandro R. Mosteo
2014-09-24 10:08 ` tonyg
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Alejandro R. Mosteo @ 2014-09-24 9:37 UTC (permalink / raw)
Hello people,
I am working nowadays in some heavy simulations that could benefit form parallelizing batches of work. Currently I either manually perform the launches of different lots, or leverage a cluster managed with Condor [1] at my institution, but using C code.
I was thinking about the possibility of requesting the installation of an Ada compiler in such cluster, and also if the DSA can fulfill my needs. I guess I could dig into the docs but probably some of you know some pitfalls that could elude me.
My question is: is the DSA well-suited for load balancing distribution, even if it is of simple nature. My impression from hearsay is that the DSA allows one to define a structure of nodes, and that you program as if this was a single entity, and the remote interactions are done for you. What I'm not sure of is if it supports, for example, is things like "allocate as many nodes as online machines", node migrations and things like that. Or, things like resilience through redundant nodes.
In other words, does the DSA support reconfiguration (even if it is at launch time) of nodes without editing a config file, or even online reconfiguration without manual intervention?
Thank you in advance,
Alex.
[1] http://research.cs.wisc.edu/htcondor/description.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: On intended use cases of the distributed annex
2014-09-24 9:37 On intended use cases of the distributed annex Alejandro R. Mosteo
@ 2014-09-24 10:08 ` tonyg
2014-09-24 10:09 ` tonyg
2014-09-24 10:09 ` Pascal Obry
2014-09-25 8:30 ` Maciej Sobczak
2 siblings, 1 reply; 12+ messages in thread
From: tonyg @ 2014-09-24 10:08 UTC (permalink / raw)
I used the DSA quite regularly and recently, but the job was not as complex as this. However I do know of a guy working at the french nuclear research institute who made a stack of PC's do some heavy computation using the DSA to break apart the computation job and put it back together using asynchronous messaging. It was quite a feat!
On Wednesday, 24 September 2014 10:37:49 UTC+1, Alejandro R. Mosteo wrote:
> Hello people,
>
>
>
> I am working nowadays in some heavy simulations that could benefit form parallelizing batches of work. Currently I either manually perform the launches of different lots, or leverage a cluster managed with Condor [1] at my institution, but using C code.
>
>
>
> I was thinking about the possibility of requesting the installation of an Ada compiler in such cluster, and also if the DSA can fulfill my needs. I guess I could dig into the docs but probably some of you know some pitfalls that could elude me.
>
>
>
> My question is: is the DSA well-suited for load balancing distribution, even if it is of simple nature. My impression from hearsay is that the DSA allows one to define a structure of nodes, and that you program as if this was a single entity, and the remote interactions are done for you. What I'm not sure of is if it supports, for example, is things like "allocate as many nodes as online machines", node migrations and things like that. Or, things like resilience through redundant nodes.
>
>
>
> In other words, does the DSA support reconfiguration (even if it is at launch time) of nodes without editing a config file, or even online reconfiguration without manual intervention?
>
>
>
> Thank you in advance,
>
> Alex.
>
>
>
> [1] http://research.cs.wisc.edu/htcondor/description.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: On intended use cases of the distributed annex
2014-09-24 9:37 On intended use cases of the distributed annex Alejandro R. Mosteo
2014-09-24 10:08 ` tonyg
@ 2014-09-24 10:09 ` Pascal Obry
2014-09-24 10:42 ` Alejandro R. Mosteo
2014-09-25 8:30 ` Maciej Sobczak
2 siblings, 1 reply; 12+ messages in thread
From: Pascal Obry @ 2014-09-24 10:09 UTC (permalink / raw)
Alejandro,
> In other words, does the DSA support reconfiguration (even if it is at
> launch time) of nodes without editing a config file, or even online
> reconfiguration without manual intervention?
Yes. A Remote_Types partition can be launched at runtime as many time as
needed. For load balancing I've been using a very simple protocol:
1. some partitions are producers of works items
2. the work-items are stored into a queue
3. many partitions are consumers of those work-item, you can start one
on each node if needed.
4. consumers take a job into the queue, do whatever is needed and post
the results possibly in another queue for other consumers to work.
All this works fine and is a great way to achieve load balancing. In
fact nothing new there, you'll do that for a parallel applications using
tasks and protected-object (for the queue). The nice thing with the
distributed annex is that it there is nothing new, just a prama. The
queue of work-items I've described above will be protected with
protected object as many partitions will access it.
--
Pascal Obry / Magny Les Hameaux (78)
The best way to travel is by means of imagination
http://v2p.fr.eu.org
http://www.obry.net
gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: On intended use cases of the distributed annex
2014-09-24 10:08 ` tonyg
@ 2014-09-24 10:09 ` tonyg
0 siblings, 0 replies; 12+ messages in thread
From: tonyg @ 2014-09-24 10:09 UTC (permalink / raw)
On Wednesday, 24 September 2014 11:08:42 UTC+1, tonyg wrote:
> I used the DSA quite regularly and recently, but the job was not as complex as this. However I do know of a guy working at the french nuclear research institute who made a stack of PC's do some heavy computation using the DSA to break apart the computation job and put it back together using asynchronous messaging. It was quite a feat!
>
>
>
> On Wednesday, 24 September 2014 10:37:49 UTC+1, Alejandro R. Mosteo wrote:
>
> > Hello people,
>
> >
>
> >
>
> >
>
> > I am working nowadays in some heavy simulations that could benefit form parallelizing batches of work. Currently I either manually perform the launches of different lots, or leverage a cluster managed with Condor [1] at my institution, but using C code.
>
> >
>
> >
>
> >
>
> > I was thinking about the possibility of requesting the installation of an Ada compiler in such cluster, and also if the DSA can fulfill my needs. I guess I could dig into the docs but probably some of you know some pitfalls that could elude me.
>
> >
>
> >
>
> >
>
> > My question is: is the DSA well-suited for load balancing distribution, even if it is of simple nature. My impression from hearsay is that the DSA allows one to define a structure of nodes, and that you program as if this was a single entity, and the remote interactions are done for you. What I'm not sure of is if it supports, for example, is things like "allocate as many nodes as online machines", node migrations and things like that. Or, things like resilience through redundant nodes.
>
> >
>
> >
>
> >
>
> > In other words, does the DSA support reconfiguration (even if it is at launch time) of nodes without editing a config file, or even online reconfiguration without manual intervention?
>
> >
>
> >
>
> >
>
> > Thank you in advance,
>
> >
>
> > Alex.
>
> >
>
> >
>
> >
>
> > [1] http://research.cs.wisc.edu/htcondor/description.html
Oh sorry the answer is yes, but you may have to operate a store of types of processing nodes in a passive partition.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: On intended use cases of the distributed annex
2014-09-24 10:09 ` Pascal Obry
@ 2014-09-24 10:42 ` Alejandro R. Mosteo
2014-09-24 10:51 ` Alejandro R. Mosteo
0 siblings, 1 reply; 12+ messages in thread
From: Alejandro R. Mosteo @ 2014-09-24 10:42 UTC (permalink / raw)
Thanks, Pascal and Tony. That sounds very encouraging, I will then certainly dig in into the details. That producer-consumer setup is like what I had in mind.
I guess the specific details of launching a set of processes in multiple machines will be compiler-dependent. In my case, I have (or could obtain) a list of IPs of machines I can access through ssh. If you have experience with gnat, could you briefly comment on this? Does one need to launch the process in every machine, or will a single command trigger a number of connections/executions?
Thanks again,
Álex.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: On intended use cases of the distributed annex
2014-09-24 10:42 ` Alejandro R. Mosteo
@ 2014-09-24 10:51 ` Alejandro R. Mosteo
0 siblings, 0 replies; 12+ messages in thread
From: Alejandro R. Mosteo @ 2014-09-24 10:51 UTC (permalink / raw)
> I guess the specific details of launching a set of processes in multiple machines will be compiler-dependent. In my case, I have (or could obtain) a list of IPs of machines I can access through ssh. If you have experience with gnat, could you briefly comment on this? Does one need to launch the process in every machine, or will a single command trigger a number of connections/executions?
Don't worry, I have just started to read about this.
Cheers.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: On intended use cases of the distributed annex
2014-09-24 9:37 On intended use cases of the distributed annex Alejandro R. Mosteo
2014-09-24 10:08 ` tonyg
2014-09-24 10:09 ` Pascal Obry
@ 2014-09-25 8:30 ` Maciej Sobczak
2014-09-25 9:26 ` J-P. Rosen
2014-09-25 15:02 ` Brad Moore
2 siblings, 2 replies; 12+ messages in thread
From: Maciej Sobczak @ 2014-09-25 8:30 UTC (permalink / raw)
W dniu środa, 24 września 2014 11:37:49 UTC+2 użytkownik Alejandro R. Mosteo napisał:
> I was thinking about the possibility of requesting the installation of an Ada compiler in such cluster, and also if the DSA can fulfill my needs.
You can make it work, but be aware that DSA was not invented with heterogeneous systems in mind. That is, the annex does not define the wire-level protocol nor even the data type mappings, so depending on the particular implementation you might be forced to use the same compiler version for all nodes and obviously all of the nodes will have to be written in Ada. This might sound like heaven for some, but in a distributed system it might as well become a maintenance and integration nightmare and if at the end you will have to use additional protocols for integration with existing software or for adding software written by others or for other functions like remote monitoring or configuration scripts, etc., then it will become a bloody mess, which kind of contradicts the intentions of using Ada in the first place. For this reason I would not use DSA at all and instead try some technology-neutral communication solution.
I don't claim that the above considerations are bound to be problems, but certainly they are something to think about before you start.
--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: On intended use cases of the distributed annex
2014-09-25 8:30 ` Maciej Sobczak
@ 2014-09-25 9:26 ` J-P. Rosen
2014-09-25 14:36 ` Maciej Sobczak
2014-09-25 15:02 ` Brad Moore
1 sibling, 1 reply; 12+ messages in thread
From: J-P. Rosen @ 2014-09-25 9:26 UTC (permalink / raw)
Le 25/09/2014 10:30, Maciej Sobczak a écrit :
> You can make it work, but be aware that DSA was not invented with
> heterogeneous systems in mind. That is, the annex does not define the
> wire-level protocol nor even the data type mappings, so depending on
> the particular implementation you might be forced to use the same
> compiler version for all nodes and obviously all of the nodes will
> have to be written in Ada. This might sound like heaven for some, but
> in a distributed system it might as well become a maintenance and
> integration nightmare and if at the end you will have to use
> additional protocols for integration with existing software or for
> adding software written by others or for other functions like remote
> monitoring or configuration scripts, etc., then it will become a
> bloody mess, which kind of contradicts the intentions of using Ada in
> the first place. For this reason I would not use DSA at all and
> instead try some technology-neutral communication solution.
>
> I don't claim that the above considerations are bound to be problems,
> but certainly they are something to think about before you start.
>
Right, but with PolyOrb you may have the same objects viewed as
distributed Ada objects from Ada, and Corba objects from the rest of the
world...
--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: On intended use cases of the distributed annex
2014-09-25 9:26 ` J-P. Rosen
@ 2014-09-25 14:36 ` Maciej Sobczak
0 siblings, 0 replies; 12+ messages in thread
From: Maciej Sobczak @ 2014-09-25 14:36 UTC (permalink / raw)
W dniu czwartek, 25 września 2014 11:26:38 UTC+2 użytkownik J-P. Rosen napisał:
> Right, but with PolyOrb you may have the same objects viewed as
> distributed Ada objects from Ada, and Corba objects from the rest of the
> world...
Except that CORBA is a technology that has lost its "cool factor" some decade or two ago and you might find it difficult to convince anybody in your team to write software using it. If Ada is *perceived* as an old technology that is no longer relevant in modern IT, then introducing CORBA into the picture will not help make Ada look any more attractive - now you have not one, but two old and irrelevant technologies to convince your colleagues to work with.
--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: On intended use cases of the distributed annex
2014-09-25 8:30 ` Maciej Sobczak
2014-09-25 9:26 ` J-P. Rosen
@ 2014-09-25 15:02 ` Brad Moore
2014-09-26 7:36 ` Maciej Sobczak
1 sibling, 1 reply; 12+ messages in thread
From: Brad Moore @ 2014-09-25 15:02 UTC (permalink / raw)
On 14-09-25 02:30 AM, Maciej Sobczak wrote:
> W dniu środa, 24 września 2014 11:37:49 UTC+2 użytkownik Alejandro R. Mosteo napisał:
>
>> I was thinking about the possibility of requesting the installation of an Ada compiler in such cluster, and also if the DSA can fulfill my needs.
>
> You can make it work, but be aware that DSA was not invented with heterogeneous systems in mind. That is, the annex does not define the wire-level protocol nor even the data type mappings, so depending on the particular implementation you might be forced to use the same compiler version for all nodes and obviously all of the nodes will have to be written in Ada. This might sound like heaven for some, but in a distributed system it might as well become a maintenance and integration nightmare and if at the end you will have to use additional protocols for integration with existing software or for adding software written by others or for other functions like remote monitoring or configuration scripts, etc., then it will become a bloody mess, which kind of contradicts the intentions of using Ada in the first place. For this reason I would not use DSA at all and instead try some technology-neutral communication solution.
>
> I don't claim that the above considerations are bound to be problems, but certainly they are something to think about before you start.
>
Not quite true that all the nodes need to be written in Ada. I have
used DSA to send C++ objects to C++ applications (or at least objects of
C++ classes that are derived from Ada types), and as well had C++
applications remotely interacting with each other C++ and other Ada
applications using the DSA.
I also appreciate that the DSA is more closely integrated with the
compiler, allowing the compiler to check and catch problems that a
library only approach does not provide.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: On intended use cases of the distributed annex
2014-09-25 15:02 ` Brad Moore
@ 2014-09-26 7:36 ` Maciej Sobczak
2014-09-30 5:44 ` Brad Moore
0 siblings, 1 reply; 12+ messages in thread
From: Maciej Sobczak @ 2014-09-26 7:36 UTC (permalink / raw)
W dniu czwartek, 25 września 2014 17:02:07 UTC+2 użytkownik Brad Moore napisał:
> Not quite true that all the nodes need to be written in Ada. I have
> used DSA to send C++ objects to C++ applications (or at least objects of
> C++ classes that are derived from Ada types), and as well had C++
> applications remotely interacting with each other C++ and other Ada
> applications using the DSA.
This sounds interesting. Can you give a bit more details on this? Was it related to the DSA implementation that actually used CORBA under the hood? Was it necessary to extract some interface definition files from Ada specs?
Or did you just reverse-engineered the DSA wire protocol that was in use?
Was your solution immune to compiler upgrades?
And so on - lot's of questions. :-)
> I also appreciate that the DSA is more closely integrated with the
> compiler, allowing the compiler to check and catch problems that a
> library only approach does not provide.
Was it also closely integrated with the C++ nodes? ;-)
The "close integration with the compiler" makes most sense when there is a single build process for all the nodes. Otherwise there is no guarantee that individual nodes are compiled with the same specs and the whole notion of static type safety goes down the drain. This is particularly relevant in bigger systems where distinct nodes are developed by different teams and/or are deployed at different time schedules. More on this here:
http://www.inspirel.com/articles/What_Is_Wrong_With_IDL.html
Still, I'm very much interested in your Ada/C++ integration over DSA.
--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: On intended use cases of the distributed annex
2014-09-26 7:36 ` Maciej Sobczak
@ 2014-09-30 5:44 ` Brad Moore
0 siblings, 0 replies; 12+ messages in thread
From: Brad Moore @ 2014-09-30 5:44 UTC (permalink / raw)
On 14-09-26 01:36 AM, Maciej Sobczak wrote:
> W dniu czwartek, 25 września 2014 17:02:07 UTC+2 użytkownik Brad Moore napisał:
>
>> Not quite true that all the nodes need to be written in Ada. I have
>> used DSA to send C++ objects to C++ applications (or at least objects of
>> C++ classes that are derived from Ada types), and as well had C++
>> applications remotely interacting with each other C++ and other Ada
>> applications using the DSA.
>
> This sounds interesting. Can you give a bit more details on this?
Sure, I wrote a paper back in 2008 describing this, which you can
download here.
http://sourceforge.net/projects/dequesterity/files/RemoteBuffers.pdf/download
The paper grew out of the buffer work that eventually became the
dequesterity project, which is the underlying buffer abstraction I was
working on.
I still have the source code for the distributed demo system, but that
is not currently available on any public site, since it is too limited
and specific of an application to be generally useful, other than
perhaps providing a base for new design.
The distributed monitoring application demo evolved out of my interest
in distributed systems.
I built a working demo of the concept, where one could monitor and
control any number of remote nodes. I did have some nodes compiled
under Linux, and others compiled under Windows, and the nodes could
communicate with each other.
Was it related to the DSA implementation that actually used CORBA under
the hood?
The original version used the DSA implementation called Glade I think
which did not involve CORBA. Later, I integrated the PolyORB version,
which was pretty new at the time, and utilized CORBA.
Was it necessary to extract some interface definition files from Ada specs?
I basically defined C++ classes, and mirroring Ada specs as Tagged
types. The C++ code used the C++ classes, but made calls to Ada servers
with exported C/C++ function calls, which knew how to marshal the C++
classes. The code involved a message factory which could create objects
of different types in the class hierarchy, which could be passed into a
C/C++ application code. Although I did not try this, Java supposedly
also could be used since the GCC compiler uses the same binary API for
the different languages.
> Or did you just reverse-engineered the DSA wire protocol that was in use?
I didn't look at the DSA wire protocol. One thing I wanted to do however
was distribute the nodes to each other without there having to be a
central server. My initial implementation had a central server, which
was an RCI Ada package, but I moved to a peer to peer type system.
I distributed the Remote Access to Class Wide Type objects to other
peers using my own multicast messaging approach. Once the nodes had
discovered each other, they could make calls to the RACW remote pointers
directly, which was pretty cool.
That was the one major limitation I found with the DSA, was that it
didn't directly support multicast communications, however I was able to
work around this. It think that could be an area of improvement for DSA,
to provide some sort of group broadcast/discovery.
> Was your solution immune to compiler upgrades?
I'd say not completely immune, but I did switch from Glade to PolyORB
relatively painlessly, which was a completely different implementation.
I don't think I needed to make any changes to my code. I only needed to
configure the underlying DSA differently.
The idea of the DSA is that the Ada code should be decoupled from the
underlying DSA implementation.
> And so on - lot's of questions. :-)
>
>> I also appreciate that the DSA is more closely integrated with the
>> compiler, allowing the compiler to check and catch problems that a
>> library only approach does not provide.
>
> Was it also closely integrated with the C++ nodes? ;-)
I'm not sure I understand your question. I think the C++ code was not as
closely integrated, to be expected, since C++ generally does not provide
as much checking as an Ada compiler, and the C++ compiler does not have
the same semantic knowledge of the Ada compiler and vice versa.
But the C++ classes worked pretty much as expected for the C++ code.
>
> The "close integration with the compiler" makes most sense when there is a single build process for all the nodes.
True. All the applications that talk to each other are compiled at the
same time in my case. Although, as I mentioned, I had nodes
communicating between OS'es, (Windows and Linux), so for that scenario,
the compilations would have been separate.
I think separate compilation could work in other cases, but if any of
the distributed object classes are modified, I think all the
applications that pass there objects around would need to be recompiled.
Otherwise there is no guarantee that individual nodes are compiled with
the same specs and the whole notion of static type safety goes down the
drain.
With the DSA there are mechanism's to at least check the consistency of
the system. Eg. P'Version, and P'Body_Version in RM E.3, although I
never experimented with these.
I think it would be difficult to change the object structures of
distributed classes, and have out of date nodes be expected to still
work. Probably someone might be able to devise some sort of
introspection mechanism, but that's far beyond what I was trying to do.
Some sort of dynamic typing system such as the one described in your
link below could be helpful here.
This is particularly relevant in bigger systems where distinct nodes
are developed by different teams and/or are deployed at different time
schedules. More on this here:
I can see how large systems and teams can make changes difficult or
messy. I've seen large deployments that have tried different approaches.
1) Replace everything at the same time. Can be very difficult,
because the upgrade can take a significant amount of time, which might
be too long to go without a working system. This is likely not an option
for many large systems.
2) Replace parts of the system. In this case, backwards
compatibility is very important. Often its better to create a new API
for new stuff and keep the old one in place until it can be fully
deprecated, if ever.
The example of HTML is a good one here, which basically follows case 2.
New features can be added to HTML and newer versions of HTML, but they
had better not break the support for earlier versions of HTML.
Another example is SNMP. Once an SNMP interface is defined, and
distributed for use in a large deployment. It usually means the existing
API's cannot be changed, and any new changes are typically brought in,
in the form of new API's.
>
> http://www.inspirel.com/articles/What_Is_Wrong_With_IDL.html
>
> Still, I'm very much interested in your Ada/C++ integration over DSA.
>
I'd be happy to answer any other questions you might have.
For future work, I was always interested in RM E.5 (24.1-24.2) and other
paragraphs in the same section that suggest that the user could supply
their own PCS system to replace the compilers version.
I don't know how easy this would be to do, and I am not aware of anyone
who has tried to do this, but I recognize that different applications
may have needs for specific protocols for specific networks that may be
outside the ones provided by the implementation.
Brad
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-09-30 5:44 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-24 9:37 On intended use cases of the distributed annex Alejandro R. Mosteo
2014-09-24 10:08 ` tonyg
2014-09-24 10:09 ` tonyg
2014-09-24 10:09 ` Pascal Obry
2014-09-24 10:42 ` Alejandro R. Mosteo
2014-09-24 10:51 ` Alejandro R. Mosteo
2014-09-25 8:30 ` Maciej Sobczak
2014-09-25 9:26 ` J-P. Rosen
2014-09-25 14:36 ` Maciej Sobczak
2014-09-25 15:02 ` Brad Moore
2014-09-26 7:36 ` Maciej Sobczak
2014-09-30 5:44 ` Brad Moore
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox