• do you have ref on optimisation

    From goblinrieur@gmail.com@21:1/5 to All on Sat Aug 5 02:11:09 2023
    hello,

    did anyone have wrote a specific document about optimization & good practice or tips in forth ? or have good links about that to provide ?

    I'm still learning & have access to I think all "well known" sites but I wonder continue my learning :) & rewrite a better way my current trainning codes.

    I'm also interested if you have such references as books too :) even I have already many beginners books.

    regards.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From none) (albert@21:1/5 to gobli...@gmail.com on Sat Aug 5 11:46:03 2023
    In article <9652494d-e625-4e86-a6b0-3fd25851e09en@googlegroups.com>, gobli...@gmail.com <goblinrieur@gmail.com> wrote:
    hello,

    did anyone have wrote a specific document about optimization & good
    practice or tips in forth ? or have good links about that to provide ?

    I'm still learning & have access to I think all "well known" sites but I >wonder continue my learning :) & rewrite a better way my current
    trainning codes.

    I'm also interested if you have such references as books too :) even I
    have already many beginners books.

    https://home.hccnet.nl/a.w.m.van.der.horst/forthlectures.html
    This contains a write up how to do optimisers in Forth.
    I actually have implemented this for ciforth.
    Also Marcel Hendrix took inspiration from it. (His iforth and
    MPE-forth are probably the fastest Forth's around.).


    regards.

    Groetjes Albert
    --
    Don't praise the day before the evening. One swallow doesn't make spring.
    You must not say "hey" before you have crossed the bridge. Don't sell the
    hide of the bear until you shot it. Better one bird in the hand than ten in
    the air. First gain is a cat spinning. - the Wise from Antrim -

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From minforth@21:1/5 to gobli...@gmail.com on Sat Aug 5 07:07:51 2023
    gobli...@gmail.com schrieb am Samstag, 5. August 2023 um 11:11:11 UTC+2:
    hello,

    did anyone have wrote a specific document about optimization & good practice or tips in forth ? or have good links about that to provide ?

    I'm still learning & have access to I think all "well known" sites but I wonder continue my learning :) & rewrite a better way my current trainning codes.

    I'm also interested if you have such references as books too :) even I have already many beginners books.

    I guess you have gone through Leo Brodie's two classic books.

    Thereafter it really depends on your optimisation goal. For instance
    - execution speed
    - least memory footprint
    - least burnt milliwatts embedded
    - most concise source code
    - ease of maintenance in a team

    For the first three: know your hardware!

    This does not answer your question, but might explain why there are not
    many generic reference papers around. Although not for Forth, but for assembler and C,
    I found Agner Fog's papers on optimization very helpful: https://www.agner.org/optimize/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Brian Fox@21:1/5 to gobli...@gmail.com on Sat Aug 5 09:54:57 2023
    On Saturday, August 5, 2023 at 5:11:11 AM UTC-4, gobli...@gmail.com wrote:
    hello,

    did anyone have wrote a specific document about optimization & good practice or tips in forth ? or have good links about that to provide ?

    I'm still learning & have access to I think all "well known" sites but I wonder continue my learning :) & rewrite a better way my current trainning codes.

    I'm also interested if you have such references as books too :) even I have already many beginners books.

    regards.

    Not sure what you mean by optimizing. It could mean an optimizing compiler but it could also
    mean how to write more efficient Forth code.

    On the latter issue there is a strange aspect of Forth that is more akin to a CPU instruction set.
    By that I mean there are hundreds of these little code snippets and they can be used in ways
    that are not always obvious. As an example the word COUNT is generally thought of as a way
    to unpack a counted string and return the text address and the length but I was amazed to see
    it used as a way to index a string, character by character, like this:

    : TYPE ( addr len -- ) 0 DO COUNT EMIT LOOP DROP ;

    COUNT could probably also be used as part of a character parser.
    I have only recently started trying to see Forth this way so that is why I am commenting.

    *DISCLAIMER : There are real experts on this subject In this forum.
    These comments are hobby coder trying to learn something on the matter.

    My hobby work involves a machine with glacial performance so making faster Forth is rewarding.
    Also with a really slow machine you get first hand experience on what really makes a difference.

    One approach I took to optimizing indirect threaded code was to copy primitive code words
    in memory end to end and use them as "headless" definitions. I believe GForth calls these
    super-instructions and does them as a matter of course. (? Anton ?)

    This gave some benefits but I found other bottle-necks.
    If you are going to compile native code then there are more efficient ways to handle
    variables and constants so that led to detecting those words and compiling appropriate code.

    But then a bottle-neck shows up around branching and looping because the threaded interpreter
    is limiting the flat out speed of IF, ELSE, WHILE, AGAIN and UNTIL so that led to detecting
    those words and compiling native code jumps.

    If it is of interest you can see the evolution in these two files.
    They may provide some ideas from someone else who is feeling their way along. :-)

    https://github.com/bfox9900/CAMEL99-ITC/blob/master/LIB.ITC/INLINE.FTH

    https://github.com/bfox9900/CAMEL99-ITC/blob/master/LIB.ITC/JIT.FTH

    To give you a sense of the improvement achievable, 10 iterations of the Byte Magazine Sieve
    takes 120 seconds running on this 1978 era CPU using ITC Camel Forth.
    (LOL I'm not kidding)

    Using the JIT on the computational section reduces the time to 49 seconds.

    However a fully native code version in a Machine Forth I wrote, using native registers as locals
    runs in just under 10 seconds.

    All that to say compilers like VFX and iForth are doing much more than the obvious stuff.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dxforth@21:1/5 to minforth on Sun Aug 6 03:20:44 2023
    On 6/08/2023 12:07 am, minforth wrote:
    gobli...@gmail.com schrieb am Samstag, 5. August 2023 um 11:11:11 UTC+2:
    hello,

    did anyone have wrote a specific document about optimization & good practice or tips in forth ? or have good links about that to provide ?

    I'm still learning & have access to I think all "well known" sites but I wonder continue my learning :) & rewrite a better way my current trainning codes.

    I'm also interested if you have such references as books too :) even I have already many beginners books.

    I guess you have gone through Leo Brodie's two classic books.

    Thereafter it really depends on your optimisation goal. For instance
    - execution speed
    - least memory footprint
    - least burnt milliwatts embedded
    - most concise source code
    - ease of maintenance in a team

    For the first three: know your hardware!

    This does not answer your question, but might explain why there are not
    many generic reference papers around. Although not for Forth, but for assembler and C,
    I found Agner Fog's papers on optimization very helpful: https://www.agner.org/optimize/

    Following that link I found myself at the MASM website browsing the following page:

    https://www.masm32.com/why.htm

    Reading the third paragraph and substituting each occurrence of "MASM" with "FORTH",
    it struck me as something Moore might say. His 'no compromise' stance is legend.
    MASM users knowing what they're about simply say 'not for the faint hearted'. No
    mention of ease of maintenance in a team as a goal at all. Perhaps it's Forth that
    has lost its way.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From minforth@21:1/5 to dxforth on Sat Aug 5 12:02:23 2023
    dxforth schrieb am Samstag, 5. August 2023 um 19:20:48 UTC+2:
    On 6/08/2023 12:07 am, minforth wrote:
    gobli...@gmail.com schrieb am Samstag, 5. August 2023 um 11:11:11 UTC+2:
    hello,

    did anyone have wrote a specific document about optimization & good practice or tips in forth ? or have good links about that to provide ?

    I'm still learning & have access to I think all "well known" sites but I wonder continue my learning :) & rewrite a better way my current trainning codes.

    I'm also interested if you have such references as books too :) even I have already many beginners books.

    I guess you have gone through Leo Brodie's two classic books.

    Thereafter it really depends on your optimisation goal. For instance
    - execution speed
    - least memory footprint
    - least burnt milliwatts embedded
    - most concise source code
    - ease of maintenance in a team

    For the first three: know your hardware!

    This does not answer your question, but might explain why there are not many generic reference papers around. Although not for Forth, but for assembler and C,
    I found Agner Fog's papers on optimization very helpful: https://www.agner.org/optimize/
    Following that link I found myself at the MASM website browsing the following page:

    https://www.masm32.com/why.htm

    Reading the third paragraph and substituting each occurrence of "MASM" with "FORTH",
    it struck me as something Moore might say. His 'no compromise' stance is legend.
    MASM users knowing what they're about simply say 'not for the faint hearted'. No
    mention of ease of maintenance in a team as a goal at all. Perhaps it's Forth that
    has lost its way.

    You are right in that "ease of maintenance" is of little importance in one-man software
    shows, eg like Forth hobbyist projects, or for assembly trick programming nerds.

    For industrial applications "ease of maintenance" has a quite different impact. Imagine
    MCUs running for years somewhere on the globe. The paying customer wants some software troubleshooting or update with minimal downtime. Now put yourself in the shoes
    of the service engineer who has to go there...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dxforth@21:1/5 to minforth on Sun Aug 6 14:42:02 2023
    On 6/08/2023 5:02 am, minforth wrote:
    dxforth schrieb am Samstag, 5. August 2023 um 19:20:48 UTC+2:
    On 6/08/2023 12:07 am, minforth wrote:
    gobli...@gmail.com schrieb am Samstag, 5. August 2023 um 11:11:11 UTC+2: >>>> hello,

    did anyone have wrote a specific document about optimization & good practice or tips in forth ? or have good links about that to provide ?

    I'm still learning & have access to I think all "well known" sites but I wonder continue my learning :) & rewrite a better way my current trainning codes.

    I'm also interested if you have such references as books too :) even I have already many beginners books.

    I guess you have gone through Leo Brodie's two classic books.

    Thereafter it really depends on your optimisation goal. For instance
    - execution speed
    - least memory footprint
    - least burnt milliwatts embedded
    - most concise source code
    - ease of maintenance in a team

    For the first three: know your hardware!

    This does not answer your question, but might explain why there are not
    many generic reference papers around. Although not for Forth, but for assembler and C,
    I found Agner Fog's papers on optimization very helpful:
    https://www.agner.org/optimize/
    Following that link I found myself at the MASM website browsing the following page:

    https://www.masm32.com/why.htm

    Reading the third paragraph and substituting each occurrence of "MASM" with "FORTH",
    it struck me as something Moore might say. His 'no compromise' stance is legend.
    MASM users knowing what they're about simply say 'not for the faint hearted'. No
    mention of ease of maintenance in a team as a goal at all. Perhaps it's Forth that
    has lost its way.

    You are right in that "ease of maintenance" is of little importance in one-man software
    shows, eg like Forth hobbyist projects, or for assembly trick programming nerds.

    For industrial applications "ease of maintenance" has a quite different impact. Imagine
    MCUs running for years somewhere on the globe. The paying customer wants some software troubleshooting or update with minimal downtime. Now put yourself in the shoes
    of the service engineer who has to go there...

    I've been there as an electronics service engineer. There was no question of HP or
    Tektronix dumbing down their products for fear it might upset some future service
    manager. Either the service organization has personnel of sufficient competence to
    handle it - or they don't. Same applies to designers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dxforth@21:1/5 to Brian Fox on Sun Aug 6 17:05:17 2023
    On 6/08/2023 2:54 am, Brian Fox wrote:
    On Saturday, August 5, 2023 at 5:11:11 AM UTC-4, gobli...@gmail.com wrote:
    hello,

    did anyone have wrote a specific document about optimization & good practice or tips in forth ? or have good links about that to provide ?

    I'm still learning & have access to I think all "well known" sites but I wonder continue my learning :) & rewrite a better way my current trainning codes.

    I'm also interested if you have such references as books too :) even I have already many beginners books.

    regards.

    Not sure what you mean by optimizing. It could mean an optimizing compiler but it could also
    mean how to write more efficient Forth code.

    On the latter issue there is a strange aspect of Forth that is more akin to a CPU instruction set.
    By that I mean there are hundreds of these little code snippets and they can be used in ways
    that are not always obvious.

    Further to the first point, it would be a mistake to judge 'good Forth' by the standards
    of other languages. The latter factor in environmental factors such as optimizing compilers.
    Moore's position has been write optimum code and the need for fancy compilers goes away.
    There's a reason GCC is such a monster. I wish its team of maintainers the best of luck.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Pelc@21:1/5 to goblinrieur@gmail.com on Sun Aug 6 16:54:03 2023
    On 5 Aug 2023 at 11:11:09 CEST, "goblinrieur@gmail.com"
    <goblinrieur@gmail.com> wrote:

    did anyone have wrote a specific document about optimization & good practice or tips in forth ? or have good links about that to provide ?

    Optimisation of Forth is really no different than for other languages. If
    there is a difference, it is
    that the Forth basic block (what's inside a control structure) is usually very/rather small.

    Start with all the classic texts from the dragon books onwards. See also
    Fraser and Hansen - Retargetable C compiler: Design and implementation
    get the second edition

    Fischer & LeBlanc (et al) - Crafting a Compiler
    We liked it. There appears to be PDF floating around.

    Note that paper books about compiler are expensive.

    You will also fing that the parsing requirements for Forth are almost trivial, and that the key
    is in designing the data structures to represent the Forth data and the instruction selection.
    For example, DUP need generate no code until one part is copied modified or moved. For
    example
    DUP 8 + @
    can be reduced to one instruction in many instruction sets. This example requires you
    to perform some degree of back-tracking in some designs.

    You have to decide what your objectives are.

    Stephen






    I'm still learning & have access to I think all "well known" sites but I wonder continue my learning :) & rewrite a better way my current trainning codes.

    I'm also interested if you have such references as books too :) even I have already many beginners books.

    regards.



    --
    Stephen Pelc, stephen@vfxforth.com
    MicroProcessor Engineering, Ltd. - More Real, Less Time
    133 Hill Lane, Southampton SO15 5AF, England
    tel: +44 (0)78 0390 3612, +34 649 662 974
    http://www.mpeforth.com - free VFX Forth downloads

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From S Jack@21:1/5 to dxforth on Sun Aug 6 09:26:48 2023
    On Saturday, August 5, 2023 at 11:42:07 PM UTC-5, dxforth wrote:
    On 6/08/2023 5:02 am, minforth wrote:

    Never was an optimizing Nazi but always pursued
    tricks of the trade e.g. xor register to itself
    instead of moving zero into it. But after Hans
    remark about bad style using flag as a mask and
    previous comments of Albert about 'premature
    optimization' it finally sunk in. Old habits
    are too ingrained to completely give but now
    strive to write straight code rather than some
    peep-hole optimization. Just assume if someone
    wants it optimized, they can run it through some
    one's optimizing compiler. Or if in a speed bind
    somewhere then sure attack it.
    Currently in my latest retro Forth I'm spending
    time importing code level word form previous
    works and converting to them high level words in
    the new Forth. In the past I would have had a
    hard time making myself do such a thing but now
    have no concern at all. Even found a new factor
    I haven't seen before (probably with good reason)
    "U->D", unsigned single to signed double.
    --
    me

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dxforth@21:1/5 to S Jack on Mon Aug 7 20:23:03 2023
    On 7/08/2023 2:26 am, S Jack wrote:
    On Saturday, August 5, 2023 at 11:42:07 PM UTC-5, dxforth wrote:
    On 6/08/2023 5:02 am, minforth wrote:

    Never was an optimizing Nazi but always pursued
    tricks of the trade e.g. xor register to itself
    instead of moving zero into it. But after Hans
    remark about bad style using flag as a mask and
    previous comments of Albert about 'premature
    optimization' it finally sunk in. Old habits
    are too ingrained to completely give but now
    strive to write straight code rather than some
    peep-hole optimization. Just assume if someone
    wants it optimized, they can run it through some
    one's optimizing compiler. Or if in a speed bind
    somewhere then sure attack it.

    In any code one writes there will be opportunities to optimize.
    I don't feel inclined to leave to an optimizer what I can do
    myself. The latter are certainly not entitled to call Forth
    code "tricky" if that's what they do under the hood out of sight.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From S Jack@21:1/5 to dxforth on Mon Aug 7 08:43:13 2023
    On Monday, August 7, 2023 at 5:23:06 AM UTC-5, dxforth wrote:

    In any code one writes there will be opportunities to optimize.

    Optimized for which processor? A general optimization
    perhaps, but wouldn't that be "premature".

    Some months back someone published a nice math library.
    All the code was straight Forth code, most words
    short and sweet. There were no "AND TRUE"s to avoid
    IF statements or other such common Forth idiosyncrasy.
    I thought it good clear logic; no need to muddle with
    optimization until optimization is needed.
    In Frog I reluctantly changed TRUE from 1 to -1 for
    that advantage of avoiding IF statements. I was
    reluctant because the assemblers that I knew had
    instructions that expected 1 for TRUE and I wanted
    to keep my Forth close to assembly. I always regretted
    it, not for any practical reason but for preference,
    and planned on changing it back. Then came Toad, pure
    retro, and I'm happy to have TRUE is 1 back along with
    the other warts.
    In industry software is always having to make up for
    short comings of the hardware. Well, now being free
    I no longer feel the need to follow the hardware.
    I pretend perfect hardware exists that can handle
    IF statements without penalty.
    --
    me

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dxforth@21:1/5 to S Jack on Tue Aug 8 16:29:22 2023
    On 8/08/2023 1:43 am, S Jack wrote:
    On Monday, August 7, 2023 at 5:23:06 AM UTC-5, dxforth wrote:

    In any code one writes there will be opportunities to optimize.

    Optimized for which processor? A general optimization
    perhaps, but wouldn't that be "premature".

    I'm talking about forth. Forth is low level compared to most HLL with
    the result concise forth translates to efficient code irrespective of processor. If one includes HLL elements such as locals the correlation
    between source and code generated is muddied. All the programmer can
    do in the latter case is apply post-optimization and hope for the best.
    But since forth is still low level it limits what such optimizers can
    achieve without re-organizing the code. Folks may wish to test their optimizers here:

    https://pastebin.com/HpDnzsGj

    Some months back someone published a nice math library.
    All the code was straight Forth code, most words
    short and sweet. There were no "AND TRUE"s to avoid
    IF statements or other such common Forth idiosyncrasy.
    I thought it good clear logic; no need to muddle with
    optimization until optimization is needed.

    Sometimes there's nothing to optimize. I think it's a mistake to apply
    norms of other languages to Forth and called it idiosyncratic. I did
    that when I first came to Forth. In my case the carry-over was BASIC.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)