Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #19200 > unrolled thread

About stack access profundity

Back to article view | Back to comp.lang.forth

Contents

  About stack access profundity Pablo Hugo Reda <pabloreda@gmail.com> - 2013-01-27 12:11 -0800
    Re: About stack access profundity humptydumpty <ouatubi@gmail.com> - 2013-01-28 00:59 -0800
      Re: About stack access profundity Pablo Hugo Reda <pabloreda@gmail.com> - 2013-01-28 07:17 -0800
    Re: About stack access profundity Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-28 03:10 -0600
      Re: About stack access profundity Pablo Hugo Reda <pabloreda@gmail.com> - 2013-01-28 07:23 -0800
        Re: About stack access profundity Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-28 10:46 -0600
          Re: About stack access profundity anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-29 08:20 +0000
            Re: About stack access profundity Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-29 03:25 -0600
              Re: About stack access profundity anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-29 09:47 +0000
                Re: About stack access profundity Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-29 04:08 -0600
                  Re: About stack access profundity anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-29 15:21 +0000
                    Re: About stack access profundity Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-29 09:57 -0600
                      Re: About stack access profundity anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-29 17:01 +0000
                        Re: About stack access profundity Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-29 12:22 -0600
                          Re: About stack access profundity anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-30 17:40 +0000
                            Re: About stack access profundity Paul Rubin <no.email@nospam.invalid> - 2013-01-30 11:49 -0800
                              Re: About stack access profundity anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-04 16:39 +0000
                            Re: About stack access profundity Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-30 16:32 -0600
                              Re: About stack access profundity anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-31 16:02 +0000
                    Re: About stack access profundity stephenXXX@mpeforth.com (Stephen Pelc) - 2013-01-29 17:06 +0000
                      Re: About stack access profundity anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-29 17:58 +0000
                        Re: About stack access profundity Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-01-29 12:29 -0600
                          Re: About stack access profundity anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-30 17:22 +0000
                        Re: About stack access profundity Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-29 20:17 +0100
                          Re: About stack access profundity mhx@iae.nl (Marcel Hendrix) - 2013-01-29 21:44 +0200
                            Re: About stack access profundity Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-29 22:14 +0100
                          Re: About stack access profundity anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-30 16:29 +0000
                            Re: About stack access profundity Pablo Hugo Reda <pabloreda@gmail.com> - 2013-01-30 09:58 -0800
                          Re: About stack access profundity stephenXXX@mpeforth.com (Stephen Pelc) - 2013-01-31 12:32 +0000
                            Re: About stack access profundity Bernd Paysan <bernd.paysan@gmx.de> - 2013-01-31 15:37 +0100
                        Re: About stack access profundity Mark Wills <forthfreak@gmail.com> - 2013-01-29 23:12 -0800
            Re: About stack access profundity stephenXXX@mpeforth.com (Stephen Pelc) - 2013-01-29 10:08 +0000
              Re: About stack access profundity Pablo Hugo Reda <pabloreda@gmail.com> - 2013-01-29 07:10 -0800
              Re: About stack access profundity anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-29 15:17 +0000
        Re: About stack access profundity Mark Wills <forthfreak@gmail.com> - 2013-01-29 00:57 -0800
    Re: About stack access profundity Mark Wills <forthfreak@gmail.com> - 2013-01-28 01:56 -0800
    Re: About stack access profundity anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-01-29 15:30 +0000
      Re: About stack access profundity Pablo Hugo Reda <pabloreda@gmail.com> - 2013-01-29 09:06 -0800
    Re: About stack access profundity Pablo Hugo Reda <pabloreda@gmail.com> - 2013-02-03 06:22 -0800
      Re: About stack access profundity Mark Wills <forthfreak@gmail.com> - 2013-02-03 07:25 -0800
        Re: About stack access profundity Pablo Hugo Reda <pabloreda@gmail.com> - 2013-02-03 15:51 -0800
          Re: About stack access profundity Coos Haak <chforth@hccnet.nl> - 2013-02-04 01:12 +0100
      Re: About stack access profundity Mark Wills <forthfreak@gmail.com> - 2013-02-03 23:10 -0800
        Re: About stack access profundity Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-04 03:26 -0600
    Re: About stack access profundity humptydumpty <ouatubi@gmail.com> - 2013-02-03 11:26 -0800
      Re: About stack access profundity Pablo Hugo Reda <pabloreda@gmail.com> - 2013-02-03 15:49 -0800

