Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
2Activity
0 of .
Results for:
No results containing your search query
P. 1
Loop Recognition in C++/Java/Go/Scala

Loop Recognition in C++/Java/Go/Scala

Ratings: (0)|Views: 421 |Likes:
Published by Jeff Pratt

More info:

Published by: Jeff Pratt on Jun 03, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

06/03/2011

pdf

text

original

 
Loop Recognition in C++/Java/Go/Scala
Robert Hundt
Google1600 Amphitheatre ParkwayMountain View, CA, 94043rhundt@google.com
 Abstract
—In this experience report we encode a well specified,compact benchmark in four programming languages, namelyC++, Java, Go, and Scala. The implementations each use thelanguages’ idiomatic container classes, looping constructs, andmemory/object allocation schemes. It does not attempt to exploitspecific language and run-time features to achieve maximumperformance. This approach allows an almost fair comparisonof language features, code complexity, compilers and compiletime, binary sizes, run-times, and memory footprint.While the benchmark itself is simple and compact, it em-ploys many language features, in particular, higher-level datastructures (lists, maps, lists and arrays of sets and lists), a fewalgorithms (union/find, dfs / deep recursion, and loop recognitionbased on Tarjan), iterations over collection types, some objectoriented features, and interesting memory allocation patterns.We do not explore any aspects of multi-threading, or higher leveltype mechanisms, which vary greatly between the languages.The benchmark points to very large differences in all examineddimensions of the language implementations. After publication of the benchmark internally at Google, several engineers producedhighly optimized versions of the benchmark. We describe manyof the performed optimizations, which were mostly targeting run-time performance and code complexity. While this effort is ananecdotal comparison only, the benchmark, and the subsequenttuning efforts, are indicative of typical performance pain pointsin the respective languages.
I. I
NTRODUCTION
Disagreements about the utility of programming languagesare as old as programming itself. Today, these “language wars”become increasingly heated, and less meaningful, as morepeople are working with more languages on more platformsin settings of greater variety, e.g., from mobile to datacenters.In this paper, we contribute to the discussion by imple-menting a well defined algorithm in four different languages,C++, Java, Go, and Scala. In all implementations, we use thedefault, idiomatic data structures in each language, as well asdefault type systems, memory allocation schemes, and defaultiteration constructs. All four implementations stay very closeto the formal specification of the algorithm and do not attemptany form of language specific optimization or adaption.The benchmark itself is simple and compact. Each imple-mentation contains some scaffold code, needed to constructtest cases allowing to benchmark the algorithm, and theimplementation of the algorithm itself.The algorithm employs many language features, in partic-ular, higher-level data structures (lists, maps, lists and arraysof sets and lists), a few algorithms (union/find, dfs / deeprecursion, and loop recognition based on Tarjan), iterationsover collection types, some object oriented features, andinteresting memory allocation patterns. We do not explore anyaspects of multi-threading, or higher level type mechanisms,which vary greatly between the languages. We also do notperform heavy numerical computation, as this omission allowsamplification of core characteristics of the language implemen-tations, specifically, memory utilization patterns.We believe that this approach highlights features and charac-teristics of the languages and allows an almost fair comparisonalong the dimensions of source code complexity, compilersand default libraries, compile time, binary sizes, run-times, andmemory footprint. The differences along these dimensions aresurprisingly large.After publication of the benchmark internally at Google,several engineers produced highly optimized versions of thebenchmark. We describe many of the performed optimizations,which were mostly targeting run-time performance and codecomplexity. While this evaluation is an anecdotal comparisononly, the benchmark itself, as well as the subsequent tuningefforts, point to typical performance pain points in the respec-tive languages.The rest of this paper is organized as follows. We brieflyintroduce the four languages in section II. We introduce thealgorithm and provide instructions on how to find, build, andrun it, in section III. We highlight core language propertiesin section IV, as they are needed to understand the imple-mentation and the performance properties. We describe thebenchmark and methodology in section V, which also containsthe performance evaluation. We discuss subsequent languagespecific tuning efforts in section VI, before we conclude.II. T
HE CONTENDERS
We describe the four languages by providing links to thethe corresponding wikipedia entries and cite the respectivefirst paragraphs from wikipedia. Readers familiar with thelanguages can skip to the next section.
C++
[7] is a statically typed, free-form, multi-paradigm,compiled, general-purpose programming language. It is re-garded as a ”middle-level” language, as it comprises a com-bination of both high-level and low-level language features.It was developed by Bjarne Stroustrup starting in 1979 atBell Labs as an enhancement to the C language and originallynamed C with Classes. It was renamed C++ in 1983.
 Java
[9] is a programming language originally developedby James Gosling at Sun Microsystems (which is now a sub-
 
sidiary of Oracle Corporation) and released in 1995 as a corecomponent of Sun Microsystems’ Java platform. The languagederives much of its syntax from C and C++ but has a simplerobject model and fewer low-level facilities. Java applicationsare typically compiled to byte-code (class file) that can run onany Java Virtual Machine (JVM) regardless of computer ar-chitecture. Java is a general-purpose, concurrent, class-based,object-oriented language that is specifically designed to haveas few implementation dependencies as possible. It is intendedto let application developers ”write once, run anywhere”. Javais currently one of the most popular programming languagesin use, and is widely used from application software to webapplications.
Go
[8] is a compiled, garbage-collected, concurrent pro-gramming language developed by Google Inc. The initialdesign of Go was started in September 2007 by Robert Griese-mer, Rob Pike, and Ken Thompson, building on previous work related to the Inferno operating system. Go was officiallyannounced in November 2009, with implementations releasedfor the Linux and Mac OS X platforms. At the time of its launch, Go was not considered to be ready for adoptionin production environments. In May 2010, Rob Pike statedpublicly that Go is being used ”for real stuff” at Google.
Scala
[10] is a multi-paradigm programming language de-signed to integrate features of object-oriented programmingand functional programming. The name Scala stands for”scalable language”, signifying that it is designed to grow withthe demands of its users.Core properties of these languages are:
C++ and Go are statically compiled, both Java and Scalarun on the JVM, which means code is compiled toJava Byte Code, which is interpreted and/or compileddynamically.
All languages but C++ are garbage collected, where Scalaand Java share the same garbage collector.
C++ has pointers, Java and Scala has no pointers, and Gomakes limited use of pointers.
C++ and Java require statements being terminated with a’;’. Both Scala and Go don’t require that. Go’s algorithmenforces certain line breaks, and with that a certain codingstyle. While Go’s and Scala’s algorithm for semicoloninference are different, both algorithms are intuitive andpowerful.
C++, Java, and Scala don’t enforce specific coding styles.As a result, there are many of them, and many larger pro-grams have many pieces written in different styles. TheC++ code is written following Google’s style guides, theJava and Scala code (are trying to) follow the official Javastyle guide. Go’s programming style is strictly enforced– a Go program is only valid if it comes unmodified outof the automatic formatter
gofmt
.
Go and Scala have powerful type inference, makingexplicit type declarations very rare. In C++ and Javaeverything needs to be declared explicitly.
C++, Java, and Go, are object-oriented. Scala is object-oriented and functional, with fluid boundaries.
Fig. 1. Finding headers of reducible and irreducible loops. This presentationis a literal copy from the original paper [1]
III. T
HE
A
LGORITHM
The benchmark is an implementation of the loop recognitionalgorithm described in ”Nesting of reducible and irreducibleloops”, by Havlak, Rice University, 1997, [1]. The algo-rithm itself is an extension to the algorithm described R.E.Tarjan, 1974, Testing flow graph reducibility [6]. It furtheremploys the Union/Find algorithm described in ”Union/FindAlgorithm”, Tarjan, R.E., 1983, Data Structures and Network Algorithms [5].The algorithm formulation in Figure 1, as well as the var-ious implementations, follow the nomenclature using variablenames from the algorithm in Havlak’s paper, which in turnfollows the Tarjan paper.The full benchmark sources are availableas open-source, hosted by Google code at
http://code.google.com/p/
in the project
multi-language-bench
. The source les containthe main algorithm implementation, as well as dummy classesto construct a control flow graph (CFG), a loop structuregraph (LSG), and a driver program for benchmarking (e.g.,
LoopTesterApp.cc
).As discussed, after an internal version of this documentwas published at Google, several engineers created optimizedversions of the benchmark. We feel that the optimizationtechniques applied for each language were interesting andindicative of the issues performance engineers are facing intheir every day experience. The optimized versions are kept
 
