What do auto(un)boxing, specialization and value classes have in common?

scala-miniboxing.org 1st of August 2014
Scala Bay Area Meetup
Linkedin HQ, Mountain View

View Slide

scala-miniboxing.org
Vlad URECHE
PhD student in the Scala Team @ EPFL
Miniboxing guy. Also worked on
specialization, the backend and scaladoc.
@
@VladUreche
@VladUreche
[email protected]

View Slide

What do auto(un)boxing,
specialization and value
classes have in common?

View Slide

What are they?

View Slide

5
Auto(un)boxing
Auto(un)boxing
def identity[T](t: T): T = t

View Slide

6
Auto(un)boxing
Auto(un)boxing
scalac / javac

View Slide

7
Auto(un)boxing
Auto(un)boxing
def identity(t: Object): Object = t
scalac / javac

View Slide

8
Auto(un)boxing
Auto(un)boxing
The process is called erasure,
and is the simplest translation
of generics to bytecode.
scalac / javac

View Slide

9
Auto(un)boxing
Auto(un)boxing
identity(5)

View Slide

10
Auto(un)boxing
Auto(un)boxing
identity(5)
scalac / javac

View Slide

11
Auto(un)boxing
Auto(un)boxing
identity(5)
identity(j.l.Integer.valueOf(5)).intValue
scalac / javac

View Slide

12
Auto(un)boxing
Auto(un)boxing
identity(5)
scalac / javac
Object representation

View Slide

13
Auto(un)boxing
Auto(un)boxing
identity(5)
scalac / javac inflates heap
requirements

View Slide

14
Auto(un)boxing
Auto(un)boxing
identity(5)
scalac / javac produces
garbage
inflates heap
requirements

View Slide

15
Auto(un)boxing
Auto(un)boxing
identity(5)
garbage
inflates heap
requirements
indirect
(slow) access
to the value

View Slide

16
Auto(un)boxing
Auto(un)boxing
identity(5)
garbage
breaks locality
guarantees
inflates heap
requirements
indirect
(slow) access
to the value

View Slide

17
Auto(un)boxing
Auto(un)boxing
val five: Int = 5

View Slide

18
Auto(un)boxing
Auto(un)boxing
val five: Int = 5
scala.Int behaves like an object
(has methods, can be used with generics)

View Slide

19
Auto(un)boxing
Auto(un)boxing
val five: Int = 5
scalac

View Slide

20
Auto(un)boxing
Auto(un)boxing
val five: Int = 5
val five: int = 5
scalac

View Slide

21
Auto(un)boxing
Auto(un)boxing
val five: Int = 5
val five: int = 5
scalac
Unboxed integer

View Slide

22
Auto(un)boxing
Auto(un)boxing
val five: Int = 5
val five: int = 5
scalac
Unboxed integer
five + 3

View Slide

23
Auto(un)boxing
Auto(un)boxing
val five: Int = 5
val five: int = 5
scalac
Unboxed integer
five + 3
scalac

View Slide

24
Auto(un)boxing
Auto(un)boxing
val five: Int = 5
val five: int = 5
scalac
Unboxed integer
five + 3
five + 3
scalac

View Slide

25
Auto(un)boxing
Auto(un)boxing
val five: Int = 5
val five: int = 5
scalac
Unboxed integer
five + 3
five + 3
scalac
Unboxed addition

View Slide

26
Auto(un)boxing
Auto(un)boxing
val five: Int = identity(5)

View Slide

27
Auto(un)boxing
Auto(un)boxing
scalac

View Slide

28
Auto(un)boxing
Auto(un)boxing
val five: int =
scalac

View Slide

29
Auto(un)boxing
Auto(un)boxing
val five: int =
identity(I.valueOf(5)).intValue
scalac

View Slide

30
Auto(un)boxing
Auto(un)boxing
val five: int =
scalac
Boxing coercion

View Slide

31
Auto(un)boxing
Auto(un)boxing
val five: int =
scalac
Boxing coercion Unboxing coercion

View Slide

32
Auto(un)boxing
Auto(un)boxing
scala.Int

View Slide

33
Auto(un)boxing
Auto(un)boxing
scala.Int

View Slide

34
Auto(un)boxing
Auto(un)boxing
scala.Int
int
●
fast access
●
no garbage collection
●
locality

View Slide

