[spire] specializing on Byte/Short

[Erik Osheim]

Hello folks,

I'm cross-posting this on the Typelevel and Spire lists (sorry if some
of you get this twice) since I think this is an important issue that
deserves some exposure.

Backstory: Spire currently specializes its algebraic type classes on
all numeric types: Byte, Short, Int, Long, Float, and Double. At the
time there wasn't an obvious principle to use to limit specialization,
and since we knew the resulting jar woudl be large, we didn't worry
about it.

Since last year, there has been work to create a shared dependency
linking Spire with Algebird (and potentially other libraries as well)
allowing shared use of type classes like Monoid, Ring, and so on. You
can see the progress here: https://github.com/non/algebra. Recently
there has been a lot of progress and I'm confident we could see an
initial release soon!

Tom and I have been working to make sure the design of 'algebra' is
consistent with Spire's needs -- the expectation is that there won't
be any big surprises for folks using Spire (although there might be
some minor changes). However, it does mean that any decisions we make
in 'algebra' will be harder to revisit later.

Recently, Socar raised the issue of reducing the jar size by avoiding
Byte/Short specializations. I think he read that boxed Byte and Short
values can reuse instances to avoid unbounded allocations, and was
hoping that meant there would not be a performance penalty.

You can see the conversation around the issue here:

https://github.com/non/algebra/issues/24

Where you come in: in the bug, I determined that indeed there is an 8x
speed penalty when working with Bytes without specialization. Tom made
the case that since the JVM doesn't support working with Byte/Short
directly [1], we ought to drop specialization there anyway.

I think Tom's reasoning is pretty sound, and personally I'm not
relying on generic operations for Byte and Short. But some of you may
be doing so, or may have strong feelings. Would you support removing
Byte/Short specialization to reduce the jar size? Do you suppport
keeping these annotations? Do you rely on them? Are you agnostic on
the issue?

Feel free to chime in with your opinions, or to ask more questions.

-- Erik

[1] As many of you have probably experienced, when you operate on byte
values (for example, to add them) the result is an Int. Internally,
the JVM promotes byte and short values to int before doing any kind of
arithmetic, logical operations, etc.

[Rüdiger Klaehn]

Just my two cents:

For me, specializing on Byte and Short is not necessary. I only need specialization on Long and Double. But I realize that there are probably a lot of people that need specialization on Int ant Float.

Cheers,

Rüdiger

[Vlad Ureche]

2015-01-13 10:06 GMT+01:00 Rüdiger Klaehn <rkl...@gmail.com>:

For me, specializing on Byte and Short is not necessary. I only need specialization on Long and Double. But I realize that there are probably a lot of people that need specialization on Int ant Float.

Erik and Tom agreed to publish two versions of the library: one transformed with Scala's specialization and one transformed with miniboxing (discussion here). Coincidentally, the current version of miniboxing creates Long and Double specializations, but to cover the full primitive spectrum it can also encode {Unit, Boolean, ..., Int} into Long and Float into Double.

In this case, given the choice between the two versions, would you choose the miniboxed one?

Cheers,

Vlad

[Rüdiger Klaehn]

What would I have to do to use the miniboxed version? Just replace the
dependency in sbt? I would definitely give it a try.

[Vlad Ureche]

2015-01-13 15:04 GMT+01:00 Rüdiger Klaehn <rkl...@gmail.com>:

What would I have to do to use the miniboxed version? Just replace the
dependency in sbt? I would definitely give it a try.

You would need to change the artifact name and add the miniboxing plugin to the build.
I'll document this as soon as we have the PR accepted and building nightly.

Cheers,

Vlad

[Erik Osheim]

Based on the replies so far, it doesn't seem like anyone uses Short or
Byte specialization.

So unless I hear something soon, I think the plan is to go ahead and
"despecialize" most types.

Thanks for your input everyone!

-- Erik