research article scalalab and groovylab: comparing scala...

Research ArticleScalaLab and GroovyLab Comparing Scala and Groovy forScientific Computing

Stergios Papadimitriou1 Kirsten Schwark2 Seferina Mavroudi34

Kostas Theofilatos3 and Spiridon Likothanasis3

1Department of Computer Engineering amp Informatics Technological Educational Institute of Kavala 65404 Kavala Greece2iDashboards 900 Tower Drive Troy MI 48098 USA3Department of Computer Engineering and Informatics University of Patras Greece4Technological Educational Institute of Patras 26332 Patras Greece

Correspondence should be addressed to Stergios Papadimitriou stergteikavedugr

Received 26 January 2014 Revised 14 August 2014 Accepted 12 January 2015

Academic Editor Damian Rouson

Copyright copy 2015 Stergios Papadimitriou et al This is an open access article distributed under the Creative Commons AttributionLicense which permits unrestricted use distribution and reproduction in any medium provided the original work is properlycited

ScalaLab and GroovyLab are both MATLAB-like environments for the Java Virtual Machine ScalaLab is based on the Scalaprogramming language and GroovyLab is based on the Groovy programming language They present similar user interfaces andfunctionality to the userThey also share the same set of Java scientific libraries and of native code libraries From the programmerrsquospoint of view though they have significant differences This paper compares some aspects of the two environments and highlightssome of the strengths and weaknesses of Scala versus Groovy for scientific computing The discussion also examines some aspectsof the dilemma of using dynamic typing versus static typing for scientific programming The performance of the Java platform iscontinuously improved at a fast pace Today Java can effectively support demanding high-performance computing and scales wellon multicore platforms Thus both systems can challenge the performance of the traditional CC++Fortran scientific code withan easier to use and more productive programming environment

1 Introduction

The recently introduced ScalaLab [1] scientific programmingenvironment for the Java Virtual Machine (JVM) leveragesthe statically typed Scala object-orientedfunctional language[2] It provides a MATLAB-like syntax that is used toconstruct scripts that are then compiled by ScalaLab forexecution on the JVM

The GroovyLab environment is based on the Groovydynamic language for the Java platform [3] The underlyingmechanisms in GroovyLab are very different from ScalaLabprimarily due to the dynamic character of Groovy

The Scala language supports the implementation ofsimple coherent and efficient MATLAB-like interfaces formany Java scientific libraries These interfaces are compiledwithin the core of ScalaLab The Groovy language alsoprovidesmechanisms to access easily and elegantlymany Java

scientific libraries but these mechanisms are quite differentfrom those provided by ScalaLab

ScalaLab and GroovyLab are open source projects andcan be obtained from httpcodegooglecompscalalaband httpcodegooglecompjlabgroovy respectively BothScalaLab and GroovyLab can be installed easily The onlyprerequisite is the installation of the Java 8 (or newer) run-time (which is free) We supply scripts for launching thesesystems for all the major platforms Also for Linux 64bit and Windows 64 bit platforms native executables (egfor Windows the WinScalaLabexe) provide an even easierstartup The general high-level architecture of ScalaLab isdepicted in Figure 1 and is described in [1] The architectureof GroovyLab is shown in Figure 2 and is very similarto that of ScalaLab except GroovyLab uses the Groovyprogramming language rather than the Scala programminglanguage It is also a successor of jLab that is described in [4]

Hindawi Publishing CorporationScientific ProgrammingVolume 2015 Article ID 498618 13 pageshttpdxdoiorg1011552015498618

2 Scientific Programming

Integrated Java librariesfor graphics and

numerical analysis

Toolboxes of class code

Application specificwizards

Import wizard

Computer algebrasubsystem

Use

r frie

ndly

scrip

ting

base

d in

terfa

ce

Scala compiler

ScalaSci domainspecific language

Java compiler

Scala interpreter

Figure 1 The architecture of the main software components ofScalaLab

Groovy compiler

GroovySci domainspecific language

Java compiler

Groovy shell


numerical analysis



Import wizard


Use

r frie

ndly

scrip

ting

base

d in

terfa

ce

Figure 2 The architecture of GroovyLab

GroovyLab is essentially a redesign of jLab that is based onthe Groovy scripting language which proves to be superiorto the various scripting modes provided by jLab (j-scriptJavaSci GroovySci compiled j-script mode) In a few wordsthe GroovySci scripting mode of jLab proved much superiorand GroovyLab was developed by improving that mode andremoving the others as somewhat redundant HistoricallyScalaLab was developed in parallel with GroovyLab as asimilar environment using the powerful statically typed Scalalanguage

In this paper some important similarities and differencesbetween ScalaLab andGroovyLab will be examinedThe userinterfaces of the two systems are similar Also the exploitedJava scientific libraries and native code high performancelibraries are the same The major differences emerge whencode is developed for these systems They present differentscripting languages for writing applications and are also verydifferent when designing and implementing libraries

The paper proceeds as follows Initially the frameworksfor developing matrix libraries in Scala and in Groovy willbe examined (Section 2) Next the implementation of high-level mathematical operators in ScalaLab and GroovyLabis discussed (Sections 3 and 4) The functional program-ming abilities of the two environments are then brieflyexamined (Section 5) Both systems provide the user withflexible scripting environments the main features of theseenvironments are then compared (Section 6) Compile-timemetaprogramming is a powerful feature offered both byGroovy and Scala an example is then presented to demon-strate how compile-time metaprogramming can be usedto expand the syntax of GroovyLab without any run-timeperformance penalties (Section 7) A few aspects of theScalaLab and GroovyLab environments that are importantfor scientific computation are then presented and comparedNext performance related issues are discussed and bench-marking results are presented (Section 8) Finally the paperconcludes with remarks concerning the relative strengths andweakness of each system

2 Matrix Design in ScalaLab and GroovyLab

In this section some main features of the Scala and Groovylanguages that are used to facilitate the utilization of theJava scientific libraries are described and compared Thesefeatures are presented in the context of providing supportfor a MATLAB-like syntax for matrix manipulation andthe utilization of underlying Java libraries to provide theimplementation of the matrix functionality

21 Matrices in ScalaLab The general architecture for inter-facing with Java libraries in ScalaLab is illustrated in Figure 3Below we describe these components

211 The Java Library The Java library module in Figure 3corresponds to the Java code of the library that performs themain numerical calculations Some examples of the Javalibraries are the EJML library (httpscodegooglecompefficient-java-matrix-library) the Apache Common Maths(httpcommonsapacheorgpropercommons-math) andthe MTJ (Matrix toolkits for Java httpsgithubcomfommilmatrix-toolkits-java) It should be noted that the Scalainterpreter can also use the native Java interface of eachlibrary

212 The Wrapper Scala Class (WSC) The Wrapper ScalaClass (WSC) aims to provide a simpler interface to themore essential functionality of the Java library for examplematrices 119860 and 119861 can be simply added as 119860 + 119861 rather thaninvoking the cumbersome Aplus(B) The wrapper Scala class

Scientific Programming 3

Java library

Scala object for staticmath operations

Wrapper scala class

Scal

a int

erpr

eter

RichDouble2DArray

Figure 3 The general architecture of interfacing Java libraries inScalaLab