35
Auto(un)boxing
Auto(un)boxing
scala.Int
int
●
fast access
●
●
locality
●
indirect access
●
object allocation
●
and thus garbage collection
●
no locality guarantees
●
compatible with erased generics
java.lang.Integer

View Slide

36
Auto(un)boxing
Auto(un)boxing
scala.Int
int
●
fast access
●
●
locality
●
indirect access
●
object allocation
●
●
●
java.lang.Integer
incompatible
→ coercions

View Slide


View Slide

38
Specialization
Specialization

View Slide

39
Specialization
Specialization
specialization

View Slide

40
Specialization
Specialization
specialization

View Slide

41
Specialization
Specialization
specialization
def identity_Z(t: bool): bool = t

View Slide

42
Specialization
Specialization
specialization
def identity_C(t: char): char = t

View Slide

43
Specialization
Specialization
specialization
def identity_C(t: char): char = t
… (7 other variants)

View Slide

44
Specialization
Specialization
identity(5)

View Slide

45
Specialization
Specialization
identity(5)
specialization

View Slide

46
Specialization
Specialization
identity(5)
identity_I(5)
specialization

View Slide

47
Specialization
Specialization
identity(5)
identity_I(5)
specialization
The variant of identity
specialized for int

View Slide

48
Specialization
Specialization
identity(5)
identity_I(5)
specialization
The variant of identity
specialized for int
// no boxing!

View Slide

49
Specialization
Specialization
def tupled[T1, T2](t1: T1, t2: T2) ...

View Slide

50
Specialization
Specialization
specialization

View Slide

51
Specialization
Specialization
// 100 methods (102)
specialization

View Slide

52
Specialization
Specialization
// 100 methods (102)
specialization

View Slide

53
Specialization
Specialization
// 100 methods (102)
specialization
Can we do something
about this?

View Slide

54
Specialization
Specialization
// 100 methods (102)
specialization
Can we do something
about this?

View Slide

55
Miniboxing
Miniboxing

View Slide

56
Miniboxing
Miniboxing
miniboxing

View Slide

57
Miniboxing
Miniboxing
miniboxing

View Slide

58
Miniboxing
Miniboxing
miniboxing
def identity_M(..., t: long): long = t

View Slide

59
Miniboxing
Miniboxing
miniboxing
long encodes all
primitive types

View Slide

60
Miniboxing
Miniboxing
miniboxing
Only 2n variants
long encodes all
primitive types

View Slide

61
Miniboxing
Miniboxing
identity(3)

View Slide

62
Miniboxing
Miniboxing
identity(3)
miniboxing

View Slide

63
Miniboxing
Miniboxing
identity(3)
identity_M(..., int2minibox(3))
miniboxing

View Slide

64
Miniboxing
Miniboxing
identity(3)
miniboxing
Coercion

View Slide

65
Miniboxing
Miniboxing
identity(3)
miniboxing
Coercion
The miniboxed
variant of identity

View Slide

66
Miniboxing
Miniboxing
T

View Slide

67
Miniboxing
Miniboxing
T

View Slide

68
Miniboxing
Miniboxing
T
long
●
preferred encoding

View Slide

69
Miniboxing
Miniboxing
T
long
●
preferred encoding ●
fallback encoding
●
compatible with
●
method calls
●
supertypes
●
erased generics
T (erased to Object)

View Slide

70
Miniboxing
Miniboxing
T
long
●
fallback encoding
●
compatible with
●
method calls
●
supertypes
●
erased generics
incompatible
→ coercions

View Slide


View Slide

72
Value Classes
Value Classes
def abs(c: Complex): Double = ...

View Slide

73
Value Classes
Value Classes
value class transformation

View Slide

74
Value Classes
Value Classes
def abs(c_re: Double,
c_im: Double): Double = ...

View Slide

75
Value Classes
Value Classes
def abs(c_re: Double,
c_im: Double): Double = ...
No object created!

View Slide

76
Value Classes
Value Classes
val c: Complex = Complex(2,1)

View Slide

77
Value Classes
Value Classes

View Slide

78
Value Classes
Value Classes
val c_re: Double = 2
val c_im: Double = 1

View Slide

79
Value Classes
Value Classes
val c_re: Double = 2
val c_im: Double = 1
No object created!

View Slide

80
Value Classes
Value Classes
val a: Any = c

View Slide

81
Value Classes
Value Classes
val a: Any = c

View Slide

