Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #52413
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: Stack Operator Symbols |
| Date | 2016-11-03 15:33 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2016Nov3.163327@mips.complang.tuwien.ac.at> (permalink) |
| References | <ypidnaiGB-84P4jFnZ2dnUU7-UPNnZ2d@supernews.com> <nv6a7f$1nrm$1@gioia.aioe.org> <2016Oct31.100240@mips.complang.tuwien.ac.at> <nvf17l$49l$1@gioia.aioe.org> |
"HAA" <someone@microsoft.com> writes:
>Anton Ertl wrote:
>> "HAA" <someone@microsoft.com> writes:
>> >It's possible to estimate which stack sequence is going to deliver the better
>> >performance. Counting instructions is a good start. The definition quoted
>> >above comprises 3 instructions, as does the PICK version, so they're going
>> >to be close (and they are).
>>
>> If you mean primitives, the PICK version uses 6 primites (3 LITs, 3
>> PICKs) and will be relatively slow on a pure threaded-code Forth
>> implementation.
>
>Did you try it? PICK doesn't involve stack gymnastics so I expect it to
>do well.
Cycles (on a Core i7-6700K) with "gforth-fast --no-dynamic
--ss-number=0" (i.e., direct-threaded code) for the tak benchmark:
2077960654 : 3dup ( a b c -- a b c a b c ) >r 2dup r@ -rot r> ;
1944817489 : 3dup dup 2over rot ;
2137982996 : 3dup 2 pick 2 pick 2 pick ;
2376062674 : 3dup { a b c } a b c a b c ;
So, yes, the PICK variant is slower on a threaded-code system than the
other stack-juggling variants. The locals variant is even slower
because is performs even more primitives. Indeed, they all perform in
the order corresponding to the number of primitives.
>On a x86 DTC, 3DUP using PICK was 20% slower than the best
>alternative DUP 2OVER ROT.
So the slowdown is even bigger on that system.
>Not bad, but obviously you would go with
>the fastest and shortest.
Yes. And I consider a slowdown by 10% or 20% without any redeeming
qualities justifying the slowdown bad.
>> Do you mean that, instead of putting as many stack items and locals
>> in registers as we can to gain efficiency and relieve programmers from
>> worrying about how to write 3DUP, we should have compilers that
>> produce slower code with hard-to-predict performance characteristics,
>> in order to "leave the programmer in the equation"?
>
>It's optimizing compilers that are hard to predict. You discover defining
>3DUP with locals is just as good as PICK. You then try locals elsewhere
>only to discover the code produced is terrible. With optimizing compilers
>you have to check every time, and there may be no logical reason why
>one strategy works better than another.
It depends on the kind of optimization or code generation that's in
play. E.g., Gforth heavily depends on copy propagation by gcc, and it
works like a charm. And then there are some special-purpose
optimizations that only work in special cases (typically built in for
benchmarks); these are of course unreliable.
Allocating stack items or locals to registers is reliable as long as
there are enough registers (which is certainly the case for 3DUP, and
for a lot of other Forth code). And the nice thing is, if you have
this kind of compiler (Peter Faelth seems to have such a compiler),
you don't need to worry about which 3DUP variant is fastest, because
they are all equally fast, and you can decide based on other criteria,
such as clarity.
>If I need 3DUP to be fast, I just
>write it in machine code myself. Maybe simple is best.
Does not necessarily give you the fastest result: On VFX running TAK
with the builtin 3DUP (which probably is a CODE word) is slower then
with the Forth-defined stack-juggling variants.
Of course, you can choose to use a threaded-code Forth, then the
CODE-defined 3DUP will give you a speedup in TAK, maybe to the 1.5G
cycles that TAK1 takes. Then you will be >3 times slower than any of
the stack-juggling 3DUP variants on VFX, but hey, at least your old
knowledge of what's fast and what's slow is still relevant.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Stack Operator Symbols trans <transfire@gmail.com> - 2016-10-24 20:42 -0700
Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-25 01:58 -0700
Re: Stack Operator Symbols november.nihal@gmail.com - 2016-10-25 10:52 -0700
Re: Stack Operator Symbols Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-10-27 19:13 -0400
Re: Stack Operator Symbols "Elizabeth D. Rather" <erather@forth.com> - 2016-10-27 17:08 -1000
Re: Stack Operator Symbols "HAA" <someone@microsoft.com> - 2016-10-28 21:53 +1000
Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-28 20:42 -0700
Re: Stack Operator Symbols Walter Banks <walter@bytecraft.com> - 2016-10-29 17:15 -0400
Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-29 17:27 -0700
Re: Stack Operator Symbols "Elizabeth D. Rather" <erather@forth.com> - 2016-10-28 20:56 -1000
Re: Stack Operator Symbols Paul Rubin <no.email@nospam.invalid> - 2016-10-29 00:46 -0700
Re: Stack Operator Symbols Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-29 04:30 -0500
Re: Stack Operator Symbols rickman <gnuarm@gmail.com> - 2016-10-29 16:58 -0400
Re: Stack Operator Symbols Paul Rubin <no.email@nospam.invalid> - 2016-10-29 14:21 -0700
Re: Stack Operator Symbols Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-30 04:03 -0500
Re: Stack Operator Symbols Paul Rubin <no.email@nospam.invalid> - 2016-10-30 18:06 -0700
Re: Stack Operator Symbols Spiros Bousbouras <spibou@gmail.com> - 2016-10-31 01:43 +0000
Re: Stack Operator Symbols Paul Rubin <no.email@nospam.invalid> - 2016-10-30 19:23 -0700
Re: Stack Operator Symbols Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-10-31 05:13 -0500
Re: Stack Operator Symbols albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-31 12:42 +0100
Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-31 12:12 +0000
Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-31 14:49 +0000
Re: Stack Operator Symbols mhx@iae.nl - 2016-10-31 13:17 -0700
Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-03 16:38 +0000
Re: Stack Operator Symbols Spiros Bousbouras <spibou@gmail.com> - 2016-11-20 14:33 +0000
Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-31 08:35 +0000
Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-30 11:01 +0000
Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-30 10:01 -0700
Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-11-03 14:46 -0700
Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-04 23:04 +0000
Re: Stack Operator Symbols Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-05 03:16 -0400
Re: Stack Operator Symbols peter.m.falth@gmail.com - 2016-10-29 09:13 -0700
Re: Stack Operator Symbols "HAA" <someone@microsoft.com> - 2016-10-30 08:47 +1100
Re: Stack Operator Symbols trans <transfire@gmail.com> - 2016-10-29 14:57 -0700
Re: Stack Operator Symbols "HAA" <someone@microsoft.com> - 2016-10-30 09:20 +1100
Re: Stack Operator Symbols Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-10-29 18:46 -0400
Re: Stack Operator Symbols Paul Rubin <no.email@nospam.invalid> - 2016-10-29 19:45 -0700
Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-29 20:29 -0700
Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-29 20:47 -0700
Re: Stack Operator Symbols Cecil Bayona <cbayona@cbayona.com> - 2016-10-29 23:15 -0500
Re: Stack Operator Symbols "Elizabeth D. Rather" <erather@forth.com> - 2016-10-29 21:37 -1000
Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-30 10:07 -0700
Re: Stack Operator Symbols "Elizabeth D. Rather" <erather@forth.com> - 2016-10-29 21:35 -1000
Re: Stack Operator Symbols "HAA" <someone@microsoft.com> - 2016-10-31 13:11 +1100
Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-30 20:02 -0700
Re: Stack Operator Symbols "Elizabeth D. Rather" <erather@forth.com> - 2016-10-30 22:08 -1000
Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-31 09:02 +0000
Re: Stack Operator Symbols "HAA" <someone@microsoft.com> - 2016-11-03 20:49 +1100
Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-03 15:33 +0000
Re: Stack Operator Symbols Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-03 16:55 -0400
Re: Stack Operator Symbols anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-11-03 22:21 +0000
Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-27 20:31 -0700
Re: Stack Operator Symbols november.nihal@gmail.com - 2016-10-28 09:52 -0700
Re: Stack Operator Symbols hughaguilar96@gmail.com - 2016-10-28 20:32 -0700
Re: Stack Operator Symbols Mark Wills <markwills1970@gmail.com> - 2016-10-30 04:49 -0700
Re: Stack Operator Symbols Coos Haak <htrofhc@gmail.com> - 2016-10-30 14:49 +0100
Re: Stack Operator Symbols Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2016-10-31 13:31 +0100
Re: Stack Operator Symbols Coos Haak <htrofhc@gmail.com> - 2016-10-31 14:12 +0100
Re: Stack Operator Symbols Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2016-10-31 15:03 +0100
Re: Stack Operator Symbols Mark Wills <markwills1970@gmail.com> - 2016-11-03 14:22 -0700
Re: Stack Operator Symbols Coos Haak <htrofhc@gmail.com> - 2016-11-04 00:46 +0100
Re: Stack Operator Symbols "HAA" <someone@microsoft.com> - 2016-11-05 13:14 +1100
Re: Stack Operator Symbols trans <transfire@gmail.com> - 2016-10-30 06:50 -0700
Re: Stack Operator Symbols trans <transfire@gmail.com> - 2016-10-30 08:56 -0700
Re: Stack Operator Symbols albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-30 18:19 +0100
csiph-web