Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #54583
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: CASEs compared |
| Date | 2017-02-01 11:39 +1100 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <o6ralk$26n$1@gioia.aioe.org> (permalink) |
| References | <o6n8ad$191s$1@gioia.aioe.org> <2017Jan30.165616@mips.complang.tuwien.ac.at><097d4d65-5777-4dae-b1b8-6210d2807fc4@googlegroups.com> <o6p01r$3sb$2@gioia.aioe.org> <fb35470d-27ba-4bc2-8ad6-e05404cd2b79@googlegroups.com> |
hughaguilar96@gmail.com wrote: > On Monday, January 30, 2017 at 8:24:56 PM UTC-7, HAA wrote: > > hughaguilar96@gmail.com wrote: > > > ... > > > Why did he use a linked list? Why not a self-balancing binary-tree? Most likely, > > > because he didn't know how to implement a self-balancing binary-tree. > > > > Or such effort couldn't be justified on the grounds it would waste resources > > for no material gain. > > Didn't you previously say that his linked-list code was 10 times slower than Eaker's > CASE construct? But now you say that there would be "no material gain" from using a > self-balancing binary-tree. hmmm... Nor can anyone claim there would be material gain unless the speed of the case/switch was critical to the application. I accept it wasn't the best Case with which to compare Eaker but it was all I had at the time and I was curious myself what would be the result. I've since created a third test which attempts to emulate the run-time of a table-based C switch of the early 1990's. It's hand-coded asm to give the best shot at speed. To use, append it the code I previously posted. code (exec) ( x table ) mov eax, 0 [ebp] add ebp, # 4 mov ecx, 0 [ebx] mov edx, ecx L$1: add ebx, # 4 cmp ax, 0 [ebx] jz L$2 dec ecx jnz L$1 \ faster than loop \ loop L$1 inc edx \ default L$2: shl edx, # 2 add edx, ebx mov ebx, 0 [ebp] add ebp, # 4 jmp 0 [edx] next, end-code : default ." no match" ; create TABLE 10 , 0 , 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , ' noop , ' noop , ' noop , ' noop , ' noop , ' noop , ' noop , ' noop , ' noop , ' noop , ' default , : test3 cr ." TABLE SWITCH - " Counter TIMES 0 do 9 table (exec) loop .timer ; By 2000, Borland's 32-bit Win compiler had thrown out tables for anything that required comparison. It used an approach similar to Eaker with the exception that target values were sorted into smaller groups of a few each for comparison. The conclusion being that when down to a few values to compare (which in my experience is most of the time) a direct compare and branch is best. > BTW: If this is Rick van Norman, who later got hired by Elizabeth Rather to write > SwiftForth for her, then I find it highly humorous that his SWITCH was 10 times slower > than Eaker's CASE > ... SwitfForth needed an extensible Case for internal reasons as imagine would VFX. Both have Eaker of course.
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