82
Value Classes
Value Classes
val a: Any = c
val a: Object =
new Complex(c_re, c_im)

View Slide

83
Value Classes
Value Classes
val a: Any = c
val a: Object =
new Complex(c_re, c_im)
Coercion!

View Slide

84
Value Classes
Value Classes
value class

View Slide

85
Value Classes
Value Classes
value class

View Slide

86
Value Classes
Value Classes
value class
structure (by-val)
●
preferred encoding

View Slide

87
Value Classes
Value Classes
value class
structure (by-val)
●
fallback encoding
●
compatible with
●
supertypes
●
erased generics
class (by-ref)

View Slide

88
Value Classes
Value Classes
value class
structure (by-val)
●
fallback encoding
●
compatible with
●
supertypes
●
erased generics
class (by-ref)
incompatible
→ coercions

View Slide


View Slide

Multi-stage programs too,
but we won't go there!

View Slide


View Slide

92
Auto(un)boxing
Auto(un)boxing
scala.Int
int
●
fast access
●
●
locality
●
indirect access
●
garbage collection
●
and object allocation
●
●
java.lang.Integer
incompatible
→ coercions

View Slide

93
Miniboxing
Miniboxing
T
long
●
fallback encoding
●
compatible with
●
method calls
●
supertypes
●
erased generics
incompatible
→ coercions

View Slide

94
Value Classes
Value Classes
value class
structure (by-val)
●
fallback encoding
●
compatible with
●
supertypes
●
erased generics
class (by-ref)
incompatible
→ coercions

View Slide


View Slide

Starting from a high-level concept:

View Slide

(1) split it into multiple representations
based on external constaints

View Slide

(1) split it into multiple representations
based on external constaints
(2) introduce the necessary coercions when
the representation has to be converted

View Slide

Why is this important?
The transformation
Benchmark
Conclusion

View Slide


View Slide

102
Late Data Layout (LDL)

View Slide

103
concept

View Slide

104
concept

View Slide

105
concept
repr. 1

View Slide

106
concept
repr. 1 repr. 2

View Slide

107
concept
repr. 1 … repr. n
repr. 2

View Slide

108
concept
repr. 1 … repr. n
repr. 2
Constraints from the interaction
with other language features:
●
generics
●
subtyping
●
virtual dispatch
●
DSL semantics (staging)

View Slide

109
concept
repr. 1 … repr. n
repr. 2
Constraints from the interaction
with other language features:
●
generics
●
subtyping
●
virtual dispatch
●
DSL semantics (staging)
We've seen this pattern over
and over again:
●
autounboxing
●
specialization
●
value classes
●
multi-stage programming
●
function representation
●
collection representation

View Slide

110
Collection Representation
List[T]

View Slide

111
List[T]
Stream[T]
●
preferred encoding
●
for pure comprehensions

View Slide

112
List[T]
Stream[T]
●
preferred encoding
●
●
for impure comprehensions
●
more expensive (needs to
be materialized at each
step)
List[T]

View Slide

113
List[T]
Stream[T]
●
preferred encoding
●
●
for impure comprehensions
●
more expensive (needs to
be materialized at each
step)
List[T]
incompatible
→ coercions

View Slide

114
val c = List(1,2,3)
val d = c.map(_+1).filter(_%2==0)
val c = List(1,2,3)

View Slide

115
val c = List(1,2,3)
Materialized list
val c = List(1,2,3)

View Slide

116
val c = List(1,2,3)
Materialized list Materialized list
val c = List(1,2,3)

View Slide

117
val c = List(1,2,3)
val c = List(1,2,3)

View Slide

118
val c = List(1,2,3)
val c: Stream[Int] =
List(1,2,3).toStream
val c = List(1,2,3)

View Slide

119
val c = List(1,2,3)
val d: Stream[Int] =
c.map(_+1).filter(_%2==0)
val c = List(1,2,3)

View Slide

120
val c = List(1,2,3)
val d: Stream[Int] =
c.map(_+1).filter(_%2==0)
val c = List(1,2,3)
No materialization!

View Slide

121

View Slide

122

View Slide

123

repr. 1 … repr. n
repr. 2

View Slide

124

repr. 1 … repr. n
repr. 2
Can LDL help you?

View Slide

125

repr. 1 … repr. n
repr. 2
Can LDL help you? It may not be a perfect fit,
but let's give it a shot!

View Slide

The transformation
Benchmark
Conclusion

