Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #5198 > unrolled thread
| Started by | JennyB <jennybrien@googlemail.com> |
|---|---|
| First post | 2011-08-24 07:01 -0700 |
| Last post | 2011-09-01 10:33 -0700 |
| Articles | 20 on this page of 117 — 15 participants |
Back to article view | Back to comp.lang.forth
A Minimal Extended Control Wordset JennyB <jennybrien@googlemail.com> - 2011-08-24 07:01 -0700
Re: A Minimal Extended Control Wordset JennyB <jennybrien@googlemail.com> - 2011-08-24 07:50 -0700
Re: A Minimal Extended Control Wordset Alex McDonald <blog@rivadpm.com> - 2011-08-24 08:04 -0700
Re: A Minimal Extended Control Wordset JennyB <jennybrien@googlemail.com> - 2011-08-24 08:59 -0700
Re: A Minimal Extended Control Wordset coos haak <chforth@hccnet.nl> - 2011-08-24 20:00 +0200
Re: A Minimal Extended Control Wordset JennyB <jennybrien@googlemail.com> - 2011-08-24 14:03 -0700
Re: A Minimal Extended Control Wordset coos haak <chforth@hccnet.nl> - 2011-08-26 20:36 +0200
Re: A Minimal Extended Control Wordset JennyB <jennybrien@googlemail.com> - 2011-08-24 07:54 -0700
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-09-12 09:43 -0700
Re: A Minimal Extended Control Wordset "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-24 18:52 -0400
Re: A Minimal Extended Control Wordset JennyB <jennybrien@googlemail.com> - 2011-08-25 06:52 -0700
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-08-26 12:23 +1000
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-08-25 21:03 -0700
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-08-26 20:02 +1000
Re: A Minimal Extended Control Wordset JennyB <jennybrien@googlemail.com> - 2011-08-26 04:36 -0700
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-08-26 10:42 -0700
Re: A Minimal Extended Control Wordset JennyB <jennybrien@googlemail.com> - 2011-08-27 14:45 -0700
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-08-27 17:13 -0700
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-08-26 10:16 -0700
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-08-25 09:46 -0700
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-08-25 20:54 -0700
Re: A Minimal Extended Control Wordset JennyB <jennybrien@googlemail.com> - 2011-08-26 10:24 -0700
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-08-26 11:04 -0700
Re: A Minimal Extended Control Wordset JennyB <jennybrien@googlemail.com> - 2011-08-31 04:14 -0700
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-08-31 15:25 -0700
Re: A Minimal Extended Control Wordset JennyB <jennybrien@googlemail.com> - 2011-09-01 04:00 -0700
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-09-01 12:47 -0700
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-08-27 13:18 +1000
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-08-27 04:41 -0700
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-08-28 13:28 +1000
Re: A Minimal Extended Control Wordset "Elizabeth D. Rather" <erather@forth.com> - 2011-08-27 18:32 -1000
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-08-29 12:32 +1000
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-08-28 09:22 -0700
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-08-29 12:30 +1000
Re: A Minimal Extended Control Wordset "Elizabeth D. Rather" <erather@forth.com> - 2011-08-28 18:17 -1000
return address manipulation (was: A Minimal Extended Control Wordset) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-29 09:14 +0000
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-29 05:53 -0500
Re: return address manipulation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-29 11:45 +0000
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-08-30 14:08 +1000
Re: A Minimal Extended Control Wordset "Elizabeth D. Rather" <erather@forth.com> - 2011-08-29 18:28 -1000
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-08-31 13:52 +1000
Re: A Minimal Extended Control Wordset "Elizabeth D. Rather" <erather@forth.com> - 2011-08-30 21:42 -1000
Re: A Minimal Extended Control Wordset Paul Rubin <no.email@nospam.invalid> - 2011-08-31 00:47 -0700
Re: A Minimal Extended Control Wordset "Elizabeth D. Rather" <erather@forth.com> - 2011-08-30 21:55 -1000
Re: A Minimal Extended Control Wordset Paul Rubin <no.email@nospam.invalid> - 2011-09-01 00:44 -0700
Re: A Minimal Extended Control Wordset Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-01 03:37 -0500
Re: A Minimal Extended Control Wordset Paul Rubin <no.email@nospam.invalid> - 2011-09-01 02:19 -0700
Re: A Minimal Extended Control Wordset Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-01 05:05 -0500
min-max-sum (was: A Minimal Extended Control Wordset) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-09-01 14:32 +0000
Re: min-max-sum Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-01 10:43 -0500
Re: min-max-sum anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-09-01 15:59 +0000
Re: min-max-sum BruceMcF <agila61@netscape.net> - 2011-09-01 13:13 -0700
Re: min-max-sum Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-02 04:12 -0500
Re: min-max-sum Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-02 04:31 -0500
Re: min-max-sum anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-09-02 10:41 +0000
Re: min-max-sum Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-02 06:31 -0500
Re: min-max-sum anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-09-04 13:18 +0000
Re: min-max-sum mhx@iae.nl (Marcel Hendrix) - 2011-09-04 22:42 +0200
Re: min-max-sum anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-09-05 08:16 +0000
Re: min-max-sum Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-05 02:58 -0500
Re: min-max-sum BruceMcF <agila61@netscape.net> - 2011-09-02 08:43 -0700
Re: min-max-sum coos haak <chforth@hccnet.nl> - 2011-09-02 20:35 +0200
Re: min-max-sum BruceMcF <agila61@netscape.net> - 2011-09-03 11:48 -0700
Re: min-max-sum BruceMcF <agila61@netscape.net> - 2011-09-04 18:31 -0700
Re: min-max-sum Alex McDonald <blog@rivadpm.com> - 2011-09-02 05:37 -0700
Re: min-max-sum mhx@iae.nl (Marcel Hendrix) - 2011-09-03 12:06 +0200
Re: A Minimal Extended Control Wordset Paul Rubin <no.email@nospam.invalid> - 2011-09-04 22:07 -0700
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-09-04 22:56 -0700
Re: A Minimal Extended Control Wordset C G Montgomery <cgm@physics.utoledo.edu> - 2011-09-05 17:44 -0400
Re: A Minimal Extended Control Wordset Paul Rubin <no.email@nospam.invalid> - 2011-09-05 18:10 -0700
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-09-01 11:01 -0700
Re: A Minimal Extended Control Wordset "Elizabeth D. Rather" <erather@forth.com> - 2011-09-01 09:17 -1000
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-09-01 13:39 +1000
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-09-01 10:21 -0700
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-09-05 12:24 +1000
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-09-04 21:11 -0700
Re: A Minimal Extended Control Wordset Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-09-06 18:13 +0000
Re: A Minimal Extended Control Wordset Alex McDonald <blog@rivadpm.com> - 2011-09-06 12:15 -0700
Re: A Minimal Extended Control Wordset "Elizabeth D. Rather" <erather@forth.com> - 2011-09-06 09:53 -1000
Re: A Minimal Extended Control Wordset Alex McDonald <blog@rivadpm.com> - 2011-09-06 14:18 -0700
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-09-06 17:32 -0700
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-09-07 19:43 +1000
Re: A Minimal Extended Control Wordset Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-07 06:02 -0500
Re: A Minimal Extended Control Wordset Alex McDonald <blog@rivadpm.com> - 2011-09-07 05:41 -0700
Re: A Minimal Extended Control Wordset anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-09-07 16:00 +0000
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-09-09 08:52 +1000
Re: A Minimal Extended Control Wordset Alex McDonald <blog@rivadpm.com> - 2011-09-08 16:08 -0700
Re: A Minimal Extended Control Wordset George Hubert <georgeahubert@yahoo.co.uk> - 2011-09-09 04:12 -0700
Re: A Minimal Extended Control Wordset Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-09-10 09:09 +0000
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-09-11 18:29 +1000
Re: A Minimal Extended Control Wordset Alex McDonald <blog@rivadpm.com> - 2011-09-11 09:04 -0700
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-09-15 19:25 +1000
Re: A Minimal Extended Control Wordset Alex McDonald <blog@rivadpm.com> - 2011-09-15 03:30 -0700
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-09-18 15:43 +1000
Re: A Minimal Extended Control Wordset "Elizabeth D. Rather" <erather@forth.com> - 2011-09-17 20:42 -1000
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-09-19 05:14 +1000
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-09-18 19:31 -0700
Re: A Minimal Extended Control Wordset Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-18 01:49 -0500
Re: A Minimal Extended Control Wordset "Elizabeth D. Rather" <erather@forth.com> - 2011-09-08 14:56 -1000
Re: A Minimal Extended Control Wordset anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-09-09 08:20 +0000
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-09-11 16:22 +1000
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-09-11 03:06 -0700
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-09-08 19:29 -0700
Re: A Minimal Extended Control Wordset Brad <hwfwguy@gmail.com> - 2011-09-08 08:58 -0700
Re: A Minimal Extended Control Wordset Alex McDonald <blog@rivadpm.com> - 2011-09-08 10:00 -0700
Re: A Minimal Extended Control Wordset coos haak <chforth@hccnet.nl> - 2011-09-08 22:00 +0200
Re: A Minimal Extended Control Wordset Alex McDonald <blog@rivadpm.com> - 2011-09-08 16:02 -0700
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-09-09 09:16 +1000
Re: A Minimal Extended Control Wordset "Elizabeth D. Rather" <erather@forth.com> - 2011-09-08 15:04 -1000
Re: A Minimal Extended Control Wordset Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-09-09 04:13 -0500
Re: A Minimal Extended Control Wordset Brad <hwfwguy@gmail.com> - 2011-08-31 09:20 -0700
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-08-28 21:31 -0700
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-08-31 13:53 +1000
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-08-31 04:11 -0700
Re: A Minimal Extended Control Wordset "Ed" <nospam@invalid.com> - 2011-09-01 14:47 +1000
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-09-01 10:32 -0700
Re: A Minimal Extended Control Wordset BruceMcF <agila61@netscape.net> - 2011-09-01 10:33 -0700
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | "Ed" <nospam@invalid.com> |
|---|---|
| Date | 2011-08-31 13:52 +1000 |
| Message-ID | <j3kb67$h0e$1@news-01.bur.connect.com.au> |
| In reply to | #5363 |
Elizabeth D. Rather wrote:
> On 8/29/11 6:08 PM, Ed wrote:
> ...
> >> Yeah, but what Chuck thinks is "intrinsic to the Forth language" changes
> >> from year to year. For example, FOR ... NEXT is in and DO ... LOOP is
> >> out in recent years.
> >
> > Wow! And this from one who cited Chuck as an expert Forth
> > programmer. Can anyone take Forth seriously after this :)
>
> He is very definitely an expert Forth programmer. He is far from an
> expert standards developer.
I intended to say "Forth designer" - meaning he has the capacity
to discriminate what Forth needs as a language.
> ...
> > Anything is possible in Forth, right? If R> DROP isn't portable
> > then pick a name e.g. UNNEST and implementors can effect
> > it as they wish.
>
> Sure. Write up a proposal.
On my system I've defined it as:
UNNEST ( -- ) ( R: nest-sys -- )
Discard nest-sys. Before executing EXIT, a program shall remove
any parameters left on the return stack by the calling definition.
An ambiguous condition exists if the current or calling definition
uses locals.
If anyone wishes to use it as a starting point for a proposal etc, they
are free to do so.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2011-08-30 21:42 -1000 |
| Message-ID | <BeCdnRqO86pmeMDTnZ2dnUVZ_oCdnZ2d@supernews.com> |
| In reply to | #5390 |
On 8/30/11 5:52 PM, Ed wrote: > Elizabeth D. Rather wrote: >> On 8/29/11 6:08 PM, Ed wrote: >> ... >>>> Yeah, but what Chuck thinks is "intrinsic to the Forth language" changes >>>> from year to year. For example, FOR ... NEXT is in and DO ... LOOP is >>>> out in recent years. >>> >>> Wow! And this from one who cited Chuck as an expert Forth >>> programmer. Can anyone take Forth seriously after this :) >> >> He is very definitely an expert Forth programmer. He is far from an >> expert standards developer. > > I intended to say "Forth designer" - meaning he has the capacity > to discriminate what Forth needs as a language. Yes. But Chuck has never thought of himself as a "language designer". His view of Forth has always been how to make it the tool to solve the current application challenge, and has little interest in the theory of programming languages. Features he needed in several applications over time found their way into the common sources, but he not only made no attempt to forecast what might be needed in the future, he had only contempt for those who attempted to do so. Moreover, he was perfectly happy to make any change in the "rules" at any time if it seemed productive for the current project, regardless of its effect on other potential users. In summary, he viewed Forth from a purely personal perspective, and (from all indications) still does. And in my experience, he took a fairly dim view of manipulating return addresses arbitrarily. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-08-31 00:47 -0700 |
| Message-ID | <7xfwkit43i.fsf@ruckus.brouhaha.com> |
| In reply to | #5393 |
"Elizabeth D. Rather" <erather@forth.com> writes: > And in my experience, he took a fairly dim view of manipulating return > addresses arbitrarily. Did he like execution tokens? I'm wondering how the heck he programs without locals, and factoring stuff into xt's seems like one approach.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2011-08-30 21:55 -1000 |
| Message-ID | <0qqdnT7OtYJidcDTnZ2dnUVZ_uednZ2d@supernews.com> |
| In reply to | #5394 |
On 8/30/11 9:47 PM, Paul Rubin wrote: > "Elizabeth D. Rather"<erather@forth.com> writes: >> And in my experience, he took a fairly dim view of manipulating return >> addresses arbitrarily. > > Did he like execution tokens? I'm wondering how the heck he programs > without locals, and factoring stuff into xt's seems like one approach. Chuck rarely used xt's explicitly. And neither he, nor I, nor most of the Forth programmers I've worked with over the years have missed locals at all. It's just a different style of programming from algebraic-style languages. One factors logic into definitions, and passes data on the stack (and sometimes that data is the address of an array, string, or other stucture), but rarely xt's. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-09-01 00:44 -0700 |
| Message-ID | <7xliu8zoy5.fsf@ruckus.brouhaha.com> |
| In reply to | #5395 |
"Elizabeth D. Rather" <erather@forth.com> writes: > Chuck rarely used xt's explicitly. And neither he, nor I, nor most of > the Forth programmers I've worked with over the years have missed > locals at all. It's just a different style of programming from > algebraic-style languages. One factors logic into definitions, and > passes data on the stack (and sometimes that data is the address of an > array, string, or other stucture), but rarely xt's. Did he avoid locals by using variables for stuff that wasn't actually shared between functions? I just don't see any clean way to do the min-max-sum problem discussed further up, without locals, variables instead of locals, or xt's to make multiple passes through the array while factoring out the looping code. Hmm, I guess another possibility is use CREATE to make boilerplate code a la C++ templates, but that doesn't seem to be in the factoring spirit.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-09-01 03:37 -0500 |
| Message-ID | <0PqdneCtEqf52cLTnZ2dnUVZ8tydnZ2d@supernews.com> |
| In reply to | #5429 |
Paul Rubin <no.email@nospam.invalid> wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> Chuck rarely used xt's explicitly. And neither he, nor I, nor most of >> the Forth programmers I've worked with over the years have missed >> locals at all. It's just a different style of programming from >> algebraic-style languages. One factors logic into definitions, and >> passes data on the stack (and sometimes that data is the address of an >> array, string, or other stucture), but rarely xt's. > > Did he avoid locals by using variables for stuff that wasn't actually > shared between functions? I just don't see any clean way to do the > min-max-sum problem discussed further up, without locals, variables > instead of locals, or xt's to make multiple passes through the array > while factoring out the looping code. Two things: That problem is horribly artificial, and it's extemely unlikely that anyone would have needed to solve a problem like that. My solution was clean without locals, variables instead of locals, or xts. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2011-09-01 02:19 -0700 |
| Message-ID | <7xbov4hb6j.fsf@ruckus.brouhaha.com> |
| In reply to | #5431 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> That problem is horribly artificial, and it's extemely unlikely that
> anyone would have needed to solve a problem like that.
It didn't seem artificial to me, wanting to know the min, max, and
average (mean) of some data set. Of course the mean is computed from
the sum.
Mean and standard deviation is another very common problem, involving
finding the sum and the sum of the squares. Maybe that's easier though,
since there are only two running totals.
> My solution was clean without locals, variables instead of locals, or
> xts.
I found your post again; your solution is readable but used structs in a
manner I thought was comparable to variables (created symbols in the
global namespace if I understand it right). Also the inner loop went:
do
i @ over f_sum +!
i @ over f_max max!
i @ over f_min min!
loop drop ;
One of my attempts tried to factor something like the repeated "i @
over" into a separate word, but that doesn't work because of the
way "i" reaches into the return stack.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-09-01 05:05 -0500 |
| Message-ID | <kcmdnVOjmP9nxcLTnZ2dnUVZ8hmdnZ2d@supernews.com> |
| In reply to | #5432 |
Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> That problem is horribly artificial, and it's extemely unlikely that
>> anyone would have needed to solve a problem like that.
>
> It didn't seem artificial to me, wanting to know the min, max, and
> average (mean) of some data set. Of course the mean is computed from
> the sum.
You always want all three? OK.
> Mean and standard deviation is another very common problem, involving
> finding the sum and the sum of the squares. Maybe that's easier though,
> since there are only two running totals.
>
>> My solution was clean without locals, variables instead of locals, or
>> xts.
>
> I found your post again; your solution is readable but used structs in a
> manner I thought was comparable to variables (created symbols in the
> global namespace if I understand it right).
Certainly not! Global variables are global, but these were local to
the caller: the names are just offsets from a base. This kind of
thing is very Forth.
> Also the inner loop went:
>
> do
> i @ over f_sum +!
> i @ over f_max max!
> i @ over f_min min!
> loop drop ;
>
> One of my attempts tried to factor something like the repeated "i @
> over" into a separate word,
Well, it could be reorganized at the expense of clarity, but I'm not
sure why you'd want to do that. From a performance point of view it
might be nice to eliminate the multiple fetches:
do
i @ over
2dup f_sum +!
2dup f_max max!
f_min min!
loop drop ;
And you might want to take advantage of the fact that sum, max, and
min are consecutive in memory:
do
dup
i @ >r
r@ over +! cell+
r@ over max! cell+
r> swap min!
loop drop ;
But this is already harder to read, and I'd strongly question whether
it was worthwhile.
You could move the offsets into max! and min! :
: >sum ( n a) f_sum +! ;
: >max ( n a) f_max max! ;
: >min ( n a) f_min min! ;
do
i @ over 2dup >max 2dup >min >sum
loop drop ;
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-09-01 14:32 +0000 |
| Subject | min-max-sum (was: A Minimal Extended Control Wordset) |
| Message-ID | <2011Sep1.163248@mips.complang.tuwien.ac.at> |
| In reply to | #5433 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Paul Rubin <no.email@nospam.invalid> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> That problem is horribly artificial, and it's extemely unlikely that
>>> anyone would have needed to solve a problem like that.
>>
>> It didn't seem artificial to me, wanting to know the min, max, and
>> average (mean) of some data set. Of course the mean is computed from
>> the sum.
>
>You always want all three? OK.
If you implement that loop, you obviously want all three. Wanting to
aggregate more than one thing over the same set of data does not seem
artificial to me, I have come across that problem occasionally.
But your comment points to the first solution I would think of:
aggregate each thing in its own loop. One can factor out the
iteration across the container, so the result might look like
2dup map< + >map >r
2dup map< max >map >r
map< min >map r> r>
or factor the individual aggregations into separate words.
The disadvantage would be that we iterate three times across the
container instead of once. It's unlikely that a Forth compiler will
perform loop fusion, so if we need to make this more efficient, we
will have to suffer from inelegance.
Hmm, I don't find the original discussion anymore, but what's wrong
with (untested):
: sum-min-max ( addr ucells -- nsum nmax nmin )
2>r 0 minint maxint 2r> cells bounds u+do ( nsum' nmax' nmin' )
rot i @ +
rot i @ max
rot i @ min
1 cells +loop ;
I leave it as an exercise to the student to time this solution against
Andrew Haley's, but my guess is that if performance is so important
that you stuff it in a single loop, you should avoid memory accesses
(even cached ones) like the ones his code performs.
- 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 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-09-01 10:43 -0500 |
| Subject | Re: min-max-sum |
| Message-ID | <MtmdnQYfTcuONcLTnZ2dnUVZ8sKdnZ2d@supernews.com> |
| In reply to | #5439 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > The disadvantage would be that we iterate three times across the > container instead of once. It's unlikely that a Forth compiler will > perform loop fusion, so if we need to make this more efficient, we > will have to suffer from inelegance. > > Hmm, I don't find the original discussion anymore, but what's wrong > with (untested): > > : sum-min-max ( addr ucells -- nsum nmax nmin ) > 2>r 0 minint maxint 2r> cells bounds u+do ( nsum' nmax' nmin' ) > rot i @ + > rot i @ max > rot i @ min > 1 cells +loop ; > > I leave it as an exercise to the student to time this solution > against Andrew Haley's, but my guess is that if performance is so > important that you stuff it in a single loop, you should avoid > memory accesses (even cached ones) like the ones his code performs. I will not be blamed for failing to do something I wasn't trying to do! My first example, as was hopefully clear, was never intended to be particularly efficient, and there are many ways to write something faster. This is quite a nice solution. I personally wouldn't do it this way because I really don't like the stack shuffling it does. Also, it fails as an illustration of a general technique for more than three operations unless you're going to use something horrible like n ROLL rather than ROT. You could instead shuffle n items to and from the return stack. Like so: do ( nsum' nmax' nmin' ) >r >r i @ + r> i @ max r> i @ min 1 cells +loop ; ... which I'd prefer to all that ROTting if efficiency was important. I'm not sure that shuffling things between stacks or shuffling the data stack is necessarily fast. ROT shuffles three items on the stack, and implemented the obvious way that's three reads and three writes. With TOS cached in a register, as people often do, it's still two reads and two writes. However, obsessing about this kind of thing isn't going to make for the most maintainable Forth code. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-09-01 15:59 +0000 |
| Subject | Re: min-max-sum |
| Message-ID | <2011Sep1.175921@mips.complang.tuwien.ac.at> |
| In reply to | #5441 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> : sum-min-max ( addr ucells -- nsum nmax nmin )
>> 2>r 0 minint maxint 2r> cells bounds u+do ( nsum' nmax' nmin' )
>> rot i @ +
>> rot i @ max
>> rot i @ min
>> 1 cells +loop ;
>>
>> I leave it as an exercise to the student to time this solution
>> against Andrew Haley's, but my guess is that if performance is so
>> important that you stuff it in a single loop, you should avoid
>> memory accesses (even cached ones) like the ones his code performs.
>
>I will not be blamed for failing to do something I wasn't trying to
>do! My first example, as was hopefully clear, was never intended to
>be particularly efficient, and there are many ways to write something
>faster.
>
>This is quite a nice solution. I personally wouldn't do it this way
>because I really don't like the stack shuffling it does. Also, it
>fails as an illustration of a general technique for more than three
>operations unless you're going to use something horrible like n ROLL
>rather than ROT.
>
>You could instead shuffle n items to and from the return stack. Like
>so:
>
>do ( nsum' nmax' nmin' )
> >r >r
> i @ + r>
> i @ max r>
> i @ min
>1 cells +loop ;
Even if it would work (which it wouldn't on many systems because DO
communicates with I through the return stack), I think the rotating
solution is clearer. And it's straightforward to extend to more than
three items. Yes, you have to use ROLL then, but avoiding a clear
solution to avoid ROLL is perverse: We normally avoid ROLL because it
is a symptom of having too many stack items. Here you would have the
same number of stack items, and introduce complex and less clear stack
manipulation just to cure the symptom.
>I'm not sure that shuffling things between stacks or shuffling the
>data stack is necessarily fast.
Sure, it's not necessarily fast, but it requires much less compiler
smarts to avoid memory stores in the loop than your solution does.
I tried it on VFX, and it produced a lot of memory accesses through
ESP and EBP, so I guess this code exceeded the capacity of its
register allocator. Maybe iForth does better.
>However, obsessing about this kind of thing
>isn't going to make for the most maintainable Forth code.
As mentioned, for the most maintainable code I would compute each
value in a separate loop.
- 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 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-09-01 13:13 -0700 |
| Subject | Re: min-max-sum |
| Message-ID | <d4670d16-8604-4730-8397-0fe5e4798060@c19g2000yqe.googlegroups.com> |
| In reply to | #5445 |
On Sep 1, 11:59 am, an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Even if it would work (which it wouldn't on many systems because DO > communicates with I through the return stack), I think the rotating > solution is clearer. And it's straightforward to extend to more than > three items. Yes, you have to use ROLL then, but avoiding a clear > solution to avoid ROLL is perverse: We normally avoid ROLL because it > is a symptom of having too many stack items. Here you would have the > same number of stack items, and introduce complex and less clear stack > manipulation just to cure the symptom. But keeping, eg, the min, max, running sum, running sum of squares all on the stack is indeed having too many stack items. And you are back to the drawing board if the sum or sum of squares overflows the range of the cell. : D+! ( x addr -- ) >R S>D R@ 2@ D+ R> 2! ; : D^2+! ( x addr -- ) >R DUP M* R@ 2@ D+ R> 2! ; : min-max! ( x addr -- ) 2DUP @ MIN OVER ! CELL+ TUCK @ MAX SWAP ! ;
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-09-02 04:12 -0500 |
| Subject | Re: min-max-sum |
| Message-ID | <GNmdnc45Y-WWA_3TnZ2dnUVZ8sadnZ2d@supernews.com> |
| In reply to | #5445 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> >>You could instead shuffle n items to and from the return stack. Like >>so: >> >>do ( nsum' nmax' nmin' ) >> >r >r >> i @ + r> >> i @ max r> >> i @ min >>1 cells +loop ; > > Even if it would work (which it wouldn't on many systems because DO > communicates with I through the return stack), Oops. > I think the rotating solution is clearer. And it's straightforward > to extend to more than three items. Yes, you have to use ROLL then, > but avoiding a clear solution to avoid ROLL is perverse: We normally > avoid ROLL because it is a symptom of having too many stack items. I avoid ROLL because it's a symptom of trying use the stack as an array, or in this case as a struct. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-09-02 04:31 -0500 |
| Subject | Re: min-max-sum |
| Message-ID | <TuidnQUKY6X6P_3TnZ2dnUVZ7vednZ2d@supernews.com> |
| In reply to | #5472 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >>> >>>You could instead shuffle n items to and from the return stack. Like >>>so: >>> >>>do ( nsum' nmax' nmin' ) >>> >r >r >>> i @ + r> >>> i @ max r> >>> i @ min >>>1 cells +loop ; >> >> Even if it would work (which it wouldn't on many systems because DO >> communicates with I through the return stack), > > Oops. > >> I think the rotating solution is clearer. And it's straightforward >> to extend to more than three items. Yes, you have to use ROLL then, >> but avoiding a clear solution to avoid ROLL is perverse: We normally >> avoid ROLL because it is a symptom of having too many stack items. > > I avoid ROLL because it's a symptom of trying use the stack as an > array, or in this case as a struct. To expand on this: you're returning a tuple of N items. Rather than a named struct you're placing these in an array which is not in memory but on the stack. Maybe some Forth happens to generate fast code for that sort of thing, but that's not a good justification for it. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-09-02 10:41 +0000 |
| Subject | Re: min-max-sum |
| Message-ID | <2011Sep2.124104@mips.complang.tuwien.ac.at> |
| In reply to | #5474 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> I avoid ROLL because it's a symptom of trying use the stack as an
>> array,
Yes, ROLL with a dynamically computed index would be such a use, but I
have never seen that. However, GET-CONTEXT SET-CONTEXT use the stack
as array and have been standardized. N>R NR> also do that, and IIRC
you are in favour of them.
> or in this case as a struct.
>
>To expand on this: you're returning a tuple of N items. Rather than a
>named struct you're placing these in an array which is not in memory
>but on the stack.
Returning multiple values on the stack is one of the features of
Forth. Does /MOD use the stack as a struct? Maybe, but if so, it's
certainly better than the altenative of going through memory, which
you seem to suggest as being more appropriate.
Likewise for MIN-MAX-SUM. And for something similar with even more
cells: Sure, at some point it may be better to return the results in a
struct in memory. But that does not mean we have to compute them
there. We have two understandable ways of computing them on the
stack, we can store them to memory afterwards.
>Maybe some Forth happens to generate fast code for
>that sort of thing, but that's not a good justification for it.
If you need the speed, it certainly is (and if not, computing each
value in a separate loop appears best to me). People even program in
assembly language because of speed.
- 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 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-09-02 06:31 -0500 |
| Subject | Re: min-max-sum |
| Message-ID | <HpWdnb0rJr4bI_3TnZ2dnUVZ8umdnZ2d@supernews.com> |
| In reply to | #5475 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> I avoid ROLL because it's a symptom of trying use the stack as an >>> array, > > Yes, ROLL with a dynamically computed index would be such a use, but > I have never seen that. However, GET-CONTEXT SET-CONTEXT use the > stack as array and have been standardized. N>R NR> also do that, > and IIRC you are in favour of them. Well, the common use for N>R and NR> is with GET-CONTEXT and SET-CONTEXT: once you have the latter, the former make good sense. >> or in this case as a struct. >> >>To expand on this: you're returning a tuple of N items. Rather than a >>named struct you're placing these in an array which is not in memory >>but on the stack. > > Returning multiple values on the stack is one of the features of > Forth. Does /MOD use the stack as a struct? Maybe, but if so, it's > certainly better than the alternative of going through memory, which > you seem to suggest as being more appropriate. One of Forth's advantages that I miss in languages like Java and C has always been the ability to return more that one item. However, it's easy to get carried away. You are overgeneralizing from what I said. Nothing in programming, not even "Don't use goto!" is an absolute rule; this is about judgment and style. > Likewise for MIN-MAX-SUM. And for something similar with even more > cells: Sure, at some point it may be better to return the results in > a struct in memory. But that does not mean we have to compute them > there. We have two understandable ways of computing them on the > stack, we can store them to memory afterwards. At some point you have to say "enough!". I presume that if you have twenty things to aggregate you wouldn't use 20 ROLL . So, the question is: how many is too many? I think your usage of ROT is tolerable, just. >>Maybe some Forth happens to generate fast code for that sort of >>thing, but that's not a good justification for it. > > If you need the speed, it certainly is Yes, but a most useful general rule for programmers is "avoid premature optimization." And in this case, it certainly is premature because we have not the slightest idea of what this is going to be used for. We don't know what Forth is going to be used, so we can't optimize for it anyway. As I said several posts ago... Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-09-04 13:18 +0000 |
| Subject | Re: min-max-sum |
| Message-ID | <2011Sep4.151850@mips.complang.tuwien.ac.at> |
| In reply to | #5477 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>At some point you have to say "enough!". I presume that if you have
>twenty things to aggregate you wouldn't use 20 ROLL .
Assuming that speed is important, I would probably write the
aggregations in a syntax for a code generator that might use a variety
of implementation approaches (including 20 ROLL). Depending on the
target syntax, the parameters of this code generator would be adjusted
for the best results. For a sophisticated Forth system on an
architecture with 32 registers or more, the resulting code might
indeed contain a 20 ROLL.
>Yes, but a most useful general rule for programmers is "avoid
>premature optimization." And in this case, it certainly is premature
>because we have not the slightest idea of what this is going to be
>used for. We don't know what Forth is going to be used, so we can't
>optimize for it anyway. As I said several posts ago...
And as I wrote several postings ago, if efficiency is no concern, I
would aggregate each value in a separate loop.
Your suggestion seems to imply that all our discussions should take
the "efficiency is no concern" POV, because everything else is
"premature optimization". I disagree. While premature optimization
should be avoided in programming, we should not avoid discussing
optimizations; after all, in such discussions we can work out how to
optimize in those cases where the optimization is not premature.
Anyway, I have now benchmarked the three different approaches on
vfxlin (program appended below):
1) using a separate loop for each aggregation (simple)
2) using one loop and keeping the intermediate results on the data stack (rot)
3) using one loop and keeping the intermediate results in a struct (haley)
The results are:
[c8:~/forth:30521] time vfxlin "include min-max-sum.fs bench-simple bye" >/dev/null
real 0m0.713s
user 0m0.696s
sys 0m0.008s
[c8:~/forth:30522] time vfxlin "include min-max-sum.fs bench-rot bye" >/dev/null
real 0m0.442s
user 0m0.432s
sys 0m0.008s
[c8:~/forth:30523] time vfxlin "include min-max-sum.fs bench-haley bye" >/dev/null
real 0m2.935s
user 0m2.912s
sys 0m0.008s
Not sure what's so slow in the haley code, but if someone wants to
investigate, the code is shown below.
- anton
: asum ( addr ucells -- n )
0 rot rot cells over + swap ?do
i @ +
[ 1 cells ] literal +loop ;
: amin ( addr ucells -- n )
$7fffffff rot rot cells over + swap ?do
i @ min
[ 1 cells ] literal +loop ;
: amax ( addr ucells -- n )
$80000000 rot rot cells over + swap ?do
i @ max
[ 1 cells ] literal +loop ;
: simple ( addr ucells -- nsum nmax nmin )
2dup amin >r
2dup amax >r
asum r> r> ;
: sum-min-max ( addr ucells -- nsum nmax nmin )
2>r 0 $80000000 $7fffffff 2r> cells over + swap ?do ( nsum' nmax' nmin' )
rot i @ +
rot i @ max
rot i @ min
1 cells +loop ;
\ define a struct the VFX way :-)
: f_sum ;
: f_max cell+ ;
: f_min 2 cells + ;
create some-f 3 cells allot
: max! ( n addr -- )
dup @ rot max swap ! ;
: min! ( n addr -- )
dup @ rot min swap ! ;
: haley ( addr ucells f-addr -- )
0 over f_sum !
$80000000 over f_max !
$7fffffff over f_min !
rot rot cells over + swap do
i @ over f_sum +!
i @ over f_max max!
i @ over f_min min!
loop drop ;
: bench-simple ( -- )
100 0 ?do
here 1000000 simple . . . cr
loop ;
: bench-rot ( -- )
100 0 ?do
here 1000000 sum-min-max . . . cr
loop ;
: bench-haley ( -- )
100 0 ?do
here 1000000 some-f haley
loop ;
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2011-09-04 22:42 +0200 |
| Subject | Re: min-max-sum |
| Message-ID | <10611399948436@frunobulax.edu> |
| In reply to | #5529 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: min-max-sum
[..]
> Anyway, I have now benchmarked the three different approaches on
> vfxlin (program appended below):
> 1) using a separate loop for each aggregation (simple)
> 2) using one loop and keeping the intermediate results on the data stack (rot)
> 3) using one loop and keeping the intermediate results in a struct (haley)
I added a few more, and even one that uses CODE.
> The results are:
> [c8:~/forth:30521] time vfxlin "include min-max-sum.fs bench-simple bye" >/dev/null
> real 0m0.713s
[..]
> [c8:~/forth:30522] time vfxlin "include min-max-sum.fs bench-rot bye" >/dev/null
> real 0m0.442s
[..]
> [c8:~/forth:30523] time vfxlin "include min-max-sum.fs bench-haley bye" >/dev/null
> real 0m2.935s
[..]
> Not sure what's so slow in the haley code, but if someone wants to
> investigate, the code is shown below.
You inadvertedly wrote "loop" instead of "1 cells +loop" :-)
In this case the error is important because it may bias one's appreciation for the
haley solution.
It is important not to use uninitialized HERE for the test area because
number formatting may overwrite this area between individual benchmarks
(your test method has no problem with it).
What is the specification for the machine you tested on? I used a 2.67 GHz
i7 quad core. The speed for 64 and 32-bit code is (nearly) the same.
-marcel
-- ---------------------
ANEW -summinmax
NEEDS -assemble
: asum ( addr ucells -- n )
0 rot rot cells over + swap ?do
i @ +
[ 1 cells ] literal +loop ;
: amin ( addr ucells -- n )
maxint rot rot cells over + swap ?do
i @ min
[ 1 cells ] literal +loop ;
: amax ( addr ucells -- n )
minint rot rot cells over + swap ?do
i @ max
[ 1 cells ] literal +loop ;
: simple ( addr ucells -- nsum nmax nmin )
2dup amin >r
2dup amax >r
asum r> r> ;
: sum-min-max ( addr ucells -- nsum nmax nmin )
2>r 0 minint maxint 2r> cells over + swap ?do ( nsum' nmax' nmin' )
rot i @ +
rot i @ max
rot i @ min
[ 1 cells ] literal +loop ;
: sum-min-max-my ( addr ucells -- nsum nmax nmin )
2>r 0 minint maxint 2r>
1-
FOR
@+ 2>R
rot r@ +
rot r@ max
rot r> min
R>
NEXT drop ;
: sum-min-max-my-1 ( addr ucells -- nsum nmax nmin )
0 minint maxint locals| =min =max =sum |
1-
FOR
@+
dup +TO =sum
dup =max max TO =max
=min min TO =min
NEXT drop
=sum =max =min ;
64bit? [if]
: sum-min-max-my-2 ( addr ucells -- nsum nmax nmin )
swap >r 0 maxint minint r> params| =sum =min =max =addr |
1-
FOR
ASM{
[rsi #48 +] qword -> rbx mov,
[rbx] -> rax mov, \ @+
8 b# -> rbx add,
rbx -> [rsi #48 +] qword mov,
rax -> [rsi] add, \ dup +TO =sum
[rsi #16 +] qword -> rcx mov, \ =max
rax -> rcx cmp, \ over max
rax -> rcx cmovg,
rcx -> [rsi #16 +] qword mov, \ TO =max
[rsi #32 +] qword -> rcx mov, \ =min
rax -> rcx cmp, \ over min
rax -> rcx cmovl,
rcx -> [rsi #32 +] qword mov, \ TO =min
}ASM
NEXT
=sum =max =min ;
[else]
: sum-min-max-my-2 ( addr ucells -- nsum nmax nmin )
swap >r 0 maxint minint r> params| =sum =min =max =addr |
1-
FOR
ASM{
[esi #48 +] dword -> ebx mov,
[ebx] -> eax mov, \ @+
4 b# -> ebx add,
ebx -> [esi #48 +] dword mov,
eax -> [esi] add, \ dup +TO =sum
[esi #16 +] dword -> ecx mov, \ =max
eax -> ecx cmp, \ over max
eax -> ecx cmovg,
ecx -> [esi #16 +] dword mov, \ TO =max
[esi #32 +] dword -> ecx mov, \ =min
eax -> ecx cmp, \ over min
eax -> ecx cmovl,
ecx -> [esi #32 +] dword mov, \ TO =min
}ASM
NEXT
=sum =max =min ;
[then]
\ define a struct the VFX way :-)
: f_sum ;
: f_max cell+ ;
: f_min 2 cells + ;
create some-f 3 cells allot
: max! ( n addr -- )
dup @ rot max swap ! ;
: min! ( n addr -- )
dup @ rot min swap ! ;
: haley ( addr ucells f-addr -- )
0 over f_sum !
minint over f_max !
maxint over f_min !
rot rot cells over + swap do
i @ over f_sum +!
i @ over f_max max!
i @ over f_min min!
cell +loop drop ;
: data here #10000 CELLS +
dup #100000 1 fill ; \ number formatting ... :-)
: bench-simple ( -- )
CR ." simple : " TIMER-RESET
0 0 0
#100 0 ?do
3drop data #1000000 simple
loop
rot . swap . . .ELAPSED ;
: bench-rot ( -- )
CR ." rot : " TIMER-RESET
0 0 0
#100 0 ?do
3drop data #1000000 sum-min-max
loop
rot . swap . . .ELAPSED ;
: bench-rot-my ( -- )
CR ." rot-my : " TIMER-RESET
0 0 0
#100 0 ?do
3drop data #1000000 sum-min-max-my
loop
rot . swap . . .ELAPSED ;
: bench-rot-my-1 ( -- )
CR ." rot-my-1 : " TIMER-RESET
0 0 0
#100 0 ?do
3drop data #1000000 sum-min-max-my-1
loop
rot . swap . . .ELAPSED ;
: bench-rot-my-2 ( -- )
CR ." rot-my-2 : " TIMER-RESET
0 0 0
#100 0 ?do
3drop data #1000000 sum-min-max-my-2
loop
rot . swap . . .ELAPSED ;
: bench-haley ( -- )
CR ." haley : " TIMER-RESET
#100 0 ?do
data #1000000 some-f haley
loop
some-f @+ . @+ . @ . .ELAPSED ;
DOC
(*
The results are:
[c8:~/forth:30521] time vfxlin "include min-max-sum.fs bench-simple bye" >/dev/null
real 0m0.713s
user 0m0.696s
sys 0m0.008s
[c8:~/forth:30522] time vfxlin "include min-max-sum.fs bench-rot bye" >/dev/null
real 0m0.442s
user 0m0.432s
sys 0m0.008s
[c8:~/forth:30523] time vfxlin "include min-max-sum.fs bench-haley bye" >/dev/null
real 0m2.935s
user 0m2.912s
sys 0m0.008s
Try: bench-simple bench-haley bench-rot bench-rot-my bench-rot-my-1 bench-rot-my-2
VFX: 0.713 2.935 0.442 ? ? ?
simple : 361700864190383316 72340172838076673 0 1.135 seconds elapsed.
haley : 361700864190383316 72340172838076673 0 0.820 seconds elapsed.
rot : 361700864190383316 72340172838076673 0 0.838 seconds elapsed.
rot-my : 361700864190383316 72340172838076673 0 0.722 seconds elapsed.
rot-my-1 : 361700864190383316 72340172838076673 0 0.507 seconds elapsed.
rot-my-2 : 361700864190383316 72340172838076673 0 0.326 seconds elapsed. ok
*)
ENDDOC
CR .( Try: bench-simple bench-haley bench-rot bench-rot-my bench-rot-my-1 bench-rot-my-2 )
CR .( VFX: 0.713 2.935 0.442 ? ? ? )
CR
bench-simple bench-haley bench-rot bench-rot-my bench-rot-my-1 bench-rot-my-2
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-09-05 08:16 +0000 |
| Subject | Re: min-max-sum |
| Message-ID | <2011Sep5.101652@mips.complang.tuwien.ac.at> |
| In reply to | #5532 |
mhx@iae.nl (Marcel Hendrix) writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: min-max-sum
>> Not sure what's so slow in the haley code, but if someone wants to
>> investigate, the code is shown below.
>
>You inadvertedly wrote "loop" instead of "1 cells +loop" :-)
I shouldn't let down my guard when copying from a posting, especially
when the results deviate from expectations. Thanks for catching
this.
After correcting that (corrected code below) I get:
[c8:~/forth:30521] time vfxlin "include min-max-sum.fs bench-simple bye" >/dev/null
real 0m0.695s
user 0m0.684s
sys 0m0.008s
[c8:~/forth:30522] time vfxlin "include min-max-sum.fs bench-rot bye" >/dev/null
real 0m0.432s
user 0m0.420s
sys 0m0.008s
[c8:~/forth:30523] time vfxlin "include min-max-sum.fs bench-haley bye" >/dev/null
real 0m0.603s
user 0m0.592s
sys 0m0.008s
>It is important not to use uninitialized HERE for the test area because
>number formatting may overwrite this area between individual benchmarks
>(your test method has no problem with it).
I don't expect the actual data to have a significant influence on the
timings, so I ignored that. Still, the corrected code uses
initialized memory (but there was no significant effect on the
performance).
>What is the specification for the machine you tested on? I used a 2.67 GHz
>i7 quad core. The speed for 64 and 32-bit code is (nearly) the same.
It's a 3GHz Xeon 5450 running vfxlin 4.40.
Here are the inner loops of a few words:
amax:
( 080B9E28 8B1424 ) MOV EDX, [ESP]
( 080B9E2B 8B0A ) MOV ECX, 0 [EDX]
( 080B9E2D 3BD9 ) CMP EBX, ECX
( 080B9E2F 0F4CD9 ) CMOVL/NGE EBX, ECX
( 080B9E32 83042404 ) ADD [ESP], 04
( 080B9E36 8344240404 ) ADD [ESP+04], 04
( 080B9E3B 71EB ) JNO 080B9E28
sum-min-max (using rot):
( 080B9FD8 8B1424 ) MOV EDX, [ESP]
( 080B9FDB 8B0A ) MOV ECX, 0 [EDX]
( 080B9FDD 034D04 ) ADD ECX, [EBP+04]
( 080B9FE0 8B1424 ) MOV EDX, [ESP]
( 080B9FE3 8B4500 ) MOV EAX, [EBP]
( 080B9FE6 3B02 ) CMP EAX, 0 [EDX]
( 080B9FE8 0F4C02 ) CMOVL/NGE EAX, DWord Ptr 0 [EDX]
( 080B9FEB 8B1424 ) MOV EDX, [ESP]
( 080B9FEE 8D6DFC ) LEA EBP, [EBP+-04]
( 080B9FF1 895D00 ) MOV [EBP], EBX
( 080B9FF4 894504 ) MOV [EBP+04], EAX
( 080B9FF7 894D08 ) MOV [EBP+08], ECX
( 080B9FFA 8B1A ) MOV EBX, 0 [EDX]
( 080B9FFC 8B5500 ) MOV EDX, [EBP]
( 080B9FFF 3BDA ) CMP EBX, EDX
( 080BA001 0F4FDA ) CMOVNLE/G EBX, EDX
( 080BA004 83042404 ) ADD [ESP], 04
( 080BA008 8344240404 ) ADD [ESP+04], 04
( 080BA00D 8D6D04 ) LEA EBP, [EBP+04]
( 080BA010 71C6 ) JNO 080B9FD8
haley:
( 080BA180 8B1424 ) MOV EDX, [ESP]
( 080BA183 8B0A ) MOV ECX, 0 [EDX]
( 080BA185 010B ) ADD 0 [EBX], ECX
( 080BA187 8B1424 ) MOV EDX, [ESP]
( 080BA18A 8BCB ) MOV ECX, EBX
( 080BA18C 83C304 ) ADD EBX, 04
( 080BA18F 8B03 ) MOV EAX, 0 [EBX]
( 080BA191 8D6DF4 ) LEA EBP, [EBP+-0C]
( 080BA194 894500 ) MOV [EBP], EAX
( 080BA197 895D04 ) MOV [EBP+04], EBX
( 080BA19A 894D08 ) MOV [EBP+08], ECX
( 080BA19D 8B1A ) MOV EBX, 0 [EDX]
( 080BA19F 8B5500 ) MOV EDX, [EBP]
( 080BA1A2 3BDA ) CMP EBX, EDX
( 080BA1A4 0F4CDA ) CMOVL/NGE EBX, EDX
( 080BA1A7 8B5504 ) MOV EDX, [EBP+04]
( 080BA1AA 891A ) MOV 0 [EDX], EBX
( 080BA1AC 8B1C24 ) MOV EBX, [ESP]
( 080BA1AF 8B5508 ) MOV EDX, [EBP+08]
( 080BA1B2 83C208 ) ADD EDX, 08
( 080BA1B5 8B0A ) MOV ECX, 0 [EDX]
( 080BA1B7 8B03 ) MOV EAX, 0 [EBX]
( 080BA1B9 3BC8 ) CMP ECX, EAX
( 080BA1BB 0F4FC8 ) CMOVNLE/G ECX, EAX
( 080BA1BE 890A ) MOV 0 [EDX], ECX
( 080BA1C0 83042404 ) ADD [ESP], 04
( 080BA1C4 8344240404 ) ADD [ESP+04], 04
( 080BA1C9 8B5D08 ) MOV EBX, [EBP+08]
( 080BA1CC 8D6D0C ) LEA EBP, [EBP+0C]
( 080BA1CF 71AF ) JNO 080BA180
Inlining works nicely in VFX.
And finally, below you find the corrected code.
- anton
0 [if]
time vfxlin "include min-max-sum.fs bench-simple bye" >/dev/null
time vfxlin "include min-max-sum.fs bench-rot bye" >/dev/null
time vfxlin "include min-max-sum.fs bench-haley bye" >/dev/null
[then]
: asum ( addr ucells -- n )
0 rot rot cells over + swap ?do
i @ +
[ 1 cells ] literal +loop ;
: amin ( addr ucells -- n )
$7fffffff rot rot cells over + swap ?do
i @ min
[ 1 cells ] literal +loop ;
: amax ( addr ucells -- n )
$80000000 rot rot cells over + swap ?do
i @ max
[ 1 cells ] literal +loop ;
: simple ( addr ucells -- nsum nmax nmin )
2dup amin >r
2dup amax >r
asum r> r> ;
: sum-min-max ( addr ucells -- nsum nmax nmin )
2>r 0 $80000000 $7fffffff 2r> cells over + swap ?do ( nsum' nmax' nmin' )
rot i @ +
rot i @ max
rot i @ min
1 cells +loop ;
\ define a struct the VFX way :-)
: f_sum ;
: f_max cell+ ;
: f_min 2 cells + ;
create some-f 3 cells allot
: max! ( n addr -- )
dup @ rot max swap ! ;
: min! ( n addr -- )
dup @ rot min swap ! ;
: haley ( addr ucells f-addr -- )
0 over f_sum !
$80000000 over f_max !
$7fffffff over f_min !
rot rot cells over + swap do
i @ over f_sum +!
i @ over f_max max!
i @ over f_min min!
[ 1 cells ] literal +loop drop ;
create a 1000000 cells allot
a 1000000 cells erase
: bench-simple ( -- )
100 0 ?do
a 1000000 simple . . . cr
loop ;
: bench-rot ( -- )
100 0 ?do
a 1000000 sum-min-max . . . cr
loop ;
: bench-haley ( -- )
100 0 ?do
a 1000000 some-f haley
loop ;
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-09-05 02:58 -0500 |
| Subject | Re: min-max-sum |
| Message-ID | <c9qdnWCK-ZWSHPnTnZ2dnUVZ8gWdnZ2d@supernews.com> |
| In reply to | #5529 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >>Yes, but a most useful general rule for programmers is "avoid >>premature optimization." And in this case, it certainly is >>premature because we have not the slightest idea of what this is >>going to be used for. We don't know what Forth is going to be used, >>so we can't optimize for it anyway. As I said several posts ago... > > And as I wrote several postings ago, if efficiency is no concern, I > would aggregate each value in a separate loop. > > Your suggestion seems to imply that all our discussions should take > the "efficiency is no concern" POV, because everything else is > "premature optimization". No, it does not. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web