Page 1 of 3  [1] 2 3  Next page →

#19200 — About stack access profundity

For two definition who make the same, the less distance in stack access is more optimal, need less register when compiler, etc. Is convenient make definition with less profundity access en the stack
.
I choose limit the word PICK and make it static, I have only PICK2,PICK3,PICK4 and no more.
Whell, until now, not need more, but now I found a word who need more PICK's.

I reeimplement the Quadratic Bezier Curve word and try to draw Cubic Bezier Curves now.
I use recursion, only integers and add,shift and compare.

Because I use recursion, I need 6 parameters (3 2D points) and the rutine access to 8 position (I need PICK8 definition).

I think about workaround the problem:

if compress the 2dvector for use one place, the word only need PICK4, work in the current system!
but this add the time for change representation (2 cells to 1 cell..) or extact (address to x y..).

but when PICK8 the solution is more direct.

I need advice..
thank's

[toc] | [next] | [standalone]

#19208

On Sunday, January 27, 2013 10:11:54 PM UTC+2, Pablo Hugo Reda wrote:
> For two definition who make the same, the less distance in stack access is more optimal, need less register when compiler, etc. Is convenient make definition with less profundity access en the stack
> 
> .
> 
> I choose limit the word PICK and make it static, I have only PICK2,PICK3,PICK4 and no more.
> 
> Whell, until now, not need more, but now I found a word who need more PICK's.
> 
> 
> 
> I reeimplement the Quadratic Bezier Curve word and try to draw Cubic Bezier Curves now.
> 
> I use recursion, only integers and add,shift and compare.
> 
> 
> 
> Because I use recursion, I need 6 parameters (3 2D points) and the rutine access to 8 position (I need PICK8 definition).
> 
> 
> 
> I think about workaround the problem:
> 
> 
> 
> if compress the 2dvector for use one place, the word only need PICK4, work in the current system!
> 
> but this add the time for change representation (2 cells to 1 cell..) or extact (address to x y..).
> 
> 
> 
> but when PICK8 the solution is more direct.
> 
> 
> 
> I need advice..
> 
> thank's

Hi!
Could you split P(X,Y) problem to problem for X and problem for Y
and solve it one a time?
Have a nice day,
humptydumpty

[toc] | [prev] | [next] | [standalone]

#19221

> 
> 
> 
> Hi!
> 
> Could you split P(X,Y) problem to problem for X and problem for Y
> 
> and solve it one a time?
> 

you say...
Y have X Y X Y X Y and tranform to X X X Y Y Y, ok work until I need the distance to cut the recursion.

thank's

[toc] | [prev] | [next] | [standalone]

#19209

Pablo Hugo Reda <pabloreda@gmail.com> wrote:
> 
> 
> For two definition who make the same, the less distance in stack
> access is more optimal, need less register when compiler, etc. Is
> convenient make definition with less profundity access en the stack
> .  I choose limit the word PICK and make it static, I have only
> PICK2,PICK3,PICK4 and no more.  Whell, until now, not need more, but
> now I found a word who need more PICK's.
> 
> I reeimplement the Quadratic Bezier Curve word and try to draw Cubic
> Bezier Curves now.  I use recursion, only integers and add,shift and
> compare.
> 
> Because I use recursion, I need 6 parameters (3 2D points) and the
> rutine access to 8 position (I need PICK8 definition).
> 
> I think about workaround the problem:
> 
> if compress the 2dvector for use one place, the word only need
> PICK4, work in the current system!  but this add the time for change
> representation (2 cells to 1 cell..) or extact (address to x y..).
> 
> but when PICK8 the solution is more direct.