Matrix represents a one-indexed matrix and is based on theNUMAL library [5]The wrapper classMat is a zero-indexedmatrix implemented in Scala It borrows functionality fromthe JAMA Java package Some other wrapper classes exist thatinterface the functionality of important Java libraries as forexample the EJMLMat class based on the EJML library andthe Apache Common Maths library We implement separatezero-based and one-based indexed Matrix classes for tworeasons (a) obtaining maximum implementation efficiencyand (b) the one-indexed Matrix class is a wrapper for theNUMAL library routines We feel that is rather inconvenientto mix zero and one indexing styles at the sameMatrix class

213 The Scala Object for Static Math Operations The ScalaObject for Static Math Operations (SOSMOs) provide over-loaded versions of basic routines for our new Scala matrixtypes For example it provides an overloaded version of thesinmethod that accepts an instance of ourMat Scala class asan argument (ie sin(B) where 119861 is aMat instance)

Each SOSMO object implements a large set of mathe-matical operations The rationale behind these objects is tofacilitate the switching of the Scala interpreter to a differentset of libraries The interpreter simply needs to import thecorresponding SOSMO objects in order to switch function-ality

The top-level mathematical functions for the zero-indexed matrices for example rand0(int n int m) ones0(intn) and so forth return the matrix representation associatedwith the currently utilized library Amatrix object can refer todifferent matrices depending on the library The ldquoswitchingrdquoof libraries is performed by creating a different new Scalainterpreter that imports the corresponding libraries with theaid of the specially designed SOSMOs Scala objects Forexample the StaticMathsJAMA object performs importantinitializations for the JAMA library and the StaticMathsE-JML utilizes the Efficient Java Matrix Library (EJML) Theutilization of the JAMA library is accomplished by creating aScala interpreter that imports the StaticMathsJAMA SOSMOobject while for the EJML the StaticMathsEJML is importedThe ScalaLab user can easily switch different underlying Javalibraries

214 The RichDouble2DArray The RichDouble2DArray isthe ldquosuperrdquo Matrix class of ScalaLab It implements mathe-matical routines that expose the best aspects of various Javascientific computing libraries It is however independent ofany particular utilized library By convention utility routinesthat do not end in 0 or 1 return RichDouble2DArray objectsFor example rand() zeros() ones() and so forth all constructRichDouble2DArray objects Furthermore the extensibilityof RichDouble2DArray is leveraged with implicit conversionsin order to provide its rich functionality to standard two-dimensional JavaScala arrays

22 Matrices in GroovyLab The design of matrix supportin GroovyLab is simpler than that in ScalaLab Instead ofproviding switchable matrix interfaces to different librarieslike ScalaLab GroovyLab provides one powerful Matrixclass that aims to combine effective numerical routines frommultiple numeric libraries In essence this Matrix class hasmany similarities in functionality to the RichDouble2DArrayclass of ScalaLab As RichDouble2DArray it provides a lot ofoperations in pure Java for efficiency Also a set of efficientnative code routines is interfaced with JNI (Java NativeInterface) from the BLAS and LAPACK libraries

The Matrix class of GroovyLab is a zero-indexed two-dimensional dense matrix type that realizes much function-ality of GroovySci GroovySci is the scripting language ofGroovyLab that is an extension of Groovy that providesMATLAB-like operators and syntax (corresponds to ScalaSciof ScalaLab) The Matrix class leverages functionality frommultiple libraries such as JAMA LAPACK NUMAL EJMLJBLAS Apache Common Maths and MTJ

TheMatrix class is fundamental in GroovySci because ofthe following

(a) It provides a number of mathematical operations ontheMatrix object that are implemented using a variety of Javalibraries For example for linear system solvers the solverfrom the JLAPACK library the NUMAL library or the JAMAlibrary could be used

Some libraries such as the Apache Common Mathslibrary the JAMA library and the NUMAL library use atwo-dimensional double array matrix representation TheGroovyLabMatrix class also uses the same underlyingmatrixrepresentation therefore their routines are readily accessiblewithout any conversion Some other libraries use differentmatrix representations For example JLAPACK uses a one-dimensional double array representation in which thematrixstorage layout is in column based order (ie Fortran like)In these cases O(N) conversion routines (where 119873 is thenumber of matrix elements) are required before using themethods of these libraries However mathematical routineswith much higher complexity than simple linear complexity(eg matrix factorization Singular Value Decompositioneigenvalue computations) benefit from such libraries TheEJML library also uses a one-dimensional ldquoflatrdquo matrixrepresentation in either row or column based order EJMLis one of the more efficient pure Java numerical libraries onereason being the proper setup for effective caching that theone-dimensional storage representation presents


(b) It provides many useful static methods that are usuallyoverloaded to handle many different types For example thesin() method is overloaded to handle input from a Matrix atwo-dimensional double array and a one-dimensional doublearray

Matrix sin(Matrix a)double [] [] sin(double [] [] a)double [] sin(double [] a)

Static importation of all the static methods of the Matrixclass is performed by GroovyLab before any code is executedwith the GroovyShell (the component that executes Groovyscripts) therefore we can write sin(119909)where 119909 can takemanypossible types for exampleMatrix double [][] double [] anddoubleTherefore theMatrix class providesmuch of the samefunctionality provided by the Scala Objects for Static MathOperations described in the previous section

23 SparseMatrices ScalaLab andGroovyLab provide exten-sive support for sparse matrices using the Java implementa-tion of the techniques presented in [6] (the source is suppliedfree from the authors) Both systems also implement classesthat wrap the sparse routines with a higher level and elegantsyntax Clearly GroovyLab exploits Groovyrsquos facilities forbuilding Domain Specific Languages (DSLs) and ScalaLabthose of Scala Also the open source project Matrix Toolk-its for Java (httpsgithubcomfommilmatrix-toolkits-java)offers an effective framework for handling sparse matriceswith Java classes These classes are integrated in the built-inlibraries of both ScalaLab and GroovyLab and can be utilizedwith MATLAB-like convenience

3 Designing High-Level Operators inScalaLab and GroovyLab

Both Scala and Groovy provide the ability to define operatorsthat function on operands of arbitrary types Groovyrsquos sup-port for operator definition is more limited than Scalarsquos andis restricted to a set of well-known symbolic operators

31 Defining Operators in ScalaLab ScalaLabrsquos support foroperator definition is best demonstrated with an exampleThe class used as an example for ScalaLab is the EJMLMatclass

The SimpleMatrix class of the Efficient JavaMatrix Library(EJML httpcodegooglecompefficient-java-matrix-li-brary) implements mathematical operations in an object-oriented way while maintaining the immutability of theoperands For example to multiply matrix 119865 and 119909 themul method on 119865 can be invoked as in Fmul(119909) TheJava-like method calls are not very elegant though Forexample the matrix calculation F P 1198651015840 +Q is executedas Fmult(P)mult(Ftranspose())plus(Q) instead of the muchclearer FlowastPlowastFsim + Q that is performed in ScalaLab

The scalaSciEJMLMat (abbreviated Mat) class in Scal-aLab wraps the EJML SimpleMatrix class and provides theScala support for high-level MATLAB-like operations

def apply(row Int col Int) =

smget(row col)

Algorithm 1

In Scala operators on objects are implemented asmethodcalls even for primitive objects like integers (ie int type)Although operators are treated syntactically and semanticallyas method calls at the code generation phase the Scalacompiler treats the usual arithmetic operators on primitivetypes by generating direct efficient bytecode Thus Scalamathematical expressions have speeds similar to those ofJava Operator characters are valid method names A familiaroperator symbol (eg ldquo+rdquo) can be used to define a methodthat implements the operator Infix operators are imple-mented as methods that have a single parameter that is of thetype of the second operand For example alowast5 corresponds toalowast(5) Prefix operators such as + minus sim are implemented byprepending the word unary to construct the correspondingmethod name Postfix operators are implemented in Scala asmethods that take no arguments For example implementinga method named sim on the Matrix class could be used toindicate Matrix transposition So the transpose of 119860 wouldbe obtained using the sim operator as Asim

