Siva Kumar Kotamraju et al, / (IJCSIT) International Journal of Computer Science and Information Technologies, Vol.

7 (6) , 2016,2469-2471

Optimization of Constraint Engine

Siva Kumar Kotamraju
CSE Department,
Vignans Nirula Institute of Technology & Science for Women
Pedapalakaluru, Guntur
Andhra Pradesh, India-522005

Abstract— The Performance Analysis of Constraint Engine is
the work done to discover new Optimization methods for
Optimizing Perl modules
Keywords— Optimization, Constraint Engine
I. INTRODUCTION
In order to determine if tests can be merged together into
a single job it is necessary to know the requirements of the
template to run correctly, and resolve the competing
requirements of templates for shared resources such as
memory locations, template build options, API options and
DUT configuration settings. The constraint engine provides
the functionality of taking in all the requirements for tests
and finding a solution that meets the user’s requests both in
terms of absolute requirements and also in terms of
probabilistic goals set by the users. Constraint Engine is
part of Migi Tool
II. GOALS
1. Track usage of shared resources to avoid building
tests that cannot run together successfully
This is the minimum functionality – without this we
can’t do test merging without the majority of merged tests
failing due to conflicts over shared resources such as
memory, shared control registers and APIs that might affect
or check more than one thread.
2. Provide globally optimal allocation of shared
resources where possible
We want to make globally-aware decisions about the
shared resources (and decisions that affect a test’s use of
those shared resources) so that a random choice doesn’t
unnecessarily restrict our ability to run tests. Historical
experience from MTMerge and previous MP test generation
tools strongly indicate that non-global allocation in this
space is undesirable.
3. Provide tests dynamically
Determining the runtime of a test is impossible without
running the test on the MUT (it’s the halting problem.) We
also believe that it is extremely likely that we will often
have threads on the MUT that will be idle for nontrivial
periods of time. We wish to reuse that simulation time to do
useful testing, so the constraint engine must be capable of
allocating resources to a new test after other tests have been
deployed on the system.
4. Provide statistically significant solutions
Users will be specifying parameters that can take on one
of many values, and in many cases the distribution of those
values over many runs of tests is significant to the user.
While in some cases it is impossible to provide the
distribution to multiple values, there needs to be a ‘best
case’ effort by the tool to provide the distribution requested.
5. Provide an interface for selecting random values
with constraints in a test
The constraint engine also will provide a mechanism for
tests to select random values for build parameters and
specify constraints on those parameters within a single test.
This is a useful mechanism for test authors to more easily
add randomness to their tests while putting limits on the
randomness.
III. GROUNDWORK AND DEFINITIONS
Parameters and Options
A parameter is a variable that is assigned a value by the
CE. An option is a possible value that the parameter may
take. Parameters may have multiple options, and the
options can have weights which affect the probability of
which option is chosen.
An option can depend on the value of other parameters.
All options will be evaluated by the Perl interpreter and
therefore may contain arbitrary Perl code that references the
values of other parameters.
Constraints
A constraint is a restriction that is imposed on the space
of parameter values. Constraints are in the form of arbitrary
Perl code that will be evaluated. If the code evaluates to
true (non-zero), the constraint is said to be satisfied.
Streams
A stream is a series of software instructions that executes
on a single LP (logical processor). It will contain
parameters, and constraints that pick combinations of
parameter values the stream needs to run.
Tests
A test is a container for one or more streams. Tests can
also contain parameters and constraints that pick
combinations of parameter values the test needs to start
building.
Tests waiting to run are kept in a priority queue. This
means that in general, higher priority tests will run before
lower priority tests as long as constraints are not blocking
the higher priority tests.
Test blocks
A test block is a container for one or more tests. Test
blocks can be layered, meaning containing other test blocks.
Constraints can also be specified for test blocks, with the
intention that those constraints will be copied into every
stream inside, and evaluated inside the stream.

www.ijcsit.com 2469
Siva Kumar Kotamraju et al, / (IJCSIT) International Journal of Computer Science and Information Technologies, Vol. 7 (6) , 2016,2469-2471

Merge blocks 1) If the Migi Builder updates a test’s parameters, this

A merge block is a container for one or more tests. may cause the constraint system to fail. In this case, the test
There are two types: goes back to WAITING.

