Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #54545
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: CASEs compared |
| Date | 2017-01-30 15:56 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2017Jan30.165616@mips.complang.tuwien.ac.at> (permalink) |
| References | <o6n8ad$191s$1@gioia.aioe.org> |
"HAA" <someone@microsoft.com> writes:
>hughaguilar96@gmail.com wrote:
>> ...
>> CASE has to be nested IF statements though, which is horribly inefficient.
>
>Perhaps not. Below is some test code for VFX. It compares IF/ELSE Case with
>SWITCH from FD 20/3. The former gave me 10x better speed.
Note that the SWITCHER from FD 20/3 also performs a linear search
through the keys; moreover, it uses a linked list for walking through
the keys, and when it has found the right key, it uses a common
EXECUTE to invoke the matchxt; unless you have a very nice pattern in
the things you search for (e.g., always the same), the IF in SWITCHER
is likely to mispredict (~20 cycles penalty), and the EXECUTE is even
more likely to mispredict (another ~20 cycles), in addition to the at
least 4 cycles per tried key for following the linked list.
This is not the kind of thing Hugh Aguilar has in mind. Also, the
point of VanNorman's SWITCH is not performance, but being able to add
more key-action pairs later; that's why he uses a linked list.
> In the FD article
>the author states:
>
>"The execution-time behavior of CASE and OF can be optimized until your system
>implementor is exhausted and performance will be similar to that of the C version."
What can be done is one thing. But is it done? I don't think so.
And I don't think that it should be done. If we want something that
does not do a linear search, we should express it directly, instead of
writing an Eaker's CASE and hoping that the compiler will optimize it.
And guess what: If we care about performance, we do. We just don't do
it by inventing another CASE/SWITCH construct, but we use EXECUTE and
an xt table; or maybe the whole thing is reorganized:
In Gforth 0.7, we have an intelligent COMPILE, that uses Eaker's CASE
to decide how to compile each word type. In the development version,
each word has a field that says how the word is COMPILE,d, and
COMPILE, now does something like
: compile, ( xt -- )
xt>compile, @ execute ;
And I think that's why there was never much demand for something
beyond Eaker's CASE. If there are so many OFs that the linear search
becomes inefficient, idiomatic Forth programming stops putting all
that code in a single word.
- 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
CASEs compared "HAA" <someone@microsoft.com> - 2017-01-30 22:34 +1100
Re: CASEs compared anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-01-30 15:56 +0000
Re: CASEs compared hughaguilar96@gmail.com - 2017-01-30 09:57 -0800
Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-01-31 14:26 +1100
Re: CASEs compared hughaguilar96@gmail.com - 2017-01-31 08:12 -0800
Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-01 11:39 +1100
Re: CASEs compared hughaguilar96@gmail.com - 2017-01-31 22:37 -0800
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-01 12:26 -0800
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-01 16:50 -0800
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-01 18:02 -0800
Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-02 21:12 +1100
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-02 13:46 -0800
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-02 17:01 -0800
Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-04 12:43 +1100
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-03 17:52 -0800
Re: CASEs compared Alex <alex@rivadpm.com> - 2017-02-04 11:10 +0000
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-02 19:57 -0500
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-02 17:05 -0800
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-02 21:55 -0500
Re: CASEs compared Mark Wills <markwills1970@gmail.com> - 2017-02-03 02:11 -0800
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-03 10:52 -0800
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-03 17:38 -0800
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-03 22:08 -0500
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-03 21:40 -0800
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-04 01:16 -0500
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-03 14:40 -0500
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-03 17:47 -0800
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-03 22:04 -0500
Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-04 12:39 +1100
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-03 23:32 -0500
Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-04 22:50 +1100
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-04 11:07 -0500
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-04 08:48 -0800
Re: CASEs compared Mark Wills <markwills1970@gmail.com> - 2017-02-04 10:01 -0800
Re: CASEs compared rickman <gnuarm@gmail.com> - 2017-02-04 16:43 -0500
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-04 18:53 -0800
Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-02-05 19:12 +1100
Re: CASEs compared "HAA" <someone@microsoft.com> - 2017-01-31 14:25 +1100
Re: CASEs compared Elliott Chapin <elliott.chapin@gmail.com> - 2017-02-05 08:25 -0800
Re: CASEs compared Coos Haak <htrofhc@gmail.com> - 2017-02-06 00:42 +0100
Re: CASEs compared jacko <jackokring@gmail.com> - 2017-02-16 17:46 -0800
Re: CASEs compared hughaguilar96@gmail.com - 2017-02-17 09:09 -0800
csiph-web