Scala provides the applymethod to provide support for asubscript-like operator for indexed object access that appearssimilar to both method invocation and array element accessFor example for the EJMLMat class the applymethod can beused to provide access to the (row col) element of the matrixThe method is implemented by calling the correspondingroutine get() of the EJML library as shown in Algorithm 1

The method is then invoked as 119872(119894 119895) to access theelement of the matrix in the 119894th row and 119895th column of 119872The apply method can also be overloaded in order to obtaina subrange of a matrix as well

In a similar fashion Scala provides the updatemethod tosupport indexed object assignment For the EJMLMat classthe update method can be implemented to assign a value toa specific element of the matrix The method is implementedas shown in Algorithm 2

The update method is then invoked as 119872(119894 119895) = 98 toassign the number 98 to the 119894-119895th element of119872

ScalaLab provides an implementation of the colon ()operator to support theMATLAB colon operator for creatingvectors as the following example

var t = 0002459

This expression returns a scalaSciVec type for 119905 To imple-ment such syntax implicit conversions are combined with thetoken cells approach [7 8]

Methods with names ending with the ldquordquo charactersare invoked on their right operand passing in the leftoperand For example the above expression is evaluatedas (459(002))(0) Since the Double class does not havea method it is implicitly converted to a MATLABRangeS-tart object The MATLABRangeStart object retrieves the


def update(row Int col Int value Double) Unit =

smset(row col value)

Algorithm 2

x = rand(50 100)

row = 5 col = 2

xr = x[14+row col4lowastcol] take a range

xrb = x[(120)by(2) (130)by(3)] like x(1220 1330)

x[(140)by(5) 12] = 44

Algorithm 3

receiverrsquos value (ie 459) with its constructor and storesit as the ending value of the range The MATLABRangeS-tart class has a method named that processes the incre-ment parameter (ie 002) Finally the method creates aMATLABRangeNext object passing itself that is the MAT-LABRangeStart object as the argument The method ofthe MATLABRangeNext receives as a parameter the startingvalue of the range (ie 0)Therefore it has all the information(ie start increment end) to construct and return the vector119905

MATLAB-like indexingassignment is implemented eas-ily by defining overloaded versions of apply() that operate onvectors For example to evaluate the expression M(242032100) the implicit conversions mechanism converts thearguments to vectors The apply method is then invokedwhich will extract from the vector arguments the necessarystart step and increment values

32 Defining Operators in GroovyLab In contrast to ScalaGroovy provides support for operator overloading only fora specific set of operator symbols The positive side of thisrestriction is that we enforced to avoid unusual operatorsymbols conforming to the familiar ones (eg ldquolowastrdquo formultiplication ldquo≪rdquo for left shift etc) To support operatoroverloading Groovy supplies a standardmapping of operatorto implementing method For example the ldquo+rdquo operatorcorresponds to the plus method From Java only thesemethods can be used but from Groovy either the operatorsor their corresponding methods may be used

We provide implementations of the Groovy operatormethods in pure Java code for both efficiencyrsquos sake and touse them from Java as methods Scala operators cannot beimplemented directly in Java (at least without considering theinternal details of the Scala compiler) because Java does notsupport operators as method names It would also be difficultto call them In order to call the methods corresponding toScala operators from Java the synthetic names that the Scalacompiler creates for the operatorsmust be used which is veryinconvenient

Operator support in Groovy is supplied by implementingthe appropriate correspondingmethod For example the plus

method is implemented to provide the addition operator ldquo+rdquotheminus method is implemented to provide the subtractionoperator ldquominusrdquo and themultiplymethod is implemented to pro-vide the multiplication ldquolowastrdquo operator This operator methodmapping approach is not as flexible as Scalarsquos ldquomethods asoperatorsrdquo approach that permits the user to define arbitrarysymbols as operators These predefined methods in Groovycan be implemented in Java and (as noted) are implementedin GroovyLab in Java for the sake of efficiency The syntacticconvenience of using the operator rather than the method isonly applicable in Groovy though For example 119909 + 100 is avalid expression in Groovy where 119909 is a Matrix object but inJava matrix addition is performed using xplus(100)

Another example of Groovyrsquos syntactic elegance isdemonstrated in the implementation of matrix indexing andassignment operators The subscript indexing operator inGroovy is overloaded by implementing the getAt() methodand the subscript assignment operator is overloaded withthe putAt() method Groovy has built-in support for integerranges via the operator so the syntax 25 can be used tocreate an IntRange instance The concept of a step can beimplemented by defining a class named IntRangeWithStepthat inherits from the Groovy range class IntRange Thisclass is used in GroovyLab to write elegant MATLAB-likeconstructs as shown in Algorithm 3

Since the predefined IntRange type does not have a by()method the Groovy compiler handles 120 as IntRangeWith-Step The by() method stores the step argument Finallyelements are accessed using the subscript access operatorimplemented with the getAt() method and the subscriptassignment operator that is implemented by the putAt()method

Similarly the DoubleRangeWithStep class that extendsObjectRange is provided by GroovyLab and implements thestep()method in order to return a vector Thus we can write

x = (0550)step(001) as equivalent to MATLABrsquos0500150

After examining both Scalarsquos and Groovyrsquos support for oper-ator overloading it can be concluded that while GroovyLabrsquos


syntax is convenient it cannot provide the MATLAB-likesyntax that can be implemented in ScalaLab

33 Matrix Operations Performance The performance of thebasic indexing and assignment operations in GroovyLabrsquosMatrix class when Groovy is statically compiled is similarto that of Scalarsquos two-dimensional matrices Other Matrixrange operations are slower in GroovyLab even thoughmany of the submatrix operations are performed in JavaSpecifically for operations involving large submatrices thespeed is about the same but performance is about threetimes better in ScalaLab than inGroovyLabwhenmany smallsubmatrices are processed In the latter case the GroovyLabimplementation involves much more dynamic Groovy coderather than the faster Java code hence the performancepenalty

4 Defining Operators for User Types ImplicitConversions versus the Metaobject Protocol

Both Scala and Groovy provide run-time mechanisms tohandle the situation where an operator is applied to a typein which there is not a specific operator that matches theargument types Implicit conversion of argument types issupplied in Scala to address these potential type mismatchesGroovy provides metaprogramming to address these sorts oftype violations

41 Implicit Conversions in Scala Returning to the matrixMat class example in Scala when the compiler detects theaddition operator ldquo+rdquo on a Double object 119889 that adds a Matobject M that is 119889 + 119872 it encounters a type error becausethere is no method defined on the predefined Double typethat adds a Mat instance to a Double (and there cannot beone since Mat is a user defined type) A similar error occurswhen a Mat instance is added to a double array

Scala provides implicit conversions [2 9 10] to addressthese sorts of type issues When an operation is not definedfor a type the compiler will try to apply available implicitconversions in order to transform the type into a type forwhich the operation is valid

The concept of implicit conversion is of fundamentalimportance in the construction of high-level mathematicaloperators in ScalaLab Implicit conversion in ScalaLab isused with many classes for example RichNumber RichDou-ble1DArray and RichDouble2DArray classes

