Transcript A Language-Independent Approach to Software Maintenance

GenAWeave:
A Generic Aspect Weaver Framework based
on Model-Driven Program Transformation
Suman Roychoudhury
[email protected]
Ph.D. Dissertation Defense
http://www.cis.uab.edu/softcom/GenAWeave/
Committee Members:
Dr. Jeff Gray (Advisor, Chair)
Dr. Purushotham Bangalore
Dr. Barrett Bryant
Dr. Marjan Mernik
Dr. Anthony Skjellum
Dr. Randy Smith
May 19, 2008
Outline of Presentation
Several Billion lines of
Legacy code
Lack of Modularization
(Legacy software decay)
Motivation
Challenges
Lack of Reusability
+
Accidental Complexities
Program Transformation
Research Goals
Model-Driven
Engineering
Approach
Evaluation
Aspect FORTRAN
Generic Aspect Weaver
Framework
Aspect Pascal
2
Challenges with Maintaining Legacy Systems
Commercial + Scientific
Applications
> 200 Billion Lines
of Legacy code
Migration is not an
easy task !
Limited knowledge
of the entire system
50% of the annual
$230 billion spent on all
software budgets
A need for
constant fixes
Huge investment in
infrastructure, effort,
manpower
Too much time required
to make simple changes
3
Laws of Evolution – Lehman, 1997

Systems
must
be
continually
adapted
else
they
become
progressively less satisfactory and are
subjected to decay over a period of
time.

As systems evolve, they become
more complex  must take some
action to reduce the complexity.
Big Ball of Mud
Brian Foote and Joseph Yoder
4
Tools and Techniques to Support
Evolution of Legacy Software

Aspect-Oriented Programming
AOP is a programming technique that allows programmers to
modularize crosscutting concerns (i.e., program features that cut
across the typical divisions of modularity, such as logging). Such
features often cannot be cleanly decomposed from the rest of the
system in both the design and implementation, and result in either
scattering or tangling of source code.

Software Refactoring
“The process of changing a software system in such a way that it
does not alter the external behavior of the code, yet improves its
internal structure” [Fowler et al., 1999].
5
Crosscutting Concerns
XML Parsing in Apache
Tomcat Server
Profiling in Apache
Tomcat Server
http://www.parc.com/research/projects/aspectj/
6
Separation of Crosscutting Concerns - AOP
Module A
Module B
Crosscutting concerns
CC1/CC2 superimposed on
Module A and B
CC1
CC2
Concern CC1
Concern CC2
7
Aspect Weaving
Aspect Program
Aspect
Specification
Aspect
Weaver
Base
Program


Modified
Target Program
The term “Aspect Weaving” refers to combining aspects (i.e.,
crosscutting features) with non-crosscutting pieces of source code.
The tool that is responsible for merging the separated aspects with the
base code is called an aspect weaver.
8
Aspect Weavers: Current Limitations
Several tools and language extensions have been
developed to enable aspect weaving
However –
1.
Specific to a few popular languages (e.g., Java)
2.
New tools are developed from scratch without
preserving knowledge of previous construction
3.
No emphasis on reusability in a different language
and platform context
4.
Generally do not support custom aspect weaving
functionality (e.g., join point for loops, with
construct in Object Pascal)
9
Research Questions

Is there a technique to construct aspect weavers for legacy
languages without extending or inventing a new parser (or
compiler) from scratch?

Can such construction be supported in a more generic or
language-independent way?

Can the knowledge of building a weaver from a previous
construction be reused in a different language and platform
context?

Can we add custom features to an existing weaver and the same
knowledge transferred to new weavers?
10
Outline of Presentation
Several Billion lines of
Legacy code
Lack of Modularization
(Legacy software decay)
Motivation
Challenges
Lack of Reusability
+
Accidental Complexities
Program Transformation
Research Goals
Model-Driven
Engineering
Approach
Evaluation
Aspect FORTRAN
Generic Aspect Weaver
Framework
Aspect Pascal
11
Challenges in Language-Independent
Legacy Adaptation
Challenge C1 – The Parser Construction Problem
Challenge C2 – The Weaver Construction Problem
Challenge C3 – Accidental Complexities of Transformation
Specifications
Challenge C4 – Language-Independent Generalization of
Transformation Objectives
12
Challenge C1 – The Parser Construction
Problem



Transformation
System
Scalability
Extensibility
Reusability
Parser
Lowerorder
Transforms
Higherorder
Transforms
Legacy System







C++
Object Pascal
Fortan
Cobol
Ada
Jovial
User Inputs
Aspect Language
VHDL
13
Challenge C2 – The Weaver Construction
Problem


Transformation
System
Availability of AST representation
Low-level Transformation Infrastructure
pattern probe_id_pattern1()
: unqualified_id = "printf".
rule insert_probe1
Legacy System
(s: statement_seq):
function_body
->
function_body
= " { \s } " ->
"{ \probe_id_pattern1\(\)
(\"Entering Method…\");
{ \s }
}".
Parser
User Inputs
Lowerorder
Transforms
Higherorder
Transforms
Aspect Language
14
Challenge C3 – Accidental Complexities
of Transformation Specifications

A high-level aspect language
layered on top of the transformation
system

Translates to low-level
specifications
Transformation
System
Parser
Lowerorder
Transforms
Higherorder
Transforms
Legacy System
aspect insert_probe1 {
before():
execution
(function_declaration)
{
// insert print
statement
}
}
User Inputs
Aspect Language
15
Challenge C4 – Language-Independent
Generalization of Transformation Objectives
Transformation
System
rule BeforeAdvice2Pattern {
from
s : APascal!BeforeAdvice
to
t : RSL!Pattern (
phead <- ph,
ptext <- spt,
token <- 'statement_list',
),
ph : RSL!PatternHead (
name <- 'before_
advice_stmt'
),
...
}
Parser
User Inputs
Lowerorder
Transforms
Higherorder
Transforms
Aspect Language
16
Outline of Presentation
Several Billion lines of
Legacy code
Lack of Modularization
(Legacy software decay)
Motivation
Challenges
Lack of Reusability
+
Accidental Complexities
Program Transformation
Research Goals
Model-Driven
Engineering
Approach
Evaluation
Aspect FORTRAN
Generic Aspect Weaver
Framework
Aspect Pascal
17
Research Goals
Goal 1 : Raise the level of
abstraction (aspect layering)
for end-programmers (C3)
Goal 2 : Reuse core transformations across
language domains using higher-order
transforms (C2, C4)
Program
Transformation
Engine
the
level
of
abstraction and reuse the
core
rules
transformations
across
High-level
Low-Levellanguage
xForm
constructs
(C1,C2)
Legacy Software
Increase
Higher-Order
Transforms
Aspect Weavers
language
domains
18
Model-Driven Program Transformation
based Aspect Weaving Framework
The high-level aspect language is used to
raise the level of abstraction and hide the
accidental complexities that are associated
with program transformation rules
The program transformation rule
generator produces program
transformation rules using higherorder model transformation rules