View Slide

How do transform a program?

View Slide

If you understand the
high-level picture, you
will immediately see if
your usecase matches.

View Slide

If you understand the
high-level picture, you
will immediately see if
your usecase matches. We'll use autounboxing
as the running example,
to keep things simple

View Slide

131
Auto(un)boxing
Auto(un)boxing
scala.Int
int
●
fast access
●
●
locality
●
indirect access
●
object allocation
●
●
●
java.lang.Integer

View Slide

132
Auto(un)boxing
Auto(un)boxing
scala.Int
int
●
fast access
●
●
locality
●
indirect access
●
object allocation
●
●
●
java.lang.Integer
incompatible
→ coercions

View Slide

Naive transformation
Syntax-based transformation
Type-based LDL transformation

View Slide

134
val x: Int = List[Int](1, 2, 3).head
val y: List[Int] = List[Int](x)
naive unboxing

View Slide

135
val x: int = List[Int](1, 2, 3).head
naive unboxing

View Slide

136
naive unboxing
representation mismatch:
expected: int
found: Int

View Slide

137
naive unboxing
expected: int
found: Int
expected: Int
found: int

View Slide

138
●
naively replacing representations
– leads to mismatches
– which are hard to recover
(impossible for value classes and miniboxing)
●
we need coercions between representations

View Slide


View Slide

140
Syntax-based
Syntax-based
●
when transforming a value
– coerce the definition right-hand side
– coerce all references to it

View Slide

141
Syntax-based
Syntax-based

View Slide

142
Syntax-based
Syntax-based
syntax-based unboxing

View Slide

143
Syntax-based
Syntax-based
val x: int =

View Slide

144
Syntax-based
Syntax-based
val x: int =
unbox(List[Int](1, 2, 3).head)

View Slide

145
Syntax-based
Syntax-based
val x: int =
There are no references to x,
so there's nothing else to do.

View Slide

146
Syntax-based
Syntax-based
val x: int =
There are no references to x,
so there's nothing else to do.

View Slide

147
Syntax-based
Syntax-based
val y: Int = x

View Slide

148
Syntax-based
Syntax-based
val y: Int = x
Transform one by one

View Slide

149
Syntax-based
Syntax-based
val y: Int = x

View Slide

150
Syntax-based
Syntax-based
val y: Int = x
val x: int =

View Slide

151
Syntax-based
Syntax-based
val y: Int = x
val x: int =
val y: Int = box(x)

View Slide

152
Syntax-based
Syntax-based
val x: int =
val y: Int = box(x)

View Slide

153
Syntax-based
Syntax-based
val x: int =
val y: Int = box(x)

View Slide

154
Syntax-based
Syntax-based
val x: int =
val y: Int = box(x)
val x: int =
val y: int =

View Slide

155
Syntax-based
Syntax-based
val x: int =
val y: Int = box(x)
val x: int =
val y: int = unbox(box(x))

View Slide

156
Syntax-based
Syntax-based
val x: int =
val y: Int = box(x)
val x: int =
suboptimal

View Slide

157
Peephole Optimization

View Slide

158
peephole

View Slide

159
val y: int = x
peephole

View Slide

160
val y: int = x
peephole

View Slide

161
val y: int = x
peephole
Okay, let's add the peephole
transformation in the pipeline.

View Slide

162
Syntax-based
Syntax-based
def choice(t1: Int, t2: Int): Int =
if (Random.nextBoolean())
t1
else
t2

View Slide

163
Syntax-based
Syntax-based
def choice(t1: Int, t2: Int): Int =
t1
else
t2

View Slide

164
Syntax-based
Syntax-based
def choice(t1: int, t2: Int): Int =
box(t1)
else
t2

View Slide

165
Syntax-based
Syntax-based
def choice(t1: int, t2: int): Int =
box(t1)
else
box(t2)

View Slide

166
Syntax-based
Syntax-based
def choice(t1: int, t2: int): Int =
box(t1)
else
box(t2)
Anything missing?

View Slide

167
Syntax-based
Syntax-based
def choice(t1: int, t2: int): int =
unbox(if (Random.nextBoolean())
box(t1)
else
box(t2))

View Slide

168
Syntax-based
Syntax-based
box(t1)
else
box(t2))

View Slide

169
Syntax-based
Syntax-based
box(t1)
else
box(t2))
new peephole rule

View Slide

