Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #52476 > unrolled thread
| Started by | trans <transfire@gmail.com> |
|---|---|
| First post | 2016-11-08 22:03 -0800 |
| Last post | 2016-11-11 15:54 -0800 |
| Articles | 20 on this page of 97 — 21 participants |
Back to article view | Back to comp.lang.forth
Average swaps per word? trans <transfire@gmail.com> - 2016-11-08 22:03 -0800
Re: Average swaps per word? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-08 20:20 -1000
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-09 08:16 +0000
Re: Average swaps per word? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-09 03:34 -0500
Re: Average swaps per word? trans <transfire@gmail.com> - 2016-11-09 02:53 -0800
Re: Average swaps per word? rickman <gnuarm@gmail.com> - 2016-11-09 11:50 -0500
Re: Average swaps per word? stephen@mpeforth.com (Stephen Pelc) - 2016-11-09 18:37 +0000
Re: Average swaps per word? Harold <hzrabbie@gmail.com> - 2016-11-10 16:28 -0800
Re: Average swaps per word? stephen@mpeforth.com (Stephen Pelc) - 2016-11-11 17:51 +0000
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-12 12:23 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-12 16:09 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-13 14:55 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-13 20:34 +0100
Re: Average swaps per word? Paul Rubin <no.email@nospam.invalid> - 2016-11-13 11:43 -0800
Re: Average swaps per word? hughaguilar96@gmail.com - 2016-11-13 16:58 -0800
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-14 16:41 +0100
Re: Average swaps per word? hughaguilar96@gmail.com - 2016-11-14 16:38 -0800
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-14 17:42 +0000
Re: Average swaps per word? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-14 16:39 -0500
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 12:40 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-17 14:10 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-18 15:14 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-20 18:16 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-22 10:29 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-22 15:54 +0100
Re: Average swaps per word? James Kuyper <jameskuyper@verizon.net> - 2016-11-22 11:50 -0500
Re: Average swaps per word? raltbos@xs4all.nl (Richard Bos) - 2016-11-24 17:27 +0000
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-15 03:55 -0600
Re: Average swaps per word? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-15 17:49 -0500
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-16 02:59 -0600
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 13:07 +0000
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-16 22:57 +0000
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-17 03:12 -0600
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-17 12:32 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-18 15:02 +0000
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 13:23 +0000
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-17 08:54 -0600
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-18 15:54 +0000
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-18 12:37 -0600
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-14 17:32 +0000
Re: Average swaps per word? Mark Wills <markwills1970@gmail.com> - 2016-11-15 02:09 -0800
Re: Average swaps per word? jim <anon@example.com> - 2016-11-15 10:44 +0000
Re: Average swaps per word? Mark Wills <markwills1970@gmail.com> - 2016-11-15 03:12 -0800
Re: Average swaps per word? Alex <alex@rivadpm.com> - 2016-11-15 13:01 +0000
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 12:51 +0000
Re: Average swaps per word? Alex <alex@rivadpm.com> - 2016-11-17 14:02 +0000
Re: Average swaps per word? Alex <alex@rivadpm.com> - 2016-11-17 14:06 +0000
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-18 15:26 +0000
Re: Average swaps per word? Alex <alex@rivadpm.com> - 2016-11-18 18:33 +0000
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-19 03:32 -0600
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-17 14:29 +0100
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-15 13:51 +0100
Re: Average swaps per word? jim <anon@example.com> - 2016-11-15 13:01 +0000
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 12:46 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-17 14:16 +0100
Re: Average swaps per word? Harold <hzrabbie@gmail.com> - 2016-11-13 11:08 -0800
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-14 17:08 +0000
Re: Average swaps per word? Mark Wills <markwills1970@gmail.com> - 2016-11-15 02:04 -0800
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-15 14:04 +0100
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-15 14:05 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-17 12:58 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-17 15:16 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-18 15:41 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-20 18:12 +0100
Re: Average swaps per word? minforth@arcor.de - 2016-11-09 03:15 -0800
Re: Average swaps per word? trans <transfire@gmail.com> - 2016-11-09 11:22 -0800
Re: Average swaps per word? "HAA" <someone@microsoft.com> - 2016-11-10 12:20 +1100
Re: Average swaps per word? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-09 21:04 -1000
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-10 03:45 -0600
Re: Average swaps per word? rickman <gnuarm@gmail.com> - 2016-11-10 11:52 -0500
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-10 11:42 -0600
Re: Average swaps per word? rickman <gnuarm@gmail.com> - 2016-11-10 13:34 -0500
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-10 12:54 -0600
Re: Average swaps per word? rickman <gnuarm@gmail.com> - 2016-11-10 16:33 -0500
Re: Average swaps per word? "Elizabeth D. Rather" <erather@forth.com> - 2016-11-10 15:56 -1000
Re: Average swaps per word? rickman <gnuarm@gmail.com> - 2016-11-10 21:30 -0500
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-11 03:04 -0600
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-12 13:25 +0000
Re: Average swaps per word? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-14 03:34 -0600
Re: Average swaps per word? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-11-11 10:41 +0000
Re: Average swaps per word? hughaguilar96@gmail.com - 2016-11-11 16:45 -0800
Re: Average swaps per word? jim <anon@example.com> - 2016-11-10 11:17 +0000
Re: Average swaps per word? Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-11-10 04:34 -0800
Re: Average swaps per word? jim <anon@example.com> - 2016-11-10 12:44 +0000
Re: Average swaps per word? Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-11-10 07:27 -0800
Re: Average swaps per word? Ron Aaron <rambamist@gmail.com> - 2016-11-10 18:26 +0200
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-10 16:05 +0000
Re: Average swaps per word? stephen@mpeforth.com (Stephen Pelc) - 2016-11-10 14:55 +0000
Re: Average swaps per word? "HAA" <someone@microsoft.com> - 2016-11-12 11:36 +1100
Re: Average swaps per word? hughaguilar96@gmail.com - 2016-11-11 16:56 -0800
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-12 16:14 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-12 12:14 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-12 16:16 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-13 14:51 +0000
Re: Average swaps per word? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-13 20:41 +0100
Re: Average swaps per word? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-10 14:42 +0000
Re: Average swaps per word? hughaguilar96@gmail.com - 2016-11-11 15:54 -0800
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-11-17 12:58 +0000 |
| Message-ID | <2016Nov17.135826@mips.complang.tuwien.ac.at> |
| In reply to | #52656 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2016Nov14.180809@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>Harold <hzrabbie@gmail.com> writes:
>>>You can get the @ DROP sequence as a result of in-lining.
>>
>>Any evidence of that occuring to any relevant extent? No? Thought so.
>
>I expect this or things similar to this to happen all the time.
>Think of FIND. It leaves an immediate flag too.
>In cases where the flag is needed and FIND is inlined, the
>optimisation trickles down to the place where something is fetched.
This is just another out-of-the-blue claim without empirical support,
the kind that's popular among "optimization" apologists. Where is the
evidence and where is the relevant extent? I.e., in which programs
does this occur, how often is the code that does this executed, and
how much time is spent in it?
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-11-17 15:16 +0100 |
| Message-ID | <o0ke40$cm1$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #52688 |
In article <2016Nov17.135826@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>In article <2016Nov14.180809@mips.complang.tuwien.ac.at>,
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>Harold <hzrabbie@gmail.com> writes:
>>>>You can get the @ DROP sequence as a result of in-lining.
>>>
>>>Any evidence of that occuring to any relevant extent? No? Thought so.
>>
>>I expect this or things similar to this to happen all the time.
>>Think of FIND. It leaves an immediate flag too.
>>In cases where the flag is needed and FIND is inlined, the
>>optimisation trickles down to the place where something is fetched.
>
>This is just another out-of-the-blue claim without empirical support,
>the kind that's popular among "optimization" apologists. Where is the
>evidence and where is the relevant extent? I.e., in which programs
>does this occur, how often is the code that does this executed, and
>how much time is spent in it?
You can do this yourself easily. How often is FIND used, and how
often do you need its flag?
If you seek excuses to not include such an optimisation as a special
case, do not think I seek excuses to include such an optimisation without
proper research whether it is useful.
In a well designed optimiser, this optimisation comes automatically
and for free:
http://home.hccnet.nl/a.w.m.van.der.horst/forthlecture5.html
Fetching of the immediate flag and not using it is a case of
a sequence with no output side effect. A sequence with
no result may be omitted, even if there is an input side effect.
Such is the case for the sequence in FIND in ciforth that fetches
the immediate flag, if it is followed by DROP:
DUP >FFA @ IMMEDIATE_BIT AND DROP
In this jargon @ has an input side effect. This is inherited by
the sequence as a whole.
(Note that a port @ ( PC@ ) which was discussed in other threads
has an input and an output side effect. )
>
>- anton
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-11-18 15:41 +0000 |
| Message-ID | <2016Nov18.164128@mips.complang.tuwien.ac.at> |
| In reply to | #52694 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2016Nov17.135826@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>In article <2016Nov14.180809@mips.complang.tuwien.ac.at>,
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>Harold <hzrabbie@gmail.com> writes:
>>>>>You can get the @ DROP sequence as a result of in-lining.
>>>>
>>>>Any evidence of that occuring to any relevant extent? No? Thought so.
>>>
>>>I expect this or things similar to this to happen all the time.
>>>Think of FIND. It leaves an immediate flag too.
>>>In cases where the flag is needed and FIND is inlined, the
>>>optimisation trickles down to the place where something is fetched.
>>
>>This is just another out-of-the-blue claim without empirical support,
>>the kind that's popular among "optimization" apologists. Where is the
>>evidence and where is the relevant extent? I.e., in which programs
>>does this occur, how often is the code that does this executed, and
>>how much time is spent in it?
>
>You can do this yourself easily. How often is FIND used, and how
>often do you need its flag?
I normally do not use it. Instead, I use FIND-NAME, which does not do
this possibly useless work of generating an immediate flag. That's
the Forth way: instead of inventing "optimizations" to deal with
crufty interfaces, have a clean interface that does not call for
optimizing parts away.
Otherwise, I expect that FIND is mostly used in user-written text
interpreters, and there the immediate flag is used.
>If you seek excuses to not include such an optimisation as a special
>case, do not think I seek excuses to include such an optimisation without
>proper research whether it is useful.
The issue is not seeking excuses, but whether we should add @RAM C@RAM
etc. to allow such optimizations. I don't think that anybody will add
such words without numbers for the usefulness of this optimization.
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-11-20 18:12 +0100 |
| Message-ID | <o0slip$4ji$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #52715 |
In article <2016Nov18.164128@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>In article <2016Nov17.135826@mips.complang.tuwien.ac.at>,
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>>In article <2016Nov14.180809@mips.complang.tuwien.ac.at>,
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>Harold <hzrabbie@gmail.com> writes:
>>>>>>You can get the @ DROP sequence as a result of in-lining.
>>>>>
>>>>>Any evidence of that occuring to any relevant extent? No? Thought so.
>>>>
>>>>I expect this or things similar to this to happen all the time.
>>>>Think of FIND. It leaves an immediate flag too.
>>>>In cases where the flag is needed and FIND is inlined, the
>>>>optimisation trickles down to the place where something is fetched.
>>>
>>>This is just another out-of-the-blue claim without empirical support,
>>>the kind that's popular among "optimization" apologists. Where is the
>>>evidence and where is the relevant extent? I.e., in which programs
>>>does this occur, how often is the code that does this executed, and
>>>how much time is spent in it?
>>
>>You can do this yourself easily. How often is FIND used, and how
>>often do you need its flag?
>
>I normally do not use it. Instead, I use FIND-NAME, which does not do
>this possibly useless work of generating an immediate flag. That's
>the Forth way: instead of inventing "optimizations" to deal with
>crufty interfaces, have a clean interface that does not call for
>optimizing parts away.
ciforth also uses FOUND which is approximately FIND. That is neither
here nor there.
>
>Otherwise, I expect that FIND is mostly used in user-written text
>interpreters, and there the immediate flag is used.
I don't want to argue about how often this particular optimisation applies.
>
>>If you seek excuses to not include such an optimisation as a special
>>case, do not think I seek excuses to include such an optimisation without
>>proper research whether it is useful.
>
>The issue is not seeking excuses, but whether we should add @RAM C@RAM
>etc. to allow such optimizations. I don't think that anybody will add
>such words without numbers for the usefulness of this optimization.
Renaming @ into @RAM is stupid. Adding PC@ for a byte fetch from a
port that has an input and an output side effect in order to
allow an optimiser to know about side effects is not.
And of course on a i86 architecture they compile to different
instructions, so C@ and PC@ are just not the same.
It is common sense for portable Forth to make the distinction anyway.
I fired up my optimiser for the first time since version 5 of ciforth.
It optimises `` @ DROP '' away but not `` PC@ DROP '' or `` PW@ DROP ''.
I would need to exclude this special case to actually prevent this
optimisation, because it is a special case from a very general optimisation.
"
~/PROJECT/ciforth$ lina-ana
80386 ciforth beta $RCSfile: ci86.gnr,v $ $Revision: 5.139 $
INCLUDE optimiser.frt
# : ISN'T UNIQUE
$-PREFIX : (WARNING) NOT PRESENT, THOUGH WANTED
PROGRESS : ISN'T UNIQUE
OK
: test BASE @ DROP ;
OK
: jan test test test ;
OK
'jan OPTIMISE
OK
SEE jan
: jan
;
OK
$41 CONSTANT timer
OK
: test2 timer PW@ DROP ;
OK
: piet test2 test2 test2 ;
OK
'piet OPTIMISE
OK
SEE piet
: piet
0000,0041 PW@ DROP 0000,0041 PW@ DROP 0000,0041 PW@ DROP
;
OK
"
>
>- anton
groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2016-11-09 03:15 -0800 |
| Message-ID | <fba26251-20ef-4b0e-a655-b2204093f1df@googlegroups.com> |
| In reply to | #52476 |
Am Mittwoch, 9. November 2016 07:03:02 UTC+1 schrieb trans: > Are there any statistics on the average swaps per word in Forth code? What is behind this question? Runtime penalty of stack juggling? Optimizing compilers for register-architectures shouldn't produce any.
[toc] | [prev] | [next] | [standalone]
| From | trans <transfire@gmail.com> |
|---|---|
| Date | 2016-11-09 11:22 -0800 |
| Message-ID | <e9901bb4-c8d6-4324-a53d-b559a24833e2@googlegroups.com> |
| In reply to | #52482 |
On Wednesday, November 9, 2016 at 6:15:19 AM UTC-5, minf...@arcor.de wrote: > Am Mittwoch, 9. November 2016 07:03:02 UTC+1 schrieb trans: > > Are there any statistics on the average swaps per word in Forth code? > > What is behind this question? Runtime penalty of stack juggling? > > Optimizing compilers for register-architectures shouldn't produce any. Yes, good to know.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-11-10 12:20 +1100 |
| Message-ID | <o00i0v$1a87$1@gioia.aioe.org> |
| In reply to | #52482 |
minforth@arcor.de wrote: > Am Mittwoch, 9. November 2016 07:03:02 UTC+1 schrieb trans: > > Are there any statistics on the average swaps per word in Forth code? > > What is behind this question? Runtime penalty of stack juggling? > > Optimizing compilers for register-architectures shouldn't produce any. If you don't have an optimizing compiler, then what? Forth is about the stack and the efficient use thereof. Terms like "stack juggling" give newcomers (and the rest of the world) the impression the stack is something to be avoided. Optimizing compilers may reduce stack operations and/or correct redundancy, however I consider it a bonus - not a goal.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-11-09 21:04 -1000 |
| Message-ID | <h8KdnUnF_umfgbnFnZ2dnUU7-UednZ2d@supernews.com> |
| In reply to | #52494 |
On 11/9/16 3:20 PM, HAA wrote: > minforth@arcor.de wrote: >> Am Mittwoch, 9. November 2016 07:03:02 UTC+1 schrieb trans: >>> Are there any statistics on the average swaps per word in Forth code? >> >> What is behind this question? Runtime penalty of stack juggling? >> >> Optimizing compilers for register-architectures shouldn't produce any. > > If you don't have an optimizing compiler, then what? Forth is about > the stack and the efficient use thereof. Terms like "stack juggling" > give newcomers (and the rest of the world) the impression the stack > is something to be avoided. Optimizing compilers may reduce stack > operations and/or correct redundancy, however I consider it a bonus > - not a goal. "Stack juggling" is a bogey man for first-time Forth users. It's rather like learning to ride a bike for the first time, rather wobbly. It takes but a few days of trying seriously to think through your process to use the stack effectively, which doesn't feel like "juggling" at all. It's worth learning good stack management techniques whether you have an optimizing compiler or not, because clean, well-designed code will always be easier to debug and maintain. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-11-10 03:45 -0600 |
| Message-ID | <5KednfIjFuQm3LnFnZ2dnUU7-cnNnZ2d@supernews.com> |
| In reply to | #52494 |
HAA <someone@microsoft.com> wrote: > minforth@arcor.de wrote: >> Am Mittwoch, 9. November 2016 07:03:02 UTC+1 schrieb trans: >> > Are there any statistics on the average swaps per word in Forth code? >> >> What is behind this question? Runtime penalty of stack juggling? >> >> Optimizing compilers for register-architectures shouldn't produce any. > > If you don't have an optimizing compiler, then what? Forth is about > the stack and the efficient use thereof. Terms like "stack > juggling" give newcomers (and the rest of the world) the impression > the stack is something to be avoided. Well, it is in a sense. One thing you can say for sure is that just moving stuff about doesn't directly do anything useful. The goal should be to make sure that words put stuff where it's going to be needed, and operations happen on the top of the stack. Well-written Forth (IMVHO) doesn't usually have a lot of stack juggling and indeed doesn't use very much stack memory. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-11-10 11:52 -0500 |
| Message-ID | <o028k6$jei$1@dont-email.me> |
| In reply to | #52498 |
On 11/10/2016 4:45 AM, Andrew Haley wrote: > HAA <someone@microsoft.com> wrote: >> minforth@arcor.de wrote: >>> Am Mittwoch, 9. November 2016 07:03:02 UTC+1 schrieb trans: >>>> Are there any statistics on the average swaps per word in Forth code? >>> >>> What is behind this question? Runtime penalty of stack juggling? >>> >>> Optimizing compilers for register-architectures shouldn't produce any. >> >> If you don't have an optimizing compiler, then what? Forth is about >> the stack and the efficient use thereof. Terms like "stack >> juggling" give newcomers (and the rest of the world) the impression >> the stack is something to be avoided. > > Well, it is in a sense. One thing you can say for sure is that just > moving stuff about doesn't directly do anything useful. The goal > should be to make sure that words put stuff where it's going to be > needed, and operations happen on the top of the stack. Well-written > Forth (IMVHO) doesn't usually have a lot of stack juggling and indeed > doesn't use very much stack memory. I'm from the school that believes stack ops are by definition "juggling" and a waste of programmer time and effort. In other languages the programmer does not have to think about register allocation or memory use. This is handled automatically. I suppose that is why local variables were added to Forth though, were they not? If you don't like stack juggling, then use local variables. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-11-10 11:42 -0600 |
| Message-ID | <JdmdnfjTv9wWLLnFnZ2dnUU7-QGdnZ2d@supernews.com> |
| In reply to | #52511 |
rickman <gnuarm@gmail.com> wrote: > I'm from the school that believes stack ops are by definition > "juggling" and a waste of programmer time and effort. In other > languages the programmer does not have to think about register > allocation or memory use. This is handled automatically. > > I suppose that is why local variables were added to Forth though, > were they not? If you don't like stack juggling, then use local > variables. I don't think that locals help as much as some people think. After all, storing things in locals and fetching them out again is still moving stuff around. And there are other ways of solving the problem than locals. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-11-10 13:34 -0500 |
| Message-ID | <o02ehv$9oi$1@dont-email.me> |
| In reply to | #52512 |
On 11/10/2016 12:42 PM, Andrew Haley wrote: > rickman <gnuarm@gmail.com> wrote: > >> I'm from the school that believes stack ops are by definition >> "juggling" and a waste of programmer time and effort. In other >> languages the programmer does not have to think about register >> allocation or memory use. This is handled automatically. >> >> I suppose that is why local variables were added to Forth though, >> were they not? If you don't like stack juggling, then use local >> variables. > > I don't think that locals help as much as some people think. After > all, storing things in locals and fetching them out again is still > moving stuff around. And there are other ways of solving the problem > than locals. You are talking about run time efficiency. I can't remember the last time I wrote a program where run time efficiency was an issue. I am talking about optimizing the truly precious resource in most programming... the programmer time. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-11-10 12:54 -0600 |
| Message-ID | <PoudnbA3WJT5X7nFnZ2dnUU7-bWdnZ2d@supernews.com> |
| In reply to | #52513 |
rickman <gnuarm@gmail.com> wrote: > On 11/10/2016 12:42 PM, Andrew Haley wrote: >> rickman <gnuarm@gmail.com> wrote: >> >>> I'm from the school that believes stack ops are by definition >>> "juggling" and a waste of programmer time and effort. In other >>> languages the programmer does not have to think about register >>> allocation or memory use. This is handled automatically. >>> >>> I suppose that is why local variables were added to Forth though, >>> were they not? If you don't like stack juggling, then use local >>> variables. >> >> I don't think that locals help as much as some people think. After >> all, storing things in locals and fetching them out again is still >> moving stuff around. And there are other ways of solving the problem >> than locals. > > You are talking about run time efficiency. I'm not, not really anyway. I'm talking about words in your program -- words in the source code -- that are nothing more than moving stuff about. Creating locals and getting values out of them is still "moving stuff about". The Forth ideal is to have a pipeline of words interconnected by the stack. Of course, in the real world nothing is quite as ideal as that, so you still need some noise words to get things into position. And as we've seen with our latest (highly contrived) example, it can get very weird. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-11-10 16:33 -0500 |
| Message-ID | <o02p1l$k4a$1@dont-email.me> |
| In reply to | #52514 |
On 11/10/2016 1:54 PM, Andrew Haley wrote: > rickman <gnuarm@gmail.com> wrote: >> On 11/10/2016 12:42 PM, Andrew Haley wrote: >>> rickman <gnuarm@gmail.com> wrote: >>> >>>> I'm from the school that believes stack ops are by definition >>>> "juggling" and a waste of programmer time and effort. In other >>>> languages the programmer does not have to think about register >>>> allocation or memory use. This is handled automatically. >>>> >>>> I suppose that is why local variables were added to Forth though, >>>> were they not? If you don't like stack juggling, then use local >>>> variables. >>> >>> I don't think that locals help as much as some people think. After >>> all, storing things in locals and fetching them out again is still >>> moving stuff around. And there are other ways of solving the problem >>> than locals. >> >> You are talking about run time efficiency. > > I'm not, not really anyway. I'm talking about words in your program > -- words in the source code -- that are nothing more than moving stuff > about. Creating locals and getting values out of them is still > "moving stuff about". > > The Forth ideal is to have a pipeline of words interconnected by the > stack. Of course, in the real world nothing is quite as ideal as > that, so you still need some noise words to get things into position. > And as we've seen with our latest (highly contrived) example, it can > get very weird. I suppose you are a serious forth user. I am not. I use Forth as often as I drive my friend's car. I have a stick, she has an automatic. I still want to push in the clutch when I come to a stop. I see using an object name as natural and not as "moving" stuff around. Maybe that's not a good analogy. My point is I don't have to think as much to use the name of an object as I do to remember where it is on the stack and to juggle the stack to get it where it can be used. That is the only real limitation of a stack, the fact that it is invisible other than in ones mind as a program is being written. This is a significant enough limitation that techniques are used to minimize the impact, such as keeping every word short and to the point. Of course this is recommended for all languages, but every word adds overhead. The cost of that overhead is less with forth while the impact of longer words is not as great in languages that use explicit routine parameters. It's a trade off. Each approach has costs and advantages. So while using a name of an object may result in data movement, I don't have to think about that explicitly. I just know I am using it or I am passing it to another word. I don't care that the underlying mechanism is the stack. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-11-10 15:56 -1000 |
| Message-ID | <A8WdnaCjJYGjuLjFnZ2dnUU7-KnNnZ2d@supernews.com> |
| In reply to | #52519 |
On 11/10/16 11:33 AM, rickman wrote: > On 11/10/2016 1:54 PM, Andrew Haley wrote: >> rickman <gnuarm@gmail.com> wrote: >>> On 11/10/2016 12:42 PM, Andrew Haley wrote: >>>> rickman <gnuarm@gmail.com> wrote: >>>> >>>>> I'm from the school that believes stack ops are by definition >>>>> "juggling" and a waste of programmer time and effort. In other >>>>> languages the programmer does not have to think about register >>>>> allocation or memory use. This is handled automatically. >>>>> >>>>> I suppose that is why local variables were added to Forth though, >>>>> were they not? If you don't like stack juggling, then use local >>>>> variables. >>>> >>>> I don't think that locals help as much as some people think. After >>>> all, storing things in locals and fetching them out again is still >>>> moving stuff around. And there are other ways of solving the problem >>>> than locals. >>> >>> You are talking about run time efficiency. >> >> I'm not, not really anyway. I'm talking about words in your program >> -- words in the source code -- that are nothing more than moving stuff >> about. Creating locals and getting values out of them is still >> "moving stuff about". >> >> The Forth ideal is to have a pipeline of words interconnected by the >> stack. Of course, in the real world nothing is quite as ideal as >> that, so you still need some noise words to get things into position. >> And as we've seen with our latest (highly contrived) example, it can >> get very weird. > > I suppose you are a serious forth user. I am not. I use Forth as often > as I drive my friend's car. I have a stick, she has an automatic. I > still want to push in the clutch when I come to a stop. I see using an > object name as natural and not as "moving" stuff around. > > Maybe that's not a good analogy. My point is I don't have to think as > much to use the name of an object as I do to remember where it is on the > stack and to juggle the stack to get it where it can be used. That is > the only real limitation of a stack, the fact that it is invisible other > than in ones mind as a program is being written. This is a significant > enough limitation that techniques are used to minimize the impact, such > as keeping every word short and to the point. Of course this is > recommended for all languages, but every word adds overhead. The cost > of that overhead is less with forth while the impact of longer words is > not as great in languages that use explicit routine parameters. It's a > trade off. Each approach has costs and advantages. > > So while using a name of an object may result in data movement, I don't > have to think about that explicitly. I just know I am using it or I am > passing it to another word. I don't care that the underlying mechanism > is the stack. The other point of view is that it's easier on the brain not to have to remember so many names of things :-) I think you hit the nail on the head when you said you didn't use Forth very often, and your analogy to driving with a stick or automatic is pretty good. A person who normally drives a stick shift car never things explicitly about shifting gears, they just do it. And they like not having to buy as much gas as the folks using the automatics. If you use Forth regularly, you rarely think much about the stack, because all you're concerned about in the moment are the one or two arguments to the word you're writing, and you document them so you'll know next time. We find that easier on the mind than having to think up more names and document what they do. As I've often said, it's like learning to ride a bicycle: wobbly at first, but thereafter smooth and natural. It's a different paradigm from most other programming languages, so unfamiliar at first, but comfortable thereafter. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-11-10 21:30 -0500 |
| Message-ID | <o03aed$d47$1@dont-email.me> |
| In reply to | #52524 |
On 11/10/2016 8:56 PM, Elizabeth D. Rather wrote: > On 11/10/16 11:33 AM, rickman wrote: >> On 11/10/2016 1:54 PM, Andrew Haley wrote: >>> rickman <gnuarm@gmail.com> wrote: >>>> On 11/10/2016 12:42 PM, Andrew Haley wrote: >>>>> rickman <gnuarm@gmail.com> wrote: >>>>> >>>>>> I'm from the school that believes stack ops are by definition >>>>>> "juggling" and a waste of programmer time and effort. In other >>>>>> languages the programmer does not have to think about register >>>>>> allocation or memory use. This is handled automatically. >>>>>> >>>>>> I suppose that is why local variables were added to Forth though, >>>>>> were they not? If you don't like stack juggling, then use local >>>>>> variables. >>>>> >>>>> I don't think that locals help as much as some people think. After >>>>> all, storing things in locals and fetching them out again is still >>>>> moving stuff around. And there are other ways of solving the problem >>>>> than locals. >>>> >>>> You are talking about run time efficiency. >>> >>> I'm not, not really anyway. I'm talking about words in your program >>> -- words in the source code -- that are nothing more than moving stuff >>> about. Creating locals and getting values out of them is still >>> "moving stuff about". >>> >>> The Forth ideal is to have a pipeline of words interconnected by the >>> stack. Of course, in the real world nothing is quite as ideal as >>> that, so you still need some noise words to get things into position. >>> And as we've seen with our latest (highly contrived) example, it can >>> get very weird. >> >> I suppose you are a serious forth user. I am not. I use Forth as often >> as I drive my friend's car. I have a stick, she has an automatic. I >> still want to push in the clutch when I come to a stop. I see using an >> object name as natural and not as "moving" stuff around. >> >> Maybe that's not a good analogy. My point is I don't have to think as >> much to use the name of an object as I do to remember where it is on the >> stack and to juggle the stack to get it where it can be used. That is >> the only real limitation of a stack, the fact that it is invisible other >> than in ones mind as a program is being written. This is a significant >> enough limitation that techniques are used to minimize the impact, such >> as keeping every word short and to the point. Of course this is >> recommended for all languages, but every word adds overhead. The cost >> of that overhead is less with forth while the impact of longer words is >> not as great in languages that use explicit routine parameters. It's a >> trade off. Each approach has costs and advantages. >> >> So while using a name of an object may result in data movement, I don't >> have to think about that explicitly. I just know I am using it or I am >> passing it to another word. I don't care that the underlying mechanism >> is the stack. > > The other point of view is that it's easier on the brain not to have to > remember so many names of things :-) I think you hit the nail on the > head when you said you didn't use Forth very often, and your analogy to > driving with a stick or automatic is pretty good. A person who normally > drives a stick shift car never things explicitly about shifting gears, > they just do it. And they like not having to buy as much gas as the > folks using the automatics. > > If you use Forth regularly, you rarely think much about the stack, > because all you're concerned about in the moment are the one or two > arguments to the word you're writing, and you document them so you'll > know next time. We find that easier on the mind than having to think up > more names and document what they do. As I've often said, it's like > learning to ride a bicycle: wobbly at first, but thereafter smooth and > natural. It's a different paradigm from most other programming > languages, so unfamiliar at first, but comfortable thereafter. I'm sure this could be debated back and forth (no pun intended). When you talk about the "extra" work of thinking up names and documenting these variables, if they are simply replacing the procedure inputs and outputs, they should be documented already. There is no extra work to using the same notation as used in the stack documentation. To each their own, but I think it is a tough sell to say the stack is easier on the brain. I know the manual transmission is *not* easier to use. As you say it is usually mentally automatic, but there has been more than once that I down shifted to the wrong gear for the speed after having to hit my brakes. It is not often, but there are plenty of times when I let the clutch out a bit too fast and the shift is not smooth. I never have that problem with an automatic transmission. I remember the days when a C compiler could not be trusted to produce good or even *correct* code. But those days are largely past and a good compiler will do as well as a person in generating efficient code. The stack may be something you get used to, but it will never be the *better* tool. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-11-11 03:04 -0600 |
| Message-ID | <8s-dnR_w-rIlFLjFnZ2dnUU7-dfNnZ2d@supernews.com> |
| In reply to | #52525 |
rickman <gnuarm@gmail.com> wrote:
>
> I'm sure this could be debated back and forth (no pun intended).
> When you talk about the "extra" work of thinking up names and
> documenting these variables, if they are simply replacing the
> procedure inputs and outputs, they should be documented already.
> There is no extra work to using the same notation as used in the
> stack documentation.
I'd like to stress Elizabeth's point about not thinking about the
stack. An experienced reader of a Forth program doesn't think about
the stack all the time, but about phrases and the flow of code. Until
they hit some incomprehensible spaghetti like
2dup 4 pick 1- recurse >r \ z'
dup 2over 1- recurse >r \ y'
1- recurse
2r> rot
which I ssuspect no Forth programmer, however experienced, could
understand without resorting to drawing stack diagrams. [I intend no
offence to Anton Ertl, the author of this code: it's a
highly-contrived example meant to illustrate a point.] But even if
this code is written in an "algebraic" notation it's hard to
understand what it does.
> To each their own, but I think it is a tough sell to say the stack
> is easier on the brain.
If you actually need to shuffle stuff around in a complex way, that
might well be true.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-11-12 13:25 +0000 |
| Message-ID | <2016Nov12.142535@mips.complang.tuwien.ac.at> |
| In reply to | #52532 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>rickman <gnuarm@gmail.com> wrote:
>I'd like to stress Elizabeth's point about not thinking about the
>stack. An experienced reader of a Forth program doesn't think about
>the stack all the time, but about phrases and the flow of code. Until
>they hit some incomprehensible spaghetti like
>
> 2dup 4 pick 1- recurse >r \ z'
> dup 2over 1- recurse >r \ y'
> 1- recurse
> 2r> rot
>
>which I ssuspect no Forth programmer, however experienced, could
>understand without resorting to drawing stack diagrams. [I intend no
>offence to Anton Ertl, the author of this code: it's a
>highly-contrived example meant to illustrate a point.] But even if
>this code is written in an "algebraic" notation it's hard to
>understand what it does.
That's because it does nothing useful. Still, the locals version is
the one that's clearest to me, with the version below making the
symmetry in the calls most obvious.
: tak1 ( z y x -- z y x r )
2dup < if
1- recurse >r 1+ -rot ( x z y )
1- recurse >r 1+ -rot ( y x z )
1- recurse >r 1+ -rot ( z y x )
r> r> r> recurse nip nip nip
else
2 pick
then ;
Let's see if we can get that property with a more idiomatic stack effect:
: tak1a ( z y x -- r )
begin
2dup < while
3dup 1- recurse >r -rot
3dup 1- recurse >r -rot
1- recurse
r> r> repeat
2drop ;
With : 3dup dup 2over rot ; this gives the following timings:
3dup-builtin 3dup-2pick locals tak1 tak2 tak1a
gforth 1160859139 1023792580 816129237 633233631 859610716
sf 472184708 533401690 4529954652 356164897 253178697 423469455
vfxlin 490283220 401685949 700320112 352936074 238431403 305372513
BTW, did you already present your go at coding TAK?
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-11-14 03:34 -0600 |
| Message-ID | <EMidnUutybywGLTFnZ2dnUU7-cPNnZ2d@supernews.com> |
| In reply to | #52555 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>which I ssuspect no Forth programmer, however experienced, could >>understand without resorting to drawing stack diagrams. [I intend no >>offence to Anton Ertl, the author of this code: it's a >>highly-contrived example meant to illustrate a point.] But even if >>this code is written in an "algebraic" notation it's hard to >>understand what it does. > > That's because it does nothing useful. Well, yes: it's literally meaningless. There's no way to understand what it does because it doesn't do anything except perhaps waste computer time. So, the question of "How would you do this if you needed to do it in a real application?" is a category error. > BTW, did you already present your go at coding TAK? No. I think that all the reasonable permutations have already been explored. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-11-11 10:41 +0000 |
| Message-ID | <o0478m$1ud$1@dont-email.me> |
| In reply to | #52524 |
On 11/11/2016 01:56, Elizabeth D. Rather wrote: > The other point of view is that it's easier on the brain not to have > to remember so many names of things. [...] > If you use Forth regularly, you rarely think much about the stack, > because all you're concerned about in the moment are the one or two > arguments to the word you're writing, and you document them so you'll > know next time. We find that easier on the mind than having to think up > more names and document what they do. I don't think that's a good reason against locals. After all the same argument applies to the commonly given advice to factor code into many small words, the names of which you have to think up, remember, document and (usually) have to be different. Why is that easier on the mind? -- Gerry
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web