Miniboxing News

Miniboxing @ PNWScala 2014

Sat, 13 Dec 2014 00:00:00 +0000

The miniboxing presentation at PNWScala is now available! A huge thanks to Thomas Lockney and the PNWScala organizers for the wonderful conference and the confreaks guys who recorded the presentation!

If you want to follow the live demo in the presentation on your own, you can use this tutorial.

... if only miniboxing could TALK

Tue, 21 Oct 2014 00:00:00 +0000

One of the most difficult problems in using specialization is finding out when something went wrong and the code reverts to using boxed primitives. This gave birth to a very useful post by Alex Prokopec explaining the quirks of specialization.

Some of these quirks also apply to miniboxing. Yet, there is an important difference. To see it, one should ask the question “what is a quirk?” for specialization. A quirk, as Alex’s explanation shows, is a design or technical limitation that results in a seemingly correct compilation, but that produces suboptimal code. From this perspective, we can say that:

Quirk = limitation + silent failure

As everything else, miniboxing and specialization have to make compromises. These can occur at different levels, from well-understood design decisions that sacrifice certain code patterns all the way to purely technical limitations where the problem is simply not worth the effort to solve.

But there is a second ingredient: the silent failure. Without silently failing, specialization would just point the user into the right direction by providing a workaround or explaining why a limitation occurred. Yet, not doing so made it much harder to use, allowing only an elite of the Scala community to benefit from the unboxed generics. If only specialization could TALK…

Well, miniboxing does talk :)

Miniboxing Warnings

A new feature of the miniboxing plugin is that it talks to you about performance. And how you can improve it. And this will expose all the code where it was not able to correctly specialize generics.

For example, here are a few cases:

When the type arguments do not allow an unambiguous choice between primitives and references:

$ mb-scala -language:_
...

scala> def foo[@miniboxed T](t: T) = t
foo: [T](t: T)T

scala> foo[Int](3) // clearly a primitive
res0: Int = 3

scala> foo[String]("5") // clearly an object
res1: String = 5

scala> foo[Any](2) // could be both

<console>:9: warning: Using the type argument "Any" for the miniboxed type
parameter T of method foo is not specific enough, as it could mean either a
primitive or a reference type. Although method foo is miniboxed, it won't
benefit from that:
              foo[Any](2)
                 ^
res2: Any = 2

scala> foo[T forSome { type T }](2) // uh-oh

<console>:9: warning: Using the type argument "T forSome { type T }" for
the miniboxed type parameter T of method foo is not specific enough, as it
could mean either a primitive or a reference type. Although method foo is
miniboxed, it won't benefit from that:
              foo[T forSome { type T }](2)
                 ^
res3: Any = 2

when adding an annotation could benefit the transformation:
- at the definition site:

scala> class C[@miniboxed T]
defined class C

scala> def foo[X] = new C[X]

<console>:8: warning: The following code could benefit from miniboxing
specialization if the type parameter X of method foo would be marked as
"@miniboxed X" (it would be used to instantiate miniboxed type parameter
T of C)
       def foo[X] = new C[X]
                    ^
foo: [X]=> C[X]

scala> class D[Z] extends C[Z]

<console>:8: warning: The following code could benefit from miniboxing
specialization if the type parameter Z of class D would be marked as
"@miniboxed Z" (it would be used to instantiate miniboxed type parameter
T of C)
       class D[Z] extends C[Z]
             ^
defined class D

at the use site:

scala> def foo[X] = "x"
foo: [X]=> String

scala> foo[Int]
<console>:9: warning: The method foo would benefit from miniboxing type
parameter X, since it is instantiated by a primitive type.
              foo[Int]
                 ^
res0: String = x

scala> def bar[@miniboxed X] = foo[X]
<console>:8: warning: The method foo would benefit from miniboxing type
parameter X, since it is instantiated by miniboxed type parameter X of method bar.
       def bar[@miniboxed X] = foo[X]
                               ^
bar: [X]=> String

when a technical limitation prevents the plugin from compiling the code:

scala> class W[@miniboxed Z](z: Z) { println(z) }

