Why isn't Numeric specialized?

Function1 is specialized. That alone results in a lot of
specialization throughout the library.

On Wed, Jun 1, 2011 at 20:07, Sciss wrote:
> hi,
>
> why isn't any of math.Ordering, and math.Numeric specialized -- i'm loosing my hope that i can do anything with optimized generics at all in scala 2.9. what is the concept about specialized if it is practically unused in the standard library? should i bake my own Ordering and Numeric ... ? or am i missing something?
>
> best, -sciss-
>
>

ok, but i want to do something with numbers, aka "crunch them"

scala> object Test { def lala[ @specialized( Int, Float, Long, Double ) T ]( a: T, b: T )( implicit num: Numeric[ T ]) = num.plus( a, b )}

scala> :javap -c Test
// --> ouch!

this is very disappointing for data structures. if you need heavy computation, it means you cannot use generics. i thought that was the idea why specialized was invented.

best, -sciss-

On 2 Jun 2011, at 00:21, Daniel Sobral wrote:

> Function1 is specialized. That alone results in a lot of
> specialization throughout the library.
>
> On Wed, Jun 1, 2011 at 20:07, Sciss wrote:
>> hi,
>>
>> why isn't any of math.Ordering, and math.Numeric specialized -- i'm loosing my hope that i can do anything with optimized generics at all in scala 2.9. what is the concept about specialized if it is practically unused in the standard library? should i bake my own Ordering and Numeric ... ? or am i missing something?
>>
>> best, -sciss-
>>
>>
>
>
>

maybe it doesn't make sense because it's based on a java comparator so
the boxing will be done anyway?

Am 02.06.2011 01:07, schrieb Sciss:
> hi,
>
> why isn't any of math.Ordering, and math.Numeric specialized -- i'm loosing my hope that i can do anything with optimized generics at all in scala 2.9. what is the concept about specialized if it is practically unused in the standard library? should i bake my own Ordering and Numeric ... ? or am i missing something?
>
> best, -sciss-
>
>

On Thu, Jun 2, 2011 at 1:07 AM, Sciss wrote:
> why isn't any of math.Ordering, and math.Numeric specialized -- i'm loosing my hope that i can do anything with optimized generics at all in scala 2.9. what is the concept about specialized if it is practically unused in the standard library? should i bake my own Ordering and Numeric ... ? or am i missing something?

There is some work happening in this direction [1]. But it's not as
easy as just adding a smattering of @specialized and recompiling, some
code might need to be restructured to make it possible to get the
right mix of specialization and inlining to rival native math.

So you're right, you can't get top performance out of scala.Numeric
with Scala 2.9. It's all just library code, so you could theoretically
drop in your own version of Numeric and friends if something comes out
of this work, assuming it doesn't depend on fixes to the compiler.

Staged programming offers another promising approach to getting
maximal performance from generic code, and goes beyond removing the
boxing tax. I'm really looking forward to the presentations from Scala
Days on this topic.

-jason

[1] https://github.com/scala-incubator/specialized-numeric

ok, thanks jason and hamster, i'll use my own Ordering and Numeric then. Didn't realize,
java.util.Comparator got in the way -- since I don't need that, I will just leave it out.

best, -sciss-

On 2 Jun 2011, at 07:32, Jason Zaugg wrote:

> On Thu, Jun 2, 2011 at 1:07 AM, Sciss wrote:
>> why isn't any of math.Ordering, and math.Numeric specialized -- i'm loosing my hope that i can do anything with optimized generics at all in scala 2.9. what is the concept about specialized if it is practically unused in the standard library? should i bake my own Ordering and Numeric ... ? or am i missing something?
>
> There is some work happening in this direction [1]. But it's not as
> easy as just adding a smattering of @specialized and recompiling, some
> code might need to be restructured to make it possible to get the
> right mix of specialization and inlining to rival native math.
>
> So you're right, you can't get top performance out of scala.Numeric
> with Scala 2.9. It's all just library code, so you could theoretically
> drop in your own version of Numeric and friends if something comes out
> of this work, assuming it doesn't depend on fixes to the compiler.
>
> Staged programming offers another promising approach to getting
> maximal performance from generic code, and goes beyond removing the
> boxing tax. I'm really looking forward to the presentations from Scala
> Days on this topic.
>
> -jason
>
> [1] https://github.com/scala-incubator/specialized-numeric