Parallel merge blocks contain tests that should run 2) As logical processors become available, some
concurrently. For any test in the merge block to build and WAITING tests will be promoted to BUILDING. If the CE
run, all tests in the merge block must also build and run. cannot solve the constraint system with these new tests, the
tests will return to WAITING. Tests are returned to the
Serial merge blocks contain tests that should run in series, WAITING queue lowest priority first, until the constraint
one after another, in the order specified. system can be solved.
Parameter / Constraint Interdependencies
Merge blocks can also contain other merge blocks, Parameters and constraints are concepts with many
meaning merge blocks can be layered. interdependencies. The following relationships exist:

Implementing serial merge blocks is difficult, and may 1) Constraints are arbitrary sections of Perl code that
not be done unless there is demand for the feature. check whether parameters satisfy certain properties. As
Furthermore, from here, if the term merge block is used such, they are dependent on the parameters they reference.
without specifying the type, it is referring to parallel merge
blocks The CE must be aware of the parameters a constraint is
dependent on so that if a constraint evaluates to false
Test Queues (indicating that it is unhappy with one or more of the
Every test has a status, which can be one of the following: parameters), the CE can then pick different options for
some of the dependent parameters in an effort to satisfy the
RUNNING The test has been reported as running by constraint.
the Migi Control. For a test to reach this state, it must have
built correctly, meaning all of its constraints are satisfied 2) Parameters are related to constraints. If a
and all of its parameters are "locked" (they can no longer parameter changes, the CE must know all of the constraints
change their value.) that referenced that parameter so that those constraints can
BUILDING The test is either ready to build or be re-evaluated.
currently building. For a test to stay in this queue, all of its
constraints must be satisfied. Updates to parameters 3) A parameter can be dependent on other
throughout the build process may cause constraints to fail, parameters. Because an option for a parameter may depend
which would cause removal of the test from the on the values of other parameters, changing one parameter
BUILDING queue. can affect the values of several other parameters. Every
WAITING The test is currently failing some of its time the CE changes the value of a parameter, it needs to
constraints and cannot be built right now. The failing check which other parameters depend on it, so those
constraints could be system-imposed (no logical processors parameters can be re-evaluated.
are available for the test), or user-imposed (the user may
have requested the test run alone on a core.) IV. OPTIMIZATION TECHNIQUES:
WAITING -> BUILDING (promotion) 1) String Comparison:
When logical processors in the system are available, The code inside the subroutine does arithmetic and a
some WAITING tests will be promoted to BUILDING. numeric comparison of two strings. It assigns one string to
The CE will then attempt to solve the constraint system. If another if the condition tests true but the condition always
successful, the tests added to the BUILDING queue will tests false.
remain, indicating they are ready to build. If adding the sub test_code{
new tests causes the constraint system to fail, tests will be my ($a,$b) = qw(foo bar);
removed (and put back in the WAITING queue) until the my $c;
constraint system can be solved. if ($a == $b) {
$c = $a;
BUILDING -> RUNNING (promotion) }
When the Migi Control indicates a test will run, it is }
promoted to RUNNING. Once a test is in the RUNNING
queue, it will remain there until the Migi Control tells the Now let's fix the comparison the way it should be, by
CE to release the test (probably because the test finished replacing == with eq, so we get:
running.)
my ($a,$b) = qw(foo bar);
BUILDING -> WAITING my $c;
This transition can happen in two cases if ($a eq $b) {
$c = $a;

www.ijcsit.com 2470
Siva Kumar Kotamraju et al, / (IJCSIT) International Journal of Computer Science and Information Technologies, Vol. 7 (6) , 2016,2469-2471

2) Concatenation: V. EXPERIMENTAL RESULTS

$title = 'My Web Page'; Performance Analysis is to identify the Non-optimized
print '<h1>' . $title . '</h1>'; # Concatenation Perl subroutines in the Constraint Engine Part. By Running
(slow) . the Command Lines for different tests and analyzing the
print '<h1>', $title, '</h1>'; # List (fast for long Profile data, the following is the Result
strings) 30_parallel_merge_advanced.test
3) Way of Calling Subroutines:
120
• Light Subroutines: function form ( like
Foo::bar('Foo')) 100

Percentage of total time

• Heavy Subroutines: method form (like Foo->bar()) 80

It will make code easier to develop, maintain and Series1

Series2
60
debug, saving programmer time which, over the life of a Series3
Series4

project may turn out to be the most significant cost factor 40

4) Needless importing : 20

use POSIX; # Exports all the defaults -0.516us 0

use POSIX (); # Exports nothing -0.315us.

lve

e
ck

ts
st

ck
ick
st

AD
t

s
in

at
c

fie
ue

tio

es
te

ie
io
pi

pi
so

ep

ra
ep

lu

LO

nc
d_

pt
tis
re

re

::t
eq

va
::_

st
::r
::r

_o

