Scala generic math function for Int and BigInt with #specialized(Int) - performance

Question

I'm new to scala and I wonder whether it is possible to define generic math function that works with both BigInt and Int and in the case of Int the arguments of function will be treated as primitives (without any boxing and unboxing in function body).
So, for example I can do something like
def foo[#specialized(Int) T: Numeric](a: T, b: T) = {
val n = implicitly[Numeric[T]]
import n._
//some code with the use of operators '+-*/'
a * b - a * a + b * b * b
}
//works for primitive Int
val i1 : Int = 1
val i2 : Int = 2
val i3 : Int = foo(i1, i2)
//works for BigInt
val b1 : BigInt = BigInt(1)
val b2 : BigInt = BigInt(2)
val b3 : BigInt = foo(b1, b2)
Here in foo I can use all math operators for both primitive ints and BigInts (that is what I need). However, function foo(Int, Int) compiles to the following:
public int foo$mIc$sp(int a, int b, Numeric<Object> evidence$1) {
Numeric n = (Numeric)Predef..MODULE$.implicitly(evidence$1);
return BoxesRunTime.unboxToInt((Object)n.mkNumericOps(n.mkNumericOps(n.mkNumericOps((Object)BoxesRunTime.boxToInteger((int)a)).$times((Object)BoxesRunTime.boxToInteger((int)b))).$minus(n.mkNumericOps((Object)BoxesRunTime.boxToInteger((int)a)).$times((Object)BoxesRunTime.boxToInteger((int)a)))).$plus(n.mkNumericOps(n.mkNumericOps((Object)BoxesRunTime.boxToInteger((int)b)).$times((Object)BoxesRunTime.boxToInteger((int)b))).$times((Object)BoxesRunTime.boxToInteger((int)b))));
}
instead of plain:
//this is what I really need and expect from `#specialized(Int)`
public int foo$mIc$sp(int a, int b) {
return a * b - a * a + b * b * b;
}
which makes #specialized(Int) useless because the performance is unacceptably low with all these (un)boxings and unnecessary invocations n.mkNumericOps(...).
So, is there a way to implement such generic function as foo that will compile to "just as is" code for primitive types?

Answer 1

The problem is that the Numeric typeclass is not specialized.
If you want to do generic math with high performance, I highly recommend the spire math library.
It has a very elaborate mathematical type class hierarchy, instead of just Numeric.
Here is how your example would look using spire:
import spire.implicits._ // typeclass instances etc.
import spire.syntax._ // syntax such as +-*/
import spire.algebra._ // typeclassses such as Field
def foo[#specialized T: Field](a: T, b: T) = {
//some code with the use of operators '+-*/'
a * b - a * a + b * b * b
}
Here you are saying that there has to be a Field instance for T. Field refers to the algebraic concept.
Spire is highly modular:
spire.algebra contains many well known algebraic concepts such as groups, fields etc, encoded as scala typeclasses
spire.syntax contains the implicit conversions to add operators and other syntax to types for which typeclass instances are available
spire.implicits contains instances for the typeclasses in spire.algebra for common types such as JVM primitives.
This is why you need the three imports.
Regarding the performance: if your code is specialized, and you are using primitives, the performance will be exactly the same as working with primitives directly.
Here is the code of the foo method when specialized for Int:
public int foo$mIc$sp(int, int, spire.algebra.Field<java.lang.Object>);
Code:
0: aload_3
1: aload_3
2: aload_3
3: iload_1
4: iload_2
5: invokeinterface #116, 3 // InterfaceMethod spire/algebra/Field.times$mcI$sp:(II)I
10: aload_3
11: iload_1
12: iload_1
13: invokeinterface #116, 3 // InterfaceMethod spire/algebra/Field.times$mcI$sp:(II)I
18: invokeinterface #119, 3 // InterfaceMethod spire/algebra/Field.minus$mcI$sp:(II)I
23: aload_3
24: aload_3
25: iload_2
26: iload_2
27: invokeinterface #116, 3 // InterfaceMethod spire/algebra/Field.times$mcI$sp:(II)I
32: iload_2
33: invokeinterface #116, 3 // InterfaceMethod spire/algebra/Field.times$mcI$sp:(II)I
38: invokeinterface #122, 3 // InterfaceMethod spire/algebra/Field.plus$mcI$sp:(II)I
43: ireturn
Note that there is no boxing, and the invokeinterface calls will be inlined by the JVM.