Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #8592 > unrolled thread
| Started by | Lynn McGuire <lmc@winsim.com> |
|---|---|
| First post | 2011-08-09 11:03 -0500 |
| Last post | 2011-08-22 10:56 -0700 |
| Articles | 20 on this page of 119 — 22 participants |
Back to article view | Back to comp.lang.c++
maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-09 11:03 -0500
Re: maximum cases in a switch ? LR <lruss@superlink.net> - 2011-08-09 12:27 -0400
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-09 12:23 -0500
Re: maximum cases in a switch ? Joe Greer <jgreer@doubletake.com> - 2011-08-10 12:45 +0000
Re: maximum cases in a switch ? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-10 09:09 -0400
Re: maximum cases in a switch ? Joe Greer <jgreer@doubletake.com> - 2011-08-11 12:49 +0000
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-11 10:48 -0500
Re: maximum cases in a switch ? Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-08-11 18:26 +0200
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-11 11:45 -0500
Re: maximum cases in a switch ? Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-08-11 20:06 +0200
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-11 14:47 -0500
Re: maximum cases in a switch ? Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-08-11 22:32 +0200
Re: maximum cases in a switch ? gwowen <gwowen@gmail.com> - 2011-08-12 06:00 -0700
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-12 10:49 -0500
Re: maximum cases in a switch ? Joe Greer <jgreer@doubletake.com> - 2011-08-12 13:46 +0000
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-12 10:58 -0500
Re: maximum cases in a switch ? Joe Greer <jgreer@doubletake.com> - 2011-08-12 20:22 +0000
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-12 15:57 -0500
Re: maximum cases in a switch ? Leo Equinox Gaspard <ekinox1995@gmail.com> - 2011-08-13 20:58 +0200
Re: maximum cases in a switch ? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-13 18:16 -0400
Re: maximum cases in a switch ? Leo Equinox Gaspard <ekinox1995@gmail.com> - 2011-08-16 07:55 +0200
Re: maximum cases in a switch ? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-16 09:04 -0400
Re: maximum cases in a switch ? Leo Equinox Gaspard <ekinox1995@gmail.com> - 2011-08-17 00:11 +0200
Re: maximum cases in a switch ? Ian Collins <ian-news@hotmail.com> - 2011-08-17 10:24 +1200
Re: maximum cases in a switch ? Leo Equinox Gaspard <ekinox1995@gmail.com> - 2011-08-17 01:33 +0200
Re: maximum cases in a switch ? Leo Equinox Gaspard <ekinox1995@gmail.com> - 2011-08-17 00:18 +0200
Re: maximum cases in a switch ? Ian Collins <ian-news@hotmail.com> - 2011-08-17 10:29 +1200
Re: maximum cases in a switch ? Leo Equinox Gaspard <ekinox1995@gmail.com> - 2011-08-17 01:37 +0200
Re: maximum cases in a switch ? Ian Collins <ian-news@hotmail.com> - 2011-08-17 12:02 +1200
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-09 16:38 +0000
Re: maximum cases in a switch ? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-09 15:42 -0400
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-09 15:39 -0500
Re: maximum cases in a switch ? Leo Equinox Gaspard <ekinox1995@gmail.com> - 2011-08-09 23:39 +0200
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-09 17:18 -0500
Re: maximum cases in a switch ? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-09 20:06 -0400
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-10 06:54 +0000
Re: maximum cases in a switch ? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-08-10 12:20 +0000
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-10 11:34 -0500
Re: maximum cases in a switch ? Paul Brettschneider <paul.brettschneider@yahoo.fr> - 2011-08-10 20:34 +0200
Re: maximum cases in a switch ? Paul Brettschneider <paul.brettschneider@yahoo.fr> - 2011-08-10 21:06 +0200
Re: maximum cases in a switch ? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-08-11 21:00 +0000
Re: maximum cases in a switch ? Marcel Müller <news.5.maazl@spamgourmet.com> - 2011-08-10 11:10 +0200
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-10 10:40 +0000
Re: maximum cases in a switch ? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-10 09:02 -0400
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-11 08:05 +0000
Re: maximum cases in a switch ? Marcel Müller <news.5.maazl@spamgourmet.com> - 2011-08-10 21:17 +0200
Re: maximum cases in a switch ? Lynn McGuire <lmc@winsim.com> - 2011-08-10 11:12 -0500
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-11 11:07 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-13 00:14 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-13 14:54 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-13 15:26 +0100
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-14 18:14 +0000
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-15 01:09 +0100
Re: maximum cases in a switch ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-15 02:15 -0700
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-15 12:18 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-15 13:22 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-15 13:38 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-15 14:06 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-15 16:05 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-15 16:20 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-15 20:24 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-15 22:09 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-15 22:19 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-16 03:10 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-16 13:08 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-16 14:01 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-16 14:10 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-16 03:07 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-16 13:05 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-16 13:57 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-16 14:07 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-16 19:29 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-16 19:35 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 00:01 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-17 00:11 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 01:23 +0100
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-15 13:32 +0000
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-15 15:20 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-15 15:33 +0100
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-16 07:34 +0000
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-16 13:49 +0100
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-16 15:02 +0000
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-16 16:07 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-16 19:50 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-16 19:57 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 00:12 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-16 19:34 +0100
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-17 12:55 +0000
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 14:32 +0100
Re: maximum cases in a switch ? Juha Nieminen <nospam@thanks.invalid> - 2011-08-17 20:11 +0000
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-18 11:00 +0100
Re: maximum cases in a switch ? Joshua Maurice <joshuamaurice@gmail.com> - 2011-08-15 15:35 -0700
Re: maximum cases in a switch ? Gareth Owen <gwowen@gmail.com> - 2011-08-17 06:34 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 12:23 +0100
Re: maximum cases in a switch ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-17 02:01 -0700
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 12:29 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-17 14:13 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 14:18 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-17 14:43 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 15:23 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-17 15:31 +0100
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 15:48 +0100
Re: maximum cases in a switch ? Leigh Johnston <leigh@i42.co.uk> - 2011-08-17 15:53 +0100
Re: maximum cases in a switch ? SG <s.gesemann@gmail.com> - 2011-08-17 07:54 -0700
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 20:40 +0100
Re: maximum cases in a switch ? Larry Evans <cppljevans@suddenlink.net> - 2011-08-17 10:54 -0500
Re: maximum cases in a switch ? Robert Wessel <robertwessel2@yahoo.com> - 2011-08-17 12:44 -0500
jump table vs. vector of function pointers(was Re: maximum cases in a switch ? Larry Evans <cppljevans@suddenlink.net> - 2011-08-17 15:18 -0500
Re: jump table vs. vector of function pointers(was Re: maximum cases in a switch ? Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2011-08-17 22:48 +0200
Re: jump table vs. vector of function pointers(was Re: maximum cases in a switch ? Larry Evans <cppljevans@suddenlink.net> - 2011-08-17 16:49 -0500
Re: maximum cases in a switch ? Thomas David Rivers <rivers@dignus.com> - 2011-08-17 13:50 -0400
Re: maximum cases in a switch ? "Paul" <pchristor@yahoo.co.uk> - 2011-08-17 22:04 +0100
Re: maximum cases in a switch ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-22 03:23 -0700
Re: maximum cases in a switch ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-12 05:51 -0700
Re: maximum cases in a switch ? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-13 08:45 -0400
Re: maximum cases in a switch ? James Kanze <james.kanze@gmail.com> - 2011-08-21 16:55 -0700
Re: maximum cases in a switch ? Robert Wessel <robertwessel2@yahoo.com> - 2011-08-21 23:22 -0500
Re: maximum cases in a switch ? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-22 08:14 -0400
Re: maximum cases in a switch ? James Kanze <james.kanze@gmail.com> - 2011-08-22 10:56 -0700
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-15 20:24 +0100 |
| Message-ID | <j2brqu$o31$1@adenine.netfront.net> |
| In reply to | #8866 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:voKdneBY59LDpNTTnZ2dnUVZ8t2dnZ2d@giganews.com... > On 15/08/2011 16:05, Paul wrote: >> >>>>>>> >>>> 525 switch cases seem alot but how long does this take to >>>>>>> >>>> compute, >>>>>>> >>>> assuming the very last case is the one that is true? Probably >>>>>>> not >>>>>>> >>>> very >>>>>>> >>>> long, maybe 3 instructions per conditional test, so it might be >>>>>>> >>>> around >>>>>>> >>>> 1500 clock cycles or something. >>>>>>> >>>>>>> >>> Only if the compiler was as naive as you (for a clue you should >>>>>>> >>> learn >>>>>>> >>> about jump tables). >>>>>>> >>>>>>> >> From behind which rock have you crawled? >>>>>>> >>>>>>> > Please explain to us how using a jump table to implement a switch >>>>>>> > block >>>>>>> > of 525 cases could possibly take 1500 clock cycles. >>>>>>> >>>>>>> I already have explained it, obviosly this is a very rough estimate >>>>>> >>>>>> --ITYM "wrong estimate" >>>>>> >>>>>> There is no "right" estimate, a quadcore cpu with precaching and >>>>>> all the >>>>>> fancy tech they have nowadays will probably do it alot faster than an >>>>>> ancient AMD cpu. >>>>>> >>>>>> So you are "wrong" to say my estimate was "wrong". >>>>>> >>>>>>> as not >>>>>>> all CPU's are the same. Can you explain how many clock cycles you >>>>>>> think it'd >>>>>>> take? >>>>>> >>>>>> --the number taken is independent of the number of entries in the >>>>>> table >>>>>> >>>>>> -- goto table[i]; >>>>>> >>>>>> --we're talking half a dozen instructions and a couple of memory >>>>>> --accesses >>>>>> >>>>>> >>>>>> Start Process: >>>>>> Load reg1 with comparee (Only done once at start) >>>>>> >>>>>> Load reg2 with case option >>>>>> Load reg3 with jump address >>>>>> Jump if reg1and reg2 are equal . >>>>>> >>>>>> repeat above until the condition is met. >>>>>> >>>>>> >>>>>> Why do you need to repeat 6 instructions ? >>>>>> And what are you talking about memeory access? L1 cache? or pipeline >>>>>> cache or prefetched queues? >>>>>> Modern CPUs have everything all prefetched into caches and its a bit >>>>>> more complicated than you seem to understand. >>>>>> You can try to pretend you know more than me about it and I don't >>>>>> really >>>>>> care if you do or don't but when you challenge something I said as >>>>>> wrong >>>>>> and present "your opinion" as right, I'd suggest you get your facts >>>>>> right first and provide some kind of evidence which supports your >>>>>> "claim". >>>>>> >>>>>> Even if your opinion that it was 6x525 clock cycles , for any given >>>>>> CPU, >>>>>> was 100% exact then that would make my estimate close enough to be >>>>>> accurate, because we are talking about cpu speeds in gigahertz now. >>>>>> Please don't claim my estimates are "wrong" without providing some >>>>>> kind >>>>>> of reason other that "because you say so". >>>>> >>>>> His opinion is that it is *just* 6 clock cycles not 6x525 clock >>>>> cycles; your lack of comprehension and naivity is stunning. Again: >>>>> learn about jump tables instead of wasting time displaying a lack of >>>>> knowledge here. >>>>> >>>> You can't have a switch statement with 525 cases executed in 6 clock >>>> cycles you fucking moronic idiot. >>> >>> Your insults do nothing to mend your reputation or make your incorrect >>> assertions correct. >>> >> Well stop being a moron. The only thing incorrect here is your incorrect >> assumption that I was talking about jump tables. >> >> A compiler is free to implement a switch statement anyway it likes. All >> I was saying that with the worst case scenario of a 525 switch case >> statement is may be something like 1500 clock cycles which is not really >> alot of CPU time anyway, even though 525 cases seems like a lot. >> It may be more it may be less, I don't know how the compiler will >> implement it and neither do you. You do not the full details of the code >> , does it have a default statement etc, which compiler is it , blah blah >> blah. >> >> So please stop making inciorrect assumptions that I was talking about >> jump tables , and trying to start an argument based on the false >> assumption that you know what a jump table is and I don't. >> I don't know why you havent learned your lesson from the past , I guess >> you are just going to keep on arguing and creating arguments until you >> actually win one. And before you start bringing up history and trying to >> falsify who had he victorious outcome please remember this: >> >> int x = new int[24]; >> x is a pointer to an array of integers. :) > > You said: "You can't have a switch statement with 525 cases executed in 6 > clock cycles you fucking moronic idiot." (just scroll up). This assertion > is false and I explained why whilst also introducing you to the concept of > jump tables (a thankyou would be nice). The assertion is true. The switch statement does not have ordered cases therefore you could only implement this with a hash table but then you are basically rewriting the software completely and you no longer have a switch statement. > > Your epic fails are so epic that they will probably make people laugh for > many years to come. > When you fail to provide some example code to prove your claim you will be the one who has failed. --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-08-15 22:09 +0100 |
| Message-ID | <9tCdnZfs3uFkF9TTnZ2dnUVZ8qmdnZ2d@giganews.com> |
| In reply to | #8873 |
On 15/08/2011 20:24, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:voKdneBY59LDpNTTnZ2dnUVZ8t2dnZ2d@giganews.com... >> On 15/08/2011 16:05, Paul wrote: >>> >>>>>>>> >>>> 525 switch cases seem alot but how long does this take to >>>>>>>> >>>> compute, >>>>>>>> >>>> assuming the very last case is the one that is true? Probably >>>>>>>> not >>>>>>>> >>>> very >>>>>>>> >>>> long, maybe 3 instructions per conditional test, so it >>>>>>>> might be >>>>>>>> >>>> around >>>>>>>> >>>> 1500 clock cycles or something. >>>>>>>> >>>>>>>> >>> Only if the compiler was as naive as you (for a clue you should >>>>>>>> >>> learn >>>>>>>> >>> about jump tables). >>>>>>>> >>>>>>>> >> From behind which rock have you crawled? >>>>>>>> >>>>>>>> > Please explain to us how using a jump table to implement a switch >>>>>>>> > block >>>>>>>> > of 525 cases could possibly take 1500 clock cycles. >>>>>>>> >>>>>>>> I already have explained it, obviosly this is a very rough estimate >>>>>>> >>>>>>> --ITYM "wrong estimate" >>>>>>> >>>>>>> There is no "right" estimate, a quadcore cpu with precaching and >>>>>>> all the >>>>>>> fancy tech they have nowadays will probably do it alot faster >>>>>>> than an >>>>>>> ancient AMD cpu. >>>>>>> >>>>>>> So you are "wrong" to say my estimate was "wrong". >>>>>>> >>>>>>>> as not >>>>>>>> all CPU's are the same. Can you explain how many clock cycles you >>>>>>>> think it'd >>>>>>>> take? >>>>>>> >>>>>>> --the number taken is independent of the number of entries in the >>>>>>> table >>>>>>> >>>>>>> -- goto table[i]; >>>>>>> >>>>>>> --we're talking half a dozen instructions and a couple of memory >>>>>>> --accesses >>>>>>> >>>>>>> >>>>>>> Start Process: >>>>>>> Load reg1 with comparee (Only done once at start) >>>>>>> >>>>>>> Load reg2 with case option >>>>>>> Load reg3 with jump address >>>>>>> Jump if reg1and reg2 are equal . >>>>>>> >>>>>>> repeat above until the condition is met. >>>>>>> >>>>>>> >>>>>>> Why do you need to repeat 6 instructions ? >>>>>>> And what are you talking about memeory access? L1 cache? or pipeline >>>>>>> cache or prefetched queues? >>>>>>> Modern CPUs have everything all prefetched into caches and its a bit >>>>>>> more complicated than you seem to understand. >>>>>>> You can try to pretend you know more than me about it and I don't >>>>>>> really >>>>>>> care if you do or don't but when you challenge something I said as >>>>>>> wrong >>>>>>> and present "your opinion" as right, I'd suggest you get your facts >>>>>>> right first and provide some kind of evidence which supports your >>>>>>> "claim". >>>>>>> >>>>>>> Even if your opinion that it was 6x525 clock cycles , for any given >>>>>>> CPU, >>>>>>> was 100% exact then that would make my estimate close enough to be >>>>>>> accurate, because we are talking about cpu speeds in gigahertz now. >>>>>>> Please don't claim my estimates are "wrong" without providing some >>>>>>> kind >>>>>>> of reason other that "because you say so". >>>>>> >>>>>> His opinion is that it is *just* 6 clock cycles not 6x525 clock >>>>>> cycles; your lack of comprehension and naivity is stunning. Again: >>>>>> learn about jump tables instead of wasting time displaying a lack of >>>>>> knowledge here. >>>>>> >>>>> You can't have a switch statement with 525 cases executed in 6 clock >>>>> cycles you fucking moronic idiot. >>>> >>>> Your insults do nothing to mend your reputation or make your incorrect >>>> assertions correct. >>>> >>> Well stop being a moron. The only thing incorrect here is your incorrect >>> assumption that I was talking about jump tables. >>> >>> A compiler is free to implement a switch statement anyway it likes. All >>> I was saying that with the worst case scenario of a 525 switch case >>> statement is may be something like 1500 clock cycles which is not really >>> alot of CPU time anyway, even though 525 cases seems like a lot. >>> It may be more it may be less, I don't know how the compiler will >>> implement it and neither do you. You do not the full details of the code >>> , does it have a default statement etc, which compiler is it , blah blah >>> blah. >>> >>> So please stop making inciorrect assumptions that I was talking about >>> jump tables , and trying to start an argument based on the false >>> assumption that you know what a jump table is and I don't. >>> I don't know why you havent learned your lesson from the past , I guess >>> you are just going to keep on arguing and creating arguments until you >>> actually win one. And before you start bringing up history and trying to >>> falsify who had he victorious outcome please remember this: >>> >>> int x = new int[24]; >>> x is a pointer to an array of integers. :) >> >> You said: "You can't have a switch statement with 525 cases executed >> in 6 clock cycles you fucking moronic idiot." (just scroll up). This >> assertion is false and I explained why whilst also introducing you to >> the concept of jump tables (a thankyou would be nice). > > The assertion is true. > The switch statement does not have ordered cases therefore you could > only implement this with a hash table but then you are basically > rewriting the software completely and you no longer have a switch > statement. From an earlier reply of mine that you seemed to have ignored: "For another clue think about the difference between a switch with contiguous case values and non-contiguous case values. *Most* switches have contiguous case values. If you have a switch with 525 non-contiguous case values then you may well need 6x525 clock cycles if again the solution was naive solution (a non-naive solution would be to use binary search on a jump table)." So your assertion remains false and you continue to fail. HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-08-15 22:19 +0100 |
| Message-ID | <dLWdnag7luznENTTnZ2dnUVZ8jidnZ2d@giganews.com> |
| In reply to | #8877 |
On 15/08/2011 22:09, Leigh Johnston wrote:
> On 15/08/2011 20:24, Paul wrote:
>>
>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
>> news:voKdneBY59LDpNTTnZ2dnUVZ8t2dnZ2d@giganews.com...
>>> On 15/08/2011 16:05, Paul wrote:
>>>>
>>>>>>>>> >>>> 525 switch cases seem alot but how long does this take to
>>>>>>>>> >>>> compute,
>>>>>>>>> >>>> assuming the very last case is the one that is true? Probably
>>>>>>>>> not
>>>>>>>>> >>>> very
>>>>>>>>> >>>> long, maybe 3 instructions per conditional test, so it
>>>>>>>>> might be
>>>>>>>>> >>>> around
>>>>>>>>> >>>> 1500 clock cycles or something.
>>>>>>>>>
>>>>>>>>> >>> Only if the compiler was as naive as you (for a clue you
>>>>>>>>> should
>>>>>>>>> >>> learn
>>>>>>>>> >>> about jump tables).
>>>>>>>>>
>>>>>>>>> >> From behind which rock have you crawled?
>>>>>>>>>
>>>>>>>>> > Please explain to us how using a jump table to implement a
>>>>>>>>> switch
>>>>>>>>> > block
>>>>>>>>> > of 525 cases could possibly take 1500 clock cycles.
>>>>>>>>>
>>>>>>>>> I already have explained it, obviosly this is a very rough
>>>>>>>>> estimate
>>>>>>>>
>>>>>>>> --ITYM "wrong estimate"
>>>>>>>>
>>>>>>>> There is no "right" estimate, a quadcore cpu with precaching and
>>>>>>>> all the
>>>>>>>> fancy tech they have nowadays will probably do it alot faster
>>>>>>>> than an
>>>>>>>> ancient AMD cpu.
>>>>>>>>
>>>>>>>> So you are "wrong" to say my estimate was "wrong".
>>>>>>>>
>>>>>>>>> as not
>>>>>>>>> all CPU's are the same. Can you explain how many clock cycles you
>>>>>>>>> think it'd
>>>>>>>>> take?
>>>>>>>>
>>>>>>>> --the number taken is independent of the number of entries in the
>>>>>>>> table
>>>>>>>>
>>>>>>>> -- goto table[i];
>>>>>>>>
>>>>>>>> --we're talking half a dozen instructions and a couple of memory
>>>>>>>> --accesses
>>>>>>>>
>>>>>>>>
>>>>>>>> Start Process:
>>>>>>>> Load reg1 with comparee (Only done once at start)
>>>>>>>>
>>>>>>>> Load reg2 with case option
>>>>>>>> Load reg3 with jump address
>>>>>>>> Jump if reg1and reg2 are equal .
>>>>>>>>
>>>>>>>> repeat above until the condition is met.
>>>>>>>>
>>>>>>>>
>>>>>>>> Why do you need to repeat 6 instructions ?
>>>>>>>> And what are you talking about memeory access? L1 cache? or
>>>>>>>> pipeline
>>>>>>>> cache or prefetched queues?
>>>>>>>> Modern CPUs have everything all prefetched into caches and its a
>>>>>>>> bit
>>>>>>>> more complicated than you seem to understand.
>>>>>>>> You can try to pretend you know more than me about it and I don't
>>>>>>>> really
>>>>>>>> care if you do or don't but when you challenge something I said as
>>>>>>>> wrong
>>>>>>>> and present "your opinion" as right, I'd suggest you get your facts
>>>>>>>> right first and provide some kind of evidence which supports your
>>>>>>>> "claim".
>>>>>>>>
>>>>>>>> Even if your opinion that it was 6x525 clock cycles , for any given
>>>>>>>> CPU,
>>>>>>>> was 100% exact then that would make my estimate close enough to be
>>>>>>>> accurate, because we are talking about cpu speeds in gigahertz now.
>>>>>>>> Please don't claim my estimates are "wrong" without providing some
>>>>>>>> kind
>>>>>>>> of reason other that "because you say so".
>>>>>>>
>>>>>>> His opinion is that it is *just* 6 clock cycles not 6x525 clock
>>>>>>> cycles; your lack of comprehension and naivity is stunning. Again:
>>>>>>> learn about jump tables instead of wasting time displaying a lack of
>>>>>>> knowledge here.
>>>>>>>
>>>>>> You can't have a switch statement with 525 cases executed in 6 clock
>>>>>> cycles you fucking moronic idiot.
>>>>>
>>>>> Your insults do nothing to mend your reputation or make your incorrect
>>>>> assertions correct.
>>>>>
>>>> Well stop being a moron. The only thing incorrect here is your
>>>> incorrect
>>>> assumption that I was talking about jump tables.
>>>>
>>>> A compiler is free to implement a switch statement anyway it likes. All
>>>> I was saying that with the worst case scenario of a 525 switch case
>>>> statement is may be something like 1500 clock cycles which is not
>>>> really
>>>> alot of CPU time anyway, even though 525 cases seems like a lot.
>>>> It may be more it may be less, I don't know how the compiler will
>>>> implement it and neither do you. You do not the full details of the
>>>> code
>>>> , does it have a default statement etc, which compiler is it , blah
>>>> blah
>>>> blah.
>>>>
>>>> So please stop making inciorrect assumptions that I was talking about
>>>> jump tables , and trying to start an argument based on the false
>>>> assumption that you know what a jump table is and I don't.
>>>> I don't know why you havent learned your lesson from the past , I guess
>>>> you are just going to keep on arguing and creating arguments until you
>>>> actually win one. And before you start bringing up history and
>>>> trying to
>>>> falsify who had he victorious outcome please remember this:
>>>>
>>>> int x = new int[24];
>>>> x is a pointer to an array of integers. :)
>>>
>>> You said: "You can't have a switch statement with 525 cases executed
>>> in 6 clock cycles you fucking moronic idiot." (just scroll up). This
>>> assertion is false and I explained why whilst also introducing you to
>>> the concept of jump tables (a thankyou would be nice).
>>
>> The assertion is true.
>> The switch statement does not have ordered cases therefore you could
>> only implement this with a hash table but then you are basically
>> rewriting the software completely and you no longer have a switch
>> statement.
>
> From an earlier reply of mine that you seemed to have ignored:
>
> "For another clue think about the difference between a switch with
> contiguous case values and non-contiguous case values. *Most* switches
> have contiguous case values. If you have a switch with 525
> non-contiguous case values then you may well need 6x525 clock cycles if
> again the solution was naive solution (a non-naive solution would be to
> use binary search on a jump table)."
>
> So your assertion remains false and you continue to fail.
>
> HTH.
>
Funnily enough I have implemented switch statements in my own
programming language using the binary search method which actually
allowed me to supported mixed case types (other than basic integers):
for (int i = 1; i < 4; ++i)
{
var v;
switch(i)
{
case 1:
v = 123;
break;
case 2:
v = "abc";
break;
case 3:
v = 1.01;
break;
}
switch(v)
{
case 123L:
print_line(v + " is an integer");
break;
case "abc":
print_line(v + " is a string");
break;
default:
print_line(v + " is a neither an integer nor a string");
break;
}
switch(v)
{
case 123:
case "abc":
print_line(v + " is an integer or a string");
break;
default:
print_line(v + " is a neither an integer nor a string");
break;
}
}
Although off-topic I thought it quite interesting and cromulent to the
discussion.
/Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-16 03:10 +0100 |
| Message-ID | <j2cjib$1is5$1@adenine.netfront.net> |
| In reply to | #8878 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:dLWdnag7luznENTTnZ2dnUVZ8jidnZ2d@giganews.com...
> On 15/08/2011 22:09, Leigh Johnston wrote:
>> On 15/08/2011 20:24, Paul wrote:
>>>
>>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
>>> news:voKdneBY59LDpNTTnZ2dnUVZ8t2dnZ2d@giganews.com...
>>>> On 15/08/2011 16:05, Paul wrote:
>>>>>
>>>>>>>>>> >>>> 525 switch cases seem alot but how long does this take to
>>>>>>>>>> >>>> compute,
>>>>>>>>>> >>>> assuming the very last case is the one that is true?
>>>>>>>>>> >>>> Probably
>>>>>>>>>> not
>>>>>>>>>> >>>> very
>>>>>>>>>> >>>> long, maybe 3 instructions per conditional test, so it
>>>>>>>>>> might be
>>>>>>>>>> >>>> around
>>>>>>>>>> >>>> 1500 clock cycles or something.
>>>>>>>>>>
>>>>>>>>>> >>> Only if the compiler was as naive as you (for a clue you
>>>>>>>>>> should
>>>>>>>>>> >>> learn
>>>>>>>>>> >>> about jump tables).
>>>>>>>>>>
>>>>>>>>>> >> From behind which rock have you crawled?
>>>>>>>>>>
>>>>>>>>>> > Please explain to us how using a jump table to implement a
>>>>>>>>>> switch
>>>>>>>>>> > block
>>>>>>>>>> > of 525 cases could possibly take 1500 clock cycles.
>>>>>>>>>>
>>>>>>>>>> I already have explained it, obviosly this is a very rough
>>>>>>>>>> estimate
>>>>>>>>>
>>>>>>>>> --ITYM "wrong estimate"
>>>>>>>>>
>>>>>>>>> There is no "right" estimate, a quadcore cpu with precaching and
>>>>>>>>> all the
>>>>>>>>> fancy tech they have nowadays will probably do it alot faster
>>>>>>>>> than an
>>>>>>>>> ancient AMD cpu.
>>>>>>>>>
>>>>>>>>> So you are "wrong" to say my estimate was "wrong".
>>>>>>>>>
>>>>>>>>>> as not
>>>>>>>>>> all CPU's are the same. Can you explain how many clock cycles you
>>>>>>>>>> think it'd
>>>>>>>>>> take?
>>>>>>>>>
>>>>>>>>> --the number taken is independent of the number of entries in the
>>>>>>>>> table
>>>>>>>>>
>>>>>>>>> -- goto table[i];
>>>>>>>>>
>>>>>>>>> --we're talking half a dozen instructions and a couple of memory
>>>>>>>>> --accesses
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Start Process:
>>>>>>>>> Load reg1 with comparee (Only done once at start)
>>>>>>>>>
>>>>>>>>> Load reg2 with case option
>>>>>>>>> Load reg3 with jump address
>>>>>>>>> Jump if reg1and reg2 are equal .
>>>>>>>>>
>>>>>>>>> repeat above until the condition is met.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Why do you need to repeat 6 instructions ?
>>>>>>>>> And what are you talking about memeory access? L1 cache? or
>>>>>>>>> pipeline
>>>>>>>>> cache or prefetched queues?
>>>>>>>>> Modern CPUs have everything all prefetched into caches and its a
>>>>>>>>> bit
>>>>>>>>> more complicated than you seem to understand.
>>>>>>>>> You can try to pretend you know more than me about it and I don't
>>>>>>>>> really
>>>>>>>>> care if you do or don't but when you challenge something I said as
>>>>>>>>> wrong
>>>>>>>>> and present "your opinion" as right, I'd suggest you get your
>>>>>>>>> facts
>>>>>>>>> right first and provide some kind of evidence which supports your
>>>>>>>>> "claim".
>>>>>>>>>
>>>>>>>>> Even if your opinion that it was 6x525 clock cycles , for any
>>>>>>>>> given
>>>>>>>>> CPU,
>>>>>>>>> was 100% exact then that would make my estimate close enough to be
>>>>>>>>> accurate, because we are talking about cpu speeds in gigahertz
>>>>>>>>> now.
>>>>>>>>> Please don't claim my estimates are "wrong" without providing some
>>>>>>>>> kind
>>>>>>>>> of reason other that "because you say so".
>>>>>>>>
>>>>>>>> His opinion is that it is *just* 6 clock cycles not 6x525 clock
>>>>>>>> cycles; your lack of comprehension and naivity is stunning. Again:
>>>>>>>> learn about jump tables instead of wasting time displaying a lack
>>>>>>>> of
>>>>>>>> knowledge here.
>>>>>>>>
>>>>>>> You can't have a switch statement with 525 cases executed in 6 clock
>>>>>>> cycles you fucking moronic idiot.
>>>>>>
>>>>>> Your insults do nothing to mend your reputation or make your
>>>>>> incorrect
>>>>>> assertions correct.
>>>>>>
>>>>> Well stop being a moron. The only thing incorrect here is your
>>>>> incorrect
>>>>> assumption that I was talking about jump tables.
>>>>>
>>>>> A compiler is free to implement a switch statement anyway it likes.
>>>>> All
>>>>> I was saying that with the worst case scenario of a 525 switch case
>>>>> statement is may be something like 1500 clock cycles which is not
>>>>> really
>>>>> alot of CPU time anyway, even though 525 cases seems like a lot.
>>>>> It may be more it may be less, I don't know how the compiler will
>>>>> implement it and neither do you. You do not the full details of the
>>>>> code
>>>>> , does it have a default statement etc, which compiler is it , blah
>>>>> blah
>>>>> blah.
>>>>>
>>>>> So please stop making inciorrect assumptions that I was talking about
>>>>> jump tables , and trying to start an argument based on the false
>>>>> assumption that you know what a jump table is and I don't.
>>>>> I don't know why you havent learned your lesson from the past , I
>>>>> guess
>>>>> you are just going to keep on arguing and creating arguments until you
>>>>> actually win one. And before you start bringing up history and
>>>>> trying to
>>>>> falsify who had he victorious outcome please remember this:
>>>>>
>>>>> int x = new int[24];
>>>>> x is a pointer to an array of integers. :)
>>>>
>>>> You said: "You can't have a switch statement with 525 cases executed
>>>> in 6 clock cycles you fucking moronic idiot." (just scroll up). This
>>>> assertion is false and I explained why whilst also introducing you to
>>>> the concept of jump tables (a thankyou would be nice).
>>>
>>> The assertion is true.
>>> The switch statement does not have ordered cases therefore you could
>>> only implement this with a hash table but then you are basically
>>> rewriting the software completely and you no longer have a switch
>>> statement.
>>
>> From an earlier reply of mine that you seemed to have ignored:
>>
>> "For another clue think about the difference between a switch with
>> contiguous case values and non-contiguous case values. *Most* switches
>> have contiguous case values. If you have a switch with 525
>> non-contiguous case values then you may well need 6x525 clock cycles if
>> again the solution was naive solution (a non-naive solution would be to
>> use binary search on a jump table)."
>>
>> So your assertion remains false and you continue to fail.
>>
>> HTH.
>>
>
> Funnily enough I have implemented switch statements in my own programming
> language using the binary search method which actually allowed me to
> supported mixed case types (other than basic integers):
omg , your language?
What do you call this language you are creating/have created?
>
> for (int i = 1; i < 4; ++i)
> {
> var v;
> switch(i)
> {
> case 1:
> v = 123;
> break;
> case 2:
> v = "abc";
> break;
> case 3:
> v = 1.01;
> break;
> }
> switch(v)
> {
> case 123L:
> print_line(v + " is an integer");
> break;
> case "abc":
> print_line(v + " is a string");
> break;
> default:
> print_line(v + " is a neither an integer nor a string");
> break;
> }
> switch(v)
> {
> case 123:
> case "abc":
> print_line(v + " is an integer or a string");
> break;
> default:
> print_line(v + " is a neither an integer nor a string");
> break;
> }
> }
>
> Although off-topic I thought it quite interesting and cromulent to the
> discussion.
>
Is the above code your language or C++?
--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-08-16 13:08 +0100 |
| Message-ID | <AKKdnb0LyJI0wNfTnZ2dnUVZ8vsAAAAA@giganews.com> |
| In reply to | #8884 |
On 16/08/2011 03:10, Paul wrote:
>
> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
> news:dLWdnag7luznENTTnZ2dnUVZ8jidnZ2d@giganews.com...
>> On 15/08/2011 22:09, Leigh Johnston wrote:
>>> On 15/08/2011 20:24, Paul wrote:
>>>>
>>>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
>>>> news:voKdneBY59LDpNTTnZ2dnUVZ8t2dnZ2d@giganews.com...
>>>>> On 15/08/2011 16:05, Paul wrote:
>>>>>>
>>>>>>>>>>> >>>> 525 switch cases seem alot but how long does this take to
>>>>>>>>>>> >>>> compute,
>>>>>>>>>>> >>>> assuming the very last case is the one that is true?
>>>>>>>>>>> >>>> Probably
>>>>>>>>>>> not
>>>>>>>>>>> >>>> very
>>>>>>>>>>> >>>> long, maybe 3 instructions per conditional test, so it
>>>>>>>>>>> might be
>>>>>>>>>>> >>>> around
>>>>>>>>>>> >>>> 1500 clock cycles or something.
>>>>>>>>>>>
>>>>>>>>>>> >>> Only if the compiler was as naive as you (for a clue you
>>>>>>>>>>> should
>>>>>>>>>>> >>> learn
>>>>>>>>>>> >>> about jump tables).
>>>>>>>>>>>
>>>>>>>>>>> >> From behind which rock have you crawled?
>>>>>>>>>>>
>>>>>>>>>>> > Please explain to us how using a jump table to implement a
>>>>>>>>>>> switch
>>>>>>>>>>> > block
>>>>>>>>>>> > of 525 cases could possibly take 1500 clock cycles.
>>>>>>>>>>>
>>>>>>>>>>> I already have explained it, obviosly this is a very rough
>>>>>>>>>>> estimate
>>>>>>>>>>
>>>>>>>>>> --ITYM "wrong estimate"
>>>>>>>>>>
>>>>>>>>>> There is no "right" estimate, a quadcore cpu with precaching and
>>>>>>>>>> all the
>>>>>>>>>> fancy tech they have nowadays will probably do it alot faster
>>>>>>>>>> than an
>>>>>>>>>> ancient AMD cpu.
>>>>>>>>>>
>>>>>>>>>> So you are "wrong" to say my estimate was "wrong".
>>>>>>>>>>
>>>>>>>>>>> as not
>>>>>>>>>>> all CPU's are the same. Can you explain how many clock cycles
>>>>>>>>>>> you
>>>>>>>>>>> think it'd
>>>>>>>>>>> take?
>>>>>>>>>>
>>>>>>>>>> --the number taken is independent of the number of entries in the
>>>>>>>>>> table
>>>>>>>>>>
>>>>>>>>>> -- goto table[i];
>>>>>>>>>>
>>>>>>>>>> --we're talking half a dozen instructions and a couple of memory
>>>>>>>>>> --accesses
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Start Process:
>>>>>>>>>> Load reg1 with comparee (Only done once at start)
>>>>>>>>>>
>>>>>>>>>> Load reg2 with case option
>>>>>>>>>> Load reg3 with jump address
>>>>>>>>>> Jump if reg1and reg2 are equal .
>>>>>>>>>>
>>>>>>>>>> repeat above until the condition is met.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Why do you need to repeat 6 instructions ?
>>>>>>>>>> And what are you talking about memeory access? L1 cache? or
>>>>>>>>>> pipeline
>>>>>>>>>> cache or prefetched queues?
>>>>>>>>>> Modern CPUs have everything all prefetched into caches and its a
>>>>>>>>>> bit
>>>>>>>>>> more complicated than you seem to understand.
>>>>>>>>>> You can try to pretend you know more than me about it and I don't
>>>>>>>>>> really
>>>>>>>>>> care if you do or don't but when you challenge something I
>>>>>>>>>> said as
>>>>>>>>>> wrong
>>>>>>>>>> and present "your opinion" as right, I'd suggest you get your
>>>>>>>>>> facts
>>>>>>>>>> right first and provide some kind of evidence which supports your
>>>>>>>>>> "claim".
>>>>>>>>>>
>>>>>>>>>> Even if your opinion that it was 6x525 clock cycles , for any
>>>>>>>>>> given
>>>>>>>>>> CPU,
>>>>>>>>>> was 100% exact then that would make my estimate close enough
>>>>>>>>>> to be
>>>>>>>>>> accurate, because we are talking about cpu speeds in gigahertz
>>>>>>>>>> now.
>>>>>>>>>> Please don't claim my estimates are "wrong" without providing
>>>>>>>>>> some
>>>>>>>>>> kind
>>>>>>>>>> of reason other that "because you say so".
>>>>>>>>>
>>>>>>>>> His opinion is that it is *just* 6 clock cycles not 6x525 clock
>>>>>>>>> cycles; your lack of comprehension and naivity is stunning. Again:
>>>>>>>>> learn about jump tables instead of wasting time displaying a
>>>>>>>>> lack of
>>>>>>>>> knowledge here.
>>>>>>>>>
>>>>>>>> You can't have a switch statement with 525 cases executed in 6
>>>>>>>> clock
>>>>>>>> cycles you fucking moronic idiot.
>>>>>>>
>>>>>>> Your insults do nothing to mend your reputation or make your
>>>>>>> incorrect
>>>>>>> assertions correct.
>>>>>>>
>>>>>> Well stop being a moron. The only thing incorrect here is your
>>>>>> incorrect
>>>>>> assumption that I was talking about jump tables.
>>>>>>
>>>>>> A compiler is free to implement a switch statement anyway it
>>>>>> likes. All
>>>>>> I was saying that with the worst case scenario of a 525 switch case
>>>>>> statement is may be something like 1500 clock cycles which is not
>>>>>> really
>>>>>> alot of CPU time anyway, even though 525 cases seems like a lot.
>>>>>> It may be more it may be less, I don't know how the compiler will
>>>>>> implement it and neither do you. You do not the full details of the
>>>>>> code
>>>>>> , does it have a default statement etc, which compiler is it , blah
>>>>>> blah
>>>>>> blah.
>>>>>>
>>>>>> So please stop making inciorrect assumptions that I was talking about
>>>>>> jump tables , and trying to start an argument based on the false
>>>>>> assumption that you know what a jump table is and I don't.
>>>>>> I don't know why you havent learned your lesson from the past , I
>>>>>> guess
>>>>>> you are just going to keep on arguing and creating arguments until
>>>>>> you
>>>>>> actually win one. And before you start bringing up history and
>>>>>> trying to
>>>>>> falsify who had he victorious outcome please remember this:
>>>>>>
>>>>>> int x = new int[24];
>>>>>> x is a pointer to an array of integers. :)
>>>>>
>>>>> You said: "You can't have a switch statement with 525 cases executed
>>>>> in 6 clock cycles you fucking moronic idiot." (just scroll up). This
>>>>> assertion is false and I explained why whilst also introducing you to
>>>>> the concept of jump tables (a thankyou would be nice).
>>>>
>>>> The assertion is true.
>>>> The switch statement does not have ordered cases therefore you could
>>>> only implement this with a hash table but then you are basically
>>>> rewriting the software completely and you no longer have a switch
>>>> statement.
>>>
>>> From an earlier reply of mine that you seemed to have ignored:
>>>
>>> "For another clue think about the difference between a switch with
>>> contiguous case values and non-contiguous case values. *Most* switches
>>> have contiguous case values. If you have a switch with 525
>>> non-contiguous case values then you may well need 6x525 clock cycles if
>>> again the solution was naive solution (a non-naive solution would be to
>>> use binary search on a jump table)."
>>>
>>> So your assertion remains false and you continue to fail.
>>>
>>> HTH.
>>>
>>
>> Funnily enough I have implemented switch statements in my own
>> programming language using the binary search method which actually
>> allowed me to supported mixed case types (other than basic integers):
>
> omg , your language?
> What do you call this language you are creating/have created?
CAWScript; http://www.clicksandwhistles.com/CAWScript.htm
>>
>> for (int i = 1; i < 4; ++i)
>> {
>> var v;
>> switch(i)
>> {
>> case 1:
>> v = 123;
>> break;
>> case 2:
>> v = "abc";
>> break;
>> case 3:
>> v = 1.01;
>> break;
>> }
>> switch(v)
>> {
>> case 123L:
>> print_line(v + " is an integer");
>> break;
>> case "abc":
>> print_line(v + " is a string");
>> break;
>> default:
>> print_line(v + " is a neither an integer nor a string");
>> break;
>> }
>> switch(v)
>> {
>> case 123:
>> case "abc":
>> print_line(v + " is an integer or a string");
>> break;
>> default:
>> print_line(v + " is a neither an integer nor a string");
>> break;
>> }
>> }
>>
>> Although off-topic I thought it quite interesting and cromulent to the
>> discussion.
>>
> Is the above code your language or C++?
My language obviously.
/Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-16 14:01 +0100 |
| Message-ID | <j2dpo2$3gc$1@adenine.netfront.net> |
| In reply to | #8914 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:AKKdnb0LyJI0wNfTnZ2dnUVZ8vsAAAAA@giganews.com...
> On 16/08/2011 03:10, Paul wrote:
>>
>>>>>>>>>>>> >>>> 525 switch cases seem alot but how long does this take to
>>>>>>>>>>>> >>>> compute,
>>>>>>>>>>>> >>>> assuming the very last case is the one that is true?
>>>>>>>>>>>> >>>> Probably
>>>>>>>>>>>> not
>>>>>>>>>>>> >>>> very
>>>>>>>>>>>> >>>> long, maybe 3 instructions per conditional test, so it
>>>>>>>>>>>> might be
>>>>>>>>>>>> >>>> around
>>>>>>>>>>>> >>>> 1500 clock cycles or something.
>>>>>>>>>>>>
>>>>>>>>>>>> >>> Only if the compiler was as naive as you (for a clue you
>>>>>>>>>>>> should
>>>>>>>>>>>> >>> learn
>>>>>>>>>>>> >>> about jump tables).
>>>>>>>>>>>>
>>>>>>>>>>>> >> From behind which rock have you crawled?
>>>>>>>>>>>>
>>>>>>>>>>>> > Please explain to us how using a jump table to implement a
>>>>>>>>>>>> switch
>>>>>>>>>>>> > block
>>>>>>>>>>>> > of 525 cases could possibly take 1500 clock cycles.
>>>>>>>>>>>>
>>>>>>>>>>>> I already have explained it, obviosly this is a very rough
>>>>>>>>>>>> estimate
>>>>>>>>>>>
>>>>>>>>>>> --ITYM "wrong estimate"
>>>>>>>>>>>
>>>>>>>>>>> There is no "right" estimate, a quadcore cpu with precaching and
>>>>>>>>>>> all the
>>>>>>>>>>> fancy tech they have nowadays will probably do it alot faster
>>>>>>>>>>> than an
>>>>>>>>>>> ancient AMD cpu.
>>>>>>>>>>>
>>>>>>>>>>> So you are "wrong" to say my estimate was "wrong".
>>>>>>>>>>>
>>>>>>>>>>>> as not
>>>>>>>>>>>> all CPU's are the same. Can you explain how many clock cycles
>>>>>>>>>>>> you
>>>>>>>>>>>> think it'd
>>>>>>>>>>>> take?
>>>>>>>>>>>
>>>>>>>>>>> --the number taken is independent of the number of entries in
>>>>>>>>>>> the
>>>>>>>>>>> table
>>>>>>>>>>>
>>>>>>>>>>> -- goto table[i];
>>>>>>>>>>>
>>>>>>>>>>> --we're talking half a dozen instructions and a couple of memory
>>>>>>>>>>> --accesses
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Start Process:
>>>>>>>>>>> Load reg1 with comparee (Only done once at start)
>>>>>>>>>>>
>>>>>>>>>>> Load reg2 with case option
>>>>>>>>>>> Load reg3 with jump address
>>>>>>>>>>> Jump if reg1and reg2 are equal .
>>>>>>>>>>>
>>>>>>>>>>> repeat above until the condition is met.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Why do you need to repeat 6 instructions ?
>>>>>>>>>>> And what are you talking about memeory access? L1 cache? or
>>>>>>>>>>> pipeline
>>>>>>>>>>> cache or prefetched queues?
>>>>>>>>>>> Modern CPUs have everything all prefetched into caches and its a
>>>>>>>>>>> bit
>>>>>>>>>>> more complicated than you seem to understand.
>>>>>>>>>>> You can try to pretend you know more than me about it and I
>>>>>>>>>>> don't
>>>>>>>>>>> really
>>>>>>>>>>> care if you do or don't but when you challenge something I
>>>>>>>>>>> said as
>>>>>>>>>>> wrong
>>>>>>>>>>> and present "your opinion" as right, I'd suggest you get your
>>>>>>>>>>> facts
>>>>>>>>>>> right first and provide some kind of evidence which supports
>>>>>>>>>>> your
>>>>>>>>>>> "claim".
>>>>>>>>>>>
>>>>>>>>>>> Even if your opinion that it was 6x525 clock cycles , for any
>>>>>>>>>>> given
>>>>>>>>>>> CPU,
>>>>>>>>>>> was 100% exact then that would make my estimate close enough
>>>>>>>>>>> to be
>>>>>>>>>>> accurate, because we are talking about cpu speeds in gigahertz
>>>>>>>>>>> now.
>>>>>>>>>>> Please don't claim my estimates are "wrong" without providing
>>>>>>>>>>> some
>>>>>>>>>>> kind
>>>>>>>>>>> of reason other that "because you say so".
>>>>>>>>>>
>>>>>>>>>> His opinion is that it is *just* 6 clock cycles not 6x525 clock
>>>>>>>>>> cycles; your lack of comprehension and naivity is stunning.
>>>>>>>>>> Again:
>>>>>>>>>> learn about jump tables instead of wasting time displaying a
>>>>>>>>>> lack of
>>>>>>>>>> knowledge here.
>>>>>>>>>>
>>>>>>>>> You can't have a switch statement with 525 cases executed in 6
>>>>>>>>> clock
>>>>>>>>> cycles you fucking moronic idiot.
>>>>>>>>
>>>>>>>> Your insults do nothing to mend your reputation or make your
>>>>>>>> incorrect
>>>>>>>> assertions correct.
>>>>>>>>
>>>>>>> Well stop being a moron. The only thing incorrect here is your
>>>>>>> incorrect
>>>>>>> assumption that I was talking about jump tables.
>>>>>>>
>>>>>>> A compiler is free to implement a switch statement anyway it
>>>>>>> likes. All
>>>>>>> I was saying that with the worst case scenario of a 525 switch case
>>>>>>> statement is may be something like 1500 clock cycles which is not
>>>>>>> really
>>>>>>> alot of CPU time anyway, even though 525 cases seems like a lot.
>>>>>>> It may be more it may be less, I don't know how the compiler will
>>>>>>> implement it and neither do you. You do not the full details of the
>>>>>>> code
>>>>>>> , does it have a default statement etc, which compiler is it , blah
>>>>>>> blah
>>>>>>> blah.
>>>>>>>
>>>>>>> So please stop making inciorrect assumptions that I was talking
>>>>>>> about
>>>>>>> jump tables , and trying to start an argument based on the false
>>>>>>> assumption that you know what a jump table is and I don't.
>>>>>>> I don't know why you havent learned your lesson from the past , I
>>>>>>> guess
>>>>>>> you are just going to keep on arguing and creating arguments until
>>>>>>> you
>>>>>>> actually win one. And before you start bringing up history and
>>>>>>> trying to
>>>>>>> falsify who had he victorious outcome please remember this:
>>>>>>>
>>>>>>> int x = new int[24];
>>>>>>> x is a pointer to an array of integers. :)
>>>>>>
>>>>>> You said: "You can't have a switch statement with 525 cases executed
>>>>>> in 6 clock cycles you fucking moronic idiot." (just scroll up). This
>>>>>> assertion is false and I explained why whilst also introducing you to
>>>>>> the concept of jump tables (a thankyou would be nice).
>>>>>
>>>>> The assertion is true.
>>>>> The switch statement does not have ordered cases therefore you could
>>>>> only implement this with a hash table but then you are basically
>>>>> rewriting the software completely and you no longer have a switch
>>>>> statement.
>>>>
>>>> From an earlier reply of mine that you seemed to have ignored:
>>>>
>>>> "For another clue think about the difference between a switch with
>>>> contiguous case values and non-contiguous case values. *Most* switches
>>>> have contiguous case values. If you have a switch with 525
>>>> non-contiguous case values then you may well need 6x525 clock cycles if
>>>> again the solution was naive solution (a non-naive solution would be to
>>>> use binary search on a jump table)."
>>>>
>>>> So your assertion remains false and you continue to fail.
>>>>
>>>> HTH.
>>>>
>>>
>>> Funnily enough I have implemented switch statements in my own
>>> programming language using the binary search method which actually
>>> allowed me to supported mixed case types (other than basic integers):
>>
>> omg , your language?
>> What do you call this language you are creating/have created?
>
> CAWScript; http://www.clicksandwhistles.com/CAWScript.htm
>
>>>
>>> for (int i = 1; i < 4; ++i)
>>> {
>>> var v;
>>> switch(i)
>>> {
>>> case 1:
>>> v = 123;
>>> break;
>>> case 2:
>>> v = "abc";
>>> break;
>>> case 3:
>>> v = 1.01;
>>> break;
>>> }
>>> switch(v)
>>> {
>>> case 123L:
>>> print_line(v + " is an integer");
>>> break;
>>> case "abc":
>>> print_line(v + " is a string");
>>> break;
>>> default:
>>> print_line(v + " is a neither an integer nor a string");
>>> break;
>>> }
>>> switch(v)
>>> {
>>> case 123:
>>> case "abc":
>>> print_line(v + " is an integer or a string");
>>> break;
>>> default:
>>> print_line(v + " is a neither an integer nor a string");
>>> break;
>>> }
>>> }
>>>
>>> Although off-topic I thought it quite interesting and cromulent to the
>>> discussion.
>>>
>> Is the above code your language or C++?
>
> My language obviously.
>
So this whole excercise has just been one big excuse to advertise your
language?
--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-08-16 14:10 +0100 |
| Message-ID | <TvqdnScKzbrd8dfTnZ2dnUVZ8nSdnZ2d@giganews.com> |
| In reply to | #8919 |
On 16/08/2011 14:01, Paul wrote: [snip] >>>> >>>> Although off-topic I thought it quite interesting and cromulent to the >>>> discussion. >>>> >>> Is the above code your language or C++? >> >> My language obviously. >> > So this whole excercise has just been one big excuse to advertise your > language? Your thought processes are wrong; see a psychiatrist. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-16 03:07 +0100 |
| Message-ID | <j2cje7$1ili$1@adenine.netfront.net> |
| In reply to | #8877 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:9tCdnZfs3uFkF9TTnZ2dnUVZ8qmdnZ2d@giganews.com... > On 15/08/2011 20:24, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:voKdneBY59LDpNTTnZ2dnUVZ8t2dnZ2d@giganews.com... >>> On 15/08/2011 16:05, Paul wrote: >>>> >>>>>>>>> >>>> 525 switch cases seem alot but how long does this take to >>>>>>>>> >>>> compute, >>>>>>>>> >>>> assuming the very last case is the one that is true? Probably >>>>>>>>> not >>>>>>>>> >>>> very >>>>>>>>> >>>> long, maybe 3 instructions per conditional test, so it >>>>>>>>> might be >>>>>>>>> >>>> around >>>>>>>>> >>>> 1500 clock cycles or something. >>>>>>>>> >>>>>>>>> >>> Only if the compiler was as naive as you (for a clue you >>>>>>>>> >>> should >>>>>>>>> >>> learn >>>>>>>>> >>> about jump tables). >>>>>>>>> >>>>>>>>> >> From behind which rock have you crawled? >>>>>>>>> >>>>>>>>> > Please explain to us how using a jump table to implement a >>>>>>>>> > switch >>>>>>>>> > block >>>>>>>>> > of 525 cases could possibly take 1500 clock cycles. >>>>>>>>> >>>>>>>>> I already have explained it, obviosly this is a very rough >>>>>>>>> estimate >>>>>>>> >>>>>>>> --ITYM "wrong estimate" >>>>>>>> >>>>>>>> There is no "right" estimate, a quadcore cpu with precaching and >>>>>>>> all the >>>>>>>> fancy tech they have nowadays will probably do it alot faster >>>>>>>> than an >>>>>>>> ancient AMD cpu. >>>>>>>> >>>>>>>> So you are "wrong" to say my estimate was "wrong". >>>>>>>> >>>>>>>>> as not >>>>>>>>> all CPU's are the same. Can you explain how many clock cycles you >>>>>>>>> think it'd >>>>>>>>> take? >>>>>>>> >>>>>>>> --the number taken is independent of the number of entries in the >>>>>>>> table >>>>>>>> >>>>>>>> -- goto table[i]; >>>>>>>> >>>>>>>> --we're talking half a dozen instructions and a couple of memory >>>>>>>> --accesses >>>>>>>> >>>>>>>> >>>>>>>> Start Process: >>>>>>>> Load reg1 with comparee (Only done once at start) >>>>>>>> >>>>>>>> Load reg2 with case option >>>>>>>> Load reg3 with jump address >>>>>>>> Jump if reg1and reg2 are equal . >>>>>>>> >>>>>>>> repeat above until the condition is met. >>>>>>>> >>>>>>>> >>>>>>>> Why do you need to repeat 6 instructions ? >>>>>>>> And what are you talking about memeory access? L1 cache? or >>>>>>>> pipeline >>>>>>>> cache or prefetched queues? >>>>>>>> Modern CPUs have everything all prefetched into caches and its a >>>>>>>> bit >>>>>>>> more complicated than you seem to understand. >>>>>>>> You can try to pretend you know more than me about it and I don't >>>>>>>> really >>>>>>>> care if you do or don't but when you challenge something I said as >>>>>>>> wrong >>>>>>>> and present "your opinion" as right, I'd suggest you get your facts >>>>>>>> right first and provide some kind of evidence which supports your >>>>>>>> "claim". >>>>>>>> >>>>>>>> Even if your opinion that it was 6x525 clock cycles , for any given >>>>>>>> CPU, >>>>>>>> was 100% exact then that would make my estimate close enough to be >>>>>>>> accurate, because we are talking about cpu speeds in gigahertz now. >>>>>>>> Please don't claim my estimates are "wrong" without providing some >>>>>>>> kind >>>>>>>> of reason other that "because you say so". >>>>>>> >>>>>>> His opinion is that it is *just* 6 clock cycles not 6x525 clock >>>>>>> cycles; your lack of comprehension and naivity is stunning. Again: >>>>>>> learn about jump tables instead of wasting time displaying a lack of >>>>>>> knowledge here. >>>>>>> >>>>>> You can't have a switch statement with 525 cases executed in 6 clock >>>>>> cycles you fucking moronic idiot. >>>>> >>>>> Your insults do nothing to mend your reputation or make your incorrect >>>>> assertions correct. >>>>> >>>> Well stop being a moron. The only thing incorrect here is your >>>> incorrect >>>> assumption that I was talking about jump tables. >>>> >>>> A compiler is free to implement a switch statement anyway it likes. All >>>> I was saying that with the worst case scenario of a 525 switch case >>>> statement is may be something like 1500 clock cycles which is not >>>> really >>>> alot of CPU time anyway, even though 525 cases seems like a lot. >>>> It may be more it may be less, I don't know how the compiler will >>>> implement it and neither do you. You do not the full details of the >>>> code >>>> , does it have a default statement etc, which compiler is it , blah >>>> blah >>>> blah. >>>> >>>> So please stop making inciorrect assumptions that I was talking about >>>> jump tables , and trying to start an argument based on the false >>>> assumption that you know what a jump table is and I don't. >>>> I don't know why you havent learned your lesson from the past , I guess >>>> you are just going to keep on arguing and creating arguments until you >>>> actually win one. And before you start bringing up history and trying >>>> to >>>> falsify who had he victorious outcome please remember this: >>>> >>>> int x = new int[24]; >>>> x is a pointer to an array of integers. :) >>> >>> You said: "You can't have a switch statement with 525 cases executed >>> in 6 clock cycles you fucking moronic idiot." (just scroll up). This >>> assertion is false and I explained why whilst also introducing you to >>> the concept of jump tables (a thankyou would be nice). >> >> The assertion is true. >> The switch statement does not have ordered cases therefore you could >> only implement this with a hash table but then you are basically >> rewriting the software completely and you no longer have a switch >> statement. > > From an earlier reply of mine that you seemed to have ignored: > > "For another clue think about the difference between a switch with > contiguous case values and non-contiguous case values. *Most* switches > have contiguous case values. If you have a switch with 525 non-contiguous > case values then you may well need 6x525 clock cycles if again the > solution was naive solution (a non-naive solution would be to use binary > search on a jump table)." From where to you obtain the info that most switches have contiguous cases? This switch does not as the OP said the cases were unordered. I'm not too sure what you mean by a binary search on a jump table, but nonethless my original point was that even with the worst case scenario where every case was checked it's stilll not a great deal having 525 conditions to check, with todays CPU's even though it may seem big in your source code > > So your assertion remains false and you continue to fail. > Exactly what assertion is false? I was simply suggesting that 525 cases may not be as bad as it seems. You attacked me with accusations of not knowing what a jump table was etc for this , when I wasn't even considering a jump table. --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-08-16 13:05 +0100 |
| Message-ID | <AKKdnYILyJKxwNfTnZ2dnUVZ8vudnZ2d@giganews.com> |
| In reply to | #8883 |
On 16/08/2011 03:07, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:9tCdnZfs3uFkF9TTnZ2dnUVZ8qmdnZ2d@giganews.com... [snip] >> From an earlier reply of mine that you seemed to have ignored: >> >> "For another clue think about the difference between a switch with >> contiguous case values and non-contiguous case values. *Most* switches >> have contiguous case values. If you have a switch with 525 >> non-contiguous case values then you may well need 6x525 clock cycles >> if again the solution was naive solution (a non-naive solution would >> be to use binary search on a jump table)." > > From where to you obtain the info that most switches have contiguous > cases? > This switch does not as the OP said the cases were unordered. > > I'm not too sure what you mean by a binary search on a jump table, but > nonethless my original point was that even with the worst case scenario > where every case was checked it's stilll not a great deal having 525 > conditions to check, with todays CPU's even though it may seem big in > your source code Do a google for: "switch statement" "binary search" sparse cases [snip] /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-16 13:57 +0100 |
| Message-ID | <j2dpft$30b$1@adenine.netfront.net> |
| In reply to | #8913 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:AKKdnYILyJKxwNfTnZ2dnUVZ8vudnZ2d@giganews.com... > On 16/08/2011 03:07, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:9tCdnZfs3uFkF9TTnZ2dnUVZ8qmdnZ2d@giganews.com... > > [snip] > >>> From an earlier reply of mine that you seemed to have ignored: >>> >>> "For another clue think about the difference between a switch with >>> contiguous case values and non-contiguous case values. *Most* switches >>> have contiguous case values. If you have a switch with 525 >>> non-contiguous case values then you may well need 6x525 clock cycles >>> if again the solution was naive solution (a non-naive solution would >>> be to use binary search on a jump table)." >> >> From where to you obtain the info that most switches have contiguous >> cases? >> This switch does not as the OP said the cases were unordered. >> >> I'm not too sure what you mean by a binary search on a jump table, but >> nonethless my original point was that even with the worst case scenario >> where every case was checked it's stilll not a great deal having 525 >> conditions to check, with todays CPU's even though it may seem big in >> your source code > > Do a google for: "switch statement" "binary search" sparse cases > I'm pretty sure I would begin reading and it say to myslef .."oh yes it's just that". But what is all the fuss about. What exactly are you trying to say now, are you still trying to suggest that I do not know what a jump table is? Which was your original line of attack. --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-08-16 14:07 +0100 |
| Message-ID | <TvqdnSQKzboy9tfTnZ2dnUVZ8nSdnZ2d@giganews.com> |
| In reply to | #8918 |
On 16/08/2011 13:57, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:AKKdnYILyJKxwNfTnZ2dnUVZ8vudnZ2d@giganews.com... >> On 16/08/2011 03:07, Paul wrote: >>> >>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>> news:9tCdnZfs3uFkF9TTnZ2dnUVZ8qmdnZ2d@giganews.com... >> >> [snip] >> >>>> From an earlier reply of mine that you seemed to have ignored: >>>> >>>> "For another clue think about the difference between a switch with >>>> contiguous case values and non-contiguous case values. *Most* switches >>>> have contiguous case values. If you have a switch with 525 >>>> non-contiguous case values then you may well need 6x525 clock cycles >>>> if again the solution was naive solution (a non-naive solution would >>>> be to use binary search on a jump table)." >>> >>> From where to you obtain the info that most switches have contiguous >>> cases? >>> This switch does not as the OP said the cases were unordered. >>> >>> I'm not too sure what you mean by a binary search on a jump table, but >>> nonethless my original point was that even with the worst case scenario >>> where every case was checked it's stilll not a great deal having 525 >>> conditions to check, with todays CPU's even though it may seem big in >>> your source code >> >> Do a google for: "switch statement" "binary search" sparse cases >> > I'm pretty sure I would begin reading and it say to myslef .."oh yes > it's just that". > > But what is all the fuss about. What exactly are you trying to say now, > are you still trying to suggest that I do not know what a jump table is? > Which was your original line of attack. What I am trying to say now?? I haven't changed what I am trying to say at all; I have been quite consistent. Your original assertion was invalid as most C++ compilers use jump tables when implementing switch statements and even if we consider the case of a switch with lots of "unordered" (sparse?) case values the performance would be better than what you seemed to be indicating as a non-naive compiler would use, for example, binary search on a jump table rather than emit branch instructions for every case. HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-16 19:29 +0100 |
| Message-ID | <j2ecvb$qvm$1@adenine.netfront.net> |
| In reply to | #8922 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:TvqdnSQKzboy9tfTnZ2dnUVZ8nSdnZ2d@giganews.com... > On 16/08/2011 13:57, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:AKKdnYILyJKxwNfTnZ2dnUVZ8vudnZ2d@giganews.com... >>> On 16/08/2011 03:07, Paul wrote: >>>> >>>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>>> news:9tCdnZfs3uFkF9TTnZ2dnUVZ8qmdnZ2d@giganews.com... >>> >>> [snip] >>> >>>>> From an earlier reply of mine that you seemed to have ignored: >>>>> >>>>> "For another clue think about the difference between a switch with >>>>> contiguous case values and non-contiguous case values. *Most* switches >>>>> have contiguous case values. If you have a switch with 525 >>>>> non-contiguous case values then you may well need 6x525 clock cycles >>>>> if again the solution was naive solution (a non-naive solution would >>>>> be to use binary search on a jump table)." >>>> >>>> From where to you obtain the info that most switches have contiguous >>>> cases? >>>> This switch does not as the OP said the cases were unordered. >>>> >>>> I'm not too sure what you mean by a binary search on a jump table, but >>>> nonethless my original point was that even with the worst case scenario >>>> where every case was checked it's stilll not a great deal having 525 >>>> conditions to check, with todays CPU's even though it may seem big in >>>> your source code >>> >>> Do a google for: "switch statement" "binary search" sparse cases >>> >> I'm pretty sure I would begin reading and it say to myslef .."oh yes >> it's just that". >> >> But what is all the fuss about. What exactly are you trying to say now, >> are you still trying to suggest that I do not know what a jump table is? >> Which was your original line of attack. > > What I am trying to say now?? I haven't changed what I am trying to say at > all; I have been quite consistent. Your original assertion was invalid as > most C++ compilers use jump tables when implementing switch statements and > even if we consider the case of a switch with lots of "unordered" > (sparse?) case values What do you mean "even if we consider". That *is* the case we were considering. Typical consistent bullshit, trying to twist the context around to suggest that the original case was considered as an implementation of a jump table when it obviously wasn't. --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-08-16 19:35 +0100 |
| Message-ID | <WJydnXigNsLvJdfTnZ2dnUVZ8uadnZ2d@giganews.com> |
| In reply to | #8930 |
On 16/08/2011 19:29, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:TvqdnSQKzboy9tfTnZ2dnUVZ8nSdnZ2d@giganews.com... >> On 16/08/2011 13:57, Paul wrote: >>> >>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>> news:AKKdnYILyJKxwNfTnZ2dnUVZ8vudnZ2d@giganews.com... >>>> On 16/08/2011 03:07, Paul wrote: >>>>> >>>>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>>>> news:9tCdnZfs3uFkF9TTnZ2dnUVZ8qmdnZ2d@giganews.com... >>>> >>>> [snip] >>>> >>>>>> From an earlier reply of mine that you seemed to have ignored: >>>>>> >>>>>> "For another clue think about the difference between a switch with >>>>>> contiguous case values and non-contiguous case values. *Most* >>>>>> switches >>>>>> have contiguous case values. If you have a switch with 525 >>>>>> non-contiguous case values then you may well need 6x525 clock cycles >>>>>> if again the solution was naive solution (a non-naive solution would >>>>>> be to use binary search on a jump table)." >>>>> >>>>> From where to you obtain the info that most switches have contiguous >>>>> cases? >>>>> This switch does not as the OP said the cases were unordered. >>>>> >>>>> I'm not too sure what you mean by a binary search on a jump table, but >>>>> nonethless my original point was that even with the worst case >>>>> scenario >>>>> where every case was checked it's stilll not a great deal having 525 >>>>> conditions to check, with todays CPU's even though it may seem big in >>>>> your source code >>>> >>>> Do a google for: "switch statement" "binary search" sparse cases >>>> >>> I'm pretty sure I would begin reading and it say to myslef .."oh yes >>> it's just that". >>> >>> But what is all the fuss about. What exactly are you trying to say now, >>> are you still trying to suggest that I do not know what a jump table is? >>> Which was your original line of attack. >> >> What I am trying to say now?? I haven't changed what I am trying to >> say at all; I have been quite consistent. Your original assertion was >> invalid as most C++ compilers use jump tables when implementing switch >> statements and even if we consider the case of a switch with lots of >> "unordered" (sparse?) case values > What do you mean "even if we consider". That *is* the case we were > considering. > > Typical consistent bullshit, trying to twist the context around to > suggest that the original case was considered as an implementation of a > jump table when it obviously wasn't. > Interesting that you snipped the second half of my sentence which explains that jump tables (with binary search) can still be used even for a switch with lots of "unordered" case values. Epic fail. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-17 00:01 +0100 |
| Message-ID | <j2essd$1f2l$1@adenine.netfront.net> |
| In reply to | #8932 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:WJydnXigNsLvJdfTnZ2dnUVZ8uadnZ2d@giganews.com... > On 16/08/2011 19:29, Paul wrote: >> >>>>> [snip] >>>>> >>>>>>> From an earlier reply of mine that you seemed to have ignored: >>>>>>> >>>>>>> "For another clue think about the difference between a switch with >>>>>>> contiguous case values and non-contiguous case values. *Most* >>>>>>> switches >>>>>>> have contiguous case values. If you have a switch with 525 >>>>>>> non-contiguous case values then you may well need 6x525 clock cycles >>>>>>> if again the solution was naive solution (a non-naive solution would >>>>>>> be to use binary search on a jump table)." >>>>>> >>>>>> From where to you obtain the info that most switches have contiguous >>>>>> cases? >>>>>> This switch does not as the OP said the cases were unordered. >>>>>> >>>>>> I'm not too sure what you mean by a binary search on a jump table, >>>>>> but >>>>>> nonethless my original point was that even with the worst case >>>>>> scenario >>>>>> where every case was checked it's stilll not a great deal having 525 >>>>>> conditions to check, with todays CPU's even though it may seem big in >>>>>> your source code >>>>> >>>>> Do a google for: "switch statement" "binary search" sparse cases >>>>> >>>> I'm pretty sure I would begin reading and it say to myslef .."oh yes >>>> it's just that". >>>> >>>> But what is all the fuss about. What exactly are you trying to say now, >>>> are you still trying to suggest that I do not know what a jump table >>>> is? >>>> Which was your original line of attack. >>> >>> What I am trying to say now?? I haven't changed what I am trying to >>> say at all; I have been quite consistent. Your original assertion was >>> invalid as most C++ compilers use jump tables when implementing switch >>> statements and even if we consider the case of a switch with lots of >>> "unordered" (sparse?) case values >> What do you mean "even if we consider". That *is* the case we were >> considering. >> >> Typical consistent bullshit, trying to twist the context around to >> suggest that the original case was considered as an implementation of a >> jump table when it obviously wasn't. >> > > Interesting that you snipped the second half of my sentence which explains > that jump tables (with binary search) can still be used even for a switch > with lots of "unordered" case values. > > Epic fail. You are completely arse for elbow. If you start on the wrong foot it doesn't matter what you say because you have already got it wrong by assuming that firstly it is a ordered switch case which can be implemented as a jump table, when that is just wrong. You are the fail here whether its an epic fail or just an average fail I'll leave you to decide , you should be an expert on failing by now. --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-08-17 00:11 +0100 |
| Message-ID | <1PKdnU12BIuGZNfTnZ2dnUVZ8midnZ2d@giganews.com> |
| In reply to | #8959 |
On 17/08/2011 00:01, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:WJydnXigNsLvJdfTnZ2dnUVZ8uadnZ2d@giganews.com... >> On 16/08/2011 19:29, Paul wrote: >>> >>>>>> [snip] >>>>>> >>>>>>>> From an earlier reply of mine that you seemed to have ignored: >>>>>>>> >>>>>>>> "For another clue think about the difference between a switch with >>>>>>>> contiguous case values and non-contiguous case values. *Most* >>>>>>>> switches >>>>>>>> have contiguous case values. If you have a switch with 525 >>>>>>>> non-contiguous case values then you may well need 6x525 clock >>>>>>>> cycles >>>>>>>> if again the solution was naive solution (a non-naive solution >>>>>>>> would >>>>>>>> be to use binary search on a jump table)." >>>>>>> >>>>>>> From where to you obtain the info that most switches have contiguous >>>>>>> cases? >>>>>>> This switch does not as the OP said the cases were unordered. >>>>>>> >>>>>>> I'm not too sure what you mean by a binary search on a jump >>>>>>> table, but >>>>>>> nonethless my original point was that even with the worst case >>>>>>> scenario >>>>>>> where every case was checked it's stilll not a great deal having 525 >>>>>>> conditions to check, with todays CPU's even though it may seem >>>>>>> big in >>>>>>> your source code >>>>>> >>>>>> Do a google for: "switch statement" "binary search" sparse cases >>>>>> >>>>> I'm pretty sure I would begin reading and it say to myslef .."oh yes >>>>> it's just that". >>>>> >>>>> But what is all the fuss about. What exactly are you trying to say >>>>> now, >>>>> are you still trying to suggest that I do not know what a jump >>>>> table is? >>>>> Which was your original line of attack. >>>> >>>> What I am trying to say now?? I haven't changed what I am trying to >>>> say at all; I have been quite consistent. Your original assertion was >>>> invalid as most C++ compilers use jump tables when implementing switch >>>> statements and even if we consider the case of a switch with lots of >>>> "unordered" (sparse?) case values >>> What do you mean "even if we consider". That *is* the case we were >>> considering. >>> >>> Typical consistent bullshit, trying to twist the context around to >>> suggest that the original case was considered as an implementation of a >>> jump table when it obviously wasn't. >>> >> >> Interesting that you snipped the second half of my sentence which >> explains that jump tables (with binary search) can still be used even >> for a switch with lots of "unordered" case values. >> >> Epic fail. > > You are completely arse for elbow. > > If you start on the wrong foot it doesn't matter what you say because > you have already got it wrong by assuming that firstly it is a ordered > switch case which can be implemented as a jump table, when that is just > wrong. > You are the fail here whether its an epic fail or just an average fail > I'll leave you to decide , you should be an expert on failing by now. That was just noise. Obviously you still don't understand how switch statements are commonly implemented; do you even know what binary search is and how it can be applied to a jump table? /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-17 01:23 +0100 |
| Message-ID | <j2f1o0$1ih4$1@adenine.netfront.net> |
| In reply to | #8960 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:1PKdnU12BIuGZNfTnZ2dnUVZ8midnZ2d@giganews.com... > On 17/08/2011 00:01, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:WJydnXigNsLvJdfTnZ2dnUVZ8uadnZ2d@giganews.com... >>> On 16/08/2011 19:29, Paul wrote: >>>> >>>>>>> [snip] >>>>>>> >>>>>>>>> From an earlier reply of mine that you seemed to have ignored: >>>>>>>>> >>>>>>>>> "For another clue think about the difference between a switch with >>>>>>>>> contiguous case values and non-contiguous case values. *Most* >>>>>>>>> switches >>>>>>>>> have contiguous case values. If you have a switch with 525 >>>>>>>>> non-contiguous case values then you may well need 6x525 clock >>>>>>>>> cycles >>>>>>>>> if again the solution was naive solution (a non-naive solution >>>>>>>>> would >>>>>>>>> be to use binary search on a jump table)." >>>>>>>> >>>>>>>> From where to you obtain the info that most switches have >>>>>>>> contiguous >>>>>>>> cases? >>>>>>>> This switch does not as the OP said the cases were unordered. >>>>>>>> >>>>>>>> I'm not too sure what you mean by a binary search on a jump >>>>>>>> table, but >>>>>>>> nonethless my original point was that even with the worst case >>>>>>>> scenario >>>>>>>> where every case was checked it's stilll not a great deal having >>>>>>>> 525 >>>>>>>> conditions to check, with todays CPU's even though it may seem >>>>>>>> big in >>>>>>>> your source code >>>>>>> >>>>>>> Do a google for: "switch statement" "binary search" sparse cases >>>>>>> >>>>>> I'm pretty sure I would begin reading and it say to myslef .."oh yes >>>>>> it's just that". >>>>>> >>>>>> But what is all the fuss about. What exactly are you trying to say >>>>>> now, >>>>>> are you still trying to suggest that I do not know what a jump >>>>>> table is? >>>>>> Which was your original line of attack. >>>>> >>>>> What I am trying to say now?? I haven't changed what I am trying to >>>>> say at all; I have been quite consistent. Your original assertion was >>>>> invalid as most C++ compilers use jump tables when implementing switch >>>>> statements and even if we consider the case of a switch with lots of >>>>> "unordered" (sparse?) case values >>>> What do you mean "even if we consider". That *is* the case we were >>>> considering. >>>> >>>> Typical consistent bullshit, trying to twist the context around to >>>> suggest that the original case was considered as an implementation of a >>>> jump table when it obviously wasn't. >>>> >>> >>> Interesting that you snipped the second half of my sentence which >>> explains that jump tables (with binary search) can still be used even >>> for a switch with lots of "unordered" case values. >>> >>> Epic fail. >> >> You are completely arse for elbow. >> >> If you start on the wrong foot it doesn't matter what you say because >> you have already got it wrong by assuming that firstly it is a ordered >> switch case which can be implemented as a jump table, when that is just >> wrong. >> You are the fail here whether its an epic fail or just an average fail >> I'll leave you to decide , you should be an expert on failing by now. > > That was just noise. Obviously you still don't understand how switch > statements are commonly implemented; do you even know what binary search > is and how it can be applied to a jump table? > It doesn't matter what you say I understand or don't understand, stop being irrellevant. --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2011-08-15 13:32 +0000 |
| Message-ID | <4e491ff5$0$2807$7b1e8fa0@news.nbl.fi> |
| In reply to | #8856 |
Paul <pchristor@yahoo.co.uk> wrote: > You can't have a switch statement with 525 cases executed in 6 clock cycles > you fucking moronic idiot. You see, that's why they recommended you to go and do some research on jump tables. What you are saying above is completely equivalent to saying "you can't access an element in an array of 525 elements in a couple of clock cycles". Of course you can. The amount of elements in the array doesn't matter.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-15 15:20 +0100 |
| Message-ID | <j2b9vu$30nc$1@adenine.netfront.net> |
| In reply to | #8860 |
"Juha Nieminen" <nospam@thanks.invalid> wrote in message news:4e491ff5$0$2807$7b1e8fa0@news.nbl.fi... > Paul <pchristor@yahoo.co.uk> wrote: >> You can't have a switch statement with 525 cases executed in 6 clock >> cycles >> you fucking moronic idiot. > > You see, that's why they recommended you to go and do some research on > jump tables. I am not even talking about a jump table, what makes you think a jump table has any relevance to what I said? > > What you are saying above is completely equivalent to saying "you can't > access an element in an array of 525 elements in a couple of clock > cycles". > Of course you can. The amount of elements in the array doesn't matter. No it isn't you are mistaken. --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-08-15 15:33 +0100 |
| Message-ID | <5YCdnbT-1Zy5s9TTnZ2dnUVZ8u-dnZ2d@giganews.com> |
| In reply to | #8863 |
On 15/08/2011 15:20, Paul wrote: > > "Juha Nieminen" <nospam@thanks.invalid> wrote in message > news:4e491ff5$0$2807$7b1e8fa0@news.nbl.fi... >> Paul <pchristor@yahoo.co.uk> wrote: >>> You can't have a switch statement with 525 cases executed in 6 clock >>> cycles >>> you fucking moronic idiot. >> >> You see, that's why they recommended you to go and do some research on >> jump tables. > I am not even talking about a jump table, what makes you think a jump > table has any relevance to what I said? > > >> >> What you are saying above is completely equivalent to saying "you can't >> access an element in an array of 525 elements in a couple of clock >> cycles". >> Of course you can. The amount of elements in the array doesn't matter. > > No it isn't you are mistaken. Nobody can be this stupid; you must be a troll. Well done. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2011-08-16 07:34 +0000 |
| Message-ID | <4e4a1da1$0$3070$7b1e8fa0@news.nbl.fi> |
| In reply to | #8863 |
Paul <pchristor@yahoo.co.uk> wrote: > > "Juha Nieminen" <nospam@thanks.invalid> wrote in message > news:4e491ff5$0$2807$7b1e8fa0@news.nbl.fi... >> Paul <pchristor@yahoo.co.uk> wrote: >>> You can't have a switch statement with 525 cases executed in 6 clock >>> cycles >>> you fucking moronic idiot. >> >> You see, that's why they recommended you to go and do some research on >> jump tables. > I am not even talking about a jump table, what makes you think a jump table > has any relevance to what I said? Read your own text above. It says "you can't have a switch statement with 525 cases executed in 6 clock cycles". It doesn't have any qualifiers or conditions. You are making an absolute assertion: That it's impossible. Now, after several people have hammered into you the concept of jump tables, and seemingly you finally understand what that means and how they can be applied by a compiler to implement a switch block, now you can't just admit that you didn't understand it first but now you do. Instead, you try to weasel yourself out of the situation by some vague claims that you were "not talking about a jump table". It's ok to say "ok, I had a misunderstanding, it is indeed possible to execute a large switch clock in just a few clock cycles using a jump table". Such an admission may hurt your pride for a while, but in the long run you will be much better off than by stubborningly sticking to your original claim. Just swallow your pride and learn to become a nicer person. You will be happier in the long run.
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web