170
Syntax-based
Syntax-based
box(t1)
else
box(t2))
new peephole rule
sink outside coercions
into the if branches

View Slide

171
Syntax-based
Syntax-based
unbox(box(t1))
else
unbox(box(t2))

View Slide

172
Syntax-based
Syntax-based
unbox(box(t1))
else
unbox(box(t2))

View Slide

173
Syntax-based
Syntax-based
t1
else
t2

View Slide

174
Syntax-based
Syntax-based
t1
else
t2
complicated

View Slide

175
Syntax-based
Syntax-based
●
peephole transformation does not scale
– needs multiple rules for each node
– needs successive rewriting => slow
– impossible to guarantee optimality

View Slide


View Slide

177
Type-based transformation
●
propagate representation information
– into the type system (based on annotated types)
– let the type system propagate this information

View Slide

178
●
re-typechecking the tree
– exposes inconsistencies in the representation
– so we introduce coercions
●
only when representations don't match

View Slide

179
●
three-stage mechanism
– inject annotate the values to be unboxed
→
– coerce introduce coercion markers
→
– commit commit to the alternative representations
→

View Slide

180
Warning!
Throughout the presentation we'll be writing
annotations written before types (e.g. “@unboxed
Int”), although in the Scala syntax they are written
after the type (e.g.“Int @unboxed”). This makes it
easier to read the types aloud.

View Slide

181
Type-based
Type-based inject
coerce
commit

View Slide

182
Type-based
Type-based
def choice(t1: Int,
t2: Int): Int =
t1
else
t2
inject
coerce
commit

View Slide

183
Type-based
Type-based
def choice(t1: Int,
t2: Int): Int =
t1
else
t2
inject
coerce
commit

View Slide

184
Type-based
Type-based
def choice(t1: @unboxed Int,
t2: @unboxed Int): @unboxed Int =
t1
else
t2
inject
coerce
commit

View Slide

185
Type-based
Type-based
t1
else
t2
inject
coerce
commit
configurable introduction
of annotations
based on external constraints

View Slide

186
Type-based
Type-based
t1
else
t2
inject
coerce
commit

View Slide

187
Type-based
Type-based
t1
else
t2
inject
coerce
commit

View Slide

188
Type-based
Type-based
t1
else
t2
inject
coerce
commit

View Slide

189
Type-based
Type-based
t1
else
t2
inject
coerce
commit
the rhs expression must
be of type @unboxed Int

View Slide

190
Type-based
Type-based
t1
else
t2
inject
coerce
commit
: @unboxed Int

View Slide

191
Type-based
Type-based
t1
else
t2
inject
coerce
commit
: @unboxed Int
expected type
(part of local type inference)

View Slide

192
Type-based
Type-based
t1
else
t2
inject
coerce
commit
: Boolean

View Slide

193
Type-based
Type-based
t1
else
t2
inject
coerce
commit
: Boolean
matches:
expected: Boolean
found: Boolean

View Slide

194
Type-based
Type-based
t1
else
t2
inject
coerce
commit
: @unboxed Int

View Slide

195
Type-based
Type-based
t1
else
t2
inject
coerce
commit
: @unboxed Int
matches:
expected: @unboxed Int
found: @unboxed Int

View Slide

196
Type-based
Type-based
t1
else
t2
inject
coerce
commit
: @unboxed Int

View Slide

197
Type-based
Type-based
t1
else
t2
inject
coerce
commit
matches:
...
: @unboxed Int

View Slide

198
Type-based
Type-based
t1
else
t2
inject
coerce
commit

View Slide

199
Type-based
Type-based
t1
else
t2
inject
coerce
commit
all okay, next phase

View Slide

200
Type-based
Type-based
t1
else
t2
inject
coerce
commit

View Slide

201
Type-based
Type-based
t1
else
t2
inject
coerce
commit
Replace:
@unboxed Int → int
(not showing Int → j.l.Integer)

View Slide

202
Type-based
Type-based
def choice(t1: int,
t2: int): int =
t1
else
t2
inject
coerce
commit

View Slide

203
Type-based
Type-based
def choice(t1: int,
t2: int): int =
t1
else
t2
inject
coerce
commit
that's it!

View Slide

204
●
three-stage mechanism
– inject: add annotations
– coerce: add coercions (based on the annotations)
– commit: final representation semantics

View Slide