_o
t::

de
ck
t::
sa
ad

TO
on
_r

::e
am
CE

ck

es

ew
in

al

lo
t::

en
s_
ss

_c

l
lo

U
ra

ev
va

tb
::T

in
tre
i::

_n
ce

ep
es

::A
tb

al

st

es
ra
ig

e_
::E
CE

:S

ev
es

ck
ro

on
oc

_d
M

on
st

:T
at
E:
5) Avoid $&:

CE
::p

pi
t::
::T

on
pr

::C
i::

ct
E:
m

er
C

r::
in
ig

ra
:_
CE

CE

::C

i::

om

C
en
CE
i::

ra

te
M
E:

xt
ig

i::
ig
i::

::g
CE

e
st
i::

:C

::e
M

ig
C

i::
M

am
ig

on
ig
i::

M
er
ig

E:

er
i::
M
$text =~ /.* rules/; $line = $&; # Now every match will

M
ig

M
::C

ar

et
C
ig

et
M

am
::P

i::
M

am
CE

ig
CE

ar
M

ar
i::

::P

::P
ig

i::
copy $& slow

ig

CE

CE
M

i::

i::
ig

ig
M

M
$text =~ /(.* rules)/; $line = $1; # Didn't mention $& fast Subroutine

Optimized Constraint.pm in CE
6) Pull things out of loops:
Perl's hash lookups are fast. But they aren't as fast as a 30_Parallel_merge_advanced.test
lexical variable. The value of $type didn't change, so I
120
pulled the lookup out above the loop into a lexical variable.
my $type_func = $encode_types{$type}; 100
Percentage of time

80
Series1
7) Transliteration operator: 60
Series2
Series3

• tr/!// # fastest way to count chars: In scalar context 40

Series4

it returns the number of characters that matched. It's the

20
fastest way to count the number of occurrences of single
characters and character ranges 0

n
t

s
n
d

te
t

ck

AD
st

ts
ck

in
es

ie
io
io
ic

ic

fie
lv
ue

ua

es
ra

pi
pi

nc
pt
pt
ep

ep
_t

so

LO
• tr/q/Q/ faster than s/q/Q/g: tr is also faster than the
is

re
re

st

:: t
eq

al

_o
_o
d

de
t
::r

::r
:_

sa

on

t::

ev

ck
ad

t::

TO
_r

al
w
E:

am
ck

en
in
es

t::

lo
_c

l::
s_
ss

ev
ne

AU
C

lo

a
in

ep
tb
a
:T

al

r
es

i::
ce

e_
tb

k_
v
st
r

ra

es
E:

:
St

:E

_d
v
ig

regexp engine for doing character-for-character n:

es
oc
ro

on
::e

at
ic
st

:T
C
M

E:

ct
E:

: :p
:p

on
:T

er
pr

:C
i::

m
t

E:

ra
in

::C
E:

C
E:

en
:_

er
ig

:C

om
E:

C
ra

xt
i::
C

E:

gi
C

et

::g

i::
C
E:

st

::e
ig
i::

:C
i::

am
C

i ::

ig
M
on
C
M

er
ig

er
substitutions.
ig
i ::

E:
ig

M
i ::
M

et
ar
:C
M

et
ig

C
ig

am
M

:P

am
E:

i ::
M

ig
E:
C

ar

ar
M
i::

:P

:P
ig

i::

• tr/a-z//d faster than s/[a-z]//g: tr is faster than the

E:

E:
M

ig

C
M

C
i::

i::
ig

ig
M

regexp engines for doing character range deletions Subroutine

8) String Concatenation: REFERENCES

• Ordinary Concatenation: less time [1] When Perl is not quite Fast enough” by Nicholas Clark
• Generating an Array and concatenating with join: Link: http://www.ccl4.org/~nick/P/Fast_Enough/
More time [2] Data Structures and Algorithms with examples in Perl by Jon
Jacky.
9) Use references : While working with large Link: http://staff.washington.edu/jon/dsa-perl/dsa-perl.html
arrays or hashes and use them as arguments to
functions. Saves memory
10) String handling: In a Web application, use
single quotes rather than doubles.
11) Loops: Excessive function calls in a loop are
generally a bad idea. Loop in a Function is a
good Procedure. Use map instead of for-each
for each Pass.
12) Using short circuit logic:
use the logical || operator, Perl will use the first
true value it comes across, in order, from left to right. The
moment it finds a valid value, it doesn't bother processing
any of the other values.
13) cache the array list, and then return the cached
copy instead of re-creating the array all the
time.

www.ijcsit.com 2471