The folloing description applies to Gforth, but I think that it
applies to many Forth systems, because this aspect is derived from a
common ancestor (probably one of Forth, Inc.'s early systems):

The word # (used in, e.g., ".") internally calls UD/MOD, which
requires two double-by-single divisions:

: ud/mod ( ud1 u2 -- urem udquot ) \ gforth
\G divide unsigned double @i{ud1} by @i{u2}, resulting in a unsigned double
\G quotient @i{udquot} and a single remainder @i{urem}.
>r 0 r@ um/mod r> swap >r
um/mod r> ;

: # ( ud1 -- ud2 )
base @ ud/mod rot dup 9 u>
[ char A char 9 1+ - ] Literal and +
'0' + hold ;

Division is slow on many CPUs, and many architectures don't have a
double-by-single division instruction. So I had the idea that we
could optimize # by

1) Dealing with the case where the high word is 0 as a special case.

2) Dealing with the case where BASE contains #10 as a special case.

Using only 1) results in:

: # ( ud1 -- ud2 )
?dup-if
base @ ud/mod
else
base @ u/mod 0
then
rot dup 9 u>
[ char A char 9 1+ - ] Literal and +
'0' + hold ;

Using 1) and 2) results in:

: # ( ud1 -- ud2 )
?dup-if
base @ ud/mod
else
base @ 10 <> if
base @ u/mod 0
else
10 u/mod 0
then
then
rot dup 9 u>
[ char A char 9 1+ - ] Literal and +
'0' + hold ;

You may be wondering about the sequence "10 u/mod". Why should it be
any faster than "base @ u/mod"? Because Gforth optimizes the division
by a constant into multiplication by the reciprocal value. If you
decompile the code above, you find:

: #
?DUP-IF useraddr #112 @ ud/mod
ELSE useraddr #112 @ #10 <>
IF useraddr #112 @ u/mod #0
ELSE $7FDBE8D435F0 u/mod-stage2m
THEN
THEN #0
rot dup #9 u> #7 and + #48 + hold ;

and the "$7FDBE8D435F0 u/mod-stage2m" performs the multiplication by
the reciprocal.

Of course, the quetion is if these optimizations pay off, and on which
CPUs. To put this optimization into Gforth, first I made # a deferred
word, and measured that step separately; the original code is variant
a), the one with deferred # is b), the one optimizing just the high
word is c), and the one that special-cases base #10 is d). Also, we
optimize the high word without converting # into a deferred word; this
is e).

Measurement with:

perf stat -e cycles:u -e instructions:u -r 10 gforth-fast -e ': print-nums 0 do i . loop ; [: 1000000 print-nums ;] >string-execute type bye' >/dev/null
for i in '(#)' '(#1)' '(#2)'; do perf stat -e cycles:u -e instructions:u -r 10 gforth-fast -e "' $i is # : print-nums 0 do i . loop ; [: 1000000 print-nums ;] >string-execute type bye" >/dev/null; done

This benchmark is the best case for these optimizations, but I think
it is representative of how # is used.

Results (in Million cycles user time):

Skylake Rocket Zen3 A72 U74
979 736 798 1506 6482 a) Original
1001 745 817 1488 6521 b) deferred #
839 653 722 1052 3772 c) special-case high=0
825 732 816 1466 3903 d) also special-case base=#10
836 650 725 1064 3563 e) special-case high=0, no deferred #

Skylake: Core i5-6600K
Rocket: Xeon W-1370P
Zen3: Ryzen 7 5800X
A72: RockPro64
U74: Starfive Visonfive

Making # deferred costs quite a bit more than I had expected (I had
actually expected that there would be no cost on the out-of-order CPUs
(the first four); when eliminating the deferred word, I see no real
speedups on the OoO CPUs, which supports my expectation, but is in
contradiction to the results I saw when making # deferred. Strange.

Special-casing high=0 is beneficial in all cases.

Special-casing base=#10 only helps the Skylake. On the other CPUs
apparently division is cheap enough and the overhead of separating
this case is expensive enough that separating this case does not pay
off. The slowdown from this special case on the A72 is surprisingly
large.