src
README file and auxiliary scripts
src/cpp
C++ version
src/cpp_pro
Improved by Doug Rhode
src/scala
Scala version
src/scala_pro
Improved by Daniel Mahler
src/go
Go version
src/go_pro
Improved by Ian Taylor
src/java
Java version
src/java_pro
Improved by Jeremy Manson
src/python
Python version (not discussed here)
Fig. 2. Benchmark source organization (at the time of this writing, thecpp pro version could not yet be open-sourced)
non_back_preds
an array of sets of int’s
back_preds
an array of lists of int’s
header
an array of int’s
type
an array of char’s
last
an array of int’s
nodes
an array of union/find nodes
number
a map from basic blocks to int’s
Fig. 3. Key benchmark data structures, modeled after the original paper
in the
Pro
versions of the benchmarks. At time of this writing,the
cpp_pro
version depended strongly on Google specificcode and could not be open-sourced. All directories in Figure2 are found in the
havlak
directory.Each directory contains a
Makefile
and supports threemethods of invocation:
make # build benchmarkmake run # run benchmarkmake clean # clean up build artifacts
Path names to compilers and libraries can be overridden onthe command lines. Readers interested in running the bench-marks are encouraged to study the very short
Makefiles
formore details.IV. I
MPLEMENTATION
N
OTES
This section highlights a few core language properties, asnecessary to understanding the benchmark sources and per-formance characteristics. Readers familiar with the languagescan safely skip to the next section.
 A. Data Structures
The key data structures for the implementation of thealgorithm are shown in Figure 3. Please note again that weare strictly following the algorithm’s notation. We do not seek to apply any manual data structure optimization at this point.We use the non object-oriented, quirky notation of the paper,and we only use the languages’ default containers.
1) C++:
With the standard library and templates, these datastructures are defined the following way in C++ using stack local variables:
typedef std::vector<UnionFindNode> NodeVector;typedef std::map<BasicBlock*, int> BasicBlockMap;typedef std::list<int> IntList;typedef std::set<int> IntSet;typedef std::list<UnionFindNode*> NodeList;typedef std::vector<IntList> IntListVector;typedef std::vector<IntSet> IntSetVector;typedef std::vector<int> IntVector;typedef std::vector<char> CharVector;[...]IntSetVector non_back_preds(size);IntListVector back_preds(size);IntVector header(size);CharVector type(size);IntVector last(size);NodeVector nodes(size);BasicBlockMap number;
The size of these data structures is known at run-time andthe
std::
collections allow pre-allocations at those sizes,except for the map type.
2) Java:
Java does not allow arrays of generic types.However, lists are index-able, so this code is permissible:
List<Set<Integer>> nonBackPreds =new ArrayList<Set<Integer>>();List<List<Integer>> backPreds =new ArrayList<List<Integer>>();int[] header = new int[size];BasicBlockClass[] type =new BasicBlockClass[size];int[] last = new int[size];UnionFindNode[] nodes = new UnionFindNode[size];Map<BasicBlock, Integer> number =new HashMap<BasicBlock, Integer>();
However, this appeared to incur tremendous GC overhead.In order to alleviate this problem we slightly rewrite the code,which reduced GC overhead modestly.
nonBackPreds.clear();backPreds.clear();number.clear();if (size > maxSize) {header = new int[size];type = new BasicBlockClass[size];last = new int[size];nodes = new UnionFindNode[size];maxSize = size;}
Constructors still need to be called:
for (int i = 0; i < size; ++i) {nonBackPreds.add(new HashSet<Integer>());backPreds.add(new ArrayList<Integer>());nodes[i] = new UnionFindNode();}
To reference an element of the
ArrayLists
, the
get/set
methods are used, like this:
if (isAncestor(w, v, last)) {backPreds.get(w).add(v);} else {nonBackPreds.get(w).add(v);}
3) Scala:
Scala allows arrays of generics, as an array is justa language extension, and not a built-in concept. Constructorsstill need to be called:
var nonBackPreds = new Array[Set[Int]](size)var backPreds = new Array[List[Int]](size)var header = new Array[Int](size)var types =new Array[BasicBlockClass.Value](size)

Activity (2)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->