[Info-vax] Python for x86?

[Dave Froble]

On 5/9/2023 6:38 PM, Chris Townley wrote:
> On 09/05/2023 23:32, Dave Froble wrote:
>> On 5/9/2023 3:38 PM, Chris Townley wrote:
>>> On 08/05/2023 16:34, Arne Vajhøj wrote:
>>>> On 5/8/2023 7:23 AM, Chris Townley wrote:
>>>>> On 08/05/2023 04:30, terry-... at glaver.org wrote:
>>>>
>>>
>>>
>>>>>>   Basic:
>>>>>>    24.6609 million integer operations per second
>>>>>>    28.4091 million floating point operations per second
>>>>
>>>>> Interesting that BASIC show integer as slower than FP
>>>>
>>>> Yes. I was puzzled by that as well. But I got the same result
>>>> on my systems.
>>>>
>>>> /NOCHECK does not change it so it is not the overflow
>>>> check.
>>>>
>>>> Maybe there is some subtle error in the Basic integer
>>>> test code. But I cannot see it.
>>>>
>>>> Or maybe it is just an example of how random results
>>>> can be with a very limited benchmark - the integer
>>>> result practically depends on a single line of code.
>>>>
>>>> Arne
>>>>
>>>
>>> Finally got round to testing my thoughts.
>>>
>>> On my FreeAXP (no JIT) setup I get the following with your code:
>>>
>>> Basic:
>>>   12.3182 million integer operations per second
>>>   14.1572 million floating point operations per second
>>>    0.0080 million string operations per second
>>>
>>>
>>> I then changed the integer bits to append the % to all integer constants, and
>>> now get:
>>>
>>> Basic:
>>>   31.6586 million integer operations per second
>>>
>>> It shows how BASIC can be slowed down not doing that!
>>>
>>
>> I haven't been following this closely, but, First guess is that the variables
>> were defaulted to floating point, and then perhaps an integer conversion
>> happened?
>>
>> Can you post the code?
>>
>> Once past the compiler, the "%" and "$" signs don't matter, since the compiler
>> would assign the variables, if not declared, and it would just be data and
>> addresses/pointers afterwards.
>>
>
> Arne posted a link to the code before, but the relevant bits are:
>
> Arne's version:
>
> sub testfp(integer xscale)
>
> declare integer constant NFP = 1000
> declare integer constant N = 1000000
> declare integer i, j, nfpscale
> declare double sum
^^^^^^^^^^^^^^^^^^^^

I'm thinking that is the problem.  There will be many conversions.

Also, "integer" is such a poor data type.  Better to use "word" or "long" to be 
rather specific what is being used.

> declare quad t1, t2
> external sub printres(quad, quad, integer, integer, string)
>
> nfpscale = NFP / xscale
> call sys$gettim(t1)
> for i = 1 to nfpscale
>     sum = i - 1

Above is FP = integer - FP
Lots of conversions.

>     for j = 1 to N
>         sum = ((sum + 1) * 2 + 1) / 2

"1", "2", "1", and "2" are all FP

>     next j
>     if abs(sum - (i - 1 + 1.5 * N)) > 1 then
>         print "Floating point test error"
>         stop
>     end if
> next i
> call sys$gettim(t2)
> call printres(t1, t2, nfpscale, N, "floating point operations")
>
> end sub

Arne mentioned elsewhere that this was the FP routine, but I'd ask, then why any 
integers?  FP/integer conversions are expensive.

> My changes:
>
> sub testint(integer xscale)
>
> declare integer constant NINT = 10000%
> declare integer constant N = 1000000%
> declare integer i, j, nintscale, sum
> declare quad t1, t2
> external sub printres(quad, quad, integer, integer, string)
> external long function sys$gettim(quad)
>
> nintscale = NINT / xscale
> call sys$gettim(t1)
> for i = 1% to nintscale
>     sum = i - 1%
>     for j = 1 to N
>         sum = ((sum + 1%) * 2% + 1%) / 2%
>     next j
>     if sum <> (i - 1% + N) then
>         print "Integer test error"
>         stop
>     end if
> next i
> call sys$gettim(t2)
> call printres(t1, t2, nintscale, N, "integer operations")
>
> end sub
>


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486