Re: The hardest Euler problem

On May 5, 10:49 am, an...@[EMAIL PROTECTED]
 (Anton Ertl)
wrote:
> >What else?  We expect the Forth version to live up to
> >Jeff Fox's boast that rewriting a program in Forth
> >makes it 100 times smaller and 1000 times faster.

That is a funny story but not true. The real examples were ANS Forth
programs that were rewritten into machineForth so I never said
anything 'rewriting a program in Forth.'

Or are YOU making the claim that ANS Forth is not really Forth?

I was under the impression that you never actually read any of
those explanations of the techniques that Chuck had intended to
be used for optimization in the dialect that came after ANS.

Also those ANS Forth programs were either intentionally or
unintentionally done in C style.  So optimization of the Forth
was pretty easy.  It was said that the standard made it possible to
write '****table' code like C, and copied from C code to be '****table
like C.'

For those who don't recall one was a jpeg image decode and display
program that was one of the first written for the i21 target.  It
was written by a C programmer learning Forth.  Eventually it was
rewritten by a good machineForth program and the result was
something 100x smaller and 1000x faster. It went from 100k to 1k
in size and from 2 seconds to 2 milliseconds in execution speed.
Since I didn't write either one I couldn't really have 'boasted'
about doing it since all I did was explain it to those interested
in understand the sort of optimizations that Chuck intended in
the immediate post ANS era so long ago.

The second example was related to the use of the original C-style
structure code in the Forth Scientific Library.  That code was
replaced later with better code so FSL progress was made.  I think it
was a good tutorial example because it was pretty easy to
understand.
The first 10x should have been easily visible to any Forth newbie
and was low hanging fruit picked in a few minutes.

The ANS Forth library code had been defined with diagnostic
messages at the end of structure sequences.  When it had been
pasted in the words that printed diagnostic messages at
the end were replaced with drops and 2drop but 90%
of the code was carrying these arguments to the end
of the word just to drop them. Something like:

: example ( n1 n2 -- ) 2dup ! 2dup swap 2drop over drop swap 2drop ;

And if that wasn't bad enough the code was written to cover 16, 20,
32, and 64 bit targets and it didn't use [IF] for a compile time
decision about which target to compile for.  Instead it compiled code
for each type of target and added more unneeded runtime code to
decide which version should actually be used on the embedded target.

I did say that established Forth programmers should be able
optimize code at least as well as first day newbie and I said
that one should not paste that sort of code ito a size
and speed sensitive embedded application just because it came
from a library that some people boasted about being so good.
You may call that boasting if you like.

What I did say, and still say, is that even if you "paste this
into your size and performance sensitive application from a
library" you should also look at it closely enough to at
least replace something like that with something
like:

: example ( n1 n2 -- ) ! ;

or maybe

m: example ( n1 n2 -- ) ! m;

If it only takes beginner level skills to make that sort
of library code twenty times smaller and fifty times faster
in five minutes why not?  The more extensive rewrite into
machineForth that followed was more like a couple hours
of work that had been scheduled.  I probably did spend
twenty or thirty hours explaining it to other people as
tutorial presentations and web pages.  Had you spent
a few minutes reviewing the early problems with FSL
you might now have made up such a malicious story.

In the real examples the rewrite to machineForth was
responsible for about 100x speed-up since that was about
the ratio of machineForth to ANS Forth.  ANS Forth
requires stack pointers and stacks in memory. While
machineForth could sustain 5ns stack access even
a decade ago while stacks in memory were more like 500ns.
It was running on the same 20k transistor machine in either
case.

If you care to discuss the real tutorial examples that you
must have missed in the past, the examples of ANS Forth being
optimized to machineForth that you trivialized and distorted
above for whatever reasons I will be happy to answer
questions about it.

Best Wishes