Overall, my conclusion is to keep the high=0 special case, and forget
about the base=#10 one.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 2022-03-11 14:09, Anton Ertl wrote:
> The folloing description applies to Gforth, but I think that it
> applies to many Forth systems, because this aspect is derived from a
> common ancestor (probably one of Forth, Inc.'s early systems):
....
> Measurement with:
>
> perf stat -e cycles:u -e instructions:u -r 10 gforth-fast -e ': print-nums 0 do i . loop ; [: 1000000 print-nums ;] >string-execute type bye' >/dev/null
> for i in '(#)' '(#1)' '(#2)'; do perf stat -e cycles:u -e instructions:u -r 10 gforth-fast -e "' $i is # : print-nums 0 do i . loop ; [: 1000000 print-nums ;] >string-execute type bye" >/dev/null; done
>
> This benchmark is the best case for these optimizations, but I think
> it is representative of how # is used.
>
> Results (in Million cycles user time):
>
> Skylake Rocket Zen3 A72 U74
> 979 736 798 1506 6482 a) Original
> 1001 745 817 1488 6521 b) deferred #
> 839 653 722 1052 3772 c) special-case high=0
> 825 732 816 1466 3903 d) also special-case base=#10
> 836 650 725 1064 3563 e) special-case high=0, no deferred #
>
> Skylake: Core i5-6600K
> Rocket: Xeon W-1370P
> Zen3: Ryzen 7 5800X
> A72: RockPro64
> U74: Starfive Visonfive
>
> Making # deferred costs quite a bit more than I had expected (I had
> actually expected that there would be no cost on the out-of-order CPUs
> (the first four); when eliminating the deferred word, I see no real
> speedups on the OoO CPUs, which supports my expectation, but is in
> contradiction to the results I saw when making # deferred. Strange.
>
> Special-casing high=0 is beneficial in all cases.
>
> Special-casing base=#10 only helps the Skylake. On the other CPUs
> apparently division is cheap enough and the overhead of separating
> this case is expensive enough that separating this case does not pay
> off. The slowdown from this special case on the A72 is surprisingly
> large.
>
> Overall, my conclusion is to keep the high=0 special case, and forget
> about the base=#10 one.
>
> - anton

Thank you. I have to say I enjoy your very detailed perf analyses. And
the counter-intuitive results are what I have come to expect, TBH, from
my own investigations.

Optimizing isn't for the faint-hearted or those who don't measure results.

