Difference between revisions of "WG211/M16Siek"

From WG 2.11
Jump to: navigation, search
(Created page with "Jeremy Siek: Compiling gradually typed languages for efficiency Gradual typing combines static and dynamic typing in the same program. One would hope that the performance i...")
 
 
Line 2: Line 2:
  
 
Gradual typing combines static and dynamic typing in the same
 
Gradual typing combines static and dynamic typing in the same
−
  program. One would hope that the performance in a gradually
+
program. One would hope that the performance in a gradually
−
  typed language would range from being similar to that of a
+
typed language would range from being similar to that of a
−
  dynamically typed language to that of a statically typed
+
dynamically typed language to that of a statically typed
−
  language.  Existing implementations of gradually typed
+
language.  Existing implementations of gradually typed
−
  languages have not achieved this goal due to overheads
+
languages have not achieved this goal due to overheads
−
  associated with runtime casts, some research reports as much as
+
associated with runtime casts, some research reports as much as
−
  100x slowdown for partially typed programs. Runtime casts are
+
100x slowdown for partially typed programs. Runtime casts are
−
  necessary to ensure sound interoperability between static and
+
necessary to ensure sound interoperability between static and
−
  dynamic regions.  In this talk I present a compiler, Schml,
+
dynamic regions.  In this talk I present a compiler, Schml,
−
  that serves as a framework for exploring implementation
+
that serves as a framework for exploring implementation
−
  strategies for gradual typing. The design space has many
+
strategies for gradual typing. The design space has many
−
  variables with different possible choices: the cast semantics,
+
variables with different possible choices: the cast semantics,
−
  the blame tracking strategy, and the runtime representation of
+
the blame tracking strategy, and the runtime representation of
−
  casted values.  
+
casted values.  
  
−
  We evaluate the performance of the operations on functions and
+
We evaluate the performance of the operations on functions and
−
  mutable references in two different implementations. The first
+
mutable references in two different implementations. The first
−
  is the traditional type-based casts with functional
+
is the traditional type-based casts with functional
−
  representation of function casts and the second is
+
representation of function casts and the second is
−
  space-efficient coercions with hybrid representation of
+
space-efficient coercions with hybrid representation of
−
  function casts.  Our evaluation methodology determines the
+
function casts.  Our evaluation methodology determines the
−
  overheads in the fully statically-typed code, in the fully
+
overheads in the fully statically-typed code, in the fully
−
  dynamically-typed code, and in the partially-typed code.  Our
+
dynamically-typed code, and in the partially-typed code.  Our
−
  preliminary finds are quite promising for the coercion-based
+
preliminary finds are quite promising for the coercion-based
−
  implementation: a statically typed quicksort is within 50% of
+
implementation: a statically typed quicksort is within 50% of
−
  C, a dynamically typed quicksort is 2x slower than Gambit, and
+
C, a dynamically typed quicksort is 2x slower than Gambit, and
−
  a partially typed quicksort is in between. The traditional
+
a partially typed quicksort is in between. The traditional
−
  type-based version often does better than the coercion-based
+
type-based version often does better than the coercion-based
−
  version, but sometimes does catistrophically worse, which is to
+
version, but sometimes does catistrophically worse, which is to
−
  be expected.
+
be expected.

Latest revision as of 18:38, 22 August 2016

Jeremy Siek: Compiling gradually typed languages for efficiency

Gradual typing combines static and dynamic typing in the same program. One would hope that the performance in a gradually typed language would range from being similar to that of a dynamically typed language to that of a statically typed language. Existing implementations of gradually typed languages have not achieved this goal due to overheads associated with runtime casts, some research reports as much as 100x slowdown for partially typed programs. Runtime casts are necessary to ensure sound interoperability between static and dynamic regions. In this talk I present a compiler, Schml, that serves as a framework for exploring implementation strategies for gradual typing. The design space has many variables with different possible choices: the cast semantics, the blame tracking strategy, and the runtime representation of casted values.

We evaluate the performance of the operations on functions and mutable references in two different implementations. The first is the traditional type-based casts with functional representation of function casts and the second is space-efficient coercions with hybrid representation of function casts. Our evaluation methodology determines the overheads in the fully statically-typed code, in the fully dynamically-typed code, and in the partially-typed code. Our preliminary finds are quite promising for the coercion-based implementation: a statically typed quicksort is within 50% of C, a dynamically typed quicksort is 2x slower than Gambit, and a partially typed quicksort is in between. The traditional type-based version often does better than the coercion-based version, but sometimes does catistrophically worse, which is to be expected.

Retrieved from "https://wiki.hh.se/wg211/index.php?title=WG211/M16Siek&oldid=1528"