I think the mistake you're making is keeping everything on the stack.
As you say, objects deep on the stack are hare to access.

Instead, use a structure with named offsets for your co-ordinates and
vectors.  You'll find the code is much easier to read and write.

Andrew.

[toc] | [prev] | [next] | [standalone]

#19222

> 
> 
> I think the mistake you're making is keeping everything on the stack.
> 
> As you say, objects deep on the stack are hare to access.
> 
> 
> 
> Instead, use a structure with named offsets for your co-ordinates and
> 
> vectors.  You'll find the code is much easier to read and write.
> 
> 

the stack if the more fast access and I need here because the recursion use this estructure


> Pass pointers, rather than the parameters directly? 

but with address need a @ and ! to load store values.

when the compiler optimice the best place is the stack


look the cuadric bezier
-------------------------------------------------------------------
:sp-dist | x y xe ye -- x y xe ye dd
	pick3 pick2 - abs pick3 pick2 - abs + ;

:sp-c | fx fy cx cy -- fx fy cx cy xn yn  ; xn=(cx*2+fx+px)/4
	pick3 pick2 2* + px + 2 >>
	pick3 pick2 2* + py + 2 >> ;

:spl | fx fy cx cy --
	sp-c sp-dist
	4 <? ( drop line 2drop line ; ) drop
	>r >r
	pick3 pick2 + 2/ pick3 pick2 + 2/		| fx fy cx cy c2 c2
	2swap 						| fx fy c2 c2 cx cy
	py + 2/ swap px + 2/ swap			| fx fy c2 c2 c1 c1
	r> r> 2swap
	spl spl ;

-------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#19225

Pablo Hugo Reda <pabloreda@gmail.com> wrote:
>> 
>> I think the mistake you're making is keeping everything on the stack.
>> As you say, objects deep on the stack are [hard] to access.
>> 
>> Instead, use a structure with named offsets for your co-ordinates and
>> vectors.  You'll find the code is much easier to read and write.
> 
> the stack if the more fast access and I need here because the
> recursion use this estructure
> 
>> Pass pointers, rather than the parameters directly? 
> 
> but with address need a @ and ! to load store values.
> when the compiler optimice the best place is the stack

That really isn't a good enough reason.  You'll end up with very
hard-to-maintain code, like this:

> look the cuadric bezier
> -------------------------------------------------------------------
> :sp-dist | x y xe ye -- x y xe ye dd
>        pick3 pick2 - abs pick3 pick2 - abs + ;
> 
> :sp-c | fx fy cx cy -- fx fy cx cy xn yn  ; xn=(cx*2+fx+px)/4
>        pick3 pick2 2* + px + 2 >>
>        pick3 pick2 2* + py + 2 >> ;
> 
> :spl | fx fy cx cy --
>        sp-c sp-dist
>        4 <? ( drop line 2drop line ; ) drop
>        >r >r
>        pick3 pick2 + 2/ pick3 pick2 + 2/               | fx fy cx cy c2 c2
>        2swap                                           | fx fy c2 c2 cx cy
>        py + 2/ swap px + 2/ swap                       | fx fy c2 c2 c1 c1
>        r> r> 2swap
>        spl spl ;
> 
> -------------------------------------------------------------------

Experienced Forthers don't much PICK, and almost never ROLL.  I think
you need to concentrate on making things easy to read and write.
Optimize later, once you have working code.

In addition, there is no reason that a decent optimizer will produce
much worse code for @ than for PICK .

Andrew.

[toc] | [prev] | [next] | [standalone]

#19236

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Pablo Hugo Reda <pabloreda@gmail.com> wrote:
>In addition, there is no reason that a decent optimizer will produce
>much worse code for @ than for PICK .

There's a good reason why decent compilers will produce worse code for
@ than for PICK.  Whether the worseness is "much" or not can be
debated forever without resolution, so let's not go there.

We have a Forth language feature that makes it relatively easy for
compilers to produce as fast native code as when using PICK: locals.
I am not sure if there are Forth compilers yet that are up to that.
There are quite a number of locals-haters around here, some arguing
that locals are foreign (as in "from another programming language"),
some that they make it possible to get away with badly factored code.