For example the RichNumber class is implemented tosupport implicit conversions in Scala related to the Dou-ble class The RichNumber class models extended Numbercapabilities of accepting operations with all the relevantclasses of ScalaLab for example withMatMatrix EJMLMatMTJMat and generally whatever class we need to process

Suppose that we have

var a = 20 + rand(22)

The 2 is transformed by the Scala compiler to a RichNumberobject that defines an operation to add a Matrix and the

addition can be performed by the addition operator imple-mentation

Similarly the classes RichDouble1DArray and RichDou-ble2DArray wrap the Array[Double] and Array[Array[Dou-ble]] Scala classes in order to support implicit type conversionfor the addition and multiplication of Array[Array[Double]]types

As RichNumber enriches simple numeric types RichDou-ble1DArray enhances the Array[Double] type and RichDou-ble2DArray the Array[Array[Double]] type For example thefollowing code is valid in Scala

var a = Ones(9 10) an Array[Array

[Double]] filled with 1s

var b = a+10 add the value 10 to

all the elements returning b as

RichDouble2DArray

var c = b + a⋆897 similarly using

implicit conversions this computation

proceeds normally

In the next sectionwe continue by describing the correspond-ing implementations of high-level mathematical operators inthe context of GroovyLab Although similar functionality asin ScalaLab can be achieved in GroovyLab the underlyingapproaches are very different

42TheMetaobject Protocol in Groovy In Groovy as inmanyother dynamic languages the implementation of high-levelmathematical operators for the standard language types isbased on the Metaobject protocol The Metaobject protocolforms the basis of metaprogramming in Groovy that is usedto implement dynamic method invocation [3] This protocolis the means by which dynamic functionality can be added toclasses at runtime Dynamic behavior is added to classes andobjects in Groovy using theMetaClassmachinery

In dynamic languages methods can be injected intoa class by adding methods to its MetaClass These addedmethods are then available globally on instances of the classIn the case of Groovy metaprogramming can be used toadd methods properties constructors and static methods toclasses at runtime New methods in Groovy can be addedto both Groovy classes and Java classes Groovy supportsmetaprogramming at both the class and object level

For example the Number class of the standard Groovyrsquoslibrary does not implement the addition operator to supportadding an array to a Number instance Metaprogrammingcan easily be used to define a method on the numberclass to support this addition operation and adding it tothe MetaClass of the Number class the Groovy Code isillustrated in Algorithm 4

The keyword delegate refers to the current object that isthe Number object Also since Groovyrsquos bytecode is some-what slow for numeric calculations GroovyLab intermixesJava code to attain improved performance

Although this mechanism is seemingly easier to imple-ment than Scalarsquos implicit conversions it requires indirect


define the operation Number + double [] at the MetaClass of the Numberrsquos class

NumbermetaClassplus =

the double [] m array denotes the input parameter

double [] m -gt

call a Java routine for the operation

res =

groovyScimathLinearAlgebraLinearAlgebraplus(delegate m) calls Java code

res

Algorithm 4

method calls through the MetaClass machinery and imposesadditional method invocation overhead However Groovyrsquosapproach is more flexible in that it supports changingwhich method will be executed at runtime This flexibilityis useful if implementations from different libraries are usedinterchangeably for example when it is desired to use aneigenvalue decomposition from a different library than theone supplied by default

5 Functional ProgrammingFunctions versus Closures

A core concept in any language that supports functionalprogramming is the provision of functions as ldquofirst-classcitizensrdquo In object-oriented languages like Scala and Groovyfunctions are objects They can be passed as argumentsto other functions be a return value from a method andhave a concise literal definition syntax Most programminglanguages now support first-class functions because theyvastly improve the readability and understandability of thesource code by allowing behavior to be captured assignedto variables and passed to functions For instance themajor new feature of Java 8 is the support of functionalprogramming with lambda expressions

51 Functions in Scala Scala has the concept of both func-tions and closures Functions are like static methods that donot belong to any classobject

An example of a function definition in Scala is

def cube(x Double) = xlowastxlowastx

Scala also has a literal function syntax that can be used toassign a function to a variable For example the functionabove can be declared as follows

val cube = (x Double) =gt xlowastxlowastx

The Function variable ldquocuberdquo can be invoked as if it were thefunction definition above that is as in the invocation cube(3)

A function in Scala that refers to a variable outside ofits scope is called a closure These variables from outside thescope of function are referred to as free variables An exampleof the definition of a Scala closure is

val raiseIt = (x Int) =gtMathpow(x power)

Here ldquopowerrdquo is a free variable because it is defined outside ofthe scope of the function At compile time a variable namedldquopowerrdquo must be in the scope of the literal definition of theraiseIt function otherwise a compiler error will result

Therefore Scala differentiates between a function and aclosure based on whether or not the definition contains freevariables

52 Closures in Groovy Groovy also supports ldquoglobalrdquo func-tion definitions (ie functions that are not defined within aclass) but these functions are simply static methods of classesimported automatically Therefore they do not support thefunctional programming style

Groovy however provides strong support for closuresthat are first-class objects that can be passed as parametersand assigned to variables The syntax of closure definitionis different from the definition of methods for example asimple Groovy closure that implements the cube function is

def cube = x -gt xlowastxlowastx

The closure is then invoked as expected as cube(3)

53 Global Function Workspace Scientific programmingenvironments demand a global namespace of functions Scalaand Groovy do not have the concept of globally visiblemethods every method must be contained in an object ora class In both environments though a global functionnamespace can be implemented easily with static imports InScala objects are imported since these objects encapsulate thestatic imports InGroovy static imports are performed as theyare in JavaTherefore the automatic import of static methodsprovides the appearance of the existence of global methodsFor example the plotmethod appears to be available globallysince we import it from the object scalaSciplotplot Scala alsooffers the ability to define apply methods for the companionobjects of classes If a class implements the apply methodan instance of the class can essentially be ldquoexecutedrdquo like afunction as the instance name followed by a list of argumentsin parentheses When the apply method is implemented by aclass amethod does not need to be imported into the ldquoglobalrdquonamespace it is only necessary to import the class itselfGroovy does not offer a similar ability to essentially execute


Groovy matrix classes

Metaclass basedexpansion of runtime

Java library

Gro

ovy

shel

l

Figure 4 The general architecture of interfacing Java libraries inGroovyLab

object instances but the classic import static Java facility canbe used to import the appropriate static methods

6 The Scala Interpreter and the Groovy Shell

An essential component of Scalarsquos scripting framework isthe Scala interpreter The corresponding component in theGroovy scripting framework is the GroovyShell This sectiondiscusses and compares some aspects of these components(Figure 4)

The overall approach of the Scala interpreter is based oninitially compiling the requested code A Java classloader andJava reflection are then used to run the compiled bytecodeand access its results

In general Scalarsquos approach to scripting and Groovyrsquosapproach to scripting are similar Scalarsquos approach is morecomplicated than Groovyrsquos approach though Groovyrsquosscripting approach is based on detecting the undeclaredvariables of a script Groovy then declares them implicitlyas an Object and maintains their state in a binding structureimplemented by means of a Java hashtable The bindingscheme of Groovy is restricted to data variables and closuresIt is important that although GroovyShell does not keepobjects and classes it keeps closure objects Therefore thecomputationworkspace consists not only of data variables butalso of defined code This permits functional programmingwithin GroovyLab

