Lightweight abstraction for mathematical computation in java
This presentation is the property of its rightful owner.
Sponsored Links
1 / 35

Lightweight Abstraction for Mathematical Computation in Java PowerPoint PPT Presentation


  • 37 Views
  • Uploaded on
  • Presentation posted in: General

Lightweight Abstraction for Mathematical Computation in Java. Pavel Bourdykine and Stephen M. Watt Department of Computer Science Western University London Ontario, Canada. CASC 2012 Maribor, Slovenia 3-6 September 2012. The Context.

Download Presentation

Lightweight Abstraction for Mathematical Computation in Java

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Lightweight abstraction for mathematical computation in java

Lightweight Abstraction for Mathematical Computation in Java

PavelBourdykine and Stephen M. Watt

Department of Computer ScienceWestern University London Ontario, Canada

CASC 2012

Maribor, Slovenia

3-6 September 2012


The context

The Context

  • Modern programming languages allow the creation of new abstractions

    • Hide implementation details

    • Eliminate programming errors

    • Allow future changes

      Z/5Zis different from int

      Z/5Z [x]is different from int[ ]


The problem

The Problem

  • In 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.


The problem1

The Problem

  • In 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.


The problem2

The Problem

  • So libraries writers cheat….

  • Compromise abstractions….

  • Circumvent the system ….

  • The standardJava 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.


Swing undermining abstraction

Swing, undermining abstraction

static Integers representing different properties

ints representing different parameters


Swing undermining abstraction1

Swing, undermining abstraction

Would like to DISTINGUISH between layer and position!

legal, but does not necessarily make sense

same arguments, different meanings


Lightweight abstraction for mathematical computation in java

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.


Lightweight abstraction for mathematical computation in java

Why?

Primitive type:

Problem multiplies with vectors of these things.


Lightweight abstraction for mathematical computation in java

Idea!

  • Use the Java type system for correctness,then

  • Compile using primitive types.


Approach objectives

Approach: Objectives

  • Combine type-safety and low cost

  • Improve performance without crippling safety and expressive power

  • It is about opacity

  • Framework for a straight forward construction

    • easy to use

    • noticeable benefits


Approach practice

Approach: 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 like

What we would like

But achieve this without losing performance and rewriting library functions!

new objects

method arguments no longer ambiguous


Approach rules and restrictions

Approach: Rules and Restrictions

  • To 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 restrictions1

Approach: Rules and Restrictions

Summary:

  • Rule 1Object 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 2Any object constructors must be declared private.

  • Rule 3All methods accessing or modifying the underlying type field representation must be declared static.


Approach implementation

Approach: Implementation

  • Annotate opaque classes

    • @Opaque(“type”) annotation

  • Type-check regular objects

  • Convert annotated classes to use underlying type representation

  • Compile the fast versions

  • Converter implemented in Java

  • Building process automated by Ant


Code transformation

Code Transformation

Annotated opaque class


Code transformation1

Code Transformation

Converted opaque class


Compilation process

Compilation 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.


Performance

Performance

  • Test performance in terms of execution speed & memory use

  • Test a variety of uses and declarations

    • cover a wide range of possible applications

  • Measure:

regular code

vs.

opaque annotated code

vs.

converted code


Performance example i

Performance: Example I

Usual Definition:

Usage:


Performance example i1

Performance: Example I

Opaque Definition:

Usage:


Performance example i time

Performance: Example I (time)

  • Opaque types execute about twice as fast


Performance example i space

Performance: Example I (space)

  • Opaque types are able to reside entirely on the stack, i.e. no allocation is needed


Performance example ii

Performance: Example II

Regular class:


Performance example ii1

Performance: Example II

Opaque class:


Performance example ii2

Performance: Example II

Regular class usage:

Opaque class usage:


Performance example ii time

Performance: Example II (time)

  • Opaque objects execute 12-15 times faster


Performance example ii space

Performance: Example II (space)

  • Even before conversion to underlying type opaque types use 10-12 times less memory


Performance example ii3

Performance: Example II

Opaque class:


Performance example ii4

Performance: Example II

Converted opaque class:


Performance example ii time1

Performance: Example II (time)

  • Converted (to long[]) opaque types execute 20-25 times faster


Performance example ii space1

Performance: Example II (space)

  • Converted (to long[]) opaque types use over 15 times less memory


Conclusions

Conclusions

  • 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 work

Future work

  • Implement Java generics

    • Cover all Java language features

  • Algebra library using opaque types

  • Native implementation?


  • Login