For this application, the badly-factored code argument may be
applicable, but have we seen better-factored code?  If we have
better-factored code that produces slower native code, we could think
about whether some new language feature might reconcile good factoring
with good native code.

- 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 2012: http://www.euroforth.org/ef12/

[toc] | [prev] | [next] | [standalone]

#19239

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Pablo Hugo Reda <pabloreda@gmail.com> wrote:
>>In addition, there is no reason that a decent optimizer will produce
>>much worse code for @ than for PICK .
> 
> There's a good reason why decent compilers will produce worse code for
> @ than for PICK.  Whether the worseness is "much" or not can be
> debated forever without resolution, so let's not go there.

OK, so let's not mention it then, whatever it may be.

> We have a Forth language feature that makes it relatively easy for
> compilers to produce as fast native code as when using PICK: locals.
> I am not sure if there are Forth compilers yet that are up to that.
> There are quite a number of locals-haters around here, some arguing
> that locals are foreign (as in "from another programming language"),
> some that they make it possible to get away with badly factored code.
> 
> For this application, the badly-factored code argument may be
> applicable, but have we seen better-factored code?  If we have
> better-factored code that produces slower native code, we could think
> about whether some new language feature might reconcile good factoring
> with good native code.

I suspect that it's not to do with language features but code
generators.

Andrew.

[toc] | [prev] | [next] | [standalone]

#19241

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> For this application, the badly-factored code argument may be
>> applicable, but have we seen better-factored code?  If we have
>> better-factored code that produces slower native code, we could think
>> about whether some new language feature might reconcile good factoring
>> with good native code.
>
>I suspect that it's not to do with language features but code
>generators.

Please elaborate on that.  What better-factored code do you have in
mind?  And how do code generators help?

- 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 2012: http://www.euroforth.org/ef12/

[toc] | [prev] | [next] | [standalone]

#19242

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> For this application, the badly-factored code argument may be
>>> applicable, but have we seen better-factored code?  If we have
>>> better-factored code that produces slower native code, we could think
>>> about whether some new language feature might reconcile good factoring
>>> with good native code.
>>
>>I suspect that it's not to do with language features but code
>>generators.
> 
> Please elaborate on that.  What better-factored code do you have in
> mind?  And how do code generators help?

You said "better-factored code that produces slower native code."  My
response is that if better-factored code produces slower native code,
it's not necessarily a language issue.  Maybe a more elaborate (or
just better) compiler is all that's needed.

Andrew.

[toc] | [prev] | [next] | [standalone]

#19248

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> For this application, the badly-factored code argument may be
>>>> applicable, but have we seen better-factored code?  If we have
>>>> better-factored code that produces slower native code, we could think
>>>> about whether some new language feature might reconcile good factoring
>>>> with good native code.
>>>
>>>I suspect that it's not to do with language features but code
>>>generators.
>> 
>> Please elaborate on that.  What better-factored code do you have in
>> mind?  And how do code generators help?
>
>You said "better-factored code that produces slower native code."  My
>response is that if better-factored code produces slower native code,
>it's not necessarily a language issue.  Maybe a more elaborate (or
>just better) compiler is all that's needed.

That depends on the way in which the code is factored.  The one that I
had in mind was your suggestion of storing the stuff in memory and
passing addresses; not sure if it results in better-factored code, but
a decent compiler will produce slower code for that than for a version
using constant PICKs.

- 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 2012: http://www.euroforth.org/ef12/

[toc] | [prev] | [next] | [standalone]