is there any tutorial on specialized out there? i never know where i need to put the annotations. for example:

trait Ordered[@specialized(Int, Float, Long, Double) A]

does that make sense? or do i need to annotate _each implementation_ of Ordered? like:

implicit def orderingToOrdered[@specialized(Int, Float, Long, Double) T](x: T)(implicit ord: Ordering[T]): Ordered[T] =
new Ordered[T] { def compare(that: T): Int = ord.compare(x, that) }

or

implicit def orderingToOrdered[@specialized(Int, Float, Long, Double) T](x: T)(implicit ord: Ordering[T]): Ordered[T] =
new Ordered[@specialized(Int, Float, Long, Double) T] { def compare(that: T): Int = ord.compare(x, that) }

or both?

thanks, -sciss-

On 2 Jun 2011, at 14:18, Sciss wrote:

> ok, thanks jason and hamster, i'll use my own Ordering and Numeric then. Didn't realize,
> java.util.Comparator got in the way -- since I don't need that, I will just leave it out.
>
> best, -sciss-
>
>
> On 2 Jun 2011, at 07:32, Jason Zaugg wrote:
>
>> On Thu, Jun 2, 2011 at 1:07 AM, Sciss wrote:
>>> why isn't any of math.Ordering, and math.Numeric specialized -- i'm loosing my hope that i can do anything with optimized generics at all in scala 2.9. what is the concept about specialized if it is practically unused in the standard library? should i bake my own Ordering and Numeric ... ? or am i missing something?
>>
>> There is some work happening in this direction [1]. But it's not as
>> easy as just adding a smattering of @specialized and recompiling, some
>> code might need to be restructured to make it possible to get the
>> right mix of specialization and inlining to rival native math.
>>
>> So you're right, you can't get top performance out of scala.Numeric
>> with Scala 2.9. It's all just library code, so you could theoretically
>> drop in your own version of Numeric and friends if something comes out
>> of this work, assuming it doesn't depend on fixes to the compiler.
>>
>> Staged programming offers another promising approach to getting
>> maximal performance from generic code, and goes beyond removing the
>> boxing tax. I'm really looking forward to the presentations from Scala
>> Days on this topic.
>>
>> -jason
>>
>> [1] https://github.com/scala-incubator/specialized-numeric
>

ok, i think i managed to add the necessary annotations: https://github.com/Sciss/SpecializedNumeric

scala> import de.sciss.specialized._ // shadow scala namespace with specialized versions of Ordering, Numeric etc.
import de.sciss.specialized._

scala> object Test {
| def lulu[ @specialized( Int, Long ) T : Ordering ]( a: T, b: T ) = implicitly[ Ordering[ T ]].compare( a, b )
| }
defined module Test

