Re: @specialized arguments

On Thu, Jul 9, 2009 at 8:38 AM, Matt Fowles <matt.fowles@gmail.com> wrote:

Nils~

Because you are writing a performance sensitive math routine, you don't want to copy code, but anything less than 64 bits doesn't have enough precision or range.

But are you not saying that you then wouldn't be referencing ints and floats anyway, in which case no specialized classes would be generated?
 

On Thu, Jul 9, 2009 at 8:59 AM, Ismael Juma <mlists@juma.me.uk> wrote:

On Thu, 2009-07-09 at 08:55 -0500, Nils Kilden-Pedersen wrote:

> But are you not saying that you then wouldn't be referencing ints and
> floats anyway, in which case no specialized classes would be
> generated?

This is probably where your misunderstanding comes from. The classes
would be generated even if only a subset of primitives were used at
runtime. That is why you can specify that you only want some of them to
be generated.

Are you saying that if I have a reference e.g. Map[@specialized Int, @specializedFloat] (right syntax?) that not only will a specialized MapIntFloat class be generated, but every combination of primitive key/value types? That seems way wrong, so maybe I'm not following.

On Thu, 2009-07-09 at 08:55 -0500, Nils Kilden-Pedersen wrote:

> But are you not saying that you then wouldn't be referencing ints and
> floats anyway, in which case no specialized classes would be
> generated?

This is probably where your misunderstanding comes from. The classes
would be generated even if only a subset of primitives were used at
runtime. That is why you can specify that you only want some of them to
be generated.

Best,
Ismael

On Thu, 2009-07-09 at 09:02 -0500, Nils Kilden-Pedersen wrote:

> Are you saying that if I have a reference e.g. Map[@specialized Int,
> @specializedFloat] (right syntax?) that not only will a specialized
> MapIntFloat class be generated, but every combination of primitive
> key/value types? That seems way wrong, so maybe I'm not following.

Did you look at the original example in this thread? I'll paste it
below:

class MyList[@specialized T] // specialize on all
class MyList[@specialized[Boolean | Int | Float] T]

Can you spot the difference? The example is about usage of @specialized
in the class, _not_ a reference.

Best,
Ismael

Nils~

I may have misunderstood how @specialized works. Will it only
specialize for used types? How does it determine what types are used,
classloaders are fairly dynamic creatures? Or does it only examine
the current compilation unit?

Matt

On Thu, Jul 9, 2009 at 9:55 AM, Nils Kilden-Pedersen wrote:
> On Thu, Jul 9, 2009 at 8:38 AM, Matt Fowles wrote:
>>
>> Nils~
>>
>> Because you are writing a performance sensitive math routine, you don't
>> want to copy code, but anything less than 64 bits doesn't have enough
>> precision or range.
>
> But are you not saying that you then wouldn't be referencing ints and floats
> anyway, in which case no specialized classes would be generated?
>

On Thu, Jul 9, 2009 at 9:14 AM, Ismael Juma <mlists@juma.me.uk> wrote:

On Thu, 2009-07-09 at 09:02 -0500, Nils Kilden-Pedersen wrote:

> Are you saying that if I have a reference e.g. Map[@specialized Int,
> @specializedFloat] (right syntax?) that not only will a specialized
> MapIntFloat class be generated, but every combination of primitive
> key/value types? That seems way wrong, so maybe I'm not following.

Did you look at the original example in this thread? I'll paste it
below:

class MyList[@specialized T] // specialize on all
class MyList[@specialized[Boolean | Int | Float] T]

Can you spot the difference? The example is about usage of @specialized
in the class, _not_ a reference.

Fair enough, but that just seems even weirder to me. The author of a class gets to decide how the user can specialize the class? What is the use case for THAT?

Nils~