In contrast the scheme implemented in the Scala inter-preter extracts the whole visible computation state as theinterpreterrsquos context ScalaLab binds both data and codeobjects automatically to this context Although this is morepowerful it imposes difficulties in retrieving the context whenwe create a new Scala interpreter In that case it is necessaryto replay the commands in order to restore the environmentHowever the restoration of the user environment in ScalaLabis performed fast the user does not notice the delay of the fewScala compiler runs Restoration of the computation contextalso is a somewhat rare operation

A single compiler instance is used in the Scalarsquos interpreterto accumulate all successfully compiled or interpreted Scalacode The interpretation of a line of code is performed bygenerating a new object that includes the line of code and haspublic members to export all variables defined by that code

The results of the interpreted lines are extracted by usinga second ldquoresult objectrdquo which imports the variables exported

by the above object and then exports a single member namedldquoresultrdquo To accommodate user expressions that are readfrom variables or methods defined in previous statementsldquoimportrdquo statements are used

It becomes evident that an effective approach for detect-ing the variables that a piece of code defines is requiredThe Scala interpreter utilizes the Scala parser to accomplishthe nontrivial task of analyzing variable visibility The Scalaparser is also utilized in order to detect which variables areused by a code snippet The values of these variables are thenrequested from previously executed code It is unnecessaryto request variables from the interpreter that do not appearin a new code snippet since these values will not change Forexample if prevVar = 55 is not used at our new script theinterpreter does not request the value of prevVar

At this point we should contrast the state managementof the Scala interpreter with the corresponding one ofthe GroovyShell GroovyShell automatically handles variablebinding and therefore it is much easier to handle the state ofvariables in GroovyLab

The Scala interpreter keeps a list of names of identifiersbound with a var or val declaration (boundVarNames) andalso a list of function identifiers definedwith a def declaration(boundDefNames) In addition we can retrieve the last textsource code of the program that has been interpreted (last-LineInterpreted)

We keep a symbol table of the current ScalaSci boundvariables This task is used to graphically display the currentwork context to the user We have to keep this externaltable synchronized with the internal variables binding thatthe interpreter keeps (ie boundVarValNames) The currentvalue of each variable is retrieved from the interpreter byissuing a simple command with the name of the variable

If an identifier is being redefined as a function then it isremoved from the variable bindingThis is necessary since thenamespace of variables and functions in Scala is common [2]and thus the identifier is hidden by the function definition

The corresponding task in the GroovyShell of displayingto the user the variablersquos workspace is much simpler in fact itonly requires a simple lookup into the hashtable binding

The GroovyShell lacks the ability to retain imports froma previously executed script This can be rather inconvenientin many cases since these same import statements must bemanually incorporated before executing code that depend onthem For that reason GroovyLab implements simple importbuffering that removes the tediousness of incorporating theimport statements explicitly each time a script is executed inGroovyLab

GroovyLab automatically incorporates some basicimport statements into the userrsquos scripts that extend thefunctionality These imports allow the user to utilize manyGroovyLab functions such as figure() and plot() The usercan also use a code buffer to retain code (both classes andscript code) for the current working session

7 Compile-Time Metaprogramming

Compile-time metaprogramming allows intervening in thecompilation process and the implementation of customized


structures that do not impose any run-time overhead Thisis important in scientific scripting since it opens up pos-sibilities for implementing efficient convenient high-levelstructures

Both languages support compile-time metaprogram-ming Groovy with Abstract Syntax Tree (AST)mdashTransfor-mations and Scala with Scala Macros Abstract Syntax Trees(AST) keep a tree like representation of a program in whichinterior nodes represent programming constructs [11] Scalamacros have not been utilized in ScalaLab yet (actually theyare used only to provide a C style for loop) so the discussionof compile-time metaprogramming will be limited to anexploration of Groovyrsquos compile-time metaprogrammingsupport

Compile-Time Metaprogramming in Groovy Run-time met-aprogramming provides the ability to modify class andinstance behavior at runtime Groovy provides compile-timemetaprogramming via AST transformations and compilationcustomizers to support altering the behavior of classes andobjects at compile time

AST transformations in Groovy come in two flavorslocal AST transformations and global AST transformationsLocal AST transformations are defined using annotations andare applied locally to a program element by annotating theelement whose AST is to be altered by the AST transforma-tion Global AST transformations are essentially provided asservices that are applied by the compiler to every class that isbeing compiled Local AST annotations aremore widely usedthan global AST transformations

Groovy implements some predefined local AST transfor-mations Examples include the Immutable AST transfor-mation that generates code to make a class immutable andthe Log AST transformation which injects a logger into aclass Of specific interest to GroovyLab is theCompileStaticAST transformation This AST transformation is applied toGroovy code that is known not to utilize Groovyrsquos dynamicprogramming capabilities When the CompileStatic ASTtransformation is applied to a method the compiler checksto see that the source code can indeed be statically compiledand bypasses Groovyrsquos dynamic dispatch for methods thatare invoked within the method implementation This abilityto bypass dynamic dispatch can have a marked impact onperformance which is of the utmost importance in scientificcomputing We should note that the recent versions ofthe Groovy compiler automatically avoid dynamic dispatchin simple numerical loops thus in such cases Groovyrsquosperformance is similar to JavaScala even without the staticcompilation annotation

GroovyLab also provides theCompileJava AST transfor-mation This transformation is applied only to methods andessentially compiles the method directly into Java bytecodeThe code is compiled as it appears in the Groovy sourcecode so the source code of the annotated method must bevalid Java and must be completely self-contained (ie it mustessentially be a static method that contains no referencesto class attributes) The CompileJava AST transformationprovides the ability to execute Java code from within a

GroovyLab script both for efficiency and as a preferredchoice

Groovy also provides the ability to modify the behaviorof the compiler using compilation customizers Compilationcustomizers are applied by the compiler to the AST corre-sponding to every class that is being compiled They differfrom global AST transformations in that customizers areeasier to define than global AST transformations GroovyLabuses a compilation customizer to convert BigDecimal literalsto primitive double to improve performance

8 Performance

Groovy was initially considered a slow language Groovy 15was about 200 to 1000 times slower than Java in performingnumber calculations The implementers of the language haveperformed impressive performance improvements in recentversions of Groovy though A clever implementation of call-site caching in Groovy 16 has reduced the performance gapbetweenGroovy and Java to Groovy being about 20ndash50 timesslower than Java Special handling of primitive operations asdirect bytecode rather than via dynamic dispatch using theMetaObject protocol has provided significant performancegains primarily because these optimizations can be appliedat compile time In many cases Groovy with compiledcomputational loops and primitive operations runs as fastas Java code (since both emit direct bytecodes) StaticallycompiledGroovy amode of theGroovy compiler introducedwith Groovy 20 produces statically compiled code that isas fast as Java but requires sacrificing the dynamic featuresof the Groovy language in the source code that is to bestatically compiled Therefore this mode is most suitablefor computationally intensive methods Groovy 20 alsoexploits the JDK7 invoke-dynamic bytecode and the relatedframework that supports the compilation of dynamic codeHowever in the current release of Groovy 24 the invokedynamic implementation improved a lot related to Groovy20 Generally code that is compiled with Groovyrsquos invokedynamic support currently runs somewhat slower than thecode that optimizes primitive operations The speed differ-ence is constantly decreased on each new Groovy releaseAs both the invoke dynamic support in Groovy improvesand Java Virtual Machine implementations better supportthe invoke dynamic instruction the static compilation andprimitive optimizations features of Groovy become of lessimportance

GroovyLab is designed with the goal in mind of perform-ing fast numeric calculations For example all of the mainmathematical operations in GroovyLab are implemented inpure Java for the sake of efficiency The important Matrixclass is also implemented in Java but it implements theGroovyObjectSupport interface in order to allow flexibleoverloaded operator syntax for example to use119860+119861 insteadof something like the cumbersome method Aplus(B) to addmatrices The Matrix class also supports many of operationsthat make use of the native BLAS This is accomplished withthe JBLAS library (httpmikiobraungithubiojblas)


Table 1

ScalaLab MATLAB SciLab GroovyLab

Speed

Very fast execution speeddepends on the Java

runtime generally fasterthan MATLAB at scriptcode but slower for

routines implemented asbuilt-in with MATLAB

Very fast especially thebuilt-in routines which arehighly optimized overall

ScalaLab and MATLAB runat comparable speeds andwhich one outperformsdepends on the case

Much slower than ScalaLab(or MATLAB) about 20 to100 times slower Newer

versions of SciLabhowever improved a lotspeed differences are now

about 3 to 10 times

Slower than ScalaLababout 2 to 5 times slowerHowever with staticallytyped blocks of code

performance is at about thesame level as JavaScala

Portability Very portable anywhereexists installed Java 8 JRE

There exist versions foreach main platform for

example Windows LinuxMacOS



Very portable anywhereexists installed Java 8 JRE

Open source Yes No Yes YesUser-friendliness Very user friendly Very user friendly Very user friendly Very user friendly

Librariestoolboxavailability All the JVM libraries

A lot of toolboxes areavailable but generally not

free

There exist toolboxes forbasic applications but forspecialized ones it is

difficult to find

All the JVM libraries

Documentation

Little yet and limited toon-line help since even

main code components arein the development process

Extensive documentation Sufficient documentation On-line documentationonly

Flexibility of thelanguage (ie syntaxmalleability)

The Scala language isdesigned to be flexible andwith very malleable syntax

The syntax of MATLAB isnot designed to be

extensible

SciLab is not designed to beextensible

The Groovy language isdynamic and different

tricks from the Scalarsquos casecan form customizable

syntax

Development of largeapplications

Scala has a lot of novelfeatures that can facilitatethe development of largeapplications ScalaLabapplications can run

standalone as any Java code

The notion ofMATLABPATH integratesmany MATLAB scripts

something not very scalable

Similar to MATLAB theSciLab scripts are not well

suited for complexapplications but rather

they fit well for rapid testingof scientific algorithms

Groovy has a full compilerthat can be used to producestandalone code of a large

application project

Active userdevelopmentcommunity

ScalaLab is a new projectand thus up-to-now lacks a

large user base

MATLAB has a huge userbase

SciLab has a large userbase however much

smaller than MATLABrsquos

GroovyLab is a new projectand thus up-to-now lacks a

large user base

Another performance pitfall with Groovy is the prefer-ence of theGroovy compiler to performdefaultmathematicalcalculations with BigDecimals objects Groovy is a flexibleextensible language that allows GroovyLab to bypass thatconstraint by performing a compile-time metaprogrammingtransformation These transformations are a powerful toolto modify the AST representation of the source code that isgenerated during compilation before bytecode is generatedfrom it for execution Since the AST modifications areperformed by the compiler during compilation there is norun-time performance penalty that results from applying theAST modifications

In case of ScalaLab the Scala language is statically typedand therefore Scala code can theoretically be compiled tobytecode that runs as fast as Java sometimes a bit faster some-times a bit slower depending on the situation However forthe advanced features of Scala such as pattern matching traitinheritance and type parameters it is difficult to optimize

their compilationThe Scala language developers concentrateon these issues and improve the performance of the Scalacompiler with each new version of the language

Table 1 compares characteristics of ScalaLab MATLABSciLab and GroovyLab SciLab (httpwwwscilaborg) is anopen source system similar to MATLAB

Wewould note that the performance of the recent versionof MATLAB (2012b) has been impressively improved whileSciLab has been improved also but not so much

9 Benchmarking

In order to access the performance of the GroovyLab andScalaLab platforms a variety of mathematical computationalgorithms will be examined These will include matrixcomputations Fast Fourier Transforms (FFT) eigen decom-position of a matrix and singular value decomposition of amatrix


119873 = 2000119872 = 2000119905119894119888

119886 = rand(119873119872)119904119898 = 00for 119903 = 1 119873119904119898 = 00for 119888 = 1 119872119886(119903 119888) = 10(119903 + 119888 + 1)119904119898 = 119904119898 + 119886(119903 119888) minus 78 lowast 119886(119903 119888)

endend119905119898 = 119905119900119888

Algorithm 5 Array access benchmark in MATLAB

91 Matrix Computation Benchmarking In order to accessthe efficiency of matrix processing in GroovyLab andScalaLab implementations of the MATLAB script ofAlgorithm 5 are used

For the ScalaLab version of this script ScalaLab clearlyoutperforms both MATLAB and SciLab GroovyLab hassimilar speed when the static compilation is used Withthe implementation of optimized primitive operations (ielater versions of Groovy produce fast code for arithmeticoperations since they avoid the overhead of the metaobjectprotocol) and with the later invoke dynamic implementationGroovy generally is slightly slower than Scala The reasonfor the superiority of ScalaLab in terms of scripting speed isclearly the statically typed design of the Scala language thatpermits the emission of efficient Java bytecode

92 Fast Fourier Transform Benchmark The Fast FourierTransform (FFT) benchmark is performed in ScalaLab usingimplementations of the FFT from various libraries

Of these libraries the Oregon DSP library provides thebest performance Close in performance to this libraryis the JTransforms (httpssitesgooglecomsitepiotrwen-dykiersoftwarejtransforms) library Since JTransforms ismultithreaded and it will accordingly perform more effi-ciently with more robust machines (eg having 8 or 32 coresinstead of only 4) The tutorial FFT implementation of theclassic Numerical Recipes book [12] (with the CC++ codetranslated to Java) was also observed to achieve reasonableperformance in ScalaLab Interestingly it was observed thatthe Oregon DSP and JTransforms FFT routines are nearlyas fast as the optimized built-in FFT of MATLAB Weshould note that the reported differences in benchmarks arestable for example the relative differences are about thesame on different computers and individual runs show smallvariations at the results Contributing to the small variabilityis that we perform explicitly garbage collection before anybenchmark run

93 Other Benchmarks Other types of problems such asthe eigen decomposition singular value decomposition andsolution of overdetermined systems were examined for the

purposes of obtaining GroovyLab and ScalaLab benchmarksThe general conclusion is that ScalaLab is faster than SciLab521 by about 3 to 5 times but is slower than MATLAB 71by about 2 to 3 times It is also evident that the routinesof JLAPACK for special matrix categories run orders ofmagnitude faster than routines for general matrices forexample for a 1500 by 1500 band matrix with 2 bands aboveand 3 bands below the main diagonal the JLAPACKrsquos SVDroutines run about 250 times faster than for a general 1500 by1500 matrix

Table 2 summarizes some basic performance results Weshould note that often ScalaLab and GroovyLab performequally well since they call the same Java library routines

Recent MATLAB versions have improved impressivelythe performance of Matrix multiplication and of manyimportant routines as for example the SVD computationHowever both ScalaLab and GroovyLab offer the poten-tial to issue commands to the MATLAB engine using theJavaMATLAB interface Similarly SciLab scripts can beexecuted using the JavaSciLab interface The wiki pages ofthe ScalaLab and GroovyLab projects describe details andprovide examples of these interfacings

