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

Groups > comp.lang.forth > #19296

Re: About stack access profundity

Show all headers | View raw

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.

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