On 5/2/2023 1:27 PM, Simon Clubley wrote:
> On 2023-05-01, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> String operations (*)
>> Alpha sim Itanium
>> (no JIT) (older)
>> C 0.076 1.94
>> Pascal 0.005 0.32
>> Fortran 0.002 0.07
>> Basic 0.039 1.31
>> Ada (gnat make) 0.005 -
>> Ada (gnat make -gnatp "-O3") 0.005 -
>> Java 5 0.033 -
>> Java 8 - 1.76
>> Python 2 0.005 -
>> Python 3 - 0.65
>>
>> *) string operations are done "natural", which means that they are done
>> different in different languages.

> std::string would be interesting here if you have access to a C++ compiler.

C++ on Alpha simulator gives 0.005.

> What string operations are you performing ? Is it simple concatenation or
> something else ? The number of concatenations versus the size of each
> concatenation could also make a difference, at least for the dynamically
> allocated strings.

It is concatanations and substring operations.

VMS Pascal version:

const
ALFA = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ';
VMS_FACTOR = 100;

procedure teststr(scale : integer);

var
i, j, nstrscale, ix, ix1, ix2 : integer;
s, buf : string;
t1, t2 : Cardinal;

begin
nstrscale := NSTR div scale;
t1 := Clock;
for i := 1 to nstrscale * VMS_FACTOR do begin
buf := '';
for j := 1 to ((N div VMS_FACTOR) div 10) do begin
s := ALFA + ALFA;
ix := (i - 1 + 10 * (j - 1)) mod length(ALFA);
buf := buf + substr(s, ix + 1, 1) + substr(s, ix + 2, 2) +
substr(s, ix + 4, 3) + substr(s, ix + 7, 4);
end;
ix1 := (N div VMS_FACTOR) div 3;
ix2 := 2 * (N div VMS_FACTOR) div 3;
if (length(buf) <> (N div VMS_FACTOR)) or
(buf[ix1] <> ALFA[((i - 1 + ix1 - 1) mod length(ALFA)) + 1]) or
(buf[ix2] <> ALFA[((i - 1 + ix2 - 1) mod length(ALFA)) + 1])
then begin
writeln('String test error');
halt;
end;
end;
t2 := Clock;
printres(t1, t2, nstrscale, N div 10, 'string operations');
end;

Arne

On 5/3/2023 11:45 AM, Arne Vajhøj wrote:
> On 5/2/2023 1:27 PM, Simon Clubley wrote:
>> std::string would be interesting here if you have access to a C++
>> compiler.
>
> C++ on Alpha simulator gives 0.005.

Note that is with an inner loop of:

for(int j = 0; j < N / VMS_FACTOR; j = j + 10)
{
s = ALFA + ALFA;
int ix = (i + j) % ALFA.length();
buf.append(s, ix, 1);
buf.append(s, ix + 1, 2);
buf.append(s, ix + 3, 3);
buf.append(s, ix + 6, 4);
}

not:

for(int j = 0; j < N / VMS_FACTOR; j = j + 10)
{
s = ALFA + ALFA;
int ix = (i + j) % ALFA.length();
buf = buf + s.substr(ix, 1) + s.substr(ix + 1, 2) +
s.substr(ix + 3, 3) + s.substr(ix + 6, 4);
}

That ones gives 0.004 - and without the VMS_FACTOR then that
one would totally die performance wise.

Arne

On 2023-05-03, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 5/2/2023 1:27 PM, Simon Clubley wrote:
>
>> std::string would be interesting here if you have access to a C++ compiler.
>
> C++ on Alpha simulator gives 0.005.
>

Thanks. It's interesting seeing how various languages compare.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 5/4/2023 8:18 AM, Simon Clubley wrote:
> On 2023-05-03, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 5/2/2023 1:27 PM, Simon Clubley wrote:
>>
>>> std::string would be interesting here if you have access to a C++ compiler.
>>
>> C++ on Alpha simulator gives 0.005.
>>
>
> Thanks. It's interesting seeing how various languages compare.

Just realized that I had an error in the calculation for
string performance in Fortran and Basic (I fucked up with the
VMS_FACTOR constant that is used to keep string length under
32K).

So again with C++ and (hopefully) with Fortran and Basic
correct for string operations:

Integer operations
Alpha sim Itanium
(no JIT) (older)
C, C++, Pascal, Fortran 24-29 246
Basic 5 38
Ada (gnat make) 8 -
Ada (gnat make -gnatp "-O3") 44 -
Java 5 11 -
Java 8 - 286
Python 2 0.05 -
Python 3 - 0.6

String operations
Alpha sim Itanium
(no JIT) (older)
C 0.078 1.94
C++ 0.049 0.40
Pascal 0.005 0.32
Fortran 0.156 6.94
Basic 0.004 0.13
Ada (gnat make) 0.005 -
Ada (gnat make -gnatp "-O3") 0.005 -
Java 5 0.033 -
Java 8 - 1.76
Python 2 0.005 -
Python 3 - 0.065

Again the string numbers are not so much a reflection on
compiler efficiency but more a reflection on how string
operations are done "natural" in the language - static
vs dynamic etc..

If someone want to check themselves the sources are
available at https://www.vajhoej.dk/arne/temp/bm.zip !

Arne

On Sunday, May 7, 2023 at 11:55:00 AM UTC-4, Arne Vajhøj wrote:
> If someone want to check themselves the sources are
> available at https://www.vajhoej.dk/arne/temp/bm.zip !

Here's what I get on my emulated Alpha (AlphaVM-Pro 1.5.73 JIT3) on dual E5-2643 v3 CPUs (only the first result from each test run reported):
2_SERVER::$ @test.com
C:
337.8378 million integer operations per second
35.2113 million floating point operations per second
3.4483 million string operations per second
C:
342.4658 million integer operations per second
35.2113 million floating point operations per second
3.4483 million string operations per second
C++:
359.7122 million integer operations per second
35.2113 million floating point operations per second
0.1748 million string operations per second
Pascal:
357.1428 million integer operations per second
35.7143 million floating point operations per second
0.2174 million string operations per second
Fortran:
343.6426 million integer operations per second
35.3357 million floating point operations per second
7.6923 million string operations per second
Fortran:
344.8276 million integer operations per second
35.3357 million floating point operations per second
8.3333 million string operations per second
Basic:
24.6609 million integer operations per second
28.4091 million floating point operations per second
0.1416 million string operations per second
Basic:
24.5038 million integer operations per second
28.8184 million floating point operations per second
0.1408 million string operations per second
[No Ada, Java or Python installed.]

On 08/05/2023 04:30, terry-...@glaver.org wrote:
> On Sunday, May 7, 2023 at 11:55:00 AM UTC-4, Arne Vajhøj wrote:
>> If someone want to check themselves the sources are
>> available at https://www.vajhoej.dk/arne/temp/bm.zip !
>
> Here's what I get on my emulated Alpha (AlphaVM-Pro 1.5.73 JIT3) on dual E5-2643 v3 CPUs (only the first result from each test run reported):
> 2_SERVER::$ @test.com
> C:
> 337.8378 million integer operations per second
> 35.2113 million floating point operations per second
> 3.4483 million string operations per second
> C:
> 342.4658 million integer operations per second
> 35.2113 million floating point operations per second
> 3.4483 million string operations per second
> C++:
> 359.7122 million integer operations per second
> 35.2113 million floating point operations per second
> 0.1748 million string operations per second
> Pascal:
> 357.1428 million integer operations per second
> 35.7143 million floating point operations per second
> 0.2174 million string operations per second
> Fortran:
> 343.6426 million integer operations per second
> 35.3357 million floating point operations per second
> 7.6923 million string operations per second
> Fortran:
> 344.8276 million integer operations per second
> 35.3357 million floating point operations per second
> 8.3333 million string operations per second
> Basic:
> 24.6609 million integer operations per second
> 28.4091 million floating point operations per second
> 0.1416 million string operations per second
> Basic:
> 24.5038 million integer operations per second
> 28.8184 million floating point operations per second
> 0.1408 million string operations per second
>
> [No Ada, Java or Python installed.]

Interesting that BASIC show integer as slower than FP

--
Chris

On 5/8/2023 7:23 AM, Chris Townley wrote:
> On 08/05/2023 04:30, terry-...@glaver.org wrote:
>> On Sunday, May 7, 2023 at 11:55:00 AM UTC-4, Arne Vajhøj wrote:
>>> If someone want to check themselves the sources are
>>> available at https://www.vajhoej.dk/arne/temp/bm.zip !
>>
>> Here's what I get on my emulated Alpha (AlphaVM-Pro 1.5.73 JIT3) on
>> dual E5-2643 v3 CPUs (only the first result from each test run reported):
>> 2_SERVER::$ @test.com
>> C:
>> 337.8378 million integer operations per second
>> 35.2113 million floating point operations per second
>> 3.4483 million string operations per second

Amazing so fast Alpha sim with JIT is. It is more than
x10 without JIT.

>>   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

On Monday, May 8, 2023 at 11:36:50 AM UTC-4, Arne Vajhøj wrote:
> Amazing so fast Alpha sim with JIT is. It is more than
> x10 without JIT.

Yes. I asked for a demo of AlphaVM-Pro after trying the (then-available) AlphaVM-Free. I evaluated it under Windows, but I couldn't deal with Windows updates, reboots, etc. killing the VM. So I asked for a quote for a port to FreeBSD (the Linux version of AlphaVM-Pro had enough Linuxisms in it that it wouldn't run under FreeBSD's Linux emulation). We eventually roped in a couple of FreeBSD developers to deal with some gnarly issues, both "how do I do this on FreeBSD" as well as to fix some interesting bugs in seldom-used FreeBSD code*. I've been running it for over 10 years now and have been extremely satisfied with it. I know the author has sold other licenses for the FreeBSD version as well.

* For example, a bug introduced in the FreeBSD SCSI passthru code in the 9.x timeframe caused a $ BACKUP/VERIFY to a physical tape to report a bogus I/O error after doing the rewind and starting the verify pass. VMS drivers do some odd things with SCSI, probably due to the historical differences between "DEC SCSI", "Apple SCSI" and "Regular SCSI".

Arne Vajhøj <arne@vajhoej.dk> writes:

> My point was that if someone took the 28.2 source and
> put back all the #ifdef vms code from 21.2 then what would
> be missing? How much of the new stuff added would require
> new #ifdef vms code?
>
> I don't think I have played with GNU Emacs since VMS VAX
> days (early 90's) and I have no idea about what has been added
> to GNU Emacs the last few decades, but I am sort of guessing
> that the new stuff would be most "edit stuff" and not
> so much "system interface stuff". Of course I could
> be totally wrong.

Indeed. The only major change is that compared to 21.1, Emacs now uses
much more of Gnulib to provide OS specific code. Adding back the VMS
code should still be straightforward, but moving much of it into Gnulib
would be even better.

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-...@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!

--
Chris

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-...@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.

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

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-...@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
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
for j = 1 to N
sum = ((sum + 1) * 2 + 1) / 2
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

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

--
Chris

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:
>>> 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.
>
> 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 can confirm that.

By changing 1 to 1% and 2 to 2% then the results are
way more as expected.

In fact BASIC is only about 25% slower than the
other native languages and BASIC/NOCHECK is
just as fast as the other native languages.

When one knows what to look for then it is
easy to find.

The VMS Basic Reference Manual says:

<quote>
An integer constant is a literal or named constant, either positive or
negative,
with no fractional digits and an optional trailing percent sign (%). The
percent
sign is required for integer literals only if the default type is not
INTEGER.
</quote>

And HELP BAS /TYPE says:

<quote>
The default is /TYPE_DEFAULT = REAL.
</quote>

so 1 and 2 are two real constants.

So my mistake.

I will have to rerun all the tests.

Arne

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:
>>> I then changed the integer bits to append the % to all integer
>>> constants, and
>>> now get:

>>> 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)