#19250

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> For this application, the badly-factored code argument may be
>>>>> applicable, but have we seen better-factored code?  If we have
>>>>> better-factored code that produces slower native code, we could think
>>>>> about whether some new language feature might reconcile good factoring
>>>>> with good native code.
>>>>
>>>>I suspect that it's not to do with language features but code
>>>>generators.
>>> 
>>> Please elaborate on that.  What better-factored code do you have in
>>> mind?  And how do code generators help?
>>
>>You said "better-factored code that produces slower native code."  My
>>response is that if better-factored code produces slower native code,
>>it's not necessarily a language issue.  Maybe a more elaborate (or
>>just better) compiler is all that's needed.
> 
> That depends on the way in which the code is factored.  The one that I
> had in mind was your suggestion of storing the stuff in memory and
> passing addresses; not sure if it results in better-factored code, but
> a decent compiler will produce slower code for that than for a version
> using constant PICKs.

Maybe.  I guess you're assuming that a decent compiler will never
hoist memory references into registers but will convert stack accesses
(even via PICK) into register moves rather than memory references.

If so, I'm going to suggest that adopting a coding style based on the
advantages and disadvantages of a particular style of Forth compiler
isn't really appropriate, and it's certainly not appropriate to add
new language features to work around such compilers.

Andrew.

[toc] | [prev] | [next] | [standalone]

#19255

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Maybe.  I guess you're assuming that a decent compiler will never
>hoist memory references into registers but will convert stack accesses
>(even via PICK) into register moves rather than memory references.

Yes.

>If so, I'm going to suggest that adopting a coding style based on the
>advantages and disadvantages of a particular style of Forth compiler
>isn't really appropriate,

This assuption is not based on a particular style of Forth compiler,
but on pretty fundamental issues:

In typical Forth code it is relatively easy to map stack items to
registers (there are exceptions, but they are rare and do not occur in
the case in point).

In contrast, many memory accesses cannot be turned into register
accesses, even with compiler heroics like alias analysis (on which
hundreds of papers have been written) or perversities like GCC's
strict aliasing.

Coming back to your statement, how would you suggest that words where
performance matters should be written?

>and it's certainly not appropriate to add
>new language features to work around such compilers.

It's certainly appropriate to add language features that allow
compilers to provide predictable performance, especially in a
low-level language like Forth.

- 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 2012: http://www.euroforth.org/ef12/

[toc] | [prev] | [next] | [standalone]

#19257

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Maybe.  I guess you're assuming that a decent compiler will never
>>hoist memory references into registers but will convert stack accesses
>>(even via PICK) into register moves rather than memory references.
> 
> Yes.
> 
>>If so, I'm going to suggest that adopting a coding style based on the
>>advantages and disadvantages of a particular style of Forth compiler
>>isn't really appropriate,
> 
> This assuption is not based on a particular style of Forth compiler,
> but on pretty fundamental issues:
> 
> In typical Forth code it is relatively easy to map stack items to
> registers (there are exceptions, but they are rare and do not occur in
> the case in point).

I take your point.  However, that is assuming a particular style of
Forth implementation.  It certainly doesn't apply to traditional
threaded code or even to simple native code Forths; in some systems it
might well be the case that a fetch from a field is faster than a
PICK.  We don't know.

> In contrast, many memory accesses cannot be turned into register
> accesses, even with compiler heroics like alias analysis (on which
> hundreds of papers have been written) or perversities like GCC's
> strict aliasing.

Eh?  GCC's strict aliasing is type-based alias analysis, like many C
compilers.  There's nothing special about it AFAIK.

> Coming back to your statement, how would you suggest that words where
> performance matters should be written?

If it's a non-portable problem, and I suggest it may well be, it can
be solved with non-portable words.  Stephen's posting suggests very
strongly that it's not universally a problem with native code
generators.

Dreaming for a moment: there may, I suppose, be some mileage in a hint
to a compiler that some memory references really don't alias to
anything else.

>>and it's certainly not appropriate to add new language features to
>>work around such compilers.

> It's certainly appropriate to add language features that allow
> compilers to provide predictable performance, especially in a
> low-level language like Forth.

Sure, but it's not worth distorting Forth source to do it.  As usual,
IMO, YMMV, etc.

Andrew.

[toc] | [prev] | [next] | [standalone]

#19290

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> This assuption is not based on a particular style of Forth compiler,
>> but on pretty fundamental issues:
>> 
>> In typical Forth code it is relatively easy to map stack items to
>> registers (there are exceptions, but they are rare and do not occur in
>> the case in point).
>
>I take your point.  However, that is assuming a particular style of
>Forth implementation.

No, it's a statement about what is possible in an implementation.

>  It certainly doesn't apply to traditional
>threaded code or even to simple native code Forths;

These don't make use of that property, then.  Does it matter?  If a
user wants high performance, will he use such a system?  Probably not.
I see little point in optimizing for systems that are intentionally
slow, except if that is your particular target platform (but then we
are into platform-specific, not general optimizations).

>in some systems it
>might well be the case that a fetch from a field is faster than a
>PICK.  We don't know.

Sure, it's possible to write a PICK that's so slow that this is true.
But why would you optimize for such an intentionally-slow system?

>> In contrast, many memory accesses cannot be turned into register
>> accesses, even with compiler heroics like alias analysis (on which
>> hundreds of papers have been written) or perversities like GCC's
>> strict aliasing.
>
>Eh?  GCC's strict aliasing is type-based alias analysis, like many C
>compilers.  There's nothing special about it AFAIK.

Just because there are other perverts does not make it any less
perverted.

>> Coming back to your statement, how would you suggest that words where
>> performance matters should be written?
>
>If it's a non-portable problem, and I suggest it may well be, it can
>be solved with non-portable words.

Like what?  Pablo Reda's code obviously is specific to his system, but
there is nothing system-specific about cubic bezier curves, and such a
program can be written in standard Forth.

More generally, is your suggestion is that we should not use Forth if
we care for performance?  What should we use?

>Stephen's posting suggests very
>strongly that it's not universally a problem with native code
>generators.

What is not universally a problem?

My rectangle example shows that Stephen's code generator produces
smaller code for code using PICK than for the memory-based solution.

>Dreaming for a moment: there may, I suppose, be some mileage in a hint
>to a compiler that some memory references really don't alias to
>anything else.

Hey, Andrew Haley suggests a language feature!

I am not sure if it's a good solution, though, and I don't want to
discuss this suggestion in detail at the moment, but currently I don't
have any other solution, either.

>> It's certainly appropriate to add language features that allow
>> compilers to provide predictable performance, especially in a
>> low-level language like Forth.
>
>Sure, but it's not worth distorting Forth source to do it.

What do you mean with "distorting Forth source"?  Using your compiler
hint would certainly be visible in the source code, no?

- 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 2012: http://www.euroforth.org/ef12/

[toc] | [prev] | [next] | [standalone]

#19292

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>might well be the case that a fetch from a field is faster than a
>>PICK.  We don't know.
>
> Sure, it's possible to write a PICK that's so slow that this is true.
> But why would you optimize for such an intentionally-slow system?

Stack-oriented hardware that is super fast at traditional stack
operations but slow at reaching into the stack?  Such cpu's have figured
significantly into Forth history.

[toc] | [prev] | [next] | [standalone]

#19427

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>might well be the case that a fetch from a field is faster than a
>>>PICK.  We don't know.
>>
>> Sure, it's possible to write a PICK that's so slow that this is true.
>> But why would you optimize for such an intentionally-slow system?
>
>Stack-oriented hardware that is super fast at traditional stack
>operations

Not really.  Even the fast stack operations (like DUP) take one cycle,
and SWAP is often more expensive.

> but slow at reaching into the stack?

Yes.  There have been Forth CPUs that supported fast constant PICK,
but AFAIK they never got very far.

>  Such cpu's have figured
>significantly into Forth history.

Whatever you consider history.  The have a lot of mindshare in the
Forth community, but the practical relevance is pretty small.  The
most-used one seems to be the RTX2000, and that has not been
manufactured for a long time, so AFAIK nobody does new projects with
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 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#19296

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> This assuption is not based on a particular style of Forth compiler,
>>> but on pretty fundamental issues:
>>> 
>>> In typical Forth code it is relatively easy to map stack items to
>>> registers (there are exceptions, but they are rare and do not occur in
>>> the case in point).
>>
>>I take your point.  However, that is assuming a particular style of
>>Forth implementation.
> 
> No, it's a statement about what is possible in an implementation.

Eh?  Of course not.  Hoisting memory references is far from
impossible.

>>  It certainly doesn't apply to traditional
>>threaded code or even to simple native code Forths;
> 
> These don't make use of that property, then.  Does it matter?

Yes, of course.  We're talking about contorting perfectly reasonable
Forth code (using PICKs) because doing it some other way that's easier
to write and understand (field accesses) is slower.

> If a user wants high performance, will he use such a system?
> Probably not.  I see little point in optimizing for systems that are
> intentionally slow, except if that is your particular target
> platform (but then we are into platform-specific, not general
> optimizations).

I don't think that threaded-code implementations are intentionally 
slow; they're optimizing for other things.

>>in some systems it might well be the case that a fetch from a field
>>is faster than a PICK.  We don't know.
> 
> Sure, it's possible to write a PICK that's so slow that this is true.
> But why would you optimize for such an intentionally-slow system?
> 
>>> In contrast, many memory accesses cannot be turned into register
>>> accesses, even with compiler heroics like alias analysis (on which
>>> hundreds of papers have been written) or perversities like GCC's
>>> strict aliasing.
>>
>>Eh?  GCC's strict aliasing is type-based alias analysis, like many C
>>compilers.  There's nothing special about it AFAIK.
> 
> Just because there are other perverts does not make it any less
> perverted.

Um, yes it does, by definition.

>>> Coming back to your statement, how would you suggest that words where
>>> performance matters should be written?
>>
>>If it's a non-portable problem, and I suggest it may well be, it can
>>be solved with non-portable words.
> 
> Like what?  Pablo Reda's code obviously is specific to his system, but
> there is nothing system-specific about cubic bezier curves, and such a
> program can be written in standard Forth.
> 
> More generally, is your suggestion is that we should not use Forth if
> we care for performance?  What should we use?

No, that is not my suggestion.  Obviously.

I am certainly not convinced that caring for performace involves
always squeezing the last microsecond out of every operation.  That
way leads to the enormous complexity of today's compilers for other
languages.  I don't think that's appropriate for Forth.  Forth gets
its performance from clarity and simplicity, by eschewing much of that
complexity.

>>Stephen's posting suggests very strongly that it's not universally a
>>problem with native code generators.
> 
> What is not universally a problem?

The performance problem that causes PICK to be faster than field
accesses.

> My rectangle example shows that Stephen's code generator produces
> smaller code for code using PICK than for the memory-based solution.
> 
>>Dreaming for a moment: there may, I suppose, be some mileage in a hint
>>to a compiler that some memory references really don't alias to
>>anything else.
> 
> Hey, Andrew Haley suggests a language feature!

Eh?  This discussion is becoming surreal.
 
> I am not sure if it's a good solution, though, and I don't want to
> discuss this suggestion in detail at the moment, but currently I don't
> have any other solution, either.

Indeed.

>>> It's certainly appropriate to add language features that allow
>>> compilers to provide predictable performance, especially in a
>>> low-level language like Forth.
>>
>>Sure, but it's not worth distorting Forth source to do it.
> 
> What do you mean with "distorting Forth source"?  Using your compiler
> hint would certainly be visible in the source code, no?

By "contorting" I mean replacing field acesses with picks and pokes.

Andrew.

[toc] | [prev] | [next] | [standalone]

#19324

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> This assuption is not based on a particular style of Forth compiler,
>>>> but on pretty fundamental issues:
>>>> 
>>>> In typical Forth code it is relatively easy to map stack items to
>>>> registers (there are exceptions, but they are rare and do not occur in
>>>> the case in point).
>>>
>>>I take your point.  However, that is assuming a particular style of
>>>Forth implementation.
>> 
>> No, it's a statement about what is possible in an implementation.
>
>Eh?  Of course not.  Hoisting memory references is far from
>impossible.