I think you are viewing this in a more C++ style light. In C++ you
template all of your types statically at the time of usage. Scala
(unless I miss my guess) has the same late binding of classes as Java.
As a result, you compile your class without knowledge of what outside
classes will call your methods with which types (recall that
type-erasure doesn't live to classload time). As a result, to
effectively specialize a method you have to generate out variants
based on what types your class *might* be called with. Now it is
possible that a library creator knows ahead of time that a variant is
silly or not worth specializing.

Matt

On Thu, Jul 9, 2009 at 10:40 AM, Nils Kilden-Pedersen wrote:
> On Thu, Jul 9, 2009 at 9:33 AM, Matt Fowles wrote:
>>
>> Nils~
>>
>> I may have misunderstood how @specialized works.  Will it only
>> specialize for used types?  How does it determine what types are used,
>> classloaders are fairly dynamic creatures?  Or does it only examine
>> the current compilation unit?
>
> I (obviously) don't have full grips on how this will work either, but I find
> it hard to believe that types will be generated that are not referenced.
>

On Thu, Jul 9, 2009 at 9:33 AM, Matt Fowles <matt.fowles@gmail.com> wrote:

Nils~

I may have misunderstood how @specialized works.  Will it only
specialize for used types?  How does it determine what types are used,
classloaders are fairly dynamic creatures?  Or does it only examine
the current compilation unit?

I (obviously) don't have full grips on how this will work either, but I find it hard to believe that types will be generated that are not referenced.

On Thu, Jul 9, 2009 at 9:45 AM, Matt Fowles <matt.fowles@gmail.com> wrote:

Nils~

I think you are viewing this in a more C++ style light.  In C++ you
template all of your types statically at the time of usage.  Scala
(unless I miss my guess) has the same late binding of classes as Java.
 As a result, you compile your class without knowledge of what outside
classes will call your methods with which types (recall that
type-erasure doesn't live to classload time).  As a result, to
effectively specialize a method you have to generate out variants
based on what types your class *might* be called with.  Now it is
possible that a library creator knows ahead of time that a variant is
silly or not worth specializing.

Yes, of course. I was clouded by looking at the from the reference perspective, not the class def perspective.
I apologize for the noise.

Here is what I wrote a few hours ago, but couldn't send due to
internet connection issues.. Some issues have been clarified in the
mean time, but here it goes anyway..

Specializations are done at definitions site, at all primitive types
(or a user-defined subset). This way we can have separate compilation
which is essential. Whenever a specialized class is used in a context
where types are known (and they match a specialization), scalac
rewrites that reference to the specialized variant.

For instance:

class Function1[@specialized -R, @specialized +T] {
def apply(x: T): R
}

triggers the generation of additional variants of apply, which
circumvent boxing:

class Function1[@specialized -R, @specialized +T] {
def apply(x: T): R
def applyIntInt(x: Int): Int = ...
def applyIntDouble(x: Int): Double = ..
...
}

An implementer of Function1 (like a closure class) would look like

class anonfun extends Function1[Int, Int] {
def applyIntInt(x: Int): Int = x * x
def apply(x: Object): Object = // boxing/unboxing forwarder to
applyIntInt
}

some code using Int => Int would be rewritten to call
'applyIntInt' (which is defined in the original trait, and overridden
in implementing classes). Generic code would still be able to use
'anonfun' through the generic 'apply' method, which handles boxing and
delegates to the specialized variant.

There is no user documentation currently, but a SID is coming. In the
meanwhile, the transformation is described in fair detail in the paper
here:

http://lamp.epfl.ch/~dragos/files/scala-spec.pdf

cheers,
iulian

On Jul 9, 2009, at 4:33 PM, Matt Fowles wrote:

> Nils~
>
> I may have misunderstood how @specialized works. Will it only
> specialize for used types? How does it determine what types are used,
> classloaders are fairly dynamic creatures? Or does it only examine
> the current compilation unit?
>
> Matt
>
> On Thu, Jul 9, 2009 at 9:55 AM, Nils Kilden-
> Pedersen wrote:
>> On Thu, Jul 9, 2009 at 8:38 AM, Matt Fowles
>> wrote:
>>>
>>> Nils~
>>>
>>> Because you are writing a performance sensitive math routine, you
>>> don't
>>> want to copy code, but anything less than 64 bits doesn't have
>>> enough
>>> precision or range.
>>
>> But are you not saying that you then wouldn't be referencing ints
>> and floats
>> anyway, in which case no specialized classes would be generated?
>>

--
Iulian Dragos
--
http://lamp.epfl.ch/~dragos