I came across this - its supposed to be a forth in python.
The only thing forthy about it is it uses stacks and postfix.

That said,I found it interesting and worth watching.

https://www.youtube.com/playlist?list=PLpM-Dvs8t0VbMZA7wW9aR3EtBqe2kinu4

On Wednesday, November 17, 2021 at 1:51:17 PM UTC+3, NN wrote:
> I came across this - its supposed to be a forth in python.
> The only thing forthy about it is it uses stacks and postfix.
>
> That said,I found it interesting and worth watching.
>
> https://www.youtube.com/playlist?list=PLpM-Dvs8t0VbMZA7wW9aR3EtBqe2kinu4

IMHO, this is the second most stupid idea -- implementing forth in python.

On Wed, 17 Nov 2021 03:25:35 -0800 (PST)
Nickolay Kolchin <nbkolchin@gmail.com> wrote:

> On Wednesday, November 17, 2021 at 1:51:17 PM UTC+3, NN wrote:
> > I came across this - its supposed to be a forth in python.
> > The only thing forthy about it is it uses stacks and postfix.
> >
> > That said,I found it interesting and worth watching.
> >
> > https://www.youtube.com/playlist?list=PLpM-Dvs8t0VbMZA7wW9aR3EtBqe2kinu4
>
> IMHO, this is the second most stupid idea -- implementing forth in python.

For speed it exports assembler text, assembles, and links to build
an executable.

For porth interaction/simulation pypy is 'strongly recommended'
because this much faster than cython.

More detail in the README.md:
https://gitlab.com/tsoding/porth/-/blob/master/README.md

Jan Coombs
--

On Wednesday, November 17, 2021 at 3:23:00 PM UTC+3, Jan Coombs wrote:
> On Wed, 17 Nov 2021 03:25:35 -0800 (PST)
> Nickolay Kolchin <nbko...@gmail.com> wrote:
>
> > On Wednesday, November 17, 2021 at 1:51:17 PM UTC+3, NN wrote:
> > > I came across this - its supposed to be a forth in python.
> > > The only thing forthy about it is it uses stacks and postfix.
> > >
> > > That said,I found it interesting and worth watching.
> > >
> > > https://www.youtube.com/playlist?list=PLpM-Dvs8t0VbMZA7wW9aR3EtBqe2kinu4
> >
> > IMHO, this is the second most stupid idea -- implementing forth in python.
> For speed it exports assembler text, assembles, and links to build
> an executable.
>
> For porth interaction/simulation pypy is 'strongly recommended'
> because this much faster than cython.
>
> More detail in the README.md:
> https://gitlab.com/tsoding/porth/-/blob/master/README.md
>
> Jan Coombs
> --

Still not convinced.

$ ./porth.py com euler/problem04.porth
[INFO] Generating euler/problem04.asm
[CMD] nasm -felf64 euler/problem04.asm
[CMD] ld -o euler/problem04 euler/problem04.o

$ time ./problem04
906609
real 0m0.042s
user 0m0.042s
sys 0m0.000s

$ time ./porth.py sim euler/problem04.porth
906609

real 4m39.338s
user 4m39.115s
sys 0m0.096s

$ time pypy3 ./porth.py sim euler/problem04.porth
906609

real 0m10.017s
user 0m9.919s
sys 0m0.030s

Nickolay Kolchin <nbkolchin@gmail.com> writes:
> $ ./porth.py com euler/problem04.porth ...
> $ time ./problem04
> 906609
> real 0m0.042s
> user 0m0.042s
> sys 0m0.000s

That doesn't look bad to me. Gforth is much slower, though my
implementation may have been worse than yours. Either nway, I'd count
Porth's compiled speed as more important than Python-simulated speed.

time gforth-fast euler04.fs
906609

real 0m0.249s
user 0m0.240s
sys 0m0.009s

On 18/11/2021 07:22, Paul Rubin wrote:
> Nickolay Kolchin <nbkolchin@gmail.com> writes:
>> $ ./porth.py com euler/problem04.porth ...
>> $ time ./problem04
>> 906609
>> real 0m0.042s
>> user 0m0.042s
>> sys 0m0.000s
>
> That doesn't look bad to me. Gforth is much slower, though my
> implementation may have been worse than yours. Either nway, I'd count
> Porth's compiled speed as more important than Python-simulated speed.
>
> time gforth-fast euler04.fs
> 906609
>
> real 0m0.249s
> user 0m0.240s
> sys 0m0.009s
>

The bigger concern is the author's starting point:

"It's like Forth but written in Python. But I don't actually know for
sure since I never programmed in Forth, I only heard that it's some
sort of stack-based programming language."

He's going to encounter the same issues Moore did. Whether he has the
same resolve and ability to solve them remains to be seen.

Writing a HLL on top of another HLL has always bothered me as it's too
easy to hide poor solutions.

On Wednesday, November 17, 2021 at 11:22:39 PM UTC+3, Paul Rubin wrote:
> Nickolay Kolchin <nbko...@gmail.com> writes:
> > $ ./porth.py com euler/problem04.porth ...
> > $ time ./problem04
> > 906609
> > real 0m0.042s
> > user 0m0.042s
> > sys 0m0.000s
> That doesn't look bad to me. Gforth is much slower, though my
> implementation may have been worse than yours. Either nway, I'd count
> Porth's compiled speed as more important than Python-simulated speed.
>
> time gforth-fast euler04.fs
> 906609
>
> real 0m0.249s
> user 0m0.240s
> sys 0m0.009s

My machine is probably faster.

$ time ~/tmp/gforth/gforth-fast euler04.fth
906609

real 0m0.041s
user 0m0.040s
sys 0m0.000s

- lxf: 0m0.017s
- SwiftForth: 0m0.020s
- Vfx32: 0m0.018s
- Vfx64: 0m0.019s
- flk: 0m0.016s

But that's not the point. 30000 times slowness in simulation mode can't be
just ignored. And pypy is "russian roulette", slight source change and it
suddenly runs slower then CPython.

\ direct porth source rewrite to normal forth
0 VALUE ans

: test
1000 100 ?DO
1000 100 ?DO
I J * DUP 0
BEGIN
OVER 0>
WHILE
10 *
OVER 10 MOD
+
SWAP 10 / SWAP
REPEAT
NIP
2DUP = IF
DUP ans > IF
DUP TO ans
THEN
THEN
2DROP
LOOP
LOOP
ans . CR
;

test BYE

On 18/11/2021 12:02, Nickolay Kolchin wrote:
> On Wednesday, November 17, 2021 at 11:22:39 PM UTC+3, Paul Rubin wrote:
>> Nickolay Kolchin <nbko...@gmail.com> writes:
>> > $ ./porth.py com euler/problem04.porth ...
>> > $ time ./problem04
>> > 906609
>> > real 0m0.042s
>> > user 0m0.042s
>> > sys 0m0.000s
>> That doesn't look bad to me. Gforth is much slower, though my
>> implementation may have been worse than yours. Either nway, I'd count
>> Porth's compiled speed as more important than Python-simulated speed.
>>
>> time gforth-fast euler04.fs
>> 906609
>>
>> real 0m0.249s
>> user 0m0.240s
>> sys 0m0.009s
>
> My machine is probably faster.
>
> $ time ~/tmp/gforth/gforth-fast euler04.fth
> 906609
>
> real 0m0.041s
> user 0m0.040s
> sys 0m0.000s
>
> - lxf: 0m0.017s
> - SwiftForth: 0m0.020s
> - Vfx32: 0m0.018s
> - Vfx64: 0m0.019s
> - flk: 0m0.016s
>
> But that's not the point. 30000 times slowness in simulation mode can't be
> just ignored. And pypy is "russian roulette", slight source change and it
> suddenly runs slower then CPython.
>
> \ direct porth source rewrite to normal forth
> 0 VALUE ans
>
> : test
> 1000 100 ?DO
> 1000 100 ?DO
> I J * DUP 0
> BEGIN
> OVER 0>
> WHILE
> 10 *
> OVER 10 MOD
> +
> SWAP 10 / SWAP
> REPEAT
> NIP
> 2DUP = IF
> DUP ans > IF
> DUP TO ans
> THEN
> THEN
> 2DROP
> LOOP
> LOOP
> ans . CR
> ;
>
> test BYE

A little neater - not necessarily faster:

: test
1000 100 DO
1000 100 DO
I J * DUP 0
BEGIN
OVER 0>
WHILE
10 * >R 10 /MOD SWAP R> +
REPEAT NIP
2DUP = IF
DUP ans MAX TO ans
THEN 2DROP
LOOP
LOOP
ans . CR
;

On Thursday, November 18, 2021 at 2:02:45 AM UTC+1, Nickolay Kolchin wrote:
> \ direct porth source rewrite to normal forth
> 0 VALUE ans
>
> : test
> 1000 100 ?DO
> 1000 100 ?DO
> I J * DUP 0
> BEGIN
> OVER 0>
> WHILE
> 10 *
> OVER 10 MOD
> +
> SWAP 10 / SWAP
> REPEAT
> NIP
> 2DUP = IF
> DUP ans > IF
> DUP TO ans
> THEN
> THEN
> 2DROP
> LOOP
> LOOP
> ans . CR
> ;
>
> test BYE