Reuses existing
parsers

Reuses several
artifacts while
creating weavers
from one language
to another
The generated program
transformation rules are processed
along with the source program to
accomplish the desired weaving
19
Outline of Presentation
Several Billion lines of
Legacy code
Lack of Modularization
(Legacy software decay)
Motivation
Challenges
Lack of Reusability
+
Accidental Complexities
Program Transformation
Research Goals
Model-Driven
Engineering
Approach
Evaluation
Aspect FORTRAN
Generic Aspect Weaver
Framework
Aspect Pascal
20
Overview of Approach
Current State-of-the-Art Techniques
FuncDef
ProcDef
FuncOrProcSignature
WithinCodeExpr
ExecExpr
CallExpr
Program Transformation
Back-End
Source
Program
AspectPascal
WhileLoop
ForLoop
WithExpr
FuncOrProcDefExpr
Transformation
System
GAspect
+name : String
LoopStatement
*
Statement
1
1
*
Expression
1
Advice
*
1
Pointcut
BeforeAdvice AroundAdvice
Grammarware TS
EBNF
Model-Driven Front-End
*
AfterAdvice
LoopExpr
ArgsExpr
+name : String
Model-Driven Engineering (MDE)
Technical Space (TS)
KM3
Grammarware TS
EBNF
M3
Aspect.g
Grammar
Aspect
Metamodel
RSL
Metamodel
Transformed
Program
Model Transformation
PT Based Back-End
RSL.g
Grammar
M2
Input
Source
Program
C4
Myaspect.ap
AspectPascal
Myaspect
Model
MyRsl
Model
MyRsl.rsl
RSL program
M1
C3
Injection
Aspect2RSL
Transformation
Extraction
C1
Generic Aspect
Metamodel
Parser
definitions
C4
Generic
Aspect Source Model Transform
Metamodel Library
GenAWeave in Action
Aspect
Source
Program
Aspect Source
Model
C3
Lexer/
Parser
C3
RSL
Metamodel
RSL
Model
AST
Graph
Domain
Reader
Concrete
RSL Transform
Analyzer
Unparser
definitions
C3
ATL Model
Transformation
Engine
Model-Driven Front-End
C2
Symbol
Table
C2
Pretty
Printer
DMS Program
Transformation
Engine
C2
C1
Program Transformation based Back-End
21
Transformed
Target
Program
Current State-of-the-Art:
Transformation Techniques

Object-based transforms, such as a visitor object applied
to an object model

Intermediate representations that permit primitive
transformations to be applied to a set of languages (e.g.,
.Net CodeDOM)

XML-based transforms that use an XML DOM structure

Term rewriting, such as a transformation rule
22
Current State-of-the-Art:
SourceWeave.Net

Uses Microsoft’s CodeDom
Architecture as the underlying
AST Representation

Uses XML descriptor to specify
interaction between aspects
and .Net components

Limited availability of CodeDOM
providers

CodeDOM biased towards
C#, hence lack of expressiveness for
other languages

Verbosity of XML representations a
serious concern for scalability
http://www.dsg.cs.tcd.ie/dynamic/?category_id=438
23
Current State-of-the-Art:
Weave.Net

Uses existing .Net Binary
Component and crosscutting
specifications in an xml file as
input

Advice is given separately in
another .Net assembly

Limited to applications
hosted within .Net

Aspect specification is difficult
to comprehend due to lack of
expressiveness of XML
constructs
Component
(.NET Assembly)
Aspect
Crosscutting Statements
(XML)
Weave.NET
http://www.dsg.cs.tcd.ie/dynamic/?category_id=194
Behaviour
(.NET Assembly)
Woven Component
(.NET Assembly)
24
Current State-of-the-Art:
Aspect Cobol

Parse trees are exported to XML

Weaving is achieved by XML
DOM tree processing in Java

XML representation of source
code (intermediate form) may
not scale with code size

It has been reported that such
internal representations are 50
times larger and much slower
to transform

Limited only to COBOL

A more generalized approach
is missing
http://homepages.cwi.nl/~ralf/AspectCobol/
25
Current State-of-the-Art:
Aspicere + GCC 4.0

Proposes to use GCC 4.0
GENERIC trees

Weaving is done by
modifying the GENERIC
AST representations


Lack of support for .Net
Languages like C#, VB.Net
and other languages like
Object Pascal, Cobol etc,
currently supports only C

Very little documentation
available from project site
Still in a proposal stage, not
clear whether API support is
available for modifying
GENERIC trees
http://users.ugent.be/~badams/aspicere/
26
Overview of Approach
Current State-of-the-Art Techniques
FuncDef
ProcDef
FuncOrProcSignature
WithinCodeExpr
ExecExpr
CallExpr
Program Transformation
Back-End
Source
Program
AspectPascal
WhileLoop
ForLoop
WithExpr
FuncOrProcDefExpr
Transformation
System
GAspect
+name : String
LoopStatement
*
Statement
1
1
*
Expression
1
Advice
*
1
Pointcut
BeforeAdvice AroundAdvice
Grammarware TS
EBNF
Model-Driven Front-End
*
AfterAdvice
LoopExpr
ArgsExpr
+name : String
Model-Driven Engineering (MDE)
Technical Space (TS)
KM3
Grammarware TS
EBNF
M3
Aspect.g
Grammar
Aspect
Metamodel
RSL
Metamodel
Transformed
Program
Model Transformation
PT Based Back-End
RSL.g
Grammar
M2
Input
Source
Program
C4
Myaspect.ap
AspectPascal
Myaspect
Model
MyRsl
Model
MyRsl.rsl
RSL program
M1
C3
Injection
Aspect2RSL
Transformation
Extraction
C1
Generic Aspect
Metamodel
Parser
definitions
C4
Generic
Aspect Source Model Transform
Metamodel Library
GenAWeave in Action
Aspect
Source
Program
Aspect Source
Model
C3
Lexer/
Parser
C3
RSL
Metamodel
RSL
Model
AST
Graph
Domain
Reader
Concrete
RSL Transform
Analyzer
Unparser
definitions
C3
ATL Model
Transformation
Engine
Model-Driven Front-End
C2
Symbol
Table
C2
Pretty
Printer
DMS Program
Transformation
Engine
C2
C1
Program Transformation based Back-End
27
Transformed
Target
Program
Program Transformation Back-End
parser
definitions
Source
Program
Parser
Symbol
Table
AST
Graph
Domain
Definitions
Program
Transformation Rules
Analyzer
unparser
definitions
Pretty
Printer
Target
Program
DMS
Transformation
Engine
1.
2.
3.
4.
5.
6.
default base domain ObjectPascal.
private rule insert_probe(stmt_list: statement_list):
function_body  function_body
= "begin \stmt_list end" 
"begin ShowMessage(\"Entering Method\"); \stmt_list end".
public ruleset TraceAllFunctions = {insert_probe}
28
Program Transformation based Aspect
Weaving (Language-specific weavers)
Experiment conducted on support utilities for a commercial
distributed application written in Object Pascal
Several aspects identified