On 3/11/22 06:09, Anton Ertl wrote:
> The folloing description applies to Gforth, but I think that it
> applies to many Forth systems, because this aspect is derived from a
> common ancestor (probably one of Forth, Inc.'s early systems):
>
> The word # (used in, e.g., ".") internally calls UD/MOD, which
> requires two double-by-single divisions:
>
> : ud/mod ( ud1 u2 -- urem udquot ) \ gforth
> \G divide unsigned double @i{ud1} by @i{u2}, resulting in a unsigned double
> \G quotient @i{udquot} and a single remainder @i{urem}.
> >r 0 r@ um/mod r> swap >r
> um/mod r> ;
>
> : # ( ud1 -- ud2 )
> base @ ud/mod rot dup 9 u>
> [ char A char 9 1+ - ] Literal and +
> '0' + hold ;
>
....

Interesting. UD/MOD is not present in kForth. When I looked at the
implementation of "#" it uses the non-standard word UTM/ to perform the
division, which should be far more expensive. So there's a significant
speedup to be had for number to string conversion here.

>
> Special-casing high=0 is beneficial in all cases.
>
> Special-casing base=#10 only helps the Skylake. On the other CPUs
> apparently division is cheap enough and the overhead of separating
> this case is expensive enough that separating this case does not pay
> off. The slowdown from this special case on the A72 is surprisingly
> large.
>
> Overall, my conclusion is to keep the high=0 special case, and forget
> about the base=#10 one.
>

Good to know. Thanks.

--
Krishna

On Friday, March 11, 2022 at 8:04:20 AM UTC-5, Anton Ertl wrote:

> Overall, my conclusion is to keep the high=0 special case, and forget
> about the base=#10 one.
>
I have been noodling on this myself.
It makes me wonder if we are breaking a rule of Forth by having one word, '#' used for two purposes:
- Printing single cell integers
- printing double integers

# goes back a long way and was probably a compromise to save space in those days. (?)

And like Ron I too enjoy your detailed analysis. Thanks.

Brian Fox <brian.fox@brianfox.ca> writes:
>I have been noodling on this myself.
>It makes me wonder if we are breaking a rule of Forth by having one word, '#' used for two purposes:
>- Printing single cell integers
>- printing double integers
>
># goes back a long way and was probably a compromise to save space in those days. (?)

I expect that that's the case. I also guess that the common case was
to output the result of # to some relatively slow device, like a
serial terminal or a printer, so optimizing # for speed was not
important, while space was at a premium.

And even when RAM became plentiful, the performance of # was never
enough of a problem that the relatively simple optimization of
special-casing high=0 was applied (not in Gforth, and looking at
SwiftForth, not in SwiftForth, either).

As for breaking a rule of Forth, the result of always dealing with
doubles is simpler than that of having an additional separate set of
words good only for single-cell numbers. So I don't see which rule
you mean.

I also expect that my special-casing of the high=0 case gives most of
the benefit of a single-cell variant of # (and friends) at a minimal
cost in code size.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Krishna Myneni schrieb am Freitag, 11. März 2022 um 14:46:12 UTC+1:
> On 3/11/22 06:09, Anton Ertl wrote:
> > The folloing description applies to Gforth, but I think that it
> > applies to many Forth systems, because this aspect is derived from a
> > common ancestor (probably one of Forth, Inc.'s early systems):
> >
> > The word # (used in, e.g., ".") internally calls UD/MOD, which
> > requires two double-by-single divisions:
> >
> > : ud/mod ( ud1 u2 -- urem udquot ) \ gforth
> > \G divide unsigned double @i{ud1} by @i{u2}, resulting in a unsigned double
> > \G quotient @i{udquot} and a single remainder @i{urem}.
> > >r 0 r@ um/mod r> swap >r
> > um/mod r> ;
> >
> > : # ( ud1 -- ud2 )
> > base @ ud/mod rot dup 9 u>
> > [ char A char 9 1+ - ] Literal and +
> > '0' + hold ;
> >
> ...
>
> Interesting. UD/MOD is not present in kForth. When I looked at the
> implementation of "#" it uses the non-standard word UTM/ to perform the
> division, which should be far more expensive. So there's a significant
> speedup to be had for number to string conversion here.
> >
> > Special-casing high=0 is beneficial in all cases.
> >
> > Special-casing base=#10 only helps the Skylake. On the other CPUs
> > apparently division is cheap enough and the overhead of separating
> > this case is expensive enough that separating this case does not pay
> > off. The slowdown from this special case on the A72 is surprisingly
> > large.
> >
> > Overall, my conclusion is to keep the high=0 special case, and forget
> > about the base=#10 one.
> >
> Good to know. Thanks.
>

I was wondering whether there is much to be won by making #
faster and thus more complex. I don't want negativity in here
but # is practically always followed by some terminal output
which is by magnitudes slower than #.

On 3/11/22 13:36, minf...@arcor.de wrote:
> Krishna Myneni schrieb am Freitag, 11. März 2022 um 14:46:12 UTC+1:
>> On 3/11/22 06:09, Anton Ertl wrote:
>>> The folloing description applies to Gforth, but I think that it
....
>>> The word # (used in, e.g., ".") internally calls UD/MOD, which
>>> requires two double-by-single divisions:
>>>
>>> : ud/mod ( ud1 u2 -- urem udquot ) \ gforth
>>> \G divide unsigned double @i{ud1} by @i{u2}, resulting in a unsigned double
>>> \G quotient @i{udquot} and a single remainder @i{urem}.
>>>> r 0 r@ um/mod r> swap >r
>>> um/mod r> ;
>>>
>>> : # ( ud1 -- ud2 )
>>> base @ ud/mod rot dup 9 u>
>>> [ char A char 9 1+ - ] Literal and +
>>> '0' + hold ;
>>>
>> ...
>>
>> Interesting. UD/MOD is not present in kForth. When I looked at the
>> implementation of "#" it uses the non-standard word UTM/ to perform the
>> division, which should be far more expensive. So there's a significant
>> speedup to be had for number to string conversion here.
>>>
>>> Special-casing high=0 is beneficial in all cases.
>>>
....
>>> Overall, my conclusion is to keep the high=0 special case, and forget
>>> about the base=#10 one.
>>>
....
>
> I was wondering whether there is much to be won by making #
> faster and thus more complex. I don't want negativity in here
> but # is practically always followed by some terminal output
> which is by magnitudes slower than #.

It's often true that number to string conversion may be followed by
terminal output, but it could also be file output (a case which I use
often). Some testing with file output will reveal whether the efficiency
gain is significant.

The reverse problem is usually more important, parsing a string and
converting to numeric fields. This can be slow if the parsing and
conversion is not optimized! I've been working on speeding this up in
the kForth string library (there's room for significant improvement
here). A recent need has been to export a spreadsheet (OpenOffice or
Excel) to a csv file, from which I want to extract specific columns and
write them out to a separate text file. There are command line tools for
this but I want a Forth tool which can be specialized for handling
specific cases.

--
Krishna

"minf...@arcor.de" <minforth@arcor.de> writes:
>I was wondering whether there is much to be won by making #
>faster and thus more complex. I don't want negativity in here
>but # is practically always followed by some terminal output
>which is by magnitudes slower than #.

Let's test the latter claim first:

time gforth-fast -e ": foo 1000000 0 do 1111111111 . loop ; foo bye" >/dev/null
real 0m0.310s
user 0m0.310s
sys 0m0.000s
time gforth-fast -e ': foo 1000000 0 do ." 1111111111 " loop ; foo bye'
....
real 0m1.267s
user 0m0.298s
sys 0m0.692s

So # is indeed faster than output on an xterm, although not by a
magnitude, much less magnitudes.

Anyway, occasionally the cost of # has been relevant for performance,
e.g., when writing the result to a file, or when using it in a hash
table.

The classic way to deal with such problems is to design a hand-written
special-purpose conversion routine. If you compare such routines with
the effort required for a faster #, the faster # usually has much less
complexity; if its performance is good enough, it's probably the
better solution.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On Friday, March 11, 2022 at 2:36:26 PM UTC-5, minf...@arcor.de wrote:
> Krishna Myneni schrieb am Freitag, 11. März 2022 um 14:46:12 UTC+1:
> > On 3/11/22 06:09, Anton Ertl wrote:
> > > The folloing description applies to Gforth, but I think that it
> > > applies to many Forth systems, because this aspect is derived from a
> > > common ancestor (probably one of Forth, Inc.'s early systems):
> > >
> > > The word # (used in, e.g., ".") internally calls UD/MOD, which
> > > requires two double-by-single divisions:
> > >
> > > : ud/mod ( ud1 u2 -- urem udquot ) \ gforth
> > > \G divide unsigned double @i{ud1} by @i{u2}, resulting in a unsigned double
> > > \G quotient @i{udquot} and a single remainder @i{urem}.
> > > >r 0 r@ um/mod r> swap >r
> > > um/mod r> ;
> > >
> > > : # ( ud1 -- ud2 )
> > > base @ ud/mod rot dup 9 u>
> > > [ char A char 9 1+ - ] Literal and +
> > > '0' + hold ;
> > >
> > ...
> >
> > Interesting. UD/MOD is not present in kForth. When I looked at the
> > implementation of "#" it uses the non-standard word UTM/ to perform the
> > division, which should be far more expensive. So there's a significant
> > speedup to be had for number to string conversion here.
> > >
> > > Special-casing high=0 is beneficial in all cases.
> > >
> > > Special-casing base=#10 only helps the Skylake. On the other CPUs
> > > apparently division is cheap enough and the overhead of separating
> > > this case is expensive enough that separating this case does not pay
> > > off. The slowdown from this special case on the A72 is surprisingly
> > > large.
> > >
> > > Overall, my conclusion is to keep the high=0 special case, and forget
> > > about the base=#10 one.
> > >
> > Good to know. Thanks.
> >
> I was wondering whether there is much to be won by making #
> faster and thus more complex. I don't want negativity in here
> but # is practically always followed by some terminal output
> which is by magnitudes slower than #.

I thought # is commonly used in formatting strings which may or may not be coupled with terminal I/O, which is not always slow. I/O is not always on serial ports these days. Even if it were, once in a buffer, the I/O can be interrupt driven, with the main process having other things to do.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

On Friday, March 11, 2022 at 11:14:45 AM UTC-5, Brian Fox wrote:
> On Friday, March 11, 2022 at 8:04:20 AM UTC-5, Anton Ertl wrote:
>
> > Overall, my conclusion is to keep the high=0 special case, and forget
> > about the base=#10 one.
> >
> I have been noodling on this myself.
> It makes me wonder if we are breaking a rule of Forth by having one word, '#' used for two purposes:
> - Printing single cell integers
> - printing double integers
>
> # goes back a long way and was probably a compromise to save space in those days. (?)

When you say, two purposes, you mean to convert single precision words by making then double precision words before formatting? I suppose C does it with separate functions, but the print library code is pretty big from what I recall.

So # is used for double precision words. Would anything else need to change to work with single precision? I guess #> would also need to change. <# would not I think, but for consistency a synonym word would be appropriate.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

On Friday, March 11, 2022 at 11:51:04 PM UTC+1, Anton Ertl wrote:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> >I was wondering whether there is much to be won by making #
> >faster and thus more complex. I don't want negativity in here
> >but # is practically always followed by some terminal output
> >which is by magnitudes slower than #.
> Let's test the latter claim first:
>
> time gforth-fast -e ": foo 1000000 0 do 1111111111 . loop ; foo bye" >/dev/null
> real 0m0.310s
> user 0m0.310s
> sys 0m0.000s
> time gforth-fast -e ': foo 1000000 0 do ." 1111111111 " loop ; foo bye'
> ...
> real 0m1.267s
> user 0m0.298s
> sys 0m0.692s
>
> So # is indeed faster than output on an xterm, although not by a
> magnitude, much less magnitudes.
That depends on the OS, and on implementation preferences:

FORTH> : foo STD-I//O SET-IODEVICE cr timer-reset 1000000 0 do 1111111111 . loop STD-I/O SET-IODEVICE .elapsed ; foo
.... 1111111 1111111111 88.891 seconds elapsed. ok
( 2.184 seconds elapsed under the WSL2 )

FORTH> : foo FILE-I//O SET-IODEVICE cr timer-reset 1000000 0 do 1111111111 . loop STD-I//O SET-IODEVICE .elapsed ; foo 0.094 seconds elapsed. ok
( 0.092 seconds under the WSL2 )

-marcel

On 12/03/2022 06:36, minf...@arcor.de wrote:
> ...
> I was wondering whether there is much to be won by making #
> faster and thus more complex. I don't want negativity in here
> but # is practically always followed by some terminal output
> which is by magnitudes slower than #.

Agreed. I/O is slow. Perhaps the greatest application of numeric
string output is floating point and # does nothing for that.

Forth standards have largely ignored numeric string out, leaving it
as an exercise for users. Never mind it actually costs more to
implement that way. I recently replaced d. u. . in an Arduino forth
with (d.) (u.) (.) d. u. . The code for the latter occupied *less*
space than the original three.

On 12/03/2022 03:14, Brian Fox wrote:
> On Friday, March 11, 2022 at 8:04:20 AM UTC-5, Anton Ertl wrote:
>
>> Overall, my conclusion is to keep the high=0 special case, and forget
>> about the base=#10 one.
>>
> I have been noodling on this myself.
> It makes me wonder if we are breaking a rule of Forth by having one word, '#' used for two purposes:
> - Printing single cell integers
> - printing double integers
>
> # goes back a long way and was probably a compromise to save space in those days. (?)

PolyForth offered doubles as an option. I don't recall whether # came
in single and double versions. For 16-bit forths, doubles is more
necessity than optional IMO.

On Friday, March 11, 2022 at 9:28:55 PM UTC-5, dxforth wrote:
> On 12/03/2022 06:36, minf...@arcor.de wrote:
> > ...
> > I was wondering whether there is much to be won by making #
> > faster and thus more complex. I don't want negativity in here
> > but # is practically always followed by some terminal output
> > which is by magnitudes slower than #.
> Agreed. I/O is slow. Perhaps the greatest application of numeric
> string output is floating point and # does nothing for that.
>
> Forth standards have largely ignored numeric string out, leaving it
> as an exercise for users. Never mind it actually costs more to
> implement that way. I recently replaced d. u. . in an Arduino forth
> with (d.) (u.) (.) d. u. . The code for the latter occupied *less*
> space than the original three.

It is funny to think that relatively speaking, a small MCU has more powerful I/O than a PC. I have written code that would process serial I/O data via interrupt allowing the main code to continue on doing what it needs to get done. The serial interface caused virtually zero delay in the main code as long as there was enough horse power.

I also recall looking at a serial port handler under one of the early Windows, probably 3.1. It was so complex and convoluted that I could not understand what the guy was doing.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

On Saturday, March 12, 2022 at 1:28:08 AM UTC+1, Marcel Hendrix wrote:
> On Friday, March 11, 2022 at 11:51:04 PM UTC+1, Anton Ertl wrote:
> > "minf...@arcor.de" <minf...@arcor.de> writes:
> > >I was wondering whether there is much to be won by making #
> > >faster and thus more complex. I don't want negativity in here
> > >but # is practically always followed by some terminal output
> > >which is by magnitudes slower than #.
> > Let's test the latter claim first:
> >
> > time gforth-fast -e ": foo 1000000 0 do 1111111111 . loop ; foo bye" >/dev/null
> > real 0m0.310s
> > user 0m0.310s
> > sys 0m0.000s
> > time gforth-fast -e ': foo 1000000 0 do ." 1111111111 " loop ; foo bye'
> > ...
> > real 0m1.267s
> > user 0m0.298s
> > sys 0m0.692s
> >
> > So # is indeed faster than output on an xterm, although not by a
> > magnitude, much less magnitudes.
> That depends on the OS, and on implementation preferences:
>
> FORTH> : foo STD-I//O SET-IODEVICE cr timer-reset 1000000 0 do 1111111111 . loop STD-I/O SET-IODEVICE .elapsed ; foo
> ... 1111111 1111111111 88.891 seconds elapsed. ok
> ( 2.184 seconds elapsed under the WSL2 )
>
> FORTH> : foo FILE-I//O SET-IODEVICE cr timer-reset 1000000 0 do 1111111111 . loop STD-I//O SET-IODEVICE .elapsed ; foo 0.094 seconds elapsed. ok
> ( 0.092 seconds under the WSL2 )
>
> -marcel

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>: ud/mod ( ud1 u2 -- urem udquot ) \ gforth
> \G divide unsigned double @i{ud1} by @i{u2}, resulting in a unsigned double
> \G quotient @i{udquot} and a single remainder @i{urem}.
> >r 0 r@ um/mod r> swap >r
> um/mod r> ;

Looking at this again, I notice that the first um/mod is actually a
single-by-single division, so on Gforth (which has single-by-single
primitives) this can be improved:

: ud/mod ( ud1 u2 -- urem udquot ) \ gforth
\G divide unsigned double @i{ud1} by @i{u2}, resulting in a unsigned double
\G quotient @i{udquot} and a single remainder @i{urem}.
dup >r u/mod r> swap >r
um/mod r> ;

On a Cortex-A72 (no double-by-single instructions on Aarch64) this
results in an improvement from:

2999656067 cycles:u
4916118703 instructions:u # 1.64 insns per cycle

to

2811393601 cycles:u
4604004500 instructions:u # 1.64 insns per cycle

Benchmark:

taskset -c 4 perf stat -e cycles:u -e instructions:u -r 10 gforth-fast -e ': print-nums 0 do 0 i <# #s #> 2drop loop ; 1000000 print-nums bye' >/dev/null

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> As for breaking a rule of Forth, the result of always dealing with
> doubles

Doubles were important when cells were 16 bits. With 32 or 64 bit
cells, do doubles matter as much as they once did? Singles are
important, and in some situations bignums are important.
Doubles... meh.

On 12/03/2022 20:45, Paul Rubin wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> As for breaking a rule of Forth, the result of always dealing with
>> doubles
>
> Doubles were important when cells were 16 bits. With 32 or 64 bit
> cells, do doubles matter as much as they once did? Singles are
> important, and in some situations bignums are important.
> Doubles... meh.

How will you random access into files without doubles?

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> As for breaking a rule of Forth, the result of always dealing with
>> doubles
>
>Doubles were important when cells were 16 bits. With 32 or 64 bit
>cells, do doubles matter as much as they once did?

For 32 bits, certainly. The number of cycles on my last 32-bit
computer overflowed an unsigned 32-bit cell in less than 4 seconds,
the number of instructions possibly even faster. The number of bytes
on my HDD overflowed an unsigned 32-bit value in the mid-90s.

Overflowing 64-bit cells is rare, though.

However, for any cell size I need double cells to implement division
through the multiplication with the reciprocal. See
<http://git.savannah.gnu.org/cgit/gforth.git/tree/stagediv.fs>

Bignums? What for?

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> However, for any cell size I need double cells to implement division...
> Bignums? What for?

Bignums eliminate a whole class of bugs and headaches related to
integers being too narrow. Double cells to implement division, and iirc
M*/ requires triple cells. If you are computing with exact rationals,
the denominators often get pretty large. Bignums are also important in
cryptography. I seem to remember that there is a situation where to
accurately convert binary floating point numbers to decimal or vice
versa, you need bignums, so gcc incorporates a bigum library for that
purpose.

I would agree that most of this stuff doesn't come up in Forth that
often. Bignums would be out of place in traditional Forth.

On 14/03/2022 20:08, Paul Rubin wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> However, for any cell size I need double cells to implement division...
>> Bignums? What for?
>
> Bignums eliminate a whole class of bugs and headaches related to
> integers being too narrow. Double cells to implement division, and iirc
> M*/ requires triple cells. If you are computing with exact rationals,
> the denominators often get pretty large. Bignums are also important in
> cryptography. I seem to remember that there is a situation where to
> accurately convert binary floating point numbers to decimal or vice
> versa, you need bignums, so gcc incorporates a bigum library for that
> purpose.
>
> I would agree that most of this stuff doesn't come up in Forth that
> often. Bignums would be out of place in traditional Forth.

'Accurate' f/p output display too it would seem. Just because something
was all the rage two decades ago doesn't mean one needed it then or now.
That Intel provided div/mul instructions which exactly mirrored UM/MOD UM*
suggests to me Forth got the basics right - at a time when C was telling
users they had to use either ints or longs.

Paul Rubin schrieb am Montag, 14. März 2022 um 10:08:19 UTC+1:
>. I seem to remember that there is a situation where to
> accurately convert binary floating point numbers to decimal or vice
> versa, you need bignums, so gcc incorporates a bigum library for that
> purpose.

How come? F.ex. the mantissa of a IEEE754 float is 54 bit wide.
Conversion of all normalized floats with zero exponent to integer
and vice versa is lossless.

Out of that range it depends on the actual approximation definition.

"minf...@arcor.de" <minforth@arcor.de> writes:
> Out of that range it depends on the actual approximation definition.

Well, you have to get the decimal digits right. I have never examined
this issue so don't know exactly why the bignums are required. I might
look into it sometime. It's possible I have some part of the story
wrong.

This seems to discuss it further down the page, but I haven't read it
all yet:

https://recompilermag.com/issues/issue-9/a-crash-course-on-floating-point-numbers-and-good-algorithms-for-printing-and-reading-them/

Decimal floating point seems like a good idea too, but that is more a
matter of wanting hardware support.

dxforth <dxforth@gmail.com> writes:
> How will you random access into files without doubles?

lseek? :-) Although, if the files are > 4GB, the cpu these days
probably has 64 bit cells.

Paul Rubin schrieb am Montag, 14. März 2022 um 10:55:58 UTC+1:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> > Out of that range it depends on the actual approximation definition.
> Well, you have to get the decimal digits right. I have never examined
> this issue so don't know exactly why the bignums are required. I might
> look into it sometime. It's possible I have some part of the story
> wrong.
>
> This seems to discuss it further down the page, but I haven't read it
> all yet:
>
> https://recompilermag.com/issues/issue-9/a-crash-course-on-floating-point-numbers-and-good-algorithms-for-printing-and-reading-them/
>
> Decimal floating point seems like a good idea too, but that is more a
> matter of wanting hardware support.

We know that fp-numbers are mostly stored with base 2 and that conversion
to/from base 10 representation is not always possible without rounding.

But why slow fat bignum packages are required to do that rounding is beyond me.