scala> :javap -c Test // compare this to the output without dragging in de.sciss.specialized._ !
Compiled from ""
public final class Test$ extends java.lang.Object implements scala.ScalaObject{
public static final Test$ MODULE$;

...
public int lulu(java.lang.Object, java.lang.Object, de.sciss.specialized.Ordering);
Code:
0: getstatic #19; //Field scala/Predef$.MODULE$:Lscala/Predef$;
3: aload_3
4: invokevirtual #24; //Method scala/Predef$.implicitly:(Ljava/lang/Object;)Ljava/lang/Object;
7: checkcast #26; //class de/sciss/specialized/Ordering
10: aload_1
11: aload_2
12: invokeinterface #30, 3; //InterfaceMethod de/sciss/specialized/Ordering.compare:(Ljava/lang/Object;Ljava/lang/Object;)I
17: ireturn

public int lulu$mIc$sp(int, int, de.sciss.specialized.Ordering);
Code:
0: getstatic #19; //Field scala/Predef$.MODULE$:Lscala/Predef$;
3: aload_3
4: invokevirtual #24; //Method scala/Predef$.implicitly:(Ljava/lang/Object;)Ljava/lang/Object;
7: checkcast #26; //class de/sciss/specialized/Ordering
10: iload_1
11: iload_2
12: invokeinterface #45, 3; //InterfaceMethod de/sciss/specialized/Ordering.compare$mcI$sp:(II)I // !!
17: ireturn

public int lulu$mJc$sp(long, long, de.sciss.specialized.Ordering);
Code:
0: getstatic #19; //Field scala/Predef$.MODULE$:Lscala/Predef$;
3: aload 5
5: invokevirtual #24; //Method scala/Predef$.implicitly:(Ljava/lang/Object;)Ljava/lang/Object;
8: checkcast #26; //class de/sciss/specialized/Ordering
11: lload_1
12: lload_3
13: invokeinterface #53, 5; //InterfaceMethod de/sciss/specialized/Ordering.compare$mcJ$sp:(JJ)I // !!
18: ireturn
...

On 2 Jun 2011, at 18:57, Sciss wrote:

> is there any tutorial on specialized out there? i never know where i need to put the annotations. for example:
>
> trait Ordered[@specialized(Int, Float, Long, Double) A]
>
> does that make sense? or do i need to annotate _each implementation_ of Ordered? like:
>
> implicit def orderingToOrdered[@specialized(Int, Float, Long, Double) T](x: T)(implicit ord: Ordering[T]): Ordered[T] =
> new Ordered[T] { def compare(that: T): Int = ord.compare(x, that) }
>
> or
>
> implicit def orderingToOrdered[@specialized(Int, Float, Long, Double) T](x: T)(implicit ord: Ordering[T]): Ordered[T] =
> new Ordered[@specialized(Int, Float, Long, Double) T] { def compare(that: T): Int = ord.compare(x, that) }
>
> or both?
>
> thanks, -sciss-
>
>
>
> On 2 Jun 2011, at 14:18, Sciss wrote:
>
>> ok, thanks jason and hamster, i'll use my own Ordering and Numeric then. Didn't realize,
>> java.util.Comparator got in the way -- since I don't need that, I will just leave it out.
>>
>> best, -sciss-
>>
>>
>> On 2 Jun 2011, at 07:32, Jason Zaugg wrote:
>>
>>> On Thu, Jun 2, 2011 at 1:07 AM, Sciss wrote:
>>>> why isn't any of math.Ordering, and math.Numeric specialized -- i'm loosing my hope that i can do anything with optimized generics at all in scala 2.9. what is the concept about specialized if it is practically unused in the standard library? should i bake my own Ordering and Numeric ... ? or am i missing something?
>>>
>>> There is some work happening in this direction [1]. But it's not as
>>> easy as just adding a smattering of @specialized and recompiling, some
>>> code might need to be restructured to make it possible to get the
>>> right mix of specialization and inlining to rival native math.
>>>
>>> So you're right, you can't get top performance out of scala.Numeric
>>> with Scala 2.9. It's all just library code, so you could theoretically
>>> drop in your own version of Numeric and friends if something comes out
>>> of this work, assuming it doesn't depend on fixes to the compiler.
>>>
>>> Staged programming offers another promising approach to getting
>>> maximal performance from generic code, and goes beyond removing the
>>> boxing tax. I'm really looking forward to the presentations from Scala
>>> Days on this topic.
>>>
>>> -jason
>>>
>>> [1] https://github.com/scala-incubator/specialized-numeric
>>
>