That was the FP sub.

> My changes:
>
> sub testint(integer xscale)

I think the only important change is from:

sum = ((sum + 1) * 2 + 1) / 2

to:

sum = ((sum + 1%) * 2% + 1%) / 2%

Arne

On 10/05/2023 01:20, Arne Vajhøj wrote:
> 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:
>>>> I then changed the integer bits to append the % to all integer
>>>> constants, and
>>>> now get:
>
>>>> 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)
>
> That was the FP sub.
>
>> My changes:
>>
>> sub testint(integer xscale)
>
> I think the only important change is from:
>
> sum = ((sum + 1) * 2 + 1) / 2
>
> to:
>
> sum = ((sum + 1%) * 2% + 1%) / 2%
>
> Arne
>

Correct - sorry - my bad cut and paste

Still at least we got to the bottom of it. Using the % sign was part of
our standards using VAX/DEC/Compaq/HP Basic

--
Chris

On 5/9/2023 8:34 PM, Chris Townley wrote:
> Still at least we got to the bottom of it. Using the % sign was part of
> our standards using VAX/DEC/Compaq/HP Basic

And an example that one should not blindly assume that
all programming languages follow the same conventions
about literals.

I actually already knew about such an example.

It is very very common that a language supports 123.45f for
32 bit FP and 123.45d for 64 bit FP and the language got some
standard for whether 123.45 default to 32 or 64 bit FP (aka
has an implicit f or d suffix).

Java:

public class WhatFP {
public static void printType(Object o) {
System.out.println(o.getClass().getName());
}
public static void main(String[] args) {
printType(123.45f);
printType(123.45d);
printType(123.45);
}
}

outputs:

java.lang.Float
java.lang.Double
java.lang.Double

works that way.

So one gets surprised when working with Groovy:

println(123.45f.class.name)
println(123.45d.class.name)
println(123.45.class.name)

outputs:

java.lang.Float
java.lang.Double
java.math.BigDecimal

Arne

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-...@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@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 5/9/2023 8:20 PM, Arne Vajhøj wrote:
> 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:
>>>> I then changed the integer bits to append the % to all integer constants, and
>>>> now get:
>
>>>> 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)
>
> That was the FP sub.
>
>> My changes:
>>
>> sub testint(integer xscale)
>
> I think the only important change is from:
>
> sum = ((sum + 1) * 2 + 1) / 2
>
> to:
>
> sum = ((sum + 1%) * 2% + 1%) / 2%
>
> Arne
>
>
>

Yes, no conversions.

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

On 5/9/2023 8:17 PM, Arne Vajhøj 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:
>>>> 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.
>>
>> 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 can confirm that.
>
> By changing 1 to 1% and 2 to 2% then the results are
> way more as expected.
>
> In fact BASIC is only about 25% slower than the
> other native languages and BASIC/NOCHECK is
> just as fast as the other native languages.
>
> When one knows what to look for then it is
> easy to find.
>
> The VMS Basic Reference Manual says:
>
> <quote>
> An integer constant is a literal or named constant, either positive or negative,
> with no fractional digits and an optional trailing percent sign (%). The percent
> sign is required for integer literals only if the default type is not INTEGER.
> </quote>
>
> And HELP BAS /TYPE says:
>
> <quote>
> The default is /TYPE_DEFAULT = REAL.
> </quote>
>
> so 1 and 2 are two real constants.
>
> So my mistake.
>
> I will have to rerun all the tests.
>
> Arne
>
>
>

The defaults in Basic are LONG integers and Single FP. A number, such as 1, is
treated as a single precision FP, so that makes not being specific even worse.

Note, I really don't like the FP default. Any program I write specifies the
defaults for both integers and FP. Something like:

OPTION SIZE = ( INTEGER WORD , REAL DOUBLE )

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

On 10/05/2023 04:39, Dave Froble wrote:

>
> The defaults in Basic are LONG integers and Single FP.  A number, such
> as 1, is treated as a single precision FP, so that makes not being
> specific even worse.
>
> Note, I really don't like the FP default.  Any program I write specifies
> the defaults for both integers and FP.  Something like:
>
> OPTION SIZE = ( INTEGER WORD , REAL DOUBLE )
>

Our coding standards insisted on

OPTION TYPE = EXPLICIT

--
Chris

On 2023-05-10 11:59, Chris Townley wrote:
> On 10/05/2023 04:39, Dave Froble wrote:
>
>>
>> The defaults in Basic are LONG integers and Single FP.  A number, such
>> as 1, is treated as a single precision FP, so that makes not being
>> specific even worse.
>>
>> Note, I really don't like the FP default.  Any program I write
>> specifies the defaults for both integers and FP.  Something like:
>>
>> OPTION SIZE = ( INTEGER WORD , REAL DOUBLE )
>>
>
> Our coding standards insisted on
>
> OPTION TYPE = EXPLICIT

That actually don't solve the problem observed here.
That only makes the compiler give errors if you don't explicitly declare
variables. However constants are still being of the default type defined.

Johnny

On 2023-05-10 00:38, Chris Townley wrote:

> 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

Here is still an untyped 1...

>         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

But yeah, classic BASIC issue. Default all values are FP.

Johnny

On 5/9/2023 11:32 PM, Dave Froble wrote:
> On 5/9/2023 6:38 PM, Chris Townley wrote:
>> 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.

sum has to be FP in testfp.

The problem was in testint.

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

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

so:

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

And that was the problem.

The assumption that 1 and 2 were integer literals.

Arne

On 5/10/2023 9:16 AM, Johnny Billquist wrote:
> On 2023-05-10 11:59, Chris Townley wrote:
>> On 10/05/2023 04:39, Dave Froble wrote:
>>> The defaults in Basic are LONG integers and Single FP.  A number,
>>> such as 1, is treated as a single precision FP, so that makes not
>>> being specific even worse.
>>>
>>> Note, I really don't like the FP default.  Any program I write
>>> specifies the defaults for both integers and FP.  Something like:
>>>
>>> OPTION SIZE = ( INTEGER WORD , REAL DOUBLE )
>>
>> Our coding standards insisted on
>>
>> OPTION TYPE = EXPLICIT
>
> That actually don't solve the problem observed here.
> That only makes the compiler give errors if you don't explicitly declare
> variables. However constants are still being of the default type defined.

I am not a Basic person so not sure how much my opinion
should count, but I think it would be nice with:

$ BASIC/VAR_TYPE_DEFAULT=EXPLICIT/LITERAL_TYPE_DEFAULT=INTEGER ...

Arne

On 10/05/2023 16:00, Arne Vajhøj wrote:
> On 5/10/2023 9:16 AM, Johnny Billquist wrote:
>> On 2023-05-10 11:59, Chris Townley wrote:
>>> On 10/05/2023 04:39, Dave Froble wrote:
>>>> The defaults in Basic are LONG integers and Single FP.  A number,
>>>> such as 1, is treated as a single precision FP, so that makes not
>>>> being specific even worse.
>>>>
>>>> Note, I really don't like the FP default.  Any program I write
>>>> specifies the defaults for both integers and FP.  Something like:
>>>>
>>>> OPTION SIZE = ( INTEGER WORD , REAL DOUBLE )
>>>
>>> Our coding standards insisted on
>>>
>>> OPTION TYPE = EXPLICIT
>>
>> That actually don't solve the problem observed here.
>> That only makes the compiler give errors if you don't explicitly
>> declare variables. However constants are still being of the default
>> type defined.
>
> I am not a Basic person so not sure how much my opinion
> should count, but I think it would be nice with:
>
> $ BASIC/VAR_TYPE_DEFAULT=EXPLICIT/LITERAL_TYPE_DEFAULT=INTEGER ...
>
> Arne

When using Basic, it is not difficult to get in the habit of using %, or
if valid FP use, for example, 1.0
Within my team I would always check for this in code reviews

--
Chris