FORTH> : tt timer-reset test space .elapsed ; ok
FORTH> tt 906609
0.009 seconds elapsed. ok
FORTH> .ticker-info
AMD Ryzen 7 5800X 8-Core Processor, TICKS-GET uses iTSC at 4192MHz

-marcel

On Thursday, November 18, 2021 at 4:12:16 AM UTC+1, dxforth wrote:
[..]
FORTH> : test 1000 100 DO
[3]<3>[FORTH>] 1000 100 DO
[6]<3>[FORTH>] I J * DUP 0
[6]<3>[FORTH>] BEGIN OVER 0>
[9]<3>[FORTH>] WHILE 10 * >R 10 /MOD SWAP R> +
[12]<3>[FORTH>] REPEAT NIP
[6]<3>[FORTH>] 2DUP = IF DUP ans MAX TO ans THEN 2DROP
[6]<3>[FORTH>] LOOP
[3]<3>[FORTH>] LOOP ; ok
FORTH> ok
FORTH> : tt cr timer-reset 100 0 do test loop .elapsed space ans . ; ok
FORTH> test test test ok
FORTH> tt tt tt
0.811 seconds elapsed. 906609
0.811 seconds elapsed. 906609
0.812 seconds elapsed. 906609 ok

-marcel

Nickolay Kolchin <nbkolchin@gmail.com> writes:
>On Wednesday, November 17, 2021 at 11:22:39 PM UTC+3, Paul Rubin wrote:
>> time gforth-fast euler04.fs
>> 906609
>>
>> real 0m0.249s
>> user 0m0.240s
>> sys 0m0.009s
>
>My machine is probably faster.
>
>$ time ~/tmp/gforth/gforth-fast euler04.fth
>906609
>
>real 0m0.041s
>user 0m0.040s
>sys 0m0.000s

Or/and you are using a different version of Gforth.

Numbers below from a 4GHz Skylake (Core i5-6600K), explanations below:

cycles:u s user
181,830,977 0.049 gforth-fast 0.7.9_20211111
229,629,657 0.061 gforth-fast 0.7.9_20211111 --no-dynamic
367,998,341 0.096 gforth-fast 0.7.9_20211111 -e "' fold2-1 folds / mod"
416,948,313 0.108 gforth-fast 0.7.9_20211111 --no-dynamic -e "' fold2-1 folds / mod"
412,787,818 0.107 gforth-fast 0.7.3
173,343,023 0.044 gforth-fast 0.6.2 (32-bit)
364,124,093 0.095 gforth-fast -e "' /s alias / ' mods alias mod"
122,955,447 0.031 lxf
129,094,238 0.036 vfxlin 4.72
139,616,441 0.038 sf 3.11.0
327,688,281 0.103 flk

We see that gforth-fast 0.7.3 is more than twice as slow as
0.7.9_20211111. Why? One reason is that for the build of 0.7.3 that
I used, a sanity check disabled dynamic native code generation. To
simulate this with 0.7.9_20211111, I disabled dynamic native code
generation with --no-dynamic.

But that's not the whole story. One difference between 0.7.3 and
0.7.9_20211111 is that 0.7.9 optimizes division by constants. I
disabled this optimization with -e "' fold2-1 folds / mod" (which
still performs constant folding on / and mod, but that does not play a
role here). This optimization seems to have a big influence on
Gforth performance.

The combination of these two disablings is close enough to the 0.7.3
results to explain the difference.

However, the other results are somewhat mysterious. The gforth 0.6.2
system I measured had dynamic native code generation, but no
optimization of /. If / and mod are so slow, why is 0.6.2 (which does
not optimize them) so fast. If the 32-bitness plays a role, one would
expect a 64-bit Forth that does not optimize division by constant to
also see a big slowdown compared to its 32-bit variant, but we don't
see it:

>- Vfx32: 0m0.018s
>- Vfx64: 0m0.019s

I also tested symmetric (rather than floored) division with -e "' /s
alias / ' mods alias mod", but performance is similar to the
unoptimized floored version (Gforth has no optimization for /S and
MODS).

My FLK results are quite different from what you reported:

>- lxf: 0m0.017s
>- SwiftForth: 0m0.020s
>- Vfx32: 0m0.018s
>- Vfx64: 0m0.019s
>- flk: 0m0.016s
....
>\ direct porth source rewrite to normal forth
>0 VALUE ans
>
>: test
> 1000 100 ?DO
> 1000 100 ?DO
> I J * DUP 0
> BEGIN
> OVER 0>
> WHILE
> 10 *
> OVER 10 MOD
> +
> SWAP 10 / SWAP
> REPEAT
> NIP
> 2DUP = IF
> DUP ans > IF
> DUP TO ans
> THEN
> THEN
> 2DROP
> LOOP
> LOOP
> ans . CR
>;
>
>test BYE

- 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 Thursday, November 18, 2021 at 8:20:03 PM UTC+3, Anton Ertl wrote:
> Nickolay Kolchin <nbko...@gmail.com> writes:
> >On Wednesday, November 17, 2021 at 11:22:39 PM UTC+3, Paul Rubin wrote:
> >> time gforth-fast euler04.fs
> >> 906609
> >>
> >> real 0m0.249s
> >> user 0m0.240s
> >> sys 0m0.009s
> >
> >My machine is probably faster.
> >
> >$ time ~/tmp/gforth/gforth-fast euler04.fth
> >906609
> >
> >real 0m0.041s
> >user 0m0.040s
> >sys 0m0.000s
> Or/and you are using a different version of Gforth.
>
> Numbers below from a 4GHz Skylake (Core i5-6600K), explanations below:
>
> cycles:u s user
> 181,830,977 0.049 gforth-fast 0.7.9_20211111
> 229,629,657 0.061 gforth-fast 0.7.9_20211111 --no-dynamic
> 367,998,341 0.096 gforth-fast 0.7.9_20211111 -e "' fold2-1 folds / mod"
> 416,948,313 0.108 gforth-fast 0.7.9_20211111 --no-dynamic -e "' fold2-1 folds / mod"
> 412,787,818 0.107 gforth-fast 0.7.3
> 173,343,023 0.044 gforth-fast 0.6.2 (32-bit)
> 364,124,093 0.095 gforth-fast -e "' /s alias / ' mods alias mod"
> 122,955,447 0.031 lxf
> 129,094,238 0.036 vfxlin 4.72
> 139,616,441 0.038 sf 3.11.0
> 327,688,281 0.103 flk
>
> We see that gforth-fast 0.7.3 is more than twice as slow as
> 0.7.9_20211111. Why? One reason is that for the build of 0.7.3 that
> I used, a sanity check disabled dynamic native code generation. To
> simulate this with 0.7.9_20211111, I disabled dynamic native code
> generation with --no-dynamic.
>
> But that's not the whole story. One difference between 0.7.3 and
> 0.7.9_20211111 is that 0.7.9 optimizes division by constants. I
> disabled this optimization with -e "' fold2-1 folds / mod" (which
> still performs constant folding on / and mod, but that does not play a
> role here). This optimization seems to have a big influence on
> Gforth performance.
>
> The combination of these two disablings is close enough to the 0.7.3
> results to explain the difference.
>
> However, the other results are somewhat mysterious. The gforth 0.6.2
> system I measured had dynamic native code generation, but no
> optimization of /. If / and mod are so slow, why is 0.6.2 (which does
> not optimize them) so fast. If the 32-bitness plays a role, one would
> expect a 64-bit Forth that does not optimize division by constant to
> also see a big slowdown compared to its 32-bit variant, but we don't
> see it:
> >- Vfx32: 0m0.018s
> >- Vfx64: 0m0.019s
> I also tested symmetric (rather than floored) division with -e "' /s
> alias / ' mods alias mod", but performance is similar to the
> unoptimized floored version (Gforth has no optimization for /S and
> MODS).
>
> My FLK results are quite different from what you reported:
> >- lxf: 0m0.017s
> >- SwiftForth: 0m0.020s
> >- Vfx32: 0m0.018s
> >- Vfx64: 0m0.019s
> >- flk: 0m0.016s
> ...

The difference probably comes from Intel vs AMD.

If I remember correctly you are testing with

"perf stat -e cycles:u -e instructions:u"

Here are results from my machine (amd5950x):

Porth variant:

- porth: 184,283,728; 509,449,073; 0.040098456
- gforth-0.7.3: 606,877,605; 1,430,796,757; 0.127517408
- gforth-fast-0.7.3: 752,358,649; 1,474,773,380; 0.155099806
- gforth 0.7.9_20211104: 405,620,747; 705,471,017; 0.089281093
- gforth-fast 0.7.9_20211104: 177,980,717; 580,122,080; 0.039897830
- lxf: 77,205,380; 81,747,059; 0.017932932
- SwiftForth: 86,075,993; 141,327,609; 0.020731892
- vfxlin32: 80,978,827; 93,408,992; 0.017410421
- vfxlin64: 87,491,736; 89,573,526; 0.018919114
- spf4: 78,587,843; 119,558,838; 0.017927621
- flk: 64,926,664; 158,114,169; 0.014062649
- ikforth: 821,123,562; 1,203,932,090; 0.202385445

Dxforth variant:

- gforth-0.7.3: 493,523,584; 1,170,771,711; 0.105020759
- gforth-fast-0.7.3: 584,927,618; 1,225,635,106; 0.124608806
- gforth 0.7.9_20211104: 333,189,391; 0.071537956
- gforth-fast 0.7.9_20211104: 138,684,586; 420,304,321; 0.030887929
- lxf: 40,495,387; 68,372,324; 0.010463832
- SwiftForth: 60,211,454; 98,827,718; 0.014094500
- vfxlin32: 50,611,681; 83,933,758; 0.011637347
- vfxlin64: 52,111,299; 80,123,961; 0.013099529
- spf4: 42,827,585; 81,697,379; 0.010892942
- flk: 54,357,589; 189,642,139; 0.013351736
- ikforth: 517,799,517; 787,688,329; 0.201992826

I don't really understand why you find gforth 0.7.3 vs 0.7.9
performance difference surprising. All tests I run show 2-10 times
improvement for 0.7.9. (time to make release, eh?)

flk generates simple code that executes at almost 4 insn per cycle.

Porth with -e "' /s alias / ' mods alias mod"

- gforth-fast 0.7.9: 143,820,949; 448,040,922; 0.033915253

Porth with -e "' fold2-1 folds / mod"

- gforth-fast 0.7.9: 153,789,784; 452,753,589; 0.035525458

Nickolay Kolchin <nbkolchin@gmail.com> writes:
> My machine is probably faster.
> $ time ~/tmp/gforth/gforth-fast euler04.fth
> 906609
>
> real 0m0.041s
> user 0m0.040s
> sys 0m0.000s

I think your Forth program has less overhead than mine. I did a little
tweaking of my version (below) and ran it on a faster machine (i5-3570S
3.10 ghz instead of my laptop which which is somewhat slower) and I
still get (gforth 0.7.3 Debian package):

$ time gforth-fast euler04.fs
906609

real 0m0.127s
user 0m0.124s
sys 0m0.000s

================================================================
#! /usr/bin/gforth
: palindrome?.1 ( n m1 m2 -- flag )
2>r dup r> / 10 mod swap r> / 10 mod = ;
: palindrome? ( n -- flag ) >r
r@ 100000 1 palindrome?.1
r@ 10000 10 palindrome?.1
r> 1000 100 palindrome?.1
AND AND ;

0 VALUE answer
: euler04 1000 100 DO
i 1+ 100 DO
i j * DUP palindrome? IF
answer MAX TO answer
ELSE drop
THEN
LOOP
LOOP answer ;

euler04 . cr
bye

dxforth <dxforth@gmail.com> writes:
> The bigger concern is the author's starting point:
>
> "It's like Forth but written in Python. But I don't actually know for
> sure since I never programmed in Forth, I only heard that it's some
> sort of stack-based programming language."

You may be onto something there. Implementing Forth without first
actually understanding Forth is a classic antipattern.

> He's going to encounter the same issues Moore did. Whether he has the
> same resolve and ability to solve them remains to be seen.

Moore had certain constraints to deal with, and the solution he reached
was inventing Forth. Certainly someone using Python and modern
computers doesn't have the same constraints. So if they reach the same
solution, something is suspicious.

> Writing a HLL on top of another HLL has always bothered me as it's too
> easy to hide poor solutions.

HLL's make most things easier so I don't see anything wrong in principle
with using them for language implementation, particularly implementing
compilers. I'm not too bothered by the huge slowdown in the simulated
version if the real target is supposed to be the compiler. It's sort of
like running a hardware design under simulation. You'd use the
simulator for certain types of functional testing and debugging, not for
running actual application workloads.

On Friday, November 19, 2021 at 12:22:28 AM UTC+3, Paul Rubin wrote:
> Nickolay Kolchin <nbko...@gmail.com> writes:
> > My machine is probably faster.
> > $ time ~/tmp/gforth/gforth-fast euler04.fth
> > 906609
> >
> > real 0m0.041s
> > user 0m0.040s
> > sys 0m0.000s
> I think your Forth program has less overhead than mine. I did a little
> tweaking of my version (below) and ran it on a faster machine (i5-3570S
> 3.10 ghz instead of my laptop which which is somewhat slower) and I
> still get (gforth 0.7.3 Debian package):
>
> $ time gforth-fast euler04.fs
> 906609
>
> real 0m0.127s
> user 0m0.124s
> sys 0m0.000s
>
> ================================================================
> #! /usr/bin/gforth
> : palindrome?.1 ( n m1 m2 -- flag )
> 2>r dup r> / 10 mod swap r> / 10 mod = ;
> : palindrome? ( n -- flag ) >r
> r@ 100000 1 palindrome?.1
> r@ 10000 10 palindrome?.1
> r> 1000 100 palindrome?.1
> AND AND ;
>
> 0 VALUE answer
> : euler04 1000 100 DO
> i 1+ 100 DO
> i j * DUP palindrome? IF
> answer MAX TO answer
> ELSE drop
> THEN
> LOOP
> LOOP answer ;
>
> euler04 . cr
> bye

This is not my program! I've just converted porth source to forth. Timings for
your version on my machine against dxforth variant with gforth 0.7.3:

$ perf stat -e cycles:u -e instructions:u -e branches:u gforth-fast euler04-dxforth.fth
906609

Performance counter stats for 'gforth-fast euler04-dxforth.fth':

680,066,582 cycles:u
1,347,282,943 instructions:u # 1.98 insn per cycle
166,991,379 branches:u

0.144651185 seconds time elapsed

0.144367000 seconds user
0.000000000 seconds sys

$ perf stat -e cycles:u -e instructions:u -e branches:u gforth-fast euler04-rubin.fth
906609

Performance counter stats for 'gforth-fast euler04-rubin.fth':

226,337,138 cycles:u
534,818,702 instructions:u # 2.36 insn per cycle
64,907,310 branches:u

0.049622518 seconds time elapsed

0.049379000 seconds user
0.000000000 seconds sys

On 19/11/2021 08:43, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> The bigger concern is the author's starting point:
>>
>> "It's like Forth but written in Python. But I don't actually know for
>> sure since I never programmed in Forth, I only heard that it's some
>> sort of stack-based programming language."
>
> You may be onto something there. Implementing Forth without first
> actually understanding Forth is a classic antipattern.
>
>> He's going to encounter the same issues Moore did. Whether he has the
>> same resolve and ability to solve them remains to be seen.
>
> Moore had certain constraints to deal with, and the solution he reached
> was inventing Forth. Certainly someone using Python and modern
> computers doesn't have the same constraints. So if they reach the same
> solution, something is suspicious.

Languages have the same goal - irreducible simplicity. In selecting a
stack-based language the definition of 'simplicity' narrows. Suspicion
is if they didn't reach the same conclusions.

>> Writing a HLL on top of another HLL has always bothered me as it's too
>> easy to hide poor solutions.
>
> HLL's make most things easier so I don't see anything wrong in principle
> with using them for language implementation, particularly implementing
> compilers. I'm not too bothered by the huge slowdown in the simulated
> version if the real target is supposed to be the compiler. It's sort of
> like running a hardware design under simulation. You'd use the
> simulator for certain types of functional testing and debugging, not for
> running actual application workloads.

When you write Forth in C - which language are you really promoting?

On 18/11/2021 23:27, Marcel Hendrix wrote:
> On Thursday, November 18, 2021 at 4:12:16 AM UTC+1, dxforth wrote:
> [..]
> FORTH> : test 1000 100 DO
> [3]<3>[FORTH>] 1000 100 DO
> [6]<3>[FORTH>] I J * DUP 0
> [6]<3>[FORTH>] BEGIN OVER 0>
> [9]<3>[FORTH>] WHILE 10 * >R 10 /MOD SWAP R> +
> [12]<3>[FORTH>] REPEAT NIP
> [6]<3>[FORTH>] 2DUP = IF DUP ans MAX TO ans THEN 2DROP
> [6]<3>[FORTH>] LOOP
> [3]<3>[FORTH>] LOOP ; ok
> FORTH> ok
> FORTH> : tt cr timer-reset 100 0 do test loop .elapsed space ans . ; ok
> FORTH> test test test ok
> FORTH> tt tt tt
> 0.811 seconds elapsed. 906609
> 0.811 seconds elapsed. 906609
> 0.812 seconds elapsed. 906609 ok

Compared to?

On VFX32 i5-7400 I get 50% improvement over the original.
As the code is dominated by multiplications and divisions,
halving the latter should have some impact.

dxforth <dxforth@gmail.com> writes:
> Languages have the same goal - irreducible simplicity. In selecting a
> stack-based language the definition of 'simplicity' narrows. Suspicion
> is if they didn't reach the same conclusions.

I thought the goal of languages was to decrease the cognitive burden of
writing programs that are reliable, efficient, and maintainable, and
maybe some other attributes as well. That is a multi-way tradeoff, and
consumption of machine resources is another resource that has to be
traded off.

In Moore's era, machine resources were scarce (so there was more premium
on conserving them), programs had to be small (there was less need for
the language to help manage their complexity, since they were less
complex to begin with); and also because they were small, they could be
made reliable with a manageable amount of debugging and testing without
too much help from the language.

Forth reflects all those factors: it emphasizes simplicity and
compactness over (for example) fancier error-checking such as a type
system. Also, its driving applications involved realtime control
(telescopes etc.) so it couldn't have random delays for garbage
collection, even if enough memory was available for that.

> When you write Forth in C - which language are you really promoting?

Forth is something of a special case these days, since I think it is
used for "spiritual" reasons as well as technical ones. So writing
Forth in C seems sinful. C is not special like Forth is though: it's
good for some things, but writing compilers is not one of them. Writing
a C compiler in C these days is just a poor technical choice. The two
main current C compilers (GCC and Clang) are written in C++ now, and the
most reliable one (CompCert) is written in Coq, basically an Ocaml
dialect emphasizing theorem proving to make sure the program is correct.

I'm not a believer in one language to rule them all. Different problems
call for different approaches.

On Saturday, November 20, 2021 at 12:33:37 AM UTC+1, dxforth wrote:
> On 18/11/2021 23:27, Marcel Hendrix wrote:
> > On Thursday, November 18, 2021 at 4:12:16 AM UTC+1, dxforth wrote:
> > [..]
> > FORTH> : test 1000 100 DO
> > [3]<3>[FORTH>] 1000 100 DO
> > [6]<3>[FORTH>] I J * DUP 0
> > [6]<3>[FORTH>] BEGIN OVER 0>
> > [9]<3>[FORTH>] WHILE 10 * >R 10 /MOD SWAP R> +
> > [12]<3>[FORTH>] REPEAT NIP
> > [6]<3>[FORTH>] 2DUP = IF DUP ans MAX TO ans THEN 2DROP
> > [6]<3>[FORTH>] LOOP
> > [3]<3>[FORTH>] LOOP ; ok
> > FORTH> ok
> > FORTH> : tt cr timer-reset 100 0 do test loop .elapsed space ans . ; ok
> > FORTH> test test test ok
> > FORTH> tt tt tt
> > 0.811 seconds elapsed. 906609
> > 0.811 seconds elapsed. 906609
> > 0.812 seconds elapsed. 906609 ok
> Compared to?
>
> On VFX32 i5-7400 I get 50% improvement over the original.
> As the code is dominated by multiplications and divisions,
> halving the latter should have some impact.

Compared to the original algorithm that I showed for iForth64 on
the same hardware (9ms for a single run => 0.900 seconds for 100x).
There appears to be an 11% speed improvement.

-marcel

Marcel Hendrix <mhx@iae.nl> writes:
>> > FORTH> : test 1000 100 DO
>> > [3]<3>[FORTH>] 1000 100 DO
>> > [6]<3>[FORTH>] I J * ...

> Compared to the original algorithm that I showed for iForth64 on
> the same hardware (9ms for a single run => 0.900 seconds for 100x).
> There appears to be an 11% speed improvement.

Am I missing something dumb, or is there an obvious 50% improvement by
just making the inner loop run from I to 1000 instead of 100 to 1000?
If you have already tested the pair 200,300 there is no need to test
300,200.

On 20/11/2021 21:34, Paul Rubin wrote:
> Marcel Hendrix <mhx@iae.nl> writes:
>>> > FORTH> : test 1000 100 DO
>>> > [3]<3>[FORTH>] 1000 100 DO
>>> > [6]<3>[FORTH>] I J * ...
>
>> Compared to the original algorithm that I showed for iForth64 on
>> the same hardware (9ms for a single run => 0.900 seconds for 100x).
>> There appears to be an 11% speed improvement.
>
> Am I missing something dumb, or is there an obvious 50% improvement by
> just making the inner loop run from I to 1000 instead of 100 to 1000?
> If you have already tested the pair 200,300 there is no need to test
> 300,200.

