Lightweight Abstraction Lightweight Abstraction for Mathematical for Mathematical Computation Computation in Javain Java
1
Pavel Bourdykine and Stephen M. Watt
Department of Computer ScienceWestern University London Ontario, Canada
CASC 2012Maribor, Slovenia3-6 September 2012
The ContextThe ContextModern programming languages
allow the creation of new abstractions ◦Hide implementation details◦Eliminate programming errors◦Allow future changes
Z/5Z is different from intZ/5Z [x] is different from int[ ]
2
The ProblemThe ProblemIn the popular scientific programming
languages, these mechanisms aren’t good enough.
In C++, typedef doesn’t create a distinct type.
In Java, adding a class abstraction is very costly.
3
The ProblemThe ProblemIn symbolic mathematical computing,
we often have a great many small values.
E.g. ◦Poly coeffs in Z mod small prime◦Packed exponent vectors
Extra storage allocation.Several 100% overhead.
4
The ProblemThe ProblemSo libraries writers cheat….Compromise abstractions….Circumvent the system ….
The standard Java libraries use intand long values to represent
◦Colours, Layout strategies, Border types, etc
instead of abstract types.
I.e. language features aren’t good enough.
5
Swing, undermining Swing, undermining abstractionabstraction
static Integers representing
different properties
ints representing different
parameters
Swing, undermining Swing, undermining abstractionabstraction
legal, but does not necessarily make
sense
same arguments,
different meaningsWould like to DISTINGUISH
between layer and position!
Why?Why?Machine-supported data types, such as
single- and double-word integers and floating point numbers are primitive types in Java, and specially handled.◦ No storage allocation◦ No “object” overhead (synchronization, etc)
User-defined types must be classes inheriting from “Object”, with all the associated overhead.
8
Why?Why?Primitive type:
Defined Java type:
Problem multiplies with vectors of these things.
Idea!Idea!Use the Java type system for
correctness,then
Compile using primitive types.
10
Approach: ObjectivesApproach: Objectives
Combine type-safety and low costImprove performance without
crippling safety and expressive powerIt is about opacityFramework for a straight forward
construction◦ easy to use◦ noticeable benefits
Approach: PracticeApproach: Practice
Want: objects that perform like primitive types◦ combine the two!
Allow class derivation, inheritance, virtualization◦ i.e. object properties◦ WITHOUT the heavy overhead
Want to avoid allocation but keep the type safety
Works with ANY underlying type!This layer of abstraction does not require its
own inheritance structure!
What we would likeWhat we would like
new objects
method arguments no longer
ambiguous
But achieve this without losing performance and rewriting library functions!
Approach: Rules and Approach: Rules and RestrictionsRestrictionsTo keep object properties need to
◦ keep representation field protected◦ follow Object-Oriented guidelines
Result: Type-check the objects by name
To boost performance and eliminate overhead◦ keep constructor(s) private◦ make methods public static
Result: Implement using underlying type
Approach: Rules and Approach: Rules and RestrictionsRestrictionsSummary:Rule 1 Object must have a single protected field of the underlying type, unless it is a subclass of an opaque type (and then must have no fields).
Rule 2 Any object constructors must be declared private.
Rule 3 All methods accessing or modifying the underlying type field representation must be declared static.
Approach: Approach: ImplementationImplementationAnnotate opaque classes
◦ @Opaque(“type”) annotationType-check regular objectsConvert annotated classes to use
underlying type representationCompile the fast versions
Converter implemented in JavaBuilding process automated by Ant
Code TransformationCode Transformation
Annotated opaque class
Code TransformationCode Transformation
Converted opaque class
Compilation ProcessCompilation Process
Annotated code is analyzed and types recorded.
All occurrences of opaque types are substituted with the underlying representation.
New code is compiled.
Process is automated using Ant.◦ Compiles original code for type checking.◦ Backs up the original code, converts it.◦ Calls compiler again on converted code.
19
PerformancePerformance
Test performance in terms of execution speed & memory use
Test a variety of uses and declarations◦cover a wide range of possible
applicationsMeasure:
regular code
opaque annotated code
converted code
vs.
vs.
Performance: Example IPerformance: Example I
Usual Definition:
Usage:
Performance: Example IPerformance: Example I
Opaque Definition:
Usage:
Performance: Example I Performance: Example I (time)(time)
Opaque types execute about twice as fast
Performance: Example I Performance: Example I (space)(space)
Opaque types are able to reside entirely on the stack, i.e. no allocation is needed
Performance: Example IIPerformance: Example II
Regular class:
Performance: Example IIPerformance: Example II
Opaque class:
Performance: Example IIPerformance: Example II
Opaque class usage:
Regular class usage:
Performance: Example II Performance: Example II (time)(time) Opaque objects execute 12-15 times
faster
Performance: Example II Performance: Example II (space)(space)Even before conversion to underlying type
opaque types use 10-12 times less memory
Performance: Example IIPerformance: Example II
Opaque class:
Performance: Example IIPerformance: Example II
Converted opaque class:
Performance: Example II Performance: Example II (time)(time)
Converted (to long[]) opaque types execute 20-25 times faster
Performance: Example II Performance: Example II (space)(space)
Converted (to long[]) opaque types use over 15 times less memory
ConclusionsConclusions
Successfully implemented structures that are type safe and perform as machine types.
Code conversion and build process are automated.
Performance is well worth the restrictions.
Sufficient for computer algebra.
Performance – native levels achieved.
Safety – maintained.
Future workFuture work
Implement Java generics◦ Cover all Java language features
Algebra library using opaque types
Native implementation?