<console>:7: warning: The following constructor statement will not be
specialized in the miniboxed trait W. This is a technical limitation
that can be worked around: (please see
https://github.com/miniboxing/miniboxing-plugin/issues/64)
       class W[@miniboxed Z](z: Z) { println(z) }
                                            ^
<console>:7: error: The following code is accessing field z of miniboxed
class/trait W, a pattern which becomes invalid after the miniboxing
transformation. Please allow Scala to generate accessors by using val/var
or removing the "private[this]" qualifier: val z: Z".
       class W[@miniboxed Z](z: Z) { println(z) }
                                             ^
defined class W

when a class you might expect to be specialized won’t be:

scala> class C[@miniboxed T] {
     |   class D {
     |     def foo(t: T): T = t
     |   }
     | }
<console>:8: warning: The class D will not be miniboxed based on type 
parameter(s) T of miniboxed class C. To have it transformed, declare
new type parameters marked with @miniboxed and instantiate it using
the parameters from class C.
         class D {
               ^
defined class C

or when a the code is just suboptimal:

scala> class W[@miniboxed Z](val z: Z) { println(z) }

<console>:7: warning: The following constructor statement will not be
specialized in the miniboxed trait W. This is a technical limitation
that can be worked around: (please see
https://github.com/miniboxing/miniboxing-plugin/issues/64)
       class W[@miniboxed Z](val z: Z) { println(z) }
                                                ^
<console>:7: warning: The following code could not benefit from m
iniboxing specialization due to technical limitations:
       class W[@miniboxed Z](val z: Z) { println(z) }
                                                 ^
defined class W

Finally, in some cases specialization is lost because some class or method in the library wasn’t miniboxed:

$ mb-scala
...

scala> 3 :: Nil
res0: List[Int] = List(3)

scala> :quit

$ mb-scala -P:minibox:warn-all
...

scala> 3 :: Nil
<console>:8: warning: The method scala.collection.immutable.List.::
would benefit from miniboxing type parameter B, since it is 
instantiated by a primitive type.
              3 :: Nil
                ^
res0: List[Int] = List(3)

scala> :quit

Hope it will be useful!

Thanks guys!

Thanks to @pstutz, @ichoran, @dragos and @StuHood for their precious comments, which spawned this feature!

Late Data Layout Transformation

Mon, 13 Oct 2014 00:00:00 +0000

Late Data Layout (LDL) is the underlying transformation mechanism used by the miniboxing plugin. It generalizes data representation transformations, enabling optimal specialization of miniboxed code. LDL enables other cool transformations as well: value classes and multi-stage execution support.

The theory will be presented at OOPSLA 2014, in Portland, OR.
For more details, check out scala-miniboxing.org/ldl.

Will miniboxing be merged into Scala?

Fri, 27 Jun 2014 00:00:00 +0000

Lately the question of merging the miniboxing plugin into the Scala compiler has arisen in different contexts. We have seen Scala collections miniboxed by hand, and we have even received a suggestion that miniboxing should be an opt-out instead of opt-in, meaning that all type parameters automatically undergo the miniboxing transformation, as if they were annotated with @miniboxed.

We are very glad such questions are asked, as it gives us the opportunity to clarify the roadmap.

So, will the miniboxing plugin be merged into Scala?

Short answer

It depends on you! For now, it will stay a plugin, but the more projects use miniboxing, the more chances it has to become the standard.

###Long answer:

Miniboxing is not currently on the Scala roadmap, but we can change that!

The first step for any plugin that changes the compilation pipeline is to become trusted. And to do so, we need projects using it and reporting their experience. We have already tested the Scala linked list with 1.5-4x speedups, the spire library and we will continue trying other use-cases. But there’s a huge number of cool projects that could use the miniboxing transformation and we need your help!

So if you’d like to see miniboxing in Scala:

Start using it as a plugin, no matter how big or small your project is! Rest assured that with 150+ tests running with each commit, there’s little risk that miniboxing will break your code;
Ask questions on the mailing list or via twitter;
Report any errors you encounter on the github issue tracker;
Write about your use-case and submit a pull request for the website (we welcome contributions!);
Help spread the word, so others can use miniboxing too.

If the miniboxing plugin becomes a common sight in Scala project builds, it may be worth merging it into scalac. Then again, having it as a scalac plugin means easier development and quicker fixes, so keeping it a plugin might not a bad solution at all.

To wrap up, miniboxing will stay as a separate compiler plugin at least for the next Scala release. Whether or not it will become part of scalac in the future depends on you!

Will Scala collections be transformed with miniboxing?

We aim to have an alternative set of collections transformed using miniboxing, which map 1:1 with Scala collections. But this is a medium-term goal.

Will miniboxing become opt-out?

YES! We are currently working on a flag that will turn miniboxing on by default. Stay tuned! :)

Spire. The miniboxed one.

Mon, 16 Jun 2014 00:00:00 +0000

The benchmarks for spire compiled with miniboxing are in! (generated from this branch)

So, why should you care about the miniboxing plugin? Join the ScalaDays talk to learn the three reasons!

ERRATA: The benchmarking numbers were completely redone, after we found out we mixed the log files. The updated conclusions are more nuanced:

most benchmarks show miniboxing is close to specialization, even being faster in some cases
arrays do slow down miniboxing more than expected (10-20%) – we will certainly look into this
in some cases generic is better than both specialization and miniboxing (MapSemigroupBenchmarks)
there are still 2 benchmarks miniboxing can’t run, we’ll be digging into those

Here are the numbers:

FibBenchmarks

benchmark	miniboxed(ns)	specialized (ns)	generic (ns)
IntFibJava	2	2	2
IntFibScala	2	2	2
IntFibGen	43	2	594
LongFibJava	68	68	70
LongFibScala	65	65	68
LongFibGen	66	66	1193
BigIntegerFibJava	23149	23384	23847
BigIntegerFibGen	26402	26296	26614
BigIntFibScala	24114	24067	24130
BigIntFibGen	26056	26368	26424
NaturalFibGen	15116	15326	15133
SpireFib	6360	6382	6402

Mo5Benchmarks

benchmark	miniboxed(ms)	specialized (ms)	generic (ms)
HBMo5	38.1	29.8	88.5
MMo5	47.7	32.6	107.5

PowBenchmarks

benchmark	miniboxed(ms)	specialized (ms)	generic (ms)
LongPowForInt	1.90	1.89	1.94
DoublePowForInt	16.94	16.88	16.92
BigIntPowForInt	19.44	18.64	17.65
LongPowForLong	1.69	1.66	1.68
DoublePowForLong	16.76	16.86	16.84
BigIntPowForLong	23.05	22.63	22.70
DoublePowForDouble	15.84	15.94	15.90

ComplexAddBenchmarks

benchmark	miniboxed(ms)	specialized (ms)	generic (ms)
AddComplexesDirect	4.19	3.68	7.69
AddComplexesGeneric	4.31	5.20	7.74
AddFastComplexes	1.56	1.57	1.55
AddFloatComplexesBoxed	2.44	2.42	2.25
AddFloatComplexesUnboxed	1.58	1.58	1.58

RexBenchmarks

pow	benchmark	miniboxed(us)	specialized (us)	generic (us)
10	Direct	45.5	45.8	47.9
10	Generic	229.6	57.9	396.4
12	Direct	152.8	111.5	170.3
12	Generic	704.8	156.4	1058.5
14	Direct	622.9	516.9	646.3
14	Generic	1253.0	531.4	3423.0
16	Direct	2076.0	2081.9	2723.9
16	Generic	4256.0	2024.4	12765.3
18	Direct	9499.6	9778.3	7361.9
18	Generic	17181.4	7720.6	48629.5

MapSemigroupBenchmarks

mapSize	mapType	benchmark	miniboxed(us)	specialized (us)	generic (us)
2	random	AlgebirdMapAdd	54.7	54.4	54.3
2	random	BulkMapAdd	53.8	54.6	54.3
2	random	SpireAdd	64.0	64.2	48.3
2	sparse	AlgebirdMapAdd	69.7	51.9	74.0
2	sparse	BulkMapAdd	39.5	62.6	63.6
2	sparse	SpireAdd	55.5	49.5	48.5
2	dense	AlgebirdMapAdd	79.9	80.3	79.7
2	dense	BulkMapAdd	80.3	78.8	80.0
2	dense	SpireAdd	78.6	78.6	61.1
4	random	AlgebirdMapAdd	616.5	697.4	618.8
4	random	BulkMapAdd	701.6	697.3	700.2
4	random	SpireAdd	695.3	629.2	694.2
4	sparse	AlgebirdMapAdd	233.9	230.4	231.9
4	sparse	BulkMapAdd	220.3	221.5	218.7
4	sparse	SpireAdd	228.4	226.9	232.3
4	dense	AlgebirdMapAdd	145.4	129.9	124.7
4	dense	BulkMapAdd	143.0	125.6	125.4
4	dense	SpireAdd	184.8	181.0	183.6
8	random	AlgebirdMapAdd	852.9	716.3	672.2
8	random	BulkMapAdd	852.5	865.1	676.5
8	random	SpireAdd	839.0	777.5	638.3
8	sparse	AlgebirdMapAdd	439.5	450.1	400.8
8	sparse	BulkMapAdd	495.6	438.3	452.8
8	sparse	SpireAdd	411.9	424.2	379.2
8	dense	AlgebirdMapAdd	726.9	714.9	682.9
8	dense	BulkMapAdd	690.9	735.9	633.4
8	dense	SpireAdd	687.0	685.4	642.7
16	random	AlgebirdMapAdd	1941.6	1934.1	1537.1
16	random	BulkMapAdd	2265.5	2086.5	1810.5
16	random	SpireAdd	1824.1	1821.7	1432.6
16	sparse	AlgebirdMapAdd	893.9	896.9	743.9
16	sparse	BulkMapAdd	836.9	1014.0	844.6
16	sparse	SpireAdd	872.7	843.4	728.8
16	dense	AlgebirdMapAdd	1545.4	1537.7	1469.0
16	dense	BulkMapAdd	1489.0	1531.5	1251.8
16	dense	SpireAdd	1540.8	1508.1	1435.2
32	random	AlgebirdMapAdd	5548.6	5582.2	4503.9
32	random	BulkMapAdd	5922.9	6023.3	4711.5
32	random	SpireAdd	5081.6	5820.2	4683.2
32	sparse	AlgebirdMapAdd	2632.4	2588.1	2578.4
32	sparse	BulkMapAdd	2545.8	2473.0	2101.0
32	sparse	SpireAdd	2517.0	2412.9	2093.6
32	dense	AlgebirdMapAdd	5435.3	5296.6	4817.5
32	dense	BulkMapAdd	5284.4	5051.2	4815.8
32	dense	SpireAdd	5427.0	5232.9	4598.0
64	random	AlgebirdMapAdd	9630.8	11037.0	8966.1
64	random	BulkMapAdd	10637.3	11466.4	8941.8
64	random	SpireAdd	9511.1	9381.2	8697.1
64	sparse	AlgebirdMapAdd	7029.0	6747.8	6692.3
64	sparse	BulkMapAdd	6865.1	6906.3	6459.0
64	sparse	SpireAdd	6598.4	6426.2	6431.1
64	dense	AlgebirdMapAdd	10568.5	10139.1	9545.6
64	dense	BulkMapAdd	10228.1	11001.8	9246.6
64	dense	SpireAdd	10443.0	10217.1	9800.8

GcdBenchmarks

benchmark	miniboxed(ms)	specialized (ms)	generic (ms)
XorEuclidGcdLong	98.6	97.3	101.1
XorBinaryGcdLong	41.3	41.4	42.7

AddBenchmarks

benchmark	miniboxed(us)	specialized (us)	generic (us)
AddIntsDirect	93.2	65.3	88.5
AddIntsGeneric	92.7	88.2	2345.4
AddLongsDirect	66.3	64.5	64.2
AddLongsGeneric	67.0	64.3	2673.5
AddFloatsDirect	197.2	194.3	193.2
AddFloatsGeneric	200.5	192.2	615.1
AddDoublesDirect	201.8	193.4	192.1
AddDoublesGeneric	203.8	194.1	649.1
AddMaybeDoublesDirect	5372.9	5166.9	5163.9
AddComplexesDirect	1594.0	1596.9	3303.5
AddComplexesGeneric	1400.0	2262.4	3340.2
AddFastComplexes	648.3	652.2	650.2

ArrayOrderBenchmarks

pow	benchmark	miniboxed(ns)	specialized (ns)	generic (ns)
6	AddGeneric	45.7	45.0	1070.8
6	AddIndirect	40.0	40.1	680.9
6	AddDirect	37.6	37.2	36.0
10	AddGeneric	5288.4	435.4	8169.6
10	AddIndirect	5118.1	441.7	8321.1
10	AddDirect	406.2	406.6	415.2
14	AddGeneric	76713.4	8568.7	281031.8
14	AddIndirect	77018.1	8624.7	382331.1
14	AddDirect	8184.1	8553.9	8705.4
18	AddGeneric	1389458.0	211852.0	4471017.1
18	AddIndirect	1386325.8	208735.3	4452107.9
18	AddDirect	207802.0	207519.9	206465.8

In case you’re interested, the updated raw execution logs are here.

First steps to Miniboxed Collections! :)

Thu, 22 May 2014 00:00:00 +0000

The last few weeks we’ve been busy to prepare a milestone of the miniboxin plugin development: miniboxing a mockup of the Scala Collections library! We included all the patterns used in the Scala Collections: our SCALA’14 submission discusses this in detail.

But here’s a sneak peak, and you can read on in the benchmarks page:

Miniboxing @ Scala Days 2014 in Berlin!

Tue, 22 Apr 2014 00:00:00 +0000

That’s right! Miniboxing will be presented at the Scala Days conference in Berlin, 16th-18th of June 2014!

To have all the coolness in place for Scala Days, we’re ramping up both plugin work and benchmarking efforts, thanks to two additions to the miniboxing team: Aymeric (MelodyLucid on github) and Vlad Haprian (HaprianVlad on github).

Hope to see you there!

Miniboxing @ Google Summer of Code 2014

Sat, 01 Mar 2014 00:00:00 +0000

We’re thrilled to announce Scala has been accepted for Google Summer of Code 2014! One of the projects we propose is to develop the miniboxing plugin: namely to help port the spire and breeze libraries to use the miniboxing transformation.

Applicants should be familiar with the Scala compiler and/or JVM bytecode and should not be scared of digging into the internals of the HotSpot Java virtual machine or the Scala compiler transformations. The project will involve hacking the miniboxing plugin to compile spire and breeze correctly, benchmarking the libraries for performance and tweaking the miniboxing transformation to obtain the best numbers possible. It’s a difficult project, but it will make a big impact on the Scala community, as both spire and breeze are highly appreciated libraries!

Consult the project page and apply by emailing to scala-language.

Miniboxing - Latest Developments

Sat, 18 Jan 2014 00:00:00 +0000

In the last three months the miniboxing plugin has seen a serious development spree, with a completely redesigned transformation, which fixes many of the limitations and bugs of the current approach. The development has been largely hidden in the topic/erasure-rebase branch, which, at the moment of writing, is 150 commits in front of the wip branch and 250 commits in front of master.

And we need your help to review the changes!

In the coming two weeks a pull request from branch topic/erasure-rebase will be made to wip. A technical document explaining the changes will be ready in time for the pull request.

Anyone interested in miniboxing is kindly invited to review at the changes, especially the test cases and their reference output (test file X.scala has reference output X.check: see all tests here). Once the pull request is made, everyone can try out the new plugin, comment on the source code and point out any suboptimality in the transformation. If all goes well, a week after the pull request has been made, it will be merged. This will also bump the plugin version from 0.1-SNAPSHOT to 0.2-SNAPSHOT.

So keep an eye out for the pull request and please help review it!

But what does this bring?

The list is quite long, but here’s a summary: * a more principled transformation, with a mechanism which generalizes SIP-15: Value Classes * avoiding unnecessary hopping between the boxed and unboxed representations (tests: 1 2 3 4 5 6 7 8) * improved nested class transformation (tests: 1 2 3 4 5) * improved overriding of class members (tests: 1 2 3 4 5 6 7) * simplified method bridging mechanism (tests: 1 2 3 4 5 6 7 8) * removing many mechanisms made redundant by the latest developments :)

Update

The pull request has been merged! For more details see the presentation.

Miniboxing is using Travis CI!

Wed, 04 Dec 2013 00:00:00 +0000

Miniboxing is now using Travis for continuous integration and publishing snapshot artifacts! For more information, see the Travis CI website and the Travis script we are using and the sbt build file.

Thanks to the Github/Travis/Sonatype teams for such wonderful (and free) tools!