94 Native Code Optimizations In order to test the JVMperformance versus native code performance an implemen-tation of SVD is used [see httpcodegooglecompscalalabwikiScalaLabVsNativeC] Both the Microsoftrsquos cl compilerof Visual Studio on Windows 8 64-bit and the gcc compilerrunning on Linux 64-bit were used ScalaLab is based on theJava runtime version 170 25 and Scala 211M7 and Groovy-Lab on Groovy 221 Again both ScalaLab and GroovyLabperform similarly since they are based on the same Java codeIt has been observed that ScalaLab and GroovyLab performbetter than unoptimized C and are even close to optimizedC code when performing matrix calculations Table 3 showssome results

10 Conclusions and Future Work

This paper compares some aspects of ScalaLab and Groovy-Lab which are both environments for scientific computingthat run within the Java Virtual Machine framework Itwas demonstrated that both environments can effectivelyutilize existing Java scientific software Both can elegantlyintegrate well-known Java numerical analysis libraries forbasic tasksThese libraries are wrapped by either Scala objectsin ScalaLab or Groovy objects in GroovyLab and their basicoperations are provided to the userwith a uniformMATLAB-like interface

An extension of Scala with MATLAB-like constructscalled ScalaSci is the language of ScalaLab and the corre-sponding language of GroovyLab is GroovySci Both lan-guages are effective and convenient for both writing smallscripts and for developing large production-level applica-tions

The design of the user interface of ScalaLab and Groovy-Lab is similar Both emphasize user friendliness and provideintegrated development environment- (IDE-) like features


Table 2 Results of some basic benchmarks

ScalaLab (secs) SciLab 521 (secs)SciLab 55

MATLAB 71 (secs)MATLAB 2012b GroovyLab (secs)

Matrix multiplication withmatrix sizes(2000 2500) times (2500 3000)

09 secs using Native BLAScombined with Javamultithreading

618 505 1305 06 The same withScalaLab

LU1000 03 313 242 036 003 The same as ScalaLab1500 12 382 21 118 004 As ScalaLab2000 29 642 16 272 009 As ScalaLabinv1000 27 1297 16 13 005 As ScalaLab1500 78 1314 25 45 015 As ScalaLab2000 931 1907 32 59 03 As ScalaLabQR1000 103 43 42 12 004 As ScalaLab1500 37 996 99 426 02 As ScalaLab2000 925 1969 193 989 03 As ScalaLab

Matrix access scriptingbenchmark 003 3216 3267 1058 032

0031 staticcompilation

0156 with primitiveops

0211 with invokedynamic

FFT100ffts of 16384 sized signal

Oregon DSPreal case 005complex case 0095JTransformsreal case 007complex case 011Apache CommonMathscomplex case 05Numerical Recipes (JavaTranslation)real case 009complex case 012

Real case 232Complex case 42


The Java libraries forFFT are the same as

ScalaLabrsquos

Table 3 SVD performance Java versus native C code

Matrix size Optimized C (gcc similar is for cl) ScalaLabGroovyLab Unoptimized C (gcc similar is for cl)200 times 200 008 015 034200 times 300 017 02 061300 times 300 034 058 123500 times 600 375 506 813900 times 1000 354 513 533

such as on-line help code completion graphical control ofthe class-path and a specialized text editorwith code coloringfacilities that greatly facilitate the development of scientificsoftware

Future work will concentrate on improving the inter-faces to Java basic libraries and on incorporating smoothlyother interested libraries (eg the parallel COLT libraryfor basic linear algebra the JCUDA library for support-ing the CUDA massively parallel computing framework

on NVIDIA graphics cards) Both ScalaLab and Groovy-Lab explore the symja Java Computer Algebra system(httpscodegooglecompsymja)This system implementsa wide range of Computer Algebra facilities Further work isin progress for making work with Computer Algebra easierThis work will include providing better on-line help and codecompletion for these routines These components are of theutmost importance in incorporating this rather complicatedlibraries into ScalaLab and GroovyLab


Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper

References

[1] S Papadimitriou K Terzidis SMavroudi and S LikothanassisldquoScalaLab an effective scientific programming environmentfor the Java Platform based on the Scala object-functionallanguagerdquo IEEE Computing in Science and Engineering vol 13no 5 Article ID 5487486 pp 43ndash55 2011

[2] M Odersky L Spoon and B Venners Programming in ScalaArtima 2008

[3] D Konig A Glover P King G Laforge and J SkeetGroovy imEinsatz Manning Publications 2007

[4] S Papadimitriou K Terzidis SMavroudi and S LikothanassisldquoScientific scripting for the java platform with jlabrdquo Computingin Science and Engineering vol 11 no 4 pp 50ndash60 2009

[5] H T Lau A Numerical Library in Java for Scientists andEngineers Chapman amp HallCRC Boca Raton Fla USA 2003

[6] T A Davis Direct Methods for Sparse Linear Systems SIAMPublishing Philadelphia Pa USA 2006

[7] G Dubochet ldquoOn Embedding domain-specific languages withuser-friendly syntaxrdquo in Proceedings of the 1st Workshop onDomain Specific Program Development pp 19ndash22 NantesFrance July 2006

[8] G Dubochet Embedded domain-specific languages usinglibraries and dynamic metaprogramming [PhD thesis] EcolePolytechnique Federale de Lausanne Lausanne Switzerland2011

[9] D Wampler and A Payne Programming Scala OrsquoReilly 2009[10] V Subramaniam Programming Scala Tackle Multi-Core Com-

plexity on the Java Virtual Machine Pragmatic Bookself 2009[11] A Aho M S Lam R Sethi and J D Ullman Compilers

Principles Techniques amp Tools Addison-Wesley Boston MassUSA 2nd edition 2007

[12] WH Press S A TeukolskyW T Vetterling and B P FlanneryNumerical Recipes in C The Art of Scientific ComputingCambridge University Press Cambridge UK 2002

Submit your manuscripts athttpwwwhindawicom

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014


Distributed Sensor Networks


Advances in

FuzzySystems

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014


ReconfigurableComputing

Hindawi Publishing Corporation httpwwwhindawicom Volume 2014


Applied Computational Intelligence and Soft Computing

thinspAdvancesthinspinthinsp

Artificial Intelligence

HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014

Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014


Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications


Hindawi Publishing Corporation

httpwwwhindawicom Volume 2014

Advances in

Multimedia


Biomedical Imaging


ArtificialNeural Systems

Advances in


RoboticsJournal of



Computational Intelligence and Neuroscience

Industrial EngineeringJournal of


Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014


Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in




numerical analysis



Import wizard


Use

r frie

ndly

scrip

ting

base

d in

terfa

ce

Scala compiler

ScalaSci domainspecific language

Java compiler

Scala interpreter

Figure 1 The architecture of the main software components ofScalaLab

Groovy compiler

GroovySci domainspecific language

Java compiler

Groovy shell


numerical analysis



Import wizard


Use

r frie

ndly

scrip

ting

base

d in

terfa

ce

Figure 2 The architecture of GroovyLab

GroovyLab is essentially a redesign of jLab that is based onthe Groovy scripting language which proves to be superiorto the various scripting modes provided by jLab (j-scriptJavaSci GroovySci compiled j-script mode) In a few wordsthe GroovySci scripting mode of jLab proved much superiorand GroovyLab was developed by improving that mode andremoving the others as somewhat redundant HistoricallyScalaLab was developed in parallel with GroovyLab as asimilar environment using the powerful statically typed Scalalanguage

