Re: Actually... why not?

Liste des GroupesRevenir à cl forth 
Sujet : Re: Actually... why not?
De : anton (at) *nospam* mips.complang.tuwien.ac.at (Anton Ertl)
Groupes : comp.lang.forth
Date : 12. Jun 2025, 17:21:16
Autres entêtes
Organisation : Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID : <2025Jun12.182116@mips.complang.tuwien.ac.at>
References : 1 2 3 4 5
User-Agent : xrn 10.11
zbigniew2011@gmail.com (LIT) writes:
[Someone wrote:]
In the 1970s and early 1980s the bigger problem was code size rather
than code performance.  And if you compile a variable or constant into
the CFA of the variable, this costs one cell, whereas compiling it
into LIT followed by the address or value costs two cells.
>
Please, have a mercy... :D it's A SINGLE cell you're
talking about.

It's a doubling of the threaded code for every use of a variable,
constant, colon definition (call <addr>), etc.

Even, if (let's assume) the two bytes
may(?) have some meaning during 70s, still in the 80s -
in the era, when 16 KB of RAM, and soon later 64 KB
became de facto standard - it wasn't sane decision(?)
to cripple the compiler(s) by "saving" (literally)
a few bytes.

If it's only a few bytes, that would mean that variables, constants,
colon definitions etc. are not invoked much.  In that case the savings
in run-time are also likely to be small.

As for the relevance of the difference in 64KB, I know of Forth
programs that use more than 64KB, so it's not as if 64KB make it
unnecessary to be economical with space.

I measured loading brew (without running a benchmark) into gforth-itc.
When compiling with "," (default in gforth-itc), the size on a 64-bit
system grew by 748560 bytes, while with "opt-compile,", it grew by
939448 bytes.  That's a factor 1.255 difference.

64 KB is a whole lot compared to "savings"
of (literally) two-byte size per VARIABLE/CONSTANT
definition. Say we've got 200 of them together
in the program — so 400 bytes has been "saved"
at a cost of significantly degraded performance.

If we take the factor 1.255, a program that fits into 64KB when
compiling with "," needs more than 80KB with "OPT-COMPILE,".  Now trim
this factor from the program in order to make it fit.  The easiest way
is to go back to compiling with ",".

As for "significantly degraded performance", as long as you stick with
ITC, my results don't show that.

- 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: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

Date Sujet#  Auteur
11 Jun 25 * Actually... why not?13LIT
11 Jun 25 `* Re: Actually... why not?12Anton Ertl
12 Jun 25  `* Re: Actually... why not?11LIT
12 Jun 25   `* Re: Actually... why not?10Anton Ertl
12 Jun 25    +* Re: Actually... why not?4LIT
12 Jun 25    i+- Re: Actually... why not?1LIT
12 Jun 25    i`* Re: Actually... why not?2Anton Ertl
12 Jun 25    i `- Re: Actually... why not?1LIT
12 Jun 25    `* Performance benefits of primitive-centric code (was: Actually... )5Anton Ertl
13 Jun 25     `* Re: Performance benefits of primitive-centric code4minforth
13 Jun 25      +* Re: Performance benefits of primitive-centric code2Paul Rubin
13 Jun 25      i`- Re: Performance benefits of primitive-centric code1Anton Ertl
13 Jun 25      `- Re: Performance benefits of primitive-centric code1Anton Ertl

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal