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

Groups > comp.lang.forth > #19324

Re: About stack access profundity

Show all headers | View raw

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/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web