In this paper some important similarities and differencesbetween ScalaLab andGroovyLab will be examinedThe userinterfaces of the two systems are similar Also the exploitedJava scientific libraries and native code high performancelibraries are the same The major differences emerge whencode is developed for these systems They present differentscripting languages for writing applications and are also verydifferent when designing and implementing libraries

The paper proceeds as follows Initially the frameworksfor developing matrix libraries in Scala and in Groovy willbe examined (Section 2) Next the implementation of high-level mathematical operators in ScalaLab and GroovyLabis discussed (Sections 3 and 4) The functional program-ming abilities of the two environments are then brieflyexamined (Section 5) Both systems provide the user withflexible scripting environments the main features of theseenvironments are then compared (Section 6) Compile-timemetaprogramming is a powerful feature offered both byGroovy and Scala an example is then presented to demon-strate how compile-time metaprogramming can be usedto expand the syntax of GroovyLab without any run-timeperformance penalties (Section 7) A few aspects of theScalaLab and GroovyLab environments that are importantfor scientific computation are then presented and comparedNext performance related issues are discussed and bench-marking results are presented (Section 8) Finally the paperconcludes with remarks concerning the relative strengths andweakness of each system

2 Matrix Design in ScalaLab and GroovyLab

In this section some main features of the Scala and Groovylanguages that are used to facilitate the utilization of theJava scientific libraries are described and compared Thesefeatures are presented in the context of providing supportfor a MATLAB-like syntax for matrix manipulation andthe utilization of underlying Java libraries to provide theimplementation of the matrix functionality

21 Matrices in ScalaLab The general architecture for inter-facing with Java libraries in ScalaLab is illustrated in Figure 3Below we describe these components

211 The Java Library The Java library module in Figure 3corresponds to the Java code of the library that performs themain numerical calculations Some examples of the Javalibraries are the EJML library (httpscodegooglecompefficient-java-matrix-library) the Apache Common Maths(httpcommonsapacheorgpropercommons-math) andthe MTJ (Matrix toolkits for Java httpsgithubcomfommilmatrix-toolkits-java) It should be noted that the Scalainterpreter can also use the native Java interface of eachlibrary

212 The Wrapper Scala Class (WSC) The Wrapper ScalaClass (WSC) aims to provide a simpler interface to themore essential functionality of the Java library for examplematrices 119860 and 119861 can be simply added as 119860 + 119861 rather thaninvoking the cumbersome Aplus(B) The wrapper Scala class


Java library


Wrapper scala class

Scal

a int

erpr

eter

RichDouble2DArray























smget(row col)

Algorithm 1







var t = 0002459






Algorithm 2

x = rand(50 100)

row = 5 col = 2


xrb = x[(120)by(2) (130)by(3)] like x(1220 1330)

x[(140)by(5) 12] = 44

Algorithm 3






















var a = 20 + rand(22)









RichDouble2DArray



proceeds normally











double [] m -gt


res =


res

Algorithm 4






















Java library

Gro

ovy

shel

l






























8 Performance




Table 1


Speed








about 3 to 10 times












free


difficult to find


Documentation







extensible




syntax










application project



large user base





large user base






9 Benchmarking



119873 = 2000119872 = 2000119905119894119888


endend119905119898 = 119905119900119888
































ScalaLabrsquos









References




















Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in




Java library


Wrapper scala class

Scal

a int

erpr

eter

RichDouble2DArray























smget(row col)

Algorithm 1







var t = 0002459






Algorithm 2

x = rand(50 100)

row = 5 col = 2


xrb = x[(120)by(2) (130)by(3)] like x(1220 1330)

x[(140)by(5) 12] = 44

Algorithm 3






















var a = 20 + rand(22)









RichDouble2DArray



proceeds normally











double [] m -gt


res =


res

Algorithm 4






















Java library

Gro

ovy

shel

l






























8 Performance




Table 1


Speed








about 3 to 10 times












free


difficult to find


Documentation







extensible




syntax










application project



large user base





large user base






9 Benchmarking



119873 = 2000119872 = 2000119905119894119888


endend119905119898 = 119905119900119888
































ScalaLabrsquos









References




















Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in














smget(row col)

Algorithm 1







var t = 0002459






Algorithm 2

x = rand(50 100)

row = 5 col = 2


xrb = x[(120)by(2) (130)by(3)] like x(1220 1330)

x[(140)by(5) 12] = 44

Algorithm 3






















var a = 20 + rand(22)









RichDouble2DArray



proceeds normally











double [] m -gt


res =


res

Algorithm 4






















Java library

Gro

ovy

shel

l






























8 Performance




Table 1


Speed








about 3 to 10 times












free


difficult to find


Documentation







extensible




syntax










application project



large user base





large user base






9 Benchmarking



119873 = 2000119872 = 2000119905119894119888


endend119905119898 = 119905119900119888
































ScalaLabrsquos









References




















Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in






Algorithm 2

x = rand(50 100)

row = 5 col = 2


xrb = x[(120)by(2) (130)by(3)] like x(1220 1330)

x[(140)by(5) 12] = 44

Algorithm 3






















var a = 20 + rand(22)









RichDouble2DArray



proceeds normally











double [] m -gt


res =


res

Algorithm 4






















Java library

Gro

ovy

shel

l






























8 Performance




Table 1


Speed








about 3 to 10 times












free


difficult to find


Documentation







extensible




syntax










application project



large user base





large user base






9 Benchmarking



119873 = 2000119872 = 2000119905119894119888


endend119905119898 = 119905119900119888
































ScalaLabrsquos









References




















Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in













var a = 20 + rand(22)









RichDouble2DArray



proceeds normally











double [] m -gt


res =


res

Algorithm 4






















Java library

Gro

ovy

shel

l






























8 Performance




Table 1


Speed








about 3 to 10 times












free


difficult to find


Documentation







extensible




syntax










application project



large user base





large user base






9 Benchmarking



119873 = 2000119872 = 2000119905119894119888


endend119905119898 = 119905119900119888
































ScalaLabrsquos









References




















Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in







double [] m -gt


res =


res

Algorithm 4






















Java library

Gro

ovy

shel

l






























8 Performance




Table 1


Speed








about 3 to 10 times












free


difficult to find


Documentation







extensible




syntax










application project



large user base





large user base






9 Benchmarking



119873 = 2000119872 = 2000119905119894119888


endend119905119898 = 119905119900119888
































ScalaLabrsquos









References




















Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in






Java library

Gro

ovy

shel

l






























8 Performance




Table 1


Speed








about 3 to 10 times












free


difficult to find


Documentation







extensible




syntax










application project



large user base





large user base






9 Benchmarking



119873 = 2000119872 = 2000119905119894119888


endend119905119898 = 119905119900119888
































ScalaLabrsquos









References




















Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in












8 Performance




Table 1


Speed








about 3 to 10 times












free


difficult to find


Documentation







extensible




syntax










application project



large user base





large user base






9 Benchmarking



119873 = 2000119872 = 2000119905119894119888


endend119905119898 = 119905119900119888
































ScalaLabrsquos









References




















Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in




Table 1


Speed








about 3 to 10 times












free


difficult to find


Documentation







extensible




syntax










application project



large user base





large user base






9 Benchmarking



119873 = 2000119872 = 2000119905119894119888


endend119905119898 = 119905119900119888
































ScalaLabrsquos









References




















Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in




119873 = 2000119872 = 2000119905119894119888


endend119905119898 = 119905119900119888
































ScalaLabrsquos









References




















Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in




















ScalaLabrsquos









References




















Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in






References




















Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in










Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in



research article scalalab and groovylab: comparing scala...

Documents