1. switch bug?
- Posted by irv Jul 20, 2008
- 891 views
switch result do case 0 : puts(1,"Quit button clicked\n") case 1 : puts(1,"OK button clicked\n") case -4 : puts(1,"You closed the window\n") case else ? result end switch
This works without the case -4 line, but causes an immediate seg fault when the case -4 line is added. Don't even have to execute the function that statement is found in, just crashes on program load.
2. Re: switch bug?
- Posted by Jeremy Cowgar Jul 20, 2008
- 871 views
switch result do case 0 : puts(1,"Quit button clicked\n") case 1 : puts(1,"OK button clicked\n") case -4 : puts(1,"You closed the window\n") case else ? result end switch
This works without the case -4 line, but causes an immediate seg fault when the case -4 line is added. Don't even have to execute the function that statement is found in, just crashes on program load.
I confirmed it as well on Linux SVN r955. I'll forward on the dev list so it can be taken care of. Thanks!
Just a note, however, you do have a slight problem in your code. Case statements will fall through. For instance, if the above program would have worked (w/o bug that is), and the result was 0, the result would be:
Quit button clicked OK button clicked You closed the window 0
You need to introduce break at the end of each case:
switch result do case 0 : puts(1,"Quit button clicked\n") break case 1 : puts(1,"OK button clicked\n") break case -4 : puts(1,"You closed the window\n") break case else ? result end switch
Jeremy
3. Re: switch bug?
- Posted by Switch Select Jul 20, 2008
- 883 views
[quote Jeremy Cowgar]
switch result do case 0 : puts(1,"Quit button clicked\n") case 1 : puts(1,"OK button clicked\n") case -4 : puts(1,"You closed the window\n") case else ? result end switch
Just a note, however, you do have a slight problem in your code. Case statements will fall through.
You need to introduce break at the end of each case:
switch result do case 0 : puts(1,"Quit button clicked\n") break case 1 : puts(1,"OK button clicked\n") break case -4 : puts(1,"You closed the window\n") break case else ? result end switch
Can we also have the select statement, that doesn't fall through.
4. Re: switch bug?
- Posted by irv Jul 20, 2008
- 855 views
Yes, I know about the break, I have that in the original code, then took it off to see if that changed the results. Didn't, so that's what I copied & pasted to the forum.
Thanks for looking into this.
5. Re: switch bug?
- Posted by Jeremy Cowgar Jul 20, 2008
- 886 views
Can we also have the select statement, that doesn't fall through.
Fall through was designed into switch for it's power. I do not think we will introduce a select just for the purpose of non-fall through.
Jeremy
6. Re: switch bug?
- Posted by DerekParnell (admin) Jul 20, 2008
- 885 views
Can we also have the select statement, that doesn't fall through.
I tried to argue for a non-fallthru switch statement too. In my opinion, the fall through should be explicit and not implicit. Something like ...
switch val do case 1: DoOne() case 2: DoTwo() fallthru case 3: DoThree() end switch
But it was rejected on the grounds (IIRC) that it was not C-like and therefore unfamiliar, and we would also need case clauses that handled lists ...
switch val do case 1, 2: DoOneTwo() case 3: DoThree() end switch
And my response to those were "this is Euphoria not C", and "Excellent idea, let's have lists".
I did not win out on this one.
I also wanted to have Euphoria issue a warning if case else was omitted. But this is an exercise in collective productivy, and from time to time we all need to make concessions.
7. Re: switch bug?
- Posted by mattlewis (admin) Jul 20, 2008
- 925 views
- Last edited Jul 21, 2008
I confirmed it as well on Linux SVN r955. I'll forward on the dev list so it can be taken care of. Thanks!
Fixed in r957.
Matt
8. Re: switch bug?
- Posted by euphoric (admin) Jul 20, 2008
- 924 views
- Last edited Jul 21, 2008
Can we also have the select statement, that doesn't fall through.
Fall through was designed into switch for its power. I do not think we will introduce a select just for the purpose of non-fall through.
What construct would you use if you had, say, 10 branches that were mutually exclusive? Is if...elsif...endif just as fast as the switch statement?
9. Re: switch bug?
- Posted by jaygade Jul 20, 2008
- 854 views
- Last edited Jul 21, 2008
Can we also have the select statement, that doesn't fall through.
Fall through was designed into switch for its power. I do not think we will introduce a select just for the purpose of non-fall through.
What construct would you use if you had, say, 10 branches that were mutually exclusive? Is if...elsif...endif just as fast as the switch statement?
Umm, I'd use a switch statement and make sure to insert the "break" after every clause.
10. Re: switch bug?
- Posted by jeremy (admin) Jul 20, 2008
- 852 views
- Last edited Jul 21, 2008
Is if...elsif...endif just as fast as the switch statement?
I was thinking that switch should be faster than if ... elsif ... end if, however this benchmark suggests that if ... elsif ... end if is faster. Matt, what are your thoughts?
integer a = 20 atom t0 t0 = time() for b = 1 to 100000000 do switch a do case 5: a = 10 break case 10: a = 15 break case 15: a = 20 break case 20: a = 25 break case 25: a = 30 break case 30: a = 35 break case else a = 5 end switch end for printf(1, "switch=%f\n", {time()-t0}) t0 = time() for b = 1 to 100000000 do if a = 5 then a = 10 elsif a = 10 then a = 15 elsif a = 15 then a = 20 elsif a = 20 then a = 25 elsif a = 25 then a = 30 elsif a = 30 then a = 35 else a = 5 end if end for printf(1, "if=%f\n", {time()-t0})
When run the output is:
switch=2.730000 if=2.465000
Jeremy
11. Re: switch bug?
- Posted by mattlewis (admin) Jul 21, 2008
- 854 views
Is if...elsif...endif just as fast as the switch statement?
I was thinking that switch should be faster than if ... elsif ... end if, however this benchmark suggests that if ... elsif ... end if is faster. Matt, what are your thoughts?
Basically, it's showing how the switch construct is not optimized.
Currently, switch is implemented using find. This means that it was pretty easy to do, but isn't always the fastest. There is some overhead for the call, of course. The if-elsif construct seems to degrade quicker if there are 'dead' options. Also, if you happen to have a sequence comparison in there, switch seems to work better.
Having said that, I have been thinking about some ways to optimize switch. For switches that are all small integers, for instance, it could simply do a type and bounds test and use a lookup on the jump table, rather than having to use find to figure out where to go. This should blow away the if-elsif construct at the cost of a bit of memory.
There are probably other optimizations. Here is a modified example with a few dead options, plus a sequence. If you change a to an object or an atom, the swtich looks better yet.
integer a = 20 atom t0 t0 = time() for b = 1 to 100000000 do switch a do case 0: a = -1 break case 5: a = 10 break case -1: a = -2 break case 10: a = 15 break case "foo": a = 0 break case 15: a = 20 break case -2: a = -3 break case 20: a = 25 break case 25: a = 30 break case -3: a = -4 break case 30: a = 35 break case -4: case else a = 5 end switch end for printf(1, "switch=%f\n", {time()-t0}) t0 = time() for b = 1 to 100000000 do if a = 0 then a = -1 elsif a = 5 then a = 10 elsif a = -1 then a = -2 elsif a = 10 then a = 15 elsif equal( a, "foo" ) then a = 0 elsif a = 15 then a = 20 elsif a = -2 then a = -3 elsif a = 20 then a = 25 elsif a = -3 then a = -4 elsif a = 25 then a = 30 elsif a = 30 then a = 35 elsif a = -4 then a = -5 else a = 5 end if end for printf(1, "if=%f\n", {time()-t0})
Matt
12. Re: switch bug?
- Posted by jeremy (admin) Jul 21, 2008
- 864 views
Just so we can see the difference, the results for Matt's benchmark are:
switch=3.400000 if=4.259000
Jeremy
13. Re: switch bug?
Is if...elsif...endif just as fast as the switch statement?
Matt just released the first round of optimizations for switch. These optimizations are in the interpreter. The translator is still hit and miss in relation to speed vs. if, but it's coming too.
here are the new results. Remember in the previous test that if was faster in the first test and switch was faster in the second.
C:\Develop\euphoria>exwc bench-switch.ex switch=0.749000 if=2.636000 C:\Develop\euphoria>exwc bench-switch2.ex switch=3.400000 if=4.540000
So, in the second case we really did not gain much speed, but in the first.... Wow! Thanks Matt!
Jeremy
14. Re: switch bug?
- Posted by mattlewis (admin) Jul 22, 2008
- 849 views
So, in the second case we really did not gain much speed, but in the first.... Wow! Thanks Matt!
Yes, the second case still uses the same code (i.e., find()). Basically, if all of your cases are integers, it will be faster. And if the difference between the max and min case is 1024 or less, it will be a lot faster.
Matt
15. Re: switch bug?
Matt just released the first round of optimizations for switch. These optimizations are in the interpreter. The translator is still hit and miss in relation to speed vs. if, but it's coming too.
I've committed some optimizations to switch for the translator. It now beats if-else every time, sometimes by a lot.
Matt