Processing dialog meter

Updating of progress meter  Appears in 62 different places of the
schema migrator


Exception handling of meter
Logging of SQL query statements The methods of the logging object
are invoked in over 50 different places in the schema migrator

Synchronization in database error handler The

Dirty Bits in language internationalization utility 
addition of this
concurrency concern resulted in a manual invasive change to over 20 classes.
This appears in 29
unique places in the language internationalization source code
29
Object Pascal Example
default base domain ObjectPascal.
external condition
func_sig_has_click(id1:IDENTIFIER,id2:IDENTIFIER)
= 'func_sig_has_click'.
(define func_sig_has_click
pattern advice(slist:statement_list)
: statement_list =
(lambda Registry:MatchingCondition
// The (let
user
wants
to
perform
another
search
(;;(=
[const_string (reference
string)]
"if EditMadeDirtyBit
then
(AST:GetString arguments:1))
SaveDBControls;
procedure TLangMan.SearchAgainClick(Sender:
TObject);
(= [search_string (reference string)]
\slist".
begin
(AST:GetString
arguments:2))
pattern isClick(id:IDENTIFIER): IDENTIFIER
= id if
StringScan:Scan
]
// Perform (=
an[scanner
update
if an edit occurred
that
func_sig_has_click(click(),
id).
(StringScan:MakeScan search_string))
pattern
click ():
IDENTIFIER
"Click".
//might
change
the =focus
of the listview
);;
rule probe_dirty_bit
(value (id1:IDENTIFIER,
if EditMadeDirtyBit
then
id2:IDENTIFIER,fps:formal_parameters,
slist:statement_list):
(while (== (StringScan:End?
(. scanner)) ~f)
SaveDBControls;
implementation_decl
->
implementation_decl
=
(ifthenelse
"procedure
\id1 . \isClick\(\id2\)
\fps ;
(StringScan:MatchString?
(. scanner)
…
const_string)
begin
end;
(return ~t)
\slist
(StringScan:Advance (. scanner))
end;" ->
)ifthenelse
"procedure \id1 . \id2
\fps ;
)while
begin
~f
\advice\(\slist\)
)value
end;". )let
if ~[modslist:statement_list
.slist matches
)lambda
"\:statement_list
\advice\(\modslist\)"].
)define
public ruleset applyrules = { probe_dirty_bit }.
30
Justification of PT Back-End

A mature PTE (e.g., DMS) can ease the construction effort for
weavers of legacy languages by offering a direct solution to
Challenges C1 and C2.

A PT model offers complex Join Point Shadows (e.g., nested
conditional statements) and a rich pointcut to join point binding.

PTEs offer powerful pattern matching and efficient tree traversal
strategies (e.g., using visitors over ASTs) that can scale to several
million lines of code.

PTEs offers internal APIs that enable transformation of ASTs in an
arbitrary manner, thereby allowing more complex and flexible
transforms required by legacy applications (e.g., aspects and
loops).

In contrast to the verbose AST representation in XML-based
approaches, DMS provides internal data structures (e.g.,
hypergraphs) to represent the underlying AST. This offers an
improved level of optimization to support parsing and transforming
large legacy applications.
31
Challenges using PT Engines

The rewrite rules used to modify base programs are difficult to
compose, which makes it accessible to only language researchers
(accidental complexities, Challenge C3)

The transformation rules are generally hard to comprehend by average
software developers (need to know about the grammar and semantics
of the underlying PTE, Challenge C3)

The transformation rules are tied to the grammar of the base language
(Challenge C4)
Moreover….

The entire weaver is rendered unusable if the base transformation
engine is replaced with another one (interoperability problem)

The PT engine may be proprietary, i.e., may not be available for use by
all desired parties (e.g., DMS)
32
Overview of Approach
Current State-of-the-Art Techniques
FuncDef
ProcDef
FuncOrProcSignature
WithinCodeExpr
ExecExpr
CallExpr
Program Transformation
Back-End
Source
Program
AspectPascal
WhileLoop
ForLoop
WithExpr
FuncOrProcDefExpr
Transformation
System
GAspect
+name : String
LoopStatement
*
Statement
1
1
*
Expression
1
Advice
*
1
Pointcut
BeforeAdvice AroundAdvice
Grammarware TS
EBNF
Model-Driven Front-End
*
AfterAdvice
LoopExpr
ArgsExpr
+name : String
Model-Driven Engineering (MDE)
Technical Space (TS)
KM3
Grammarware TS
EBNF
M3
Aspect.g
Grammar
Aspect
Metamodel
RSL
Metamodel
Transformed
Program
Model Transformation
PT Based Back-End
RSL.g
Grammar
M2
Input
Source
Program
C4
Myaspect.ap
AspectPascal
Myaspect
Model
MyRsl
Model
MyRsl.rsl
RSL program
M1
C3
Injection
Aspect2RSL
Transformation
Extraction
C1
Generic Aspect
Metamodel
Parser
definitions
C4
Generic
Aspect Source Model Transform
Metamodel Library
GenAWeave in Action
Aspect
Source
Program
Aspect Source
Model
C3
Lexer/
Parser
C3
RSL
Metamodel
RSL
Model
AST
Graph
Domain
Reader
Concrete
RSL Transform
Analyzer
Unparser
definitions
C3
ATL Model
Transformation
Engine
Model-Driven Front-End
C2
Symbol
Table
C2
Pretty
Printer
DMS Program
Transformation
Engine
C2
C1
Program Transformation based Back-End
33
Transformed
Target
Program
Model-Driven Front-End - Justification