I didn't alter the algorithm. OTOH I was running a 32-bit forth on a
64-bit - enough to get a different result?

On Saturday, November 20, 2021 at 2:08:08 PM UTC+3, dxforth wrote:
> On 20/11/2021 21:34, Paul Rubin wrote:
> > Marcel Hendrix <m...@iae.nl> writes:
> >>> > FORTH> : test 1000 100 DO
> >>> > [3]<3>[FORTH>] 1000 100 DO
> >>> > [6]<3>[FORTH>] I J * ...
> >
> >> Compared to the original algorithm that I showed for iForth64 on
> >> the same hardware (9ms for a single run => 0.900 seconds for 100x).
> >> There appears to be an 11% speed improvement.
> >
> > Am I missing something dumb, or is there an obvious 50% improvement by
> > just making the inner loop run from I to 1000 instead of 100 to 1000?
> > If you have already tested the pair 200,300 there is no need to test
> > 300,200.
> I didn't alter the algorithm. OTOH I was running a 32-bit forth on a
> 64-bit - enough to get a different result?

No.

On Wednesday, November 17, 2021 at 7:25:36 AM UTC-4, Nickolay Kolchin wrote:
> On Wednesday, November 17, 2021 at 1:51:17 PM UTC+3, NN wrote:
> > I came across this - its supposed to be a forth in python.
> > The only thing forthy about it is it uses stacks and postfix.
> >
> > That said,I found it interesting and worth watching.
> >
> > https://www.youtube.com/playlist?list=PLpM-Dvs8t0VbMZA7wW9aR3EtBqe2kinu4
> IMHO, this is the second most stupid idea -- implementing forth in python.

Of course, that begs the question, what is the first most stupid idea? Python in Forth perhaps?

--

Rick C.

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

On Saturday, November 20, 2021 at 5:28:50 PM UTC+3, gnuarm.del...@gmail.com wrote:
> On Wednesday, November 17, 2021 at 7:25:36 AM UTC-4, Nickolay Kolchin wrote:
> > On Wednesday, November 17, 2021 at 1:51:17 PM UTC+3, NN wrote:
> > > I came across this - its supposed to be a forth in python.
> > > The only thing forthy about it is it uses stacks and postfix.
> > >
> > > That said,I found it interesting and worth watching.
> > >
> > > https://www.youtube.com/playlist?list=PLpM-Dvs8t0VbMZA7wW9aR3EtBqe2kinu4
> > IMHO, this is the second most stupid idea -- implementing forth in python.
> Of course, that begs the question, what is the first most stupid idea? Python in Forth perhaps?
>

Implementing Forth in R.

dxforth <dxforth@gmail.com> wrote:
> On 19/11/2021 08:43, Paul Rubin wrote:
> > dxforth <dxforth@gmail.com> writes:
> >> The bigger concern is the author's starting point:
> >>
> >> "It's like Forth but written in Python. But I don't actually know for
> >> sure since I never programmed in Forth, I only heard that it's some
> >> sort of stack-based programming language."
> >
> > You may be onto something there. Implementing Forth without first
> > actually understanding Forth is a classic antipattern.
> >
> >> He's going to encounter the same issues Moore did. Whether he has the
> >> same resolve and ability to solve them remains to be seen.
> >
> > Moore had certain constraints to deal with, and the solution he reached
> > was inventing Forth. Certainly someone using Python and modern
> > computers doesn't have the same constraints. So if they reach the same
> > solution, something is suspicious.
>
> Languages have the same goal - irreducible simplicity. In selecting a
> stack-based language the definition of 'simplicity' narrows. Suspicion
> is if they didn't reach the same conclusions.

Consider stack-based language, with two stacks and dictionary of
words. Sounds like Forth? Well, a small sample of statements is:

1, 2 +, sin() -> a;
sin(1 + 2) -> a;
cons,[], cons() -> a;
cons(cons,[]) -> a;

First line is kind of ugly Forth: it needs commas and calling 'sin'
needs parenthesis. Second line is how most users would write the
same thing as first line. Third line is again in "ugly Forth"
style, it creates list consisting of function 'cons' and assigns
it to variable 'a'. Fourth line is how most users would write
the same thing as third line.

Is there something wrong with this language? If you want Forth,
then probably it is very wrong. OTOH, fourth line shows that
it can do things which probably would be more complicated in
Forth. There are tradeofs, designing programming language
you want to make some things easy, do not care if some other
things get more complicated and sometimes want to forbid
another things. Change goals and different language will
emerge...

--
Waldek Hebisch