Eliminating memory accesses is possible in some cases, but there are
other cases where it is impossible; and whether a compiler actually
does eliminate the memory access in a case where it is possible is
hard to predict; also, I would not expect a Forth compiler to do it
because of the costs in complexity and compilation time (and AFAIK no
Forth compiler does it). 

So, in my performance model for general use, a memory access on the
programming language level costs a memory access on the machine level;
if you are doing supercomputer-type programming, you may use a more
complex performance model, but that's too complex for most uses.

>>>  It certainly doesn't apply to traditional
>>>threaded code or even to simple native code Forths;
>> 
>> These don't make use of that property, then.  Does it matter?
>
>Yes, of course.  We're talking about contorting perfectly reasonable
>Forth code (using PICKs) because doing it some other way that's easier
>to write and understand (field accesses) is slower.

You are talking about that, but the OP actually has code that uses
PICKs and no code that uses memory, so he obviously has not contorted
memory-using code.

For the rectangle example, I had the memory and locals variants from
the paper
<http://www.complang.tuwien.ac.at/anton/euroforth/ef11/papers/ertl.pdf>
and derived the stack variant from the locals variant, not the memory
variant.  You might consider the PICKing variant more contorted than
the locals variant, but the locals-haters may disagree.

BTW, I would expect picking and locals to be equally fast.  Both can
be mapped to registers.

>> Just because there are other perverts does not make it any less
>> perverted.
>
>Um, yes it does, by definition.

The definition of "pervert" is not "singleton".

>I am certainly not convinced that caring for performace involves
>always squeezing the last microsecond out of every operation.  That
>way leads to the enormous complexity of today's compilers for other
>languages.  I don't think that's appropriate for Forth.  Forth gets
>its performance from clarity and simplicity, by eschewing much of that
>complexity.

We seem to be on the same page here.  And certainly, when doing the
the Bezier thing for real, one would note that the LINE word uses so
much time that the time for dealing with the coordinates probably does
not matter (whether stack, locals, or memory).

But there are other cases where performance does matter, and there one
needs a performance model.  Having that, we can consider if the
cleaner solution is expected to be faster (good), equally fast (good),
or slower, and in the latter case, which concern is more important.

And on a different level, if we find that there are many cases where
speed conflicts with clarity and simplicity, maybe there could be a
new language feature that allows us to reconcile both.

>>>Stephen's posting suggests very strongly that it's not universally a
>>>problem with native code generators.
>> 
>> What is not universally a problem?
>
>The performance problem that causes PICK to be faster than field
>accesses.

His posting does not suggest that very much.  He compared two
unspecified pieces of code, and for all we know (and as you
suggested), there might be a lot of differences other than just
between PICKs and field accesses.

>>>Dreaming for a moment: there may, I suppose, be some mileage in a hint
>>>to a compiler that some memory references really don't alias to
>>>anything else.
>> 
>> Hey, Andrew Haley suggests a language feature!
>
>Eh?  This discussion is becoming surreal.

Hmm?  Ok, we started discussing your dreams, but it's a somewhat
realistic dream.

- 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 2012: http://www.euroforth.org/ef12/

[toc] | [prev] | [next] | [standalone]

#19254

On Tue, 29 Jan 2013 15:21:33 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>That depends on the way in which the code is factored.  The one that I
>had in mind was your suggestion of storing the stuff in memory and
>passing addresses; not sure if it results in better-factored code, but
>a decent compiler will produce slower code for that than for a version
>using constant PICKs.

Nearly all PICKs that I have seen have used a literal index.

What happens is that PICKs produce fetches indexed from the data
stack pointer, and (assuming that the code generator gets the
structure address into a register) the structure is accessed as
offsets from a base register. If an item on the stack is DUPped
or OVERred, it's usually a big hint to a compiler that the item
should be in a register.

When we rewrote our PowerView embedded GUI to pass structures rather
than than keep graphics coordinates on the stack, the code (for ARM
and Cortex) became shorter and faster. In our experience, your
assertion does not hold bcause the use of structures considerably
reduces the stack traffic.

I'm prepared to be convinced that there are conditions under which
our experience does not hold.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web