Modularize the weaver construction process by decoupling the
model of the high-level aspect language from the model of the target
program transformation language (RSL).

The source aspect metamodel need not be altered even if one
chooses to opt for a different target PTE, only a new PTE metamodel
needs to be developed.

Conversely, for every new language, one needs to add the
appropriate metamodel extensions to the base aspect metamodel,
but no change to the target metamodel is needed.

Both the aspect language (source) and rules language (target) can
evolve independent of each other. This leads to new features being
added to the weaver.
34
Metamodel for Aspect Pascal
+aspect
AspectPascal
+name : String
1
*
Statement
1
+stmts
*
1
+aspect
+advices
+advice +pointcut
*
+pointcuts
Pointcut
Advice
+name : String
+advice
1
*
BeforeAdvice
AroundAdvice
AfterAdvice
+pointcut
+expressions
Expression
Pointcut
+advice
+name : String
Advice
1
*
1
+stmts
Statement
LoopStatement
OpaqueStatement
+advice
*
1
+pointcut
*
+expressions
+paramdefs
Expression
ParamDef
ProceedStatement
CallExpr
0-1
1
WithExpr
1
FunctionOrProcSignature
ExecExpr
0-1
35
KM3 and TCS Specification
class AspectPascal extends LocatedElement {
attribute name : String;
reference domain container : Domain;
reference pointcuts[1-*] container : Pointcut oppositeOf aspect;
reference advice[1-*] container : Advice oppositeOf aspect;
}
class Pointcut extends Element {
attribute name : String;
reference aspect : AspectPascal oppositeOf pointcut;
reference paramdefs[*] container : ParameterDef;
reference exprs[1-*] container : Expression oppositeOf pointcut;
}
abstract class Advice extends LocatedElement {
reference aspect : AspectPascal oppositeOf advice;
reference pointcut : Pointcut;
reference paramdefs[*] container : ParameterDef;
reference stmts[1-*] container : Statement;
}
36
KM3 and TCS Specification
template AspectPascal main
: "aspect" name "{" pointcut advice "}"
;
template Pointcut context addToContext
: "pointcut" name "(" paramdefs{separator = ","} ")"
":" exprs {separator = "&&"} ";"
;
template Advice abstract;
template BeforeAdvice
: "before" "(" paramdefs {separator = ","} ")" ":"
...
;
template AfterAdvice
: "after" "(" paramdefs {separator = ","} ")" ":"
...
;
37
Support for Generic Front-End (Aspect Pascal)
FuncDef
ProcDef
FuncOrProcSignature
WithinCodeExpr
ExecExpr
CallExpr
AspectPascal
ForLoop
WhileLoop
WithExpr
FuncOrProcDefExpr
GAspect
+name : String
LoopStatement
*
Statement
1
1
*
Expression
1
*
Advice
*
1
Pointcut
BeforeAdvice
AroundAdvice
AfterAdvice
LoopExpr
ArgsExpr
+name : String
38
Support for Generic Front-End (Aspect FORTRAN)
FuncDef
SubDef
FuncOrProcSignature
WithinCodeExpr
ExecExpr
CallExpr
AspectFORTRAN
DoLoop
FuncOrSubDefExpr
GAspect
+name : String
LoopStatement
*
Statement
1
1*
Expression
1
*
Advice
*
1
Pointcut
BeforeAdvice
AroundAdvice
AfterAdvice
LoopExpr
ArgsExpr
+name : String
39
40
Target Metamodel (RSL)
*
1
RSL
RuleSet
+name : String
1
+ruleset +rsl
+rulesets
-dname : String
1
+rsl
*
+elems
Element
+name : String
+type : String
*
+rules
Rule
Pattern
Condition
ExternalCondition
ExternalPattern
+dname : String
+tokens : String
+dname : String
+tokens : String
41
Overview of Approach
Current State-of-the-Art Techniques
FuncDef
ProcDef
FuncOrProcSignature
WithinCodeExpr
ExecExpr
CallExpr
Program Transformation
Back-End
Source
Program
AspectPascal
WhileLoop
ForLoop
WithExpr
FuncOrProcDefExpr
Transformation
System
GAspect
+name : String
LoopStatement
*
Statement
1
1
*
Expression
1
Advice
*
1
Pointcut
BeforeAdvice AroundAdvice
Grammarware TS
EBNF
Model-Driven Front-End
*
AfterAdvice
LoopExpr
ArgsExpr
+name : String
Model-Driven Engineering (MDE)
Technical Space (TS)
KM3
Grammarware TS
EBNF
M3
Aspect.g
Grammar
Aspect
Metamodel
RSL
Metamodel
Transformed
Program
Model Transformation
PT Based Back-End
RSL.g
Grammar
M2
Input
Source
Program
C4
Myaspect.ap
AspectPascal
Myaspect
Model
MyRsl
Model
MyRsl.rsl
RSL program
M1
C3
Injection
Aspect2RSL
Transformation
Extraction
C1
Generic Aspect
Metamodel
Parser
definitions
C4
Generic
Aspect Source Model Transform
Metamodel Library
GenAWeave in Action
Aspect
Source
Program
Aspect Source
Model
C3
Lexer/
Parser
C3
RSL
Metamodel
RSL
Model
AST
Graph
Domain
Reader
Concrete
RSL Transform
Analyzer
Unparser
definitions
C3
ATL Model
Transformation
Engine
Model-Driven Front-End
C2
Symbol
Table
C2
Pretty
Printer
DMS Program
Transformation
Engine
C2
C1
Program Transformation based Back-End
42
Transformed
Target
Program
Model Transformation
Grammarware TS
Model-Driven Engineering (MDE)
Technical Space (TS)
Grammarware TS
M3
EBNF
M2
Aspect.g
Grammar
Aspect
Metamodel
RSL
Metamodel
RSL.g
Grammar
M1
Myaspect.ap
AspectPascal
Myaspect
Model
MyRsl
Model
MyRsl.rsl
RSL program
Injection
EBNF
KM3
Aspect2RSL
Transformation
Extraction
M1 = model level;
M2 = metamodel level;
M3 = meta-metamodel level
43
ATL Transformations
rule Aspect2Rsl {
rule AfterAdvice2Pattern {
from
from
s: Aspect!Aspect
s : Aspect!AfterAdvice
to
to
t: Rsl!Rsl (
t : Rsl!Pattern (
domain <- s.domain,
ptoken <-'statement_list',
pattern <- s.advice,
ptext <- s.advStmt.stmt
rule
<- s.pointcut,
...
ruleset <- rs
),
),
...
rs: Rsl!RuleSet (
}
rsname <- s.aname,
Core transformation library :
rname <- s.pointcut-> call, exec, loop, with, withincode
collect(e|e).pctname),
(i.e., one transformation for
…
each type of pointcut)
}

The transformations generate the corresponding RSL rule
for the given aspect
44
Generalizing the Rule Generator Design
generic_advice_call (
{ program_root_  Fortran90_program},
{ method_id_
 Name},
{ proceed_
 Name},
{ before_advice_  execution_part_construct_list},
{ after_advice_  execution_part_construct_list},
)  Fortran90_program
generic_advice_call
{ program_root_ 
{ method_id_

{ proceed_

{ before_advice_ 
{ after_advice_ 
)  ObjectPascal
(
ObjectPascal},
IDENTIFIER},
IDENTIFIER},
statement_list},
statement_list},
45
Support for Reusable Back-End Functions
 To support back-end construction, GenAWeave provides a reusable library
of external functions that can be used to construct part of the low-level
weaving infrastructure for a given weaver
name_ends_with - useful for matching identifiers (e.g., function name)
whose name ends with a given input. This is equivalent to a wildcard search
*name in an aspect program
name_begins_with - useful for matching names (e.g., function name,
identifiers), which begin with the given input. This is equivalent to a wildcard
search name* in an aspect program
GetChildFromParent - helper routine useful for finding a child node with
a given property from the parent node
GetParentFromChild - helper routine useful for finding a parent node
with a given property from the child node
46
(define name_ends_with
(lambda Registry:MatchingCondition
(let (;; (= [search_string (reference string)]
(Graph:HGHandling:GetString arguments:1))
[sub_string string]
[search_string_size natural]
[search_id_size natural]
[start_index natural]
);;
(value
(;;
(= search_string_size
(size (@(AST:GetString arguments:1))))
(= search_id_size (size
(@(AST:GetString arguments:2))))
(= start_index
(- search_string_size search_id_size))
(= sub_string (Strings:Substring
(AST:GetString arguments:1)
(+ start_index 1) search_id_size))
(ifthen(== sub_string
(@(AST:GetString arguments:2)))
(return ~t)
)ifthen
(return ~f)
);;
~f
)value
)let
)lambda
)define
47
Overview of Approach
Current State-of-the-Art Techniques
FuncDef
ProcDef
FuncOrProcSignature
WithinCodeExpr
ExecExpr
CallExpr
Program Transformation
Back-End
Source
Program
AspectPascal
WhileLoop
ForLoop
WithExpr
FuncOrProcDefExpr
Transformation
System
GAspect
+name : String
LoopStatement
*
Statement
1
1
*
Expression
1
Advice
*
1
Pointcut
BeforeAdvice AroundAdvice
Grammarware TS
EBNF
Model-Driven Front-End
*
AfterAdvice
LoopExpr
ArgsExpr
+name : String
Model-Driven Engineering (MDE)
Technical Space (TS)
KM3
Grammarware TS
EBNF
M3
Aspect.g
Grammar
Aspect
Metamodel
RSL
Metamodel
Transformed
Program
Model Transformation
PT Based Back-End
RSL.g
Grammar
M2
Input
Source
Program
C4
Myaspect.ap
AspectPascal
Myaspect
Model
MyRsl
Model
MyRsl.rsl
RSL program
M1
C3
Injection
Aspect2RSL
Transformation
Extraction
C1
Generic Aspect
Metamodel
Parser
definitions
C4
Generic
Aspect Source Model Transform
Metamodel Library
GenAWeave in Action
Aspect
Source
Program
Aspect Source
Model
C3
Lexer/
Parser
C3
RSL
Metamodel
RSL
Model
AST
Graph
Domain
Reader
Concrete
RSL Transform
Analyzer
Unparser
definitions
C3
ATL Model
Transformation
Engine
Model-Driven Front-End
C2
Symbol
Table
C2
Pretty
Printer
DMS Program
Transformation
Engine
C2
C1
Program Transformation based Back-End
48
Transformed
Target
Program
GenAWeave in Action
Input
Source
Program
Generic Aspect
Metamodel
Parser
definitions
Generic
Aspect Source Model Transform
Metamodel Library
Aspect
Source
Program
Lexer/
Parser
Symbol
Table
AST
Graph
RSL
Metamodel
Aspect Source
Model
RSL
Model
ATL Model
Transformation
Engine
Model-Driven Front-End
Domain
Reader
Concrete
RSL Transform
Analyzer
Unparser
definitions
Pretty
Printer
Transformed
Target
Program
DMS Program
Transformation
Engine
Program Transformation Back-End
49
GenAWeave in Action
Input
Source
Program
Generic Aspect
Metamodel
Parser
definitions
Generic
Aspect Source Model Transform
Metamodel Library
Aspect
Source
Program
Lexer/
Parser
Symbol
Table
AST
Graph
RSL
Metamodel
Aspect Source
Model
RSL
Model
ATL Model
Transformation
Engine
Model-Driven Front-End
Domain
Reader
Concrete
RSL Transform
Analyzer
Unparser
definitions
Pretty
Printer
Transformed
Target
Program
DMS Program
Transformation
Engine
Program Transformation Back-End
50
GenAWeave in Action
Input
Source
Program
Generic Aspect
Metamodel
Parser
definitions
Generic
Aspect Source Model Transform
Metamodel Library
Aspect
Source
Program
Lexer/
Parser
Symbol
Table
AST
Graph
RSL
Metamodel
Aspect Source
Model
RSL
Model
ATL Model
Transformation
Engine
Model-Driven Front-End
Domain
Reader
Concrete
RSL Transform
Analyzer
Unparser
definitions
Pretty
Printer
Transformed
Target
Program
DMS Program
Transformation
Engine
Program Transformation Back-End
51
GenAWeave in Action
Input
Source
Program
Generic Aspect
Metamodel
Parser
definitions
Generic
Aspect Source Model Transform
Metamodel Library
Aspect
Source
Program
Lexer/
Parser
Symbol
Table
AST
Graph
RSL
Metamodel
Aspect Source
Model
RSL
Model
ATL Model
Transformation
Engine
Model-Driven Front-End
Domain
Reader
Concrete
RSL Transform
Analyzer
Unparser
definitions
Pretty
Printer
Transformed
Target
Program
DMS Program
Transformation
Engine
Program Transformation Back-End
52
GenAWeave in Action
Input
Source
Program
Generic Aspect
Metamodel
Parser
definitions
Generic
Aspect Source Model Transform
Metamodel Library
Aspect
Source
Program
Lexer/
Parser
Symbol
Table
AST
Graph
RSL
Metamodel
Aspect Source
Model
RSL
Model
ATL Model
Transformation
Engine
Model-Driven Front-End
Domain
Reader
Concrete
RSL Transform
Analyzer
Unparser
definitions
Pretty
Printer
Transformed
Target
Program
DMS Program
Transformation
Engine
Program Transformation Back-End
53
GenAWeave in Action
Input
Source
Program
Generic Aspect
Metamodel
Parser
definitions
Generic
Aspect Source Model Transform
Metamodel Library
Aspect
Source
Program
Lexer/
Parser
Symbol
Table
AST
Graph
RSL
Metamodel
Aspect Source
Model
RSL
Model
ATL Model
Transformation
Engine
Model-Driven Front-End
Domain
Reader
Concrete
RSL Transform
Analyzer
Unparser
definitions
Pretty
Printer
Transformed
Target
Program
DMS Program
Transformation
Engine
Program Transformation Back-End
54
GenAWeave in Action
Input
Source
Program
C4
C1
Generic Aspect
Metamodel
C3
Parser
definitions
C4
Generic
Aspect Source Model Transform
Metamodel Library
Aspect
Source
Program
C3
RSL
Metamodel
Aspect Source
Model
C3
Lexer/
Parser
RSL
Model
AST
Graph
Domain
Reader
Concrete
RSL Transform
Model-Driven Front-End
Symbol
Table
C2
Analyzer
C1
Unparser
definitions
C3
ATL Model
Transformation
Engine
C2
Pretty
Printer
Transformed
Target
Program
DMS Program
Transformation
Engine
C2
C1
Program Transformation Back-End
55
Integration into Eclipse
Outline view
Syntax highlighting
Error reporting
The editor indicates the misspelling of the pointcut name timer_around_loops
56
Outline of Presentation
Several Billion lines of
Legacy code
Lack of Modularization
(Legacy software decay)
Motivation
Challenges
Lack of Reusability
+
Accidental Complexities
Program Transformation
Research Goals
Model-Driven
Engineering
Approach
Evaluation
Aspect FORTRAN
Generic Aspect Weaver
Framework
Aspect Pascal
57
Experimental Evaluation – Case Study

Two weavers were constructed; one each for Object Pascal and
FORTRAN. In addition, metamodels for aspect extensions of
Java and C++ were also built.

A subset (e.g., primitive pointcuts like call, execution, loop,
withincode, and args) of standard AOP features was built into
both weavers in an AspectJ-like style.
// The user wants to perform another search
procedure TLangMan.SearchAgainClick(Sender: TObject);
begin
// Perform an update if an edit occurred that
//might change the focus of the listview
if EditMadeDirtyBit then
SaveDBControls;
…
end;
58
Aspect Specification
domain ObjectPascal;
aspect probe_dirty_bit {
pointcut proc_click(): execution(procedure *.*Click(*:*));
before() : proc_click() {
if EditMadeDirtyBit
then SaveDBControls ;
}
}

Note the wildcard *, internally supported by reusable PARLANSE
external function name_ends_with
59
Aspect Model – XMI representation
(internal)
<?xml version="1.0" encoding="ISO-8859-1"?>
<APascal xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="APascal"
xmlns:_1="GAspect" location="1:1-11:2" name="probe_dirty_bit">
<domain location="1:1-1:21" name="ObjectPascal"/>
<pointcut location="5:3-5:63" name="proc_click">
<pctexpr xsi:type="ExecExpr" location="5:26-5:62">
<funcOrProcSig xsi:type="ProcedureDef" location="5:36-5:61"
name="*Click" classifier="*">
<paramdefs location="5:57-5:60" name="*" type="*"/>
</funcOrProcSig>
</pctexpr>
</pointcut>
<advice xsi:type="_1:BeforeAdvice" location="7:3-10:4"
pctname="//@pointcut.0">
<advStmt xsi:type="_1:OpaqueStatement" location="8:5-9:33" stmt="if
EditMadeDirtyBit&#xD;&#xA; then SaveDBControls;"/>
</advice>
</APascal>
60
Model Transformation Rule (method-exec join point)
lazy rule PointCutToExternalPattern {
from
s : APascal!Pointcut
to
t : RSL!ExternalPattern (
dname <- 'ObjectPascal',
eptext <- s.extPatternName,
ptoken <- 'statement_list',
phead <- ph
),
ph : RSL!PatternHead (
name <- s.extPatternName,
slist : RSL!PatternParameter (
name <- 'slist',
referTo <- 'statement_list'
),
proceed_bef : RSL!PatternParameter (
name <- 'proceed_bef',
referTo <- 'statement_list'
),
proceed_aft : RSL!PatternParameter (
name <- 'proceed_aft',
referTo <- 'statement_list'
),
...
61
Generated RSL (internal)
default base domain ObjectPascal.
pattern find(id : IDENTIFIER) : IDENTIFIER
=
id if name_ends_with(id, search_id()).
pattern search_id() : IDENTIFIER
=
" Click ".
pattern before_advice_stmt() : statement_list
=
"if EditMadeDirtyBit
then SaveDBControls;".
external pattern around_advice_exec(slist : statement_list, proceed_bef : statement_list, proceed_aft :
statement_list) : statement_list
=
'around_advice_exec' in domain ObjectPascal.
external condition name_ends_with(
routine_name : IDENTIFIER,
search_id : IDENTIFIER)
= 'name_ends_with'.
rule proc_click(
id1 : IDENTIFIER,
id2 : IDENTIFIER,
fps : formal_parameters,
slist : statement_list)
:
implementation_declaration->
implementation_declaration
=
"procedure \id1 . \find\(\id2\) \fps ; begin \slist end;"
->
"procedure \id1 . \id2 \fps ; begin \around_advice_exec\(\slist \, \before_advice_stmt\(\) \,
\after_advice_stmt\(\) \) end;"
if slist == around_advice_exec(slist, before_advice_stmt(), after_advice_stmt())
.
pattern after_advice_stmt() : statement_list
=
"".
public ruleset probe_dirty_bit = {proc_click}.
62
Join Point for Loops
It is often desired to monitor the performance of loops for some highperformance scientific applications. Harbulot et al. first introduced this concept
in an extension to AspectJ [Harbulot and Gurd, 2005].
According to our definition, the join point for a loop has the following signature:
<loop_name>(init::<val>, exit::<val>, stride::<val>)
Init specifies the loop initialization value, exit specifies the loop termination
value and stride specifies the loop increment counter.
aspect AddTimerAroundLoops
{
pointcut loop_timer_():
execution(do(init::1,exit::10,stride:*));
void around(): loop_timer_()
{
time_begin = MPI_Wtime()
proceed()
time_end = MPI_Wtime()
}
}
63
Discussion of Experimental Results
Advice
FEATURES
before after
Pointcuts
around
call
exec
withincode
loop
args
with
Aspect Pascal









Aspect
FORTRAN










For translating a method call join point in FORTRAN and Object Pascal, 230
lines of model transformation code (out of 280 LOC) were reused without
any modification. The remaining 50 LOC were reused with minor
customization.

For translating a loop execution join point in FORTRAN and Object Pascal,
265 LOC out of 305 were reused without any modification, while the
remaining 40 LOC were reused with minor customization
64
Discussion of Experimental Results

Likewise, the front-end of all weavers share a generic metamodel (i.e.,
GAspect). Out of 550 LOC used for defining the front-end metamodel (KM3
and TCS specifications), nearly 280 LOC were shared among the two
weavers.

In additions to front-end reuse, GenAWeave provides a reusable library of
back-end external functions. Currently, there are 11 such functions that are
shared by the Object Pascal and FORTRAN weavers.
65
Reusability Summary
FRONT-END REUSABILITY
METAMODEL
KM3+TCS (LOC)
Aspect Pascal
565
Aspect FORTRAN
550
MODEL
TRANSFORMATION
ATL (LOC)
Aspect Pascal
1890
Aspect FORTRAN
1585
Shared LOC
Percentage
49.5
280
50.1
Shared LOC
Percentage
68.2
1290
81.3
BACK-END REUSABILITY
PARLANSE FUNCTIONS
Total LOC
Aspect Pascal
873
Aspect FORTRAN
775
Shared
LOC
No. of Shared
Functions
310
11
Percentage
35.5
40
OVERALL REUSABILITY
OVERALL
LOC
Aspect Pascal
3328
Aspect FORTRAN
2910
Shared LOC
1880
Percentage
56.4
64.6
66
GenAWeave on the Web
Software and Video demos available at http://www.cis.uab.edu/softcom/genaweave
67
Future Work

Improve the generality of the framework.

Metamodel inheritance
GAspect
GAspect
OO-A
APascal


AFortran
APascal
ARuby
Rule inheritance
Apply and evaluate the framework towards construction of other aspect
weavers for legacy and modern programming languages.



ARuby
AFortran
Applying the approach to domain-specific aspect languages (DSALs)
Applying the approach towards high-performance scientific computing applications,
especially towards specialization of scientific libraries
Investigate other software engineering techniques like generalized refactoring
and generic aspect mining based on the knowledge gained in developing a
generic framework for aspect weaving.
68
Core Contributions

An exploration of the underlying science to support
a generic source model for AOP, including higherorder transformations, and high-level aspect
language as a foundation for reusable program
transformation and analysis.

A generative methodology to permit construction of
aspect weavers for multiple languages; provide a
language
experimentation
environment
for
investigating ideas in new paradigms without
constructing all of the underlying parsing and
transformation mechanisms from scratch.
69
Lessons Learned




Lesson 1 - Generalizing the weaver front-end
 Parts of the aspect language front-end can be reused
by making it generic
Lesson 2 - Improving the generic metamodel
 Using model and rule inheritance
Lesson 3 - Use of generic interfaces in the rule
generator
 This helps to improve the rule generator library with
minimum customization
Lesson 4 - Modeling can be suitably applied to PTEs
 Higher-order transforms could be used to generate
lower-order program transformation rules
70
Lessons Learned



Lesson 5 - Changing the target PTE
 Source aspect metamodel need not be altered even if
one chooses to opt for a different target PTE, may also
use a pivot metamodel for PTEs
Lesson 6 - Changing the source language
 Conversely, for every new aspect language, one needs
to add the appropriate metamodel extensions to the
GAspect metamodel, but no change to the target
metamodel is needed
Lesson 7 - Automation of rule generator
 It is possible to extract the join point model from
transformation rules, and model it in terms of the
concrete syntax. In future, can also use a model weaver
to map the differences in concrete syntax
71
Publications
Journal Papers: 4 (2 under review), Conference and Workshop papers: 10














Suman Roychoudhury, Jeff Gray, Jing Zhang, Purushotham Bangalore, and Anthony Skjellum, “Modularizing Scientific Libraries with
Aspect-Oriented and Generative Programming Techniques,” Acta Electrotechnica et Informatica, (accepted Jan, 2008).
Suman Roychoudhury, Jeff Gray, and Frederic Jouault, “Model-Driven Aspect Weaving Framework,” Transactions of Aspect-Oriented
Software Development (conditional acceptance, Mar 2008).
Suman Roychoudhury, Jeff Gray, Jing Zhang, Purushotham Bangalore, and Anthony Skjellum, “A Program Transformation Technique to
Support Aspect-Oriented Programming within C++ Templates”, International Journal of Computer Science and Software Technology, (under
review since Dec, 2007).
Faizan Javed, Marjan Mernik, Jeff Gray, Jing Zhang, Barrett R. Bryant, and Suman Roychoudhury, “Using a Program Transformation
Engine to Infer Types in a Metamodel Recovery System,” Acta Electrotechnica et Informatica, (accepted Sep, 2007).
Jeff Gray and Suman Roychoudhury, “A Technique for Constructing Aspect Weavers Using a Program Transformation Engine,”
International Conference on Aspect-Oriented Software Development, Lancaster, UK, March 22-26, 2004, pp. 36-45 Alabama IEEE “Best
Paper of 2004” Award (1st place).
Suman Roychoudhury, Jeff Gray, and Frederic Jouault, “Model-based Aspect Weaver Construction,” 4th International Workshop on
Software Language Engineering, Nashville, TN, Oct 1-2, 2007.
Xiaoqing Wu, Barrett Bryant, Jeff Gray, Suman Roychoudhury, and Marjan Mernik, “Separation of Concerns in Compiler Development
using Aspect-Orientation,” ACM Symposium for Applied Computing – Programming for Separation of Concerns Track, Dijon, Bourgogne,
France, April 2006.
Xiaoqing Wu, Suman Roychoudhury, Barrett Bryant, Jeff Gray, and Marjan Mernik, “A Two-Dimensional Separation of Concerns for
Compiler Construction,” ACM Symposium for Applied Computing– Programming for Separation of Concerns Track, Santa Fe, NM, March
2005, pp. 1365-1369.
Suman Roychoudhury and Jeff Gray, “Towards Language-Independent Weaving Using Grammar Adapters,” AOSD Workshop on Linking
Aspect Technology and Evolution, Chicago, IL, March 2005.
Hui Wu, Jeff Gray, Suman Roychoudhury, and Marjan Mernik, “Weaving a Debugging Aspect into Domain-Specific Language Grammars,”
ACM Symposium for Applied Computing – Programming for Separation of Concerns Track, Santa Fe, NM, March 2005, pp. 1370-1374.
Suman Roychoudhury, “A Language-Independent Approach to Software Maintenance Using Grammar Adapters,” Doctoral Symposium,
Object-Oriented Programming, Systems, Languages, and Applications Companion Vancouver, BC, October 2004, pp. 52-53.
Jeff Gray, Jing Zhang, Yuehua Lin, Suman Roychoudhury, Hui Wu, Rajesh Sudarsan, Aniruddha Gokhale, Sandeep Neema, Feng Shi,
and Ted Bapty, “Model-Driven Program Transformation of a Large Avionics Framework,” Generative Programming and Component
Engineering, Springer-Verlag LNCS 3286, Vancouver, BC, October 2004, pp. 361-378.
Shairaj Shaik, Raymond Corvin, Rajesh Sudarsan, Faizan Javed, Qasim Ijaz, Suman Roychoudhury, Jeff Gray, and Barrett Bryant,
“SpeechClipse - An Eclipse Speech Plug-In,” Eclipse Technology eXchange Workshop, Anaheim, CA, October 2003.
Suman Roychoudhury, Jeff Gray, Hui Wu, Jing Zhang, and Yuehua Lin, “A Comparative Analysis of Meta-programming and AspectOrientation,” 41st Annual ACM SE Conference, Savannah, GA, March 7-8, 2003, pp. 196-201.
72
Conclusion

The research raised several key challenges in
designing a generic framework to construct aspect
weavers

The research demonstrated an approach that combines
PTEs with MDE to construct aspect weavers for legacy
programming languages

The combination of the two distinct technical spaces
(i.e., PTEs and MDE) offered more possibilities than
each considered separately
73
Back-up Slides
74
Specialization of HPL

HPL is a software package that solves a random
dense linear system (LU factorization) on
distributed-memory architectures

Depending on the machine architecture and the
availability of the type of BLAS (either FBLAS or
CBLAS) or VSIPL, the software package mostly
relies on preprocessor directives to make specific
calls to appropriate linear algebra subroutines.
75
HPL Specialization using DMS
2 Specialization
1 Macro Extraction
HPL-ALL
HPL
Core
Remove all preprocessor
directives, i.e., calls to
FBLAS, CBLAS and
VSIPL
Specialize to HPL-CBLAS,
HPL-FBLAS, HPL-VSIPL,
i.e., a software product line
HPLCBLAS
HPLFBLAS
HPLVSIPL
76
DMS Macro-Extraction and Specialization Rule
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
external pattern remove_macro(tran_unit:translation_unit,id:identifier):
translation_unit = 'remove_macro' in domain Cpp~ISO14882c1998.
external pattern add_macro(tran_unit:translation_unit,id:identifier):
translation_unit = 'add_macro' in domain Cpp~ISO14882c1998.
pattern FBLAS(): identifier = "HPL_CALL_FBLAS".
pattern CBLAS(): identifier = "HPL_CALL_CBLAS".
pattern VSIPL(): identifier = "HPL_CALL_VSIPL".
rule del_cblas(t_u: translation_unit): translation_unit-> translation_unit
= t_u -> remove_macro(t_u,CBLAS())
if tran_unit ~= remove_macro(t_u,CBLAS()).
rule del_vsip(t_u: translation_unit): translation_unit-> translation_unit
= t_u -> remove_macro(t_u,VSIPL())
if t_u ~= remove_macro(t_u,VSIPL()).
rule del_fblas(t_u: translation_unit): translation_unit-> translation_unit
= t_u -> remove_macro(t_u,FBLAS())
if t_u ~= remove_macro(t_u,FBLAS()).
rule add_cblas(t_u: translation_unit): translation_unit-> translation_unit
= t_u -> add_macro(t_u,CBLAS())
if t_u ~= add_macro(t_u,CBLAS()).
rule add_vsip(t_u: translation_unit): translation_unit -> translation_unit
= t_u -> add_macro(t_u,VSIPL())
if t_u ~= add_macro(t_u,VSIPL()).
rule add_fblas(t_u: translation_unit): translation_unit-> translation_unit
= t_u -> add_macro(t_u,FBLAS())
if t_u ~= add_macro(t_u,FBLAS()).
77
Before and After Specialization with
CBLAS
Size of HPL BLAS (before)
Size of HPL BLAS (after)
Number of lines of code:
1719
Number of directive lines:
390
Number of empty lines:
172
Number of comment lines:
731
Number of empty comment lines: 327
Number of lines of code:
Number of directive lines:
Number of empty lines:
Number of comment lines:
Number of empty comment lines:
Total number of lines:
Total number of lines:
3339
40
50
10
731
327
1158
78
Time Analysis
Time (Seconds)
HPL-ALL vs HPL-CBLAS Time Analysis (NxTime)
1000
800
600
HPL-ALL
400
HPL-CBLAS
200
0
HPL-ALL
HPL-CBLAS
5000
10000
20000
40000
14.58
41.51
177.11
877.12
5.5
19.01
97.01
878.57
Matrix Dimension NxN
79
Performance Analysis
HPL-ALL vs HPL-CBLAS Performance Analysis (NxGFlops)
60
GFlops
50
40
HPL-ALL
30
HPL-CBLAS
20
10
0
5000
10000
20000
40000
60000
HPL-ALL
5.719
16.11
30.02
48.54
54.91
HPL-CBLAS
15.23
34.82
54.88
48.57
56.93
Matrix Dimension NxN
80