We propose an approach to the semi-automatic transformation of legacy Fortran applications for execution on cloud computing platforms. An architecture is proposed based on web-services choreography, which allows unlimited scalability of the system and reduces overhead on message passing. The approach is tested on an example program from the quantum chemistry field.
Fortran language exists since the 1950s and during this time positioned itself as one of
the best tools for scientific research. Language has huge support from the software
industry, new libraries and compilers are released that allow using modern
technologies and standards. Examples are: compiler from Portland Group [
Cloud computing became popular because of the need to reduce the cost of computations. The difference between cloud computing and other parallel approaches is usage of scalability (ability to support more resources) vs. performance (running fast
- 112 on given resources). Scalable systems can contain components which individually perform poorly. Cloud computing is focused on reducing the cost and time/performance balance using cheap components, and therefore allows using more resources.
This paper describes work in progress aimed at parallelizing Fortran scientific applications for the cloud platform. We propose a methodology for semi-automatic parallelization of legacy applications. The paper also describes an architecture for running distributed applications on the cloud.
Related parallelization approaches for porting legacy applications to cloud
platform have been described, such as Pydron [
In this paper, we discuss our approach of transforming legacy scientific applications based on an example Fortran application from the quantum chemistry field. Some properties we discuss are specific to this application, such as time distribution of subroutines (Section 2) or the structure of control flow graph (Section 3). However, our approach can be applied in the more general case.
The example application calculates the geometry of electron orbitals [
The first step of our approach requires identifying the most promising subroutines for parallelization. The example program consists of data input, computation subroutines, logging intermediate results into the file and data output. Profiling the application before optimization shows the time distribution for the main computational steps: Data input from files and initialization – approximately 1% of time; Subroutine hcore calculates integrals for every atom – 60% of time; Subroutine iterc – optimization of the geometry of molecule, 30% of the time.
Therefore, the main focus of parallelization would be spent in subroutines hcore and iterc. Time performance of algorithms in both subroutines has a linear dependency on the input size. Each of two subroutines is applied independently for every atom in the input, which allows parallelization. However, iterc depends on the results of hcore, because the calculation of the Fock operator requires integrals computed in hcore.
The generic question of Fortran parallelization for distributed architecture is widely
studied [
On the next step, we try to find and parallelize independent loops that allow unlimited scalability. Structurally, the application can be modeled with the following graph: I -> A ([a1..n ]) -> B ([b1..n ]) -> O (1)
Graph vertices I, A, B, O stand for the sequential steps of computation: I – data input and allocation of the memory, A – calculation of the integrals for every atom (hcore), B – calculation of the Fock operator for every atom (iterc), O – final steps and data output. Graph edges correspond to the control flow between parts of the program, a1..n and b1..n stand for input data of subroutines. The goal of this step is to transform program to the parallel form:
I -> A1..n ([a1..n ]) -> B1..n ([b1..n ]) -> O (2)
We transform sequential loop A, into n parallel processes A1..n([a1..n ]). Each process Ai will perform calculations on a single segment of data ai. The same transformation will be applied to B as well. After manual analysis of the data dependencies, it was identified that there are no dependencies between iterations of the loop in code fragment A, and processes A1..n can be invoked in parallel, same applicable to the processes B1..n . However, B had a dependency on the results of A and in order to address this dependency barrier synchronization will be used between parallel processes Ai and Bi.
After selection of the model for parallel computation, we should ensure that code fragments invoked in parallel do not have any side effects. This is done by replacing subroutines with pure functions (introduced in Fortran 95 standard). The following changes in code are needed: 1. Create FUNCTION instead of SUBROUTINE 2. Remove IMPLICIT statements – all local variables of the function should be explicitly declared. 3. Remove COMMON BLOCKs (global variables) – all corresponding global variables should be passed as an inputs/outputs of the function, and reads/writes to global variables performed by the calling code. 4. Remove read and write operations – all such operations should be invoked before and after the call to the pure function. 4
TermWare [
As an example of transformation we use a set of rules to transform IMPLICIT statements to explicit declarations of variables: 1. _MarkPure(Subroutine($name,$params,$return,$body)) -> Function($name,$params,$return,_MkImp($body)) 2. _MkImp([$x:$y]) -> [_MkImp($x):_MkImp($y)] 3. _MkImp(NIL) -> NIL 4. _MkImp(Declare($var,$type,$val) ->
Declare($var,$type,$val) [check($var, $type)] 5. [_MkImp(Assign($var,$expr)): $y] [isUnchecked ($var)] -> [Declare_MARK($var, $type) : [Assign ($var,$expr) : $y ]] [inferType ($var,$type)] 6. [$x:[Declare_MARK($var,$type) : $y]] ->
[Declare_MARK($var,$type):[$x:$y]] 7. Function ($name,$params,$return, [Declare_ MARK($var,$type):$y]) -> Function ($name,$params,$return,[Declare($var,$type):$y]) Rule 1 triggers transformation, marking the body of the function with the marker term _MkImp. Rules 2 and 3 walk through the body of the function and expand the _MkImp marker to all operations. Rule 4 memorizes the variables which have explicit declaration using the method check($var, $type) from the facts DB. Rule 5 finds variables without explicit declaration using method isUnchecked($var). For these variables it determines the type with the method inferType($var,$type) and adds declaration marked with Declare_MARK($var,$type). To determine the variable type, the method checks the variable name against IMPLICIT statements in Fortran code, as well as default convention that declares variables starting with 'i'-'n' as INTEGER and all others as REAL. Rule 6 moves this declaration to the beginning of the function, and rule 7 removes the mark. As a result, term Declare($var,$type) is generated, which later is transformed to the declaration of the variable in the code.
As an example of rules application, consider a simple procedure of square matrix multiplication (Table 1).
In the initial code, some variables are used with no declaration. After
transformation, all the variables are declared. Also, note that the syntax for
SUBROUTINE is different from the FUNCTION. But such changes should not be
described as additional rules. A simple substitution of the term “Subroutine” with the
term “Function” is sufficient. During the code generation phase, all necessary changes
are added automatically, which is one of the advantages of the TermWare and
highlevel algebraic models [
Previously discussed transformation steps are not specific to any given parallel
platform. Starting from this section, we discuss additional steps needed for the cloud
platform. In order to transform application to distributed architecture, its source code has
to be transformed to support network calls. Functions Ai and Bi are converted into
web-services – separate programs with HTTP interface which can be invoked
remotely. The body of the program is transformed into transaction script which invokes
remote web-services and aggregates results. In order to use HTTP calls from the
Fortran, libcurl library is used with the C interface [
Cloud platform operation system, such as CloudStack, provides APIs to do scaling
– provisioning of the nodes with the predefined configuration on demand. This
capability is used by transaction script: after reading the input data and extracting the
number of atoms, it makes a call to API of the cloud operating system and requires a
startup of the necessary amount of nodes of needed type. In the simplest case,
processing of N atoms will require 2N nodes, one for each Ai and Bi. However, the
number of nodes, time they are actively working and the size of the used memory affects
the cost of computation. For optimization of the cost the optimal parameters of
configuration should be chosen, so that cost is minimized. In [
Approach when transaction script calls remote web-services in a service-oriented
architecture is called Orchestration. Usage of Orchestration has disadvantages. Paper
[
Our goal is to reduce message passing overhead and eliminate a single point of failure
represented by transaction script, by using choreography. From the perspective of
distributed systems modeling, Choreography could be represented as an asynchronous
network [
Communication Protocol can replace the part of transaction script responsible for service invocation and results processing. Part of responsibilities related to data input is transferred to web-service itself. Code fragment I performing initial data processing is implemented by the new service I1 which plays the role of starting point in the machine description. Invocation of tail fragment O which outputs the result should be implemented by a separate service O1, which will be executed after synchronizing all the processes B1..n and will do the post-processing of the data and data output.
In order to follow the protocol, every web-service should have a controlling mechanism which executes state machine by the description of the protocol. Controlling mechanism is written in Java. Choreography execution is initiated by an initial event, e.g. the file with input data has been uploaded to the cloud data volume. Process I1 in the waiting state receives this event from the file system and invokes Fortran code responsible for initial data processing. After the event is processed, process I1 sends broadcast message with the results of invocation to all the processes of the asynchronous network. In the simplest case, this message is received by all the processes A1..n , B1..n, I1, and O1. The processes B1..n, O1, and I1 ignore this message because Bi and O1 processes do not have enough information yet to start, and process I1 already finished its part of the work. It means that only processes A1..n start execution.
An important aspect of choreography is the implementation of barrier
synchronization. In [
In order to achieve better resource utilization using Choreography, following considerations should be taken into account. If certain web-service, such as I1, is expected to consume fewer resources than others, it should run on the smaller node (with less RAM and CPUs). If some web-services are never expected to run simultaneously, such as Ai and Bi, they should re-use the same node. Ideally, it should be the same service with a same controlling mechanism which can play different roles in the protocol. This will guarantee that minimal amount of nodes are started at any point of process execution. Choreography allows reducing the number of messages passed between transaction script and web-services. It also allows better resource utilization having non-blocking requests between web-services. Besides, it provides integration framework with the generic rule sets defined which reduce the amount of code needed to be written to convert the application into distributed system. 7
In order to verify the proposed approach, we used a simplified task with the same model of the data dependency – Gaussian elimination. Testing was performed on the Amazon cloud platform and compares two different configurations of the system. Both configurations have the same amount of processors – 8, and the same amount of RAM – 32Gb. The first configuration consists from one server AWS m4.2xlarge (26 ECUs, 8 vCPUs, 2.4 GHz, Intel Xeon E5-2676v3, 32 GiB memory, EBS only) and is used to run the sequential program. Second configuration consists of four servers AWS m4.large (6.5 ECUs, 2 vCPUs, 2.4 GHz, Intel Xeon E5-2676v3, 8 GiB memory, EBS only) and it is used to run the service-oriented application (with choreography). We have measured the time spent on the processing of the square matrices of different sizes. Comparison of execution time is in Fig. 1. For smaller matrix size, the sequential program runs faster because of overhead in a parallel program. However, for larger matrices the execution time of sequential program grows faster, and it becomes less efficient. The paper describes the work in progress of scaling legacy Fortran code using cloud platforms. Proposed architecture uses choreography of web-services which allows unlimited scalability and reduces overhead on message passing. Scaling exercise is performed on application from quantum chemistry field for calculation of atoms orbitals. One of the main results of the paper is a methodology for adjustment of the legacy source code to the cloud infrastructure, including transition steps to distributed scalable architecture. Our future research directions include automating additional transformation steps using TermWare framework, applying our approach to different applications, as well as testing different cloud configurations to find the most efficient ways of parallelizing legacy applications.