Interpreted not yielding the same results as compiled ...

[Rony G. Flatscher (wu-wien)]

While creating a little nutshell NetRexx program and testing the timings of interpreted vs. compiled, I stumbled over the following phaenomenon:

Program:

limit=1000000     -- one million
start=GregorianCalendar()
loop i=1 to limit
   k=i/17 
end
end=GregorianCalendar()
say 'loop is done, i='i 'k='k
say "executing loop lasted:" (end.getTimeInMillis-start.getTimeInMillis)/1000 "seconds"
say "end:  " "millis:" end.getTimeInMillis
say "start:" "millis:" start.getTimeInMillis
say "end-start:" end.getTimeInMillis-start.getTimeInMillis
say "(end-start)/1000=" ((long end.getTimeInMillis)-(long start.getTimeInMillis))/(long 1000)
  

Execution of program:

• Interpreted, output:

NetRexx portable processor, version 3.00
Copyright (c) RexxLA, 2011.  All rights reserved.
Parts Copyright (c) IBM Corporation, 1995,2008.
Program spin1.nrx
===== Exec: spin1 =====
loop is done, i=1000001 k=58823.5294
executing loop lasted: 30 seconds
end:   millis: 1317287620140
start: millis: 1317287592265
end-start: 30000
(end-start)/1000= 30
  

• Compiled, output:

loop is done, i=1000001 k=58823.5294
executing loop lasted: 0 seconds
end:   millis: 1317287676265
start: millis: 1317287672500
end-start: 0
(end-start)/1000= 0
  

• NetRexx: RexxLA-ProtoRelease-2011-Release-3.00, also: NetRexx-3.01RC2
  
• System: Windows XP SP 3
• Java:
  java version "1.6.0_26"
  Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
  Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)
  

Is this considered a bug or working as designed? (And if the latter, what would be the reasoning?)

---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Hi Rony,
Is the issue the arithmetic difference?  If so it looks like a consequence of 9 digits (or thereabouts) of precision -- note that in the first case, end-start (27875) got rounded to 30000 .  Try increasing DIGITS.
George

On Thu, Sep 29, 2011 at 5:43 AM, Rony G. Flatscher <[hidden email]> wrote:

While creating a little nutshell NetRexx program and testing the timings of interpreted vs. compiled, I stumbled over the following phaenomenon:

Program:

limit=1000000     -- one million
start=GregorianCalendar()
loop i=1 to limit
   k=i/17 
end
end=GregorianCalendar()
say 'loop is done, i='i 'k='k
say "executing loop lasted:" (end.getTimeInMillis-start.getTimeInMillis)/1000 "seconds"
say "end:  " "millis:" end.getTimeInMillis
say "start:" "millis:" start.getTimeInMillis
say "end-start:" end.getTimeInMillis-start.getTimeInMillis
say "(end-start)/1000=" ((long end.getTimeInMillis)-(long start.getTimeInMillis))/(long 1000)
  

Execution of program:

• Interpreted, output:

NetRexx portable processor, version 3.00
Copyright (c) RexxLA, 2011.  All rights reserved.
Parts Copyright (c) IBM Corporation, 1995,2008.
Program spin1.nrx
===== Exec: spin1 =====
loop is done, i=1000001 k=58823.5294
executing loop lasted: 30 seconds
end:   millis: 1317287620140
start: millis: 1317287592265
end-start: 30000
(end-start)/1000= 30
  

• Compiled, output:

loop is done, i=1000001 k=58823.5294
executing loop lasted: 0 seconds
end:   millis: 1317287676265
start: millis: 1317287672500
end-start: 0
(end-start)/1000= 0
  

• NetRexx: RexxLA-ProtoRelease-2011-Release-3.00, also: NetRexx-3.01RC2
  
• System: Windows XP SP 3
• Java:
  java version "1.6.0_26"
  Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
  Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)
  

Is this considered a bug or working as designed? (And if the latter, what would be the reasoning?)

---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

Hi George,

On 29.09.2011 13:02, George Hovey wrote:
> Is the issue the arithmetic difference?  If so it looks like a
> consequence of 9 digits (or thereabouts) of precision -- note that in
> the first case, end-start (27875) got rounded to 30000 .  Try
> increasing DIGITS.
Yes, increasing digits to e.g. 13 yields the same results (in the sense
that the interpreted and the compiled versions show that time has passed
executing the program. Hmm, overlooked that the highest 9 digits are the
same in the compiled version (and both numbers consist of 13 digits) !

---rony


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Rony,
I guess I don't understand what you see as a problem; could you state the issue explicitly?
George

On Thu, Sep 29, 2011 at 8:57 AM, Rony G. Flatscher <[hidden email]> wrote:

Hi George,

On 29.09.2011 13:02, George Hovey wrote:
> Is the issue the arithmetic difference?  If so it looks like a
> consequence of 9 digits (or thereabouts) of precision -- note that in
> the first case, end-start (27875) got rounded to 30000 .  Try
> increasing DIGITS.

Yes, increasing digits to e.g. 13 yields the same results (in the sense
that the interpreted and the compiled versions show that time has passed
executing the program. Hmm, overlooked that the highest 9 digits are the
same in the compiled version (and both numbers consist of 13 digits) !

---rony


_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Rony G. Flatscher (wu-wien)]

George,

On 29.09.2011 16:27, George Hovey wrote:
> I guess I don't understand what you see as a problem; could you state
> the issue explicitly?
The perceived problem was that the NetRexx program that ran interpreted
would show that time has passed while running, whereas the compiled
version would show 0, although noticeable time (measured in milliseconds
from the GregorianCalendar) has elapsed in the compiled version as well.
So measurable time passed in the compiled version, but 0 time was shown
in the results.

Thanks to your hint at the number of digits, it became clear that the
milliseconds consist of 13 digits, but the default digit settings is
working on 9 digits. As the compiled version executes much faster, the
millisecond difference occurred right of the first nine digits, hence
the difference is 0.

Adding the statement "numeric digits 13" remedies the situation for the
compiled version as now it is shown that time has elapsed as indicated
by the difference in the GregorianCalendar's milliseconds for the start
and the end time.

So alli is well as NetRexx has been behaving in interpreted and compiled
mode according to its specifications.

---rony

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/