efficiency regression in r8479

efficiency regression in r8479

[Jamison Hope]

Up through r8478, this code:

> (define n ::int 0)

> (define (f) (set! n (+ n 1)) #t)


produced this bytecode for the function f:

  0: getstatic <Field atInteractiveLevel$1.n int>
  3: iconst_1
  4: iadd
  5: putstatic <Field atInteractiveLevel$1.n int>
  8: iconst_1
  9: ireturn

Now, it produced all this gobbledygook:


  0: getstatic <Field gnu.kawa.functions.AddOp.$Pl gnu.kawa.functions.AddOp>
  3: getstatic <Field atInteractiveLevel$1.n int>
  6: invokestatic <Method java.lang.Integer.valueOf (int)java.lang.Integer>
  9: getstatic <Field atInteractiveLevel$2.Lit0 gnu.math.IntNum>
 12: invokevirtual <Method gnu.mapping.Procedure.apply2 (java.lang.Object,java.lang.Object)java.lang.Object>
 15: invokestatic <Method gnu.mapping.Promise.force (java.lang.Object)java.lang.Object>
 18: dup
 19: astore_0
 20: checkcast <Class java.lang.Number>
 23: invokevirtual <Method java.lang.Number.intValue ()int>
 26: putstatic <Field atInteractiveLevel$1.n int>
 29: iconst_1
 30: ireturn
 31: new <Class gnu.mapping.WrongType>
 34: dup_x1
 35: swap
 36: ldc <String "n">
 38: bipush -2
 40: aload_0
 41: invokespecial <Method gnu.mapping.WrongType.<init> (java.lang.ClassCastException,java.lang.String,int,java.lang.Object)void>
 44: athrow


I see the same behavior if I compile a .scm file and look at the class
file, so it's not a REPL-only thing.  If I change the code from (+ n 1)
to (+ n (->int 1)) then I get the old bytecode back.

Am I just catching a work-in-progress with this new unsigned primitive
stuff?

Thanks,


--
Jamison Hope
The PTR Group
www.theptrgroup.com

Re: efficiency regression in r8479

[Per Bothner]

On 05/26/2015 03:35 PM, Jamison Hope wrote:
> Am I just catching a work-in-progress with this new unsigned primitive
> stuff?

Hm.  I can't reproduce this - I get the efficient bytecode, using
the currently-checked-in code, using JDK 1.7.

Indeed, unsigned primitive integer support is a work-in-progress.
BTW a major motivation for doing this work at this time
is to provide consistent behavior between SRFI-4 uniform vectors
and native arrays, including having the former return unboxed results.
This in turn is related to the "generic sequence" support I'm working on.
(Once that is done, I plan to document and stabilize for a Kawa 2.2 release.)
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: efficiency regression in r8479

[Jamison Hope]

On May 27, 2015, at 12:20 PM, Per Bothner <per@bothner.com> wrote:

> On 05/26/2015 03:35 PM, Jamison Hope wrote:
>> Am I just catching a work-in-progress with this new unsigned primitive
>> stuff?
> 
> Hm.  I can't reproduce this - I get the efficient bytecode, using
> the currently-checked-in code, using JDK 1.7.

Interesting.  If I do "svn up && ant" then I see the problem (with both 1.7
and 1.8), but if I do "svn up && ant clean && ant" then I don't.  So there
must be something that needs to get rebuilt after the 8479 change set that
ant overlooks.

Sorry for the noise!

> Indeed, unsigned primitive integer support is a work-in-progress.
> BTW a major motivation for doing this work at this time
> is to provide consistent behavior between SRFI-4 uniform vectors
> and native arrays, including having the former return unboxed results.

Sounds reasonable.  Is there going to be reader syntax for unsigned
literals?

> This in turn is related to the "generic sequence" support I'm working on.
> (Once that is done, I plan to document and stabilize for a Kawa 2.2 release.)

Are we skipping 2.1?


--
Jamison Hope
The PTR Group
www.theptrgroup.com

Re: efficiency regression in r8479

[Per Bothner]

On 05/27/2015 11:08 AM, Jamison Hope wrote:
> On May 27, 2015, at 12:20 PM, Per Bothner <per@bothner.com> wrote:
>> Indeed, unsigned primitive integer support is a work-in-progress.
>> BTW a major motivation for doing this work at this time
>> is to provide consistent behavior between SRFI-4 uniform vectors
>> and native arrays, including having the former return unboxed results.
>
> Sounds reasonable.  Is there going to be reader syntax for unsigned
> literals?

I hadn't thought about it, but it would seem reasonable.
The syntax NNNu seems the most obvious (and is consistent with
Common Lisp "potential numbers").  But there are some issue.  For example
should unsigned numbers be printed with 'u'? Do we also want
byte/short/long suffixes?

These questions aren't a priority right now.

>> This in turn is related to the "generic sequence" support I'm working on.
>> (Once that is done, I plan to document and stabilize for a Kawa 2.2 release.)
>
> Are we skipping 2.1?

I'm thinking about using even minor numbers for actual releases, and odd
numbers for "in-between", as in SVN snapshots. But perhaps we can use
SVN sequence numbers for the 3rd part:
    2.0.8479
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/