205
●
Scalac's erasure
– similar transformation
– less flexible (no annotations)
– entangled with other transformations
●
we took what's good
– and allowed the transformation to work on other
usecases as well

View Slide

206
●
why do this?
– at the core of:
●
miniboxing (http://scala-miniboxing.org)
●
value classes plugin (https://github.com/miniboxing/value-plugin)
●
multi-stage plugin (https://github.com/miniboxing/staging-plugin)
●

View Slide

207
●
why do this?
– at the core of:
●
miniboxing (http://scala-miniboxing.org)
●
value classes plugin (https://github.com/miniboxing/value-plugin)
●
multi-stage plugin (https://github.com/miniboxing/staging-plugin)
●

most important one

View Slide

Consistency
Selectivity
Optimality*
Properties
* not formally proven yet

View Slide

209
Consistency
Consistency inject
coerce
commit
●
representations become explicit in types
– representation mismatches
●
become type mismatches
●
are exposed by the type system
– mismatches lead to coercions
●
explicit bridges between representations
●
are introduced automatically
– regardless of the representations
●
at a meta-level

View Slide

Consistency
Selectivity
Optimality*
Properties

View Slide

211
Selectivity
Selectivity inject
coerce
commit
●
annotations allow selectively picking the values
to be transformed
– value classes
●
cannot unbox multi-param values in return position (not
supported by the JVM platform)
●
bridge methods
– staging
●
annotations signal domain-specific knowledge
– can occur inside generics (List[@staged Int])

View Slide

212
Selectivity
Selectivity
def choice(t1: Int,
t2: Int): Int =
t1
else
t2
inject
coerce
commit

View Slide

213
Selectivity
Selectivity
def choice(t1: Int,
t2: Int): Int =
t1
else
t2
inject
coerce
commit
what if we did not annotate t1?

View Slide

214
Selectivity
Selectivity
def choice(t1: Int,
t1
else
t2
inject
coerce
commit
what if we did not annotate t1?

View Slide

215
Selectivity
Selectivity
def choice(t1: Int,
t1
else
t2
inject
coerce
commit
: @unboxed Int

View Slide

216
Selectivity
Selectivity
def choice(t1: Int,
t1
else
t2
inject
coerce
commit
: @unboxed Int

View Slide

217
Selectivity
Selectivity
def choice(t1: Int,
t1
else
t2
inject
coerce
commit
: @unboxed Int
mismatch:
found: Int

View Slide

218
Selectivity
Selectivity
def choice(t1: Int,
t1
else
t2
inject
coerce
commit
: @unboxed Int
mismatch:
found: Int
coercion

View Slide

219
Selectivity
Selectivity
def choice(t1: Int,
unbox(t1)
else
t2
inject
coerce
commit

View Slide

220
Selectivity
Selectivity
def choice(t1: Int,
unbox(t1)
else
t2
inject
coerce
commit

View Slide

221
Selectivity
Selectivity
def choice(t1: Int,
t2: int): int =
t1.intValue
else
t2
inject
coerce
commit

View Slide

Consistency
Selectivity
Optimality*
Properties

View Slide

223
Optimality
Optimality
def choice(t1: Int,
unbox(t1)
else
t2
inject
coerce
commit

View Slide

224
Optimality
Optimality
def choice(t1: Int,
unbox(t1)
else
t2
inject
coerce
commit

View Slide

225
Optimality
Optimality
def choice(t1: Int,
unbox(t1)
else
t2
inject
coerce
commit
Coercions are sunk in the tree →
excute only if necessary

View Slide

Miniboxing
Value Classes*
Multi-stage Programming*
Use cases
* early prototypes

View Slide

227
LDL for miniboxing
LDL for miniboxing
def tupled[T1, T2](t1: T1, t2: T2) = ...

View Slide

228
LDL for miniboxing
LDL for miniboxing
miniboxing

View Slide

229
LDL for miniboxing
LDL for miniboxing
miniboxing
first: duplicate body

View Slide

230
LDL for miniboxing
LDL for miniboxing
miniboxing
def tupled[T1, T2](t1: T1, t2: T2) = …

View Slide

231
LDL for miniboxing
LDL for miniboxing
miniboxing
def tupled_ML[T1, T2](..., t1: T1, t2: T2) = …

View Slide

232
LDL for miniboxing
LDL for miniboxing
miniboxing
def tupled_LM[T1, T2](..., t1: T1, t2: T2) = …

View Slide

233
LDL for miniboxing
LDL for miniboxing
miniboxing
def tupled_MM[T1, T2](..., t1: T1, t2: T2) = …

View Slide

234
LDL for miniboxing
LDL for miniboxing
miniboxing
def tupled_MM[T1, T2](..., t1: T1, t2: T2) = …
second: adapt it

View Slide

235
LDL for miniboxing
LDL for miniboxing
miniboxing
def tupled_ML[T1, T2](..., t1: @long T1, t2: T2) = …
def tupled_LM[T1, T2](..., t1: T1, t2: @long T2) = …
def tupled_MM[T1, T2](..., t1: @long T1, t2: @long T2) =
* @long is used instead of @storage[Long]
second: adapt it

View Slide

236
LDL for miniboxing
LDL for miniboxing
miniboxing
second: adapt it
using the transformation

View Slide

237
LDL for miniboxing
LDL for miniboxing
miniboxing
second: adapt it
using the transformation
body gets adapted**

View Slide

Miniboxing
Value Classes*
Use cases
* early prototypes

View Slide

239
LDL for value classes
def abs(c: @unboxed Complex): Double = ...

View Slide

240
value class plugin
(commit phase)

View Slide

241
value class plugin
(commit phase)
def abs(c_re: Double, c_im: Double): Double = ...

View Slide

242
value class plugin
(commit phase)

View Slide

243
value class plugin
(commit phase)
I'm hiding a lot of details here.
But one could talk about this for an entire day

View Slide

244
value class plugin
(commit phase)
I'm hiding a lot of details here.
But one could talk about this for an entire day
The one is @xeno-by!
He implemented this :)

View Slide

Miniboxing
Value Classes*
Use cases
* early prototypes

View Slide

Miniboxing
Value Classes*
Use cases
We won't go into it today, but see
github.com/miniboxing/staging-plugin
* early prototypes

View Slide

The transformation
Benchmark
Conclusion

View Slide

249
Miniboxing Benchmarks
on the Scala library
●
benchmark: Least Squares Method
– using a mockup of scala.collection.immutable.List

View Slide

250
●
work with Aymeric Genet (github: @MelodyLucid)
●
mock-up of Scala linked List
– Tuples
– Traversable/TraversableLike
– Iterator/Iterable/IterableLike
– LinearSeqOptimized
– Builder/CanBuildFrom
●
FunctionX has a nice story

View Slide

251
●
FunctionX from the Scala library
– specialized
– no way to call from miniboxed code without boxing slow
→
●
MiniboxedFunctionX benchmarked
←
– miniboxed, call without coercing
– added automatically with another LDL cycle
●
MyFunctionX benchmarked
←
– miniboxed, call without coercing
– added by hand to the library

View Slide

252

View Slide

253
30%-45% faster

View Slide

254
30%-45% faster
On a non-contiguous
data structure

View Slide

255
on the Scala library (with GC)

View Slide

256
3x faster
On a non-contiguous
data structure

View Slide

The transformation
Benchmark
Conclusion

View Slide

The transformation
Benchmark
Conclusion
`

View Slide

259
Conclusion
Conclusion
LDL is a
LDL is a transformation
transformation
●
that allows splitting a high-level concept
– into multiple representations
– in a consistent way (through coercions)
– in a selective way (through annotations)
– in an optimal way (coerce only if necessary)
●
use cases covered
– miniboxing
– value classes
●
what is your use case?

repr. 1 … repr. n
repr. 2

View Slide

Credits and Thank you-s
●
Cristian Talau - developed the initial prototype, as a semester project
●
Eugene Burmako - the value class plugin based on the LDL transformation
●
Aymeric Genet - developing collection-like benchmarks for the miniboxing plugin
●
Martin Odersky, for his patient guidance
●
Eugene Burmako, for trusting the idea enough to develop the value-plugin based on the LDL transformation
●
Iulian Dragos, for his work on specialization and many explanations
●
Miguel Garcia, for his original insights that spawned the miniboxing idea
●
Michel Schinz, for his wonderful comments and enlightening ACC course
●
Andrew Myers and Roland Ducournau for the discussions we had and the feedback provided
●
Heather Miller for the eye-opening discussions we had
●
Vojin Jovanovic, Sandro Stucki, Manohar Jonalagedda and the whole LAMP laboratory in EPFL for the extraordinary atmosphere
●
Adriaan Moors, for the miniboxing name which stuck :))
●
Thierry Coppey, Vera Salvisberg and George Nithin, who patiently listened to many presentations and provided valuable feedback
●
Grzegorz Kossakowski, for the many brainstorming sessions on specialization
●
Erik Osheim, Tom Switzer and Rex Kerr for their guidance on the Scala community side
●
OOPSLA paper and artifact reviewers, who reshaped the paper with their feedback
●
Sandro, Vojin, Nada, Heather, Manohar - reviews and discussions on the LDL paper
●
Hubert Plociniczak for the type notation in the LDL paper
●
Denys Shabalin, Dmitry Petrashko for their patient reviews of the LDL paper
Special thanks to the Scala Community for their support!
(@StuHood, @vpatryshev and everyone else!)

View Slide

261
Conclusion
Conclusion
LDL is a
LDL is a transformation
transformation
●
that allows splitting a high-level concept
– into multiple representations
– in a consistent way (through coercions)
– in a selective way (through annotations)
– in an optimal way (coerce only if necessary)
●
use cases covered
– miniboxing
– value classes
●
what is your use case?

repr. 1 … repr. n
repr. 2

View Slide

ScalaTeam @ EPFL

View Slide

ScalaTeam @ EPFL
●
Dependent Object Types calculus
– core type system of the dotty compiler
– Nada Amin/Tiark Rompf
https://github.com/TiarkRompf/minidot
https://github.com/lampepfl/dotty

View Slide

ScalaTeam @ EPFL
●
YinYang multi-stage macro-based frontend
– replacement for scala-virtualized
– Vojin Jovanovic/Sandro Stucki + others
https://github.com/vjovanov/yin-yang

View Slide

ScalaTeam @ EPFL
●
Scala.js backend
– compiles Scala to JavaScript
– Sébastien Doeraene/Tobias Schlatter + others
http://www.scala-js.org/
www

View Slide

ScalaTeam @ EPFL
●
Staged Parser-combinators
– fast parser combinators through staging
– Manohar Jonnalagedda + others
https://github.com/manojo/experiments

View Slide

ScalaTeam @ EPFL
●
Pickling framework and Spores
– support for distributed programming
– Heather Miller/Philipp Haller + others
https://github.com/scala/pickling
https://github.com/heathermiller/spores

View Slide

ScalaTeam @ EPFL
●
dotty
– experimental compiler based on DOT
– Martin Odersky/Dmitry Petrashko/Samuel
Grütter/Tobias Schlatter + others
https://github.com/lampepfl/dotty

View Slide

ScalaTeam @ EPFL
●
scala.meta metaprogramming support
– Improved reflection, macros, and many more
– Eugene Burmako/Denys Shabalin + others
http://scalameta.org/
www

View Slide

ScalaTeam @ EPFL
●
miniboxing specialization
– LDL transformation
– Vlad Ureche/Aymeric Genêt + others
http://scala-miniboxing.org/
www

View Slide

ScalaTeam @ EPFL
●
scaladyno plugin
– giving Scala a dynamic language look and feel
– Cédric Bastin/Vlad Ureche
https://github.com/scaladyno/scaladyno-plugin

View Slide

ScalaTeam @ EPFL
●
ScalaBlitz optimization framework
– macro-based collection optimization
– Dmitry Petrashko/Aleksandar Prokopec
http://scala-blitz.github.io/
www

View Slide

ScalaTeam @ EPFL
●
Type debugger for Scala
– debugging aid for Scala type errors
– Hubert Plociniczak
http://lampwww.epfl.ch/~plocinic/
type-debugger-tutorial/
www

View Slide

ScalaTeam @ EPFL
●
ScalaMeter benchmarking framework
– google caliper for scala
– Aleksandar Prokopec
http://scalameter.github.io/
www

View Slide

ScalaTeam @ EPFL
●
the new scalac backend
– good performance gains
– Miguel Garcia
●
on the job market right now
http://magarciaepfl.github.io/scala/
www
@ [email protected]

View Slide

scala-miniboxing.org 1st of August 2014
Scala Bay Area Meetup
Linkedin HQ, Mountain View
Thank you!

View Slide

What do auto(un)boxing, specialization and value classes have in common?

What do auto(un)boxing, specialization and value classes have in common?

Vlad Ureche

More Decks by Vlad Ureche

Other Decks in Programming

Featured

Transcript