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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2011-08-11 21:00 +0000 |
| Message-ID | <slrnj48gmo.gtj.grahn+nntp@frailea.sa.invalid> |
| In reply to | #8637 |
On Wed, 2011-08-10, Lynn McGuire wrote:
> On 8/10/2011 7:20 AM, Jorgen Grahn wrote:
>> On Wed, 2011-08-10, Juha Nieminen wrote:
>>> Victor Bazarov<v.bazarov@comcast.invalid> wrote:
>>>> I wonder, have you tried looking at the generated code? Does the
>>>> compiler have a jump table or does it create a bunch of 'if-then goto'
>>>> parts? The latter gets expensive for the case labels at the bottom of
>>>> the switch statement.
>>>
>>> One can generally assume that modern compilers are decently good at
>>> optimizing large switch blocks. (If a specific compiler isn't, chances
>>> are that it isn't good at optimizing anything else either.)
>>
>> With such an unusually large switch, I'd rather not assume anything.
>> The price for being wrong could be high, like Victor said.
>>
>> I'd be interested to hear what the compiler generates in this case.
>>
>> /Jorgen
>
> DataDescriptor * GenGroup::descriptor (int aSymbol, int version)
> {
> 0075D5B0 push ebp
> 0075D5B1 mov ebp,esp
> 0075D5B3 sub esp,8
> 0075D5B6 mov dword ptr [ebp-4],ecx
> switch (aSymbol)
> 0075D5B9 mov eax,dword ptr [aSymbol]
> 0075D5BC mov dword ptr [ebp-8],eax
> 0075D5BF cmp dword ptr [ebp-8],20Ch
> 0075D5C6 ja $LN1+7 (75EA22h)
> 0075D5CC mov ecx,dword ptr [ebp-8]
> 0075D5CF jmp dword ptr (75EA2Ch)[ecx*4]
> {
> case GEN_CALVAPPRE:
> return & aDD_GEN_CALVAPPRE;
> 0075D5D6 mov eax,offset aDD_GEN_CALVAPPRE (0DA0080h)
> 0075D5DB jmp $LN1+9 (75EA24h)
> case GEN_CALSONVEL:
> return & aDD_GEN_CALSONVEL;
> 0075D5E0 mov eax,offset aDD_GEN_CALSONVEL (0D88908h)
> 0075D5E5 jmp $LN1+9 (75EA24h)
> case GEN_ONLYWRITESTREAMBOXONFIRSTSHEET:
> return & aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET;
> 0075D5EA mov eax,offset aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET (0D9C648h)
> 0075D5EF jmp $LN1+9 (75EA24h)
> ...
And I guess here is where I'll have to admit that I don't know
assembly unless its MC68k ;-) Is this a jump table implementation?
It's not a plain if ... elseif ... elseif chain -- that much I can
see.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Marcel Müller <news.5.maazl@spamgourmet.com> |
|---|---|
| Date | 2011-08-10 11:10 +0200 |
| Message-ID | <4e424aff$0$6580$9b4e6d93@newsspool3.arcor-online.net> |
| In reply to | #8603 |
Lynn McGuire wrote:
> Incredibly easy. Here is some of the method:
>
> DataDescriptor aDD_GEN_CALVAPPRE (GEN_CALVAPPRE, "CALVAPPRE",
> "Calculate Vapor Pressure for all streams", true, false,
> false,
> SYM_Enumerated, nil, nil, nil, nil, nil, SYM_BOOLEAN,
> SYM_DGenInit, 420, nil, nil);
>
> DataDescriptor * GenGroup::descriptor (int aSymbol, int version)
> {
> switch (aSymbol)
> {
> case GEN_CALVAPPRE:
> return & aDD_GEN_CALVAPPRE;
> case GEN_CALSONVEL:
> return & aDD_GEN_CALSONVEL;
> case GEN_ONLYWRITESTREAMBOXONFIRSTSHEET:
> return & aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET;
> ...
> }
>
> // default return
> return NULL;
> }
I would strongly recommend a meta data table.
static const DataDescriptor DispatchTable[] =
{ DataDescriptor(GEN_CALVAPPRE, "CALVAPPRE",
"Calculate Vapor Pressure for all streams", true, false, false,
SYM_Enumerated, nil, nil, nil, nil, nil, SYM_BOOLEAN,
SYM_DGenInit, 420, nil, nil),
DataDescriptor(GEN_CALSONVEL, ...),
...
};
If the DataDescriptors are ordered by the key aSymbol, you could use a
binary search to locate a DataDescriptor in the table.
Alternatively class DataDescriptor could hold a static repository of
type std::map<int,DataDescriptor*> with all it's instances. The
constructor of DataDescriptor could register it's own instance in the
repository. Then the method GenGroup::descriptor reduces to a hash
lookup in the repository. No more than a dozen code lines instead of
some thousands in the switch case. And the advantage is that you can
keep the code for the DataDescriptor definitions without changes. You
only have to delete the large switch.
> This is a 470,000 line C++ Win32 user interface for a highly
> successful calculation engine.
Maybe, but keep in mind that compilers are not well tested with this
kind of code. I triggered internal compiler errors with too large
functions from time to time (large window procedures).
> This code is bulletproof and
> very extensible.
The two above solutions too.
Marcel
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2011-08-10 10:40 +0000 |
| Message-ID | <4e426008$0$3077$7b1e8fa0@news.nbl.fi> |
| In reply to | #8612 |
Marcel Müller <news.5.maazl@spamgourmet.com> wrote: > If the DataDescriptors are ordered by the key aSymbol, you could use a > binary search to locate a DataDescriptor in the table. Since he's clearly aiming for maximum speed, the switch block is probably the most efficient solution because most compilers will create a jump table, which means executing the proper case block will be done in O(1) (rather than in O(log n) as with the binary search). (Now, of course it's not guaranteed that all compilers will be so smart as to generate a jump table from a large switch block, but AFAIK most modern compilers do.) Of course an alternative solution would be to create the jump table explicitly yourself (basically, an array of function pointers which you index with the value). This would allow a better rearrangment of the code into their own functions, but I don't know if it would result in a more, less or equally efficient program. (This solution, however, has the disadvantage of making it more complicated for the "case blocks", in this case the separate functions, to handle shared local variables. Passing them as parameters to the functions might decrease efficiency.)
[toc] | [prev] | [next] | [standalone]
| From | Victor Bazarov <v.bazarov@comcast.invalid> |
|---|---|
| Date | 2011-08-10 09:02 -0400 |
| Message-ID | <j1tvgu$hnj$2@dont-email.me> |
| In reply to | #8614 |
On 8/10/2011 6:40 AM, Juha Nieminen wrote: > Marcel Müller<news.5.maazl@spamgourmet.com> wrote: >> If the DataDescriptors are ordered by the key aSymbol, you could use a >> binary search to locate a DataDescriptor in the table. > > Since he's clearly aiming for maximum speed, the switch block is > probably the most efficient solution because most compilers will create > a jump table, which means executing the proper case block will be done > in O(1) (rather than in O(log n) as with the binary search). > > (Now, of course it's not guaranteed that all compilers will be so smart > as to generate a jump table from a large switch block, but AFAIK most > modern compilers do.) > > Of course an alternative solution would be to create the jump table > explicitly yourself (basically, an array of function pointers which you > index with the value). This would allow a better rearrangment of the > code into their own functions, but I don't know if it would result in > a more, less or equally efficient program. (This solution, however, has > the disadvantage of making it more complicated for the "case blocks", in > this case the separate functions, to handle shared local variables. Passing > them as parameters to the functions might decrease efficiency.) Not if you *assume* those functions are inlined, like "most modern compilers do"... V -- I do not respond to top-posted replies, please don't ask
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2011-08-11 08:05 +0000 |
| Message-ID | <4e438d3b$0$2851$7b1e8fa0@news.nbl.fi> |
| In reply to | #8622 |
Victor Bazarov <v.bazarov@comcast.invalid> wrote: > On 8/10/2011 6:40 AM, Juha Nieminen wrote: >> Of course an alternative solution would be to create the jump table >> explicitly yourself (basically, an array of function pointers which you >> index with the value). This would allow a better rearrangment of the >> code into their own functions, but I don't know if it would result in >> a more, less or equally efficient program. (This solution, however, has >> the disadvantage of making it more complicated for the "case blocks", in >> this case the separate functions, to handle shared local variables. Passing >> them as parameters to the functions might decrease efficiency.) > > Not if you *assume* those functions are inlined, like "most modern > compilers do"... There's only one explicit "function call", and several functions. The call is not direct, it's an indirect call using a (variable) function pointer. You can't inline several functions to one function call.
[toc] | [prev] | [next] | [standalone]
| From | Marcel Müller <news.5.maazl@spamgourmet.com> |
|---|---|
| Date | 2011-08-10 21:17 +0200 |
| Message-ID | <4e42d940$0$6634$9b4e6d93@newsspool2.arcor-online.net> |
| In reply to | #8614 |
Juha Nieminen wrote: > Marcel Müller <news.5.maazl@spamgourmet.com> wrote: >> If the DataDescriptors are ordered by the key aSymbol, you could use a >> binary search to locate a DataDescriptor in the table. > > Since he's clearly aiming for maximum speed, the switch block is > probably the most efficient solution because most compilers will create > a jump table, which means executing the proper case block will be done > in O(1) (rather than in O(log n) as with the binary search). > > (Now, of course it's not guaranteed that all compilers will be so smart > as to generate a jump table from a large switch block, but AFAIK most > modern compilers do.) Well, if and only if the values are in a sufficiently small range. If not, the compiler will use binary or linear search. > Of course an alternative solution would be to create the jump table > explicitly yourself (basically, an array of function pointers which you > index with the value). This would allow a better rearrangment of the > code into their own functions, but I don't know if it would result in > a more, less or equally efficient program. (This solution, however, has > the disadvantage of making it more complicated for the "case blocks", in > this case the separate functions, to handle shared local variables. Passing > them as parameters to the functions might decrease efficiency.) As long as the case blocks do nothing but returning a constant (i.e. the address of a global object) the functions are entirely superfluous as well as the case code too. Storing the addresses in the lookup table is sufficient. And if you do not need the symbol names of the DataDescriptors elsewhere the entire Objects can be stored in the lookup table, saving another indirection. If he has really need for speed, he should entirely eliminate the the integer IDs of the DataDescriptors and use the address of the DataDescriptors instead. If they are multitons this is equivalent. Of course, if there is a transposed data model in the backend with the IDs as keys this is not an option. But transposed data models are not fast. Marcel
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lmc@winsim.com> |
|---|---|
| Date | 2011-08-10 11:12 -0500 |
| Message-ID | <j1uanm$3qf$1@dont-email.me> |
| In reply to | #8612 |
On 8/10/2011 4:10 AM, Marcel Müller wrote:
> Lynn McGuire wrote:
>> Incredibly easy. Here is some of the method:
>>
>> DataDescriptor aDD_GEN_CALVAPPRE (GEN_CALVAPPRE, "CALVAPPRE",
>> "Calculate Vapor Pressure for all streams", true, false, false,
>> SYM_Enumerated, nil, nil, nil, nil, nil, SYM_BOOLEAN,
>> SYM_DGenInit, 420, nil, nil);
>>
>> DataDescriptor * GenGroup::descriptor (int aSymbol, int version)
>> {
>> switch (aSymbol)
>> {
>> case GEN_CALVAPPRE:
>> return & aDD_GEN_CALVAPPRE;
>> case GEN_CALSONVEL:
>> return & aDD_GEN_CALSONVEL;
>> case GEN_ONLYWRITESTREAMBOXONFIRSTSHEET:
>> return & aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET;
>> ...
>> }
>>
>> // default return
>> return NULL;
>> }
>
> I would strongly recommend a meta data table.
>
> static const DataDescriptor DispatchTable[] =
> { DataDescriptor(GEN_CALVAPPRE, "CALVAPPRE",
> "Calculate Vapor Pressure for all streams", true, false, false,
> SYM_Enumerated, nil, nil, nil, nil, nil, SYM_BOOLEAN,
> SYM_DGenInit, 420, nil, nil),
> DataDescriptor(GEN_CALSONVEL, ...),
> ...
> };
>
> If the DataDescriptors are ordered by the key aSymbol, you could use a binary search to locate a DataDescriptor in the table.
>
> Alternatively class DataDescriptor could hold a static repository of type std::map<int,DataDescriptor*> with all it's instances. The
> constructor of DataDescriptor could register it's own instance in the repository. Then the method GenGroup::descriptor reduces to a
> hash lookup in the repository. No more than a dozen code lines instead of some thousands in the switch case. And the advantage is
> that you can keep the code for the DataDescriptor definitions without changes. You only have to delete the large switch.
>
>> This is a 470,000 line C++ Win32 user interface for a highly
>> successful calculation engine.
>
> Maybe, but keep in mind that compilers are not well tested with this kind of code. I triggered internal compiler errors with too
> large functions from time to time (large window procedures).
>
>> This code is bulletproof and
>> very extensible.
>
> The two above solutions too.
>
>
> Marcel
This solution is order dependent. Mine is not. Not that
I'm looking for a new solution.
Lynn
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-11 11:07 +0100 |
| Message-ID | <j209kt$ijs$1@adenine.netfront.net> |
| In reply to | #8634 |
"Lynn McGuire" <lmc@winsim.com> wrote in message
news:j1uanm$3qf$1@dont-email.me...
> On 8/10/2011 4:10 AM, Marcel Müller wrote:
>> Lynn McGuire wrote:
>>> Incredibly easy. Here is some of the method:
>>>
>>> DataDescriptor aDD_GEN_CALVAPPRE (GEN_CALVAPPRE, "CALVAPPRE",
>>> "Calculate Vapor Pressure for all streams", true, false, false,
>>> SYM_Enumerated, nil, nil, nil, nil, nil, SYM_BOOLEAN,
>>> SYM_DGenInit, 420, nil, nil);
>>>
>>> DataDescriptor * GenGroup::descriptor (int aSymbol, int version)
>>> {
>>> switch (aSymbol)
>>> {
>>> case GEN_CALVAPPRE:
>>> return & aDD_GEN_CALVAPPRE;
>>> case GEN_CALSONVEL:
>>> return & aDD_GEN_CALSONVEL;
>>> case GEN_ONLYWRITESTREAMBOXONFIRSTSHEET:
>>> return & aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET;
>>> ...
>>> }
>>>
>>> // default return
>>> return NULL;
>>> }
>>
>> I would strongly recommend a meta data table.
>>
>> static const DataDescriptor DispatchTable[] =
>> { DataDescriptor(GEN_CALVAPPRE, "CALVAPPRE",
>> "Calculate Vapor Pressure for all streams", true, false, false,
>> SYM_Enumerated, nil, nil, nil, nil, nil, SYM_BOOLEAN,
>> SYM_DGenInit, 420, nil, nil),
>> DataDescriptor(GEN_CALSONVEL, ...),
>> ...
>> };
>>
>> If the DataDescriptors are ordered by the key aSymbol, you could use a
>> binary search to locate a DataDescriptor in the table.
>>
>> Alternatively class DataDescriptor could hold a static repository of type
>> std::map<int,DataDescriptor*> with all it's instances. The
>> constructor of DataDescriptor could register it's own instance in the
>> repository. Then the method GenGroup::descriptor reduces to a
>> hash lookup in the repository. No more than a dozen code lines instead of
>> some thousands in the switch case. And the advantage is
>> that you can keep the code for the DataDescriptor definitions without
>> changes. You only have to delete the large switch.
>>
>>> This is a 470,000 line C++ Win32 user interface for a highly
>>> successful calculation engine.
>>
>> Maybe, but keep in mind that compilers are not well tested with this kind
>> of code. I triggered internal compiler errors with too
>> large functions from time to time (large window procedures).
>>
>>> This code is bulletproof and
>>> very extensible.
>>
>> The two above solutions too.
>>
>>
>> Marcel
>
> This solution is order dependent. Mine is not. Not that
> I'm looking for a new solution.
>
Best to keep it simple it seems you are already using the best solution.
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.
--- 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-13 00:14 +0100 |
| Message-ID | <3uydnS2bVrh7LtjTnZ2dnUVZ7vGjnZ2d@giganews.com> |
| In reply to | #8665 |
On 11/08/2011 11:07, Paul wrote:
>
> "Lynn McGuire" <lmc@winsim.com> wrote in message
> news:j1uanm$3qf$1@dont-email.me...
>> On 8/10/2011 4:10 AM, Marcel Müller wrote:
>>> Lynn McGuire wrote:
>>>> Incredibly easy. Here is some of the method:
>>>>
>>>> DataDescriptor aDD_GEN_CALVAPPRE (GEN_CALVAPPRE, "CALVAPPRE",
>>>> "Calculate Vapor Pressure for all streams", true, false, false,
>>>> SYM_Enumerated, nil, nil, nil, nil, nil, SYM_BOOLEAN,
>>>> SYM_DGenInit, 420, nil, nil);
>>>>
>>>> DataDescriptor * GenGroup::descriptor (int aSymbol, int version)
>>>> {
>>>> switch (aSymbol)
>>>> {
>>>> case GEN_CALVAPPRE:
>>>> return & aDD_GEN_CALVAPPRE;
>>>> case GEN_CALSONVEL:
>>>> return & aDD_GEN_CALSONVEL;
>>>> case GEN_ONLYWRITESTREAMBOXONFIRSTSHEET:
>>>> return & aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET;
>>>> ...
>>>> }
>>>>
>>>> // default return
>>>> return NULL;
>>>> }
>>>
>>> I would strongly recommend a meta data table.
>>>
>>> static const DataDescriptor DispatchTable[] =
>>> { DataDescriptor(GEN_CALVAPPRE, "CALVAPPRE",
>>> "Calculate Vapor Pressure for all streams", true, false, false,
>>> SYM_Enumerated, nil, nil, nil, nil, nil, SYM_BOOLEAN,
>>> SYM_DGenInit, 420, nil, nil),
>>> DataDescriptor(GEN_CALSONVEL, ...),
>>> ...
>>> };
>>>
>>> If the DataDescriptors are ordered by the key aSymbol, you could use
>>> a binary search to locate a DataDescriptor in the table.
>>>
>>> Alternatively class DataDescriptor could hold a static repository of
>>> type std::map<int,DataDescriptor*> with all it's instances. The
>>> constructor of DataDescriptor could register it's own instance in the
>>> repository. Then the method GenGroup::descriptor reduces to a
>>> hash lookup in the repository. No more than a dozen code lines
>>> instead of some thousands in the switch case. And the advantage is
>>> that you can keep the code for the DataDescriptor definitions without
>>> changes. You only have to delete the large switch.
>>>
>>>> This is a 470,000 line C++ Win32 user interface for a highly
>>>> successful calculation engine.
>>>
>>> Maybe, but keep in mind that compilers are not well tested with this
>>> kind of code. I triggered internal compiler errors with too
>>> large functions from time to time (large window procedures).
>>>
>>>> This code is bulletproof and
>>>> very extensible.
>>>
>>> The two above solutions too.
>>>
>>>
>>> Marcel
>>
>> This solution is order dependent. Mine is not. Not that
>> I'm looking for a new solution.
>>
> Best to keep it simple it seems you are already using the best solution.
>
> 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).
HTH.
/Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-13 14:54 +0100 |
| Message-ID | <j25vnh$307c$1@adenine.netfront.net> |
| In reply to | #8760 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:3uydnS2bVrh7LtjTnZ2dnUVZ7vGjnZ2d@giganews.com...
> On 11/08/2011 11:07, Paul wrote:
>>
>> "Lynn McGuire" <lmc@winsim.com> wrote in message
>> news:j1uanm$3qf$1@dont-email.me...
>>> On 8/10/2011 4:10 AM, Marcel Müller wrote:
>>>> Lynn McGuire wrote:
>>>>> Incredibly easy. Here is some of the method:
>>>>>
>>>>> DataDescriptor aDD_GEN_CALVAPPRE (GEN_CALVAPPRE, "CALVAPPRE",
>>>>> "Calculate Vapor Pressure for all streams", true, false, false,
>>>>> SYM_Enumerated, nil, nil, nil, nil, nil, SYM_BOOLEAN,
>>>>> SYM_DGenInit, 420, nil, nil);
>>>>>
>>>>> DataDescriptor * GenGroup::descriptor (int aSymbol, int version)
>>>>> {
>>>>> switch (aSymbol)
>>>>> {
>>>>> case GEN_CALVAPPRE:
>>>>> return & aDD_GEN_CALVAPPRE;
>>>>> case GEN_CALSONVEL:
>>>>> return & aDD_GEN_CALSONVEL;
>>>>> case GEN_ONLYWRITESTREAMBOXONFIRSTSHEET:
>>>>> return & aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET;
>>>>> ...
>>>>> }
>>>>>
>>>>> // default return
>>>>> return NULL;
>>>>> }
>>>>
>>>> I would strongly recommend a meta data table.
>>>>
>>>> static const DataDescriptor DispatchTable[] =
>>>> { DataDescriptor(GEN_CALVAPPRE, "CALVAPPRE",
>>>> "Calculate Vapor Pressure for all streams", true, false, false,
>>>> SYM_Enumerated, nil, nil, nil, nil, nil, SYM_BOOLEAN,
>>>> SYM_DGenInit, 420, nil, nil),
>>>> DataDescriptor(GEN_CALSONVEL, ...),
>>>> ...
>>>> };
>>>>
>>>> If the DataDescriptors are ordered by the key aSymbol, you could use
>>>> a binary search to locate a DataDescriptor in the table.
>>>>
>>>> Alternatively class DataDescriptor could hold a static repository of
>>>> type std::map<int,DataDescriptor*> with all it's instances. The
>>>> constructor of DataDescriptor could register it's own instance in the
>>>> repository. Then the method GenGroup::descriptor reduces to a
>>>> hash lookup in the repository. No more than a dozen code lines
>>>> instead of some thousands in the switch case. And the advantage is
>>>> that you can keep the code for the DataDescriptor definitions without
>>>> changes. You only have to delete the large switch.
>>>>
>>>>> This is a 470,000 line C++ Win32 user interface for a highly
>>>>> successful calculation engine.
>>>>
>>>> Maybe, but keep in mind that compilers are not well tested with this
>>>> kind of code. I triggered internal compiler errors with too
>>>> large functions from time to time (large window procedures).
>>>>
>>>>> This code is bulletproof and
>>>>> very extensible.
>>>>
>>>> The two above solutions too.
>>>>
>>>>
>>>> Marcel
>>>
>>> This solution is order dependent. Mine is not. Not that
>>> I'm looking for a new solution.
>>>
>> Best to keep it simple it seems you are already using the best solution.
>>
>> 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?
--- 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-13 15:26 +0100 |
| Message-ID | <AO2dna1DbZ4vFNvTnZ2dnUVZ8hGdnZ2d@giganews.com> |
| In reply to | #8788 |
On 13/08/2011 14:54, Paul wrote:
>
> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
> news:3uydnS2bVrh7LtjTnZ2dnUVZ7vGjnZ2d@giganews.com...
>> On 11/08/2011 11:07, Paul wrote:
>>>
>>> "Lynn McGuire" <lmc@winsim.com> wrote in message
>>> news:j1uanm$3qf$1@dont-email.me...
>>>> On 8/10/2011 4:10 AM, Marcel Müller wrote:
>>>>> Lynn McGuire wrote:
>>>>>> Incredibly easy. Here is some of the method:
>>>>>>
>>>>>> DataDescriptor aDD_GEN_CALVAPPRE (GEN_CALVAPPRE, "CALVAPPRE",
>>>>>> "Calculate Vapor Pressure for all streams", true, false, false,
>>>>>> SYM_Enumerated, nil, nil, nil, nil, nil, SYM_BOOLEAN,
>>>>>> SYM_DGenInit, 420, nil, nil);
>>>>>>
>>>>>> DataDescriptor * GenGroup::descriptor (int aSymbol, int version)
>>>>>> {
>>>>>> switch (aSymbol)
>>>>>> {
>>>>>> case GEN_CALVAPPRE:
>>>>>> return & aDD_GEN_CALVAPPRE;
>>>>>> case GEN_CALSONVEL:
>>>>>> return & aDD_GEN_CALSONVEL;
>>>>>> case GEN_ONLYWRITESTREAMBOXONFIRSTSHEET:
>>>>>> return & aDD_GEN_ONLYWRITESTREAMBOXONFIRSTSHEET;
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>> // default return
>>>>>> return NULL;
>>>>>> }
>>>>>
>>>>> I would strongly recommend a meta data table.
>>>>>
>>>>> static const DataDescriptor DispatchTable[] =
>>>>> { DataDescriptor(GEN_CALVAPPRE, "CALVAPPRE",
>>>>> "Calculate Vapor Pressure for all streams", true, false, false,
>>>>> SYM_Enumerated, nil, nil, nil, nil, nil, SYM_BOOLEAN,
>>>>> SYM_DGenInit, 420, nil, nil),
>>>>> DataDescriptor(GEN_CALSONVEL, ...),
>>>>> ...
>>>>> };
>>>>>
>>>>> If the DataDescriptors are ordered by the key aSymbol, you could use
>>>>> a binary search to locate a DataDescriptor in the table.
>>>>>
>>>>> Alternatively class DataDescriptor could hold a static repository of
>>>>> type std::map<int,DataDescriptor*> with all it's instances. The
>>>>> constructor of DataDescriptor could register it's own instance in the
>>>>> repository. Then the method GenGroup::descriptor reduces to a
>>>>> hash lookup in the repository. No more than a dozen code lines
>>>>> instead of some thousands in the switch case. And the advantage is
>>>>> that you can keep the code for the DataDescriptor definitions without
>>>>> changes. You only have to delete the large switch.
>>>>>
>>>>>> This is a 470,000 line C++ Win32 user interface for a highly
>>>>>> successful calculation engine.
>>>>>
>>>>> Maybe, but keep in mind that compilers are not well tested with this
>>>>> kind of code. I triggered internal compiler errors with too
>>>>> large functions from time to time (large window procedures).
>>>>>
>>>>>> This code is bulletproof and
>>>>>> very extensible.
>>>>>
>>>>> The two above solutions too.
>>>>>
>>>>>
>>>>> Marcel
>>>>
>>>> This solution is order dependent. Mine is not. Not that
>>>> I'm looking for a new solution.
>>>>
>>> Best to keep it simple it seems you are already using the best solution.
>>>
>>> 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?
What an amazingly original insult. Perhaps you think I was being
disrespectful? Well you will receive as much respect as you deserve and
in this forum your past record dictates how much respect you deserve.
Your past record is awful.
HTH.
/Leigh
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2011-08-14 18:14 +0000 |
| Message-ID | <4e48109f$0$2874$7b1e8fa0@news.nbl.fi> |
| In reply to | #8788 |
Paul <pchristor@yahoo.co.uk> 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.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-15 01:09 +0100 |
| Message-ID | <j29o5d$vlt$1@adenine.netfront.net> |
| In reply to | #8841 |
"Juha Nieminen" <nospam@thanks.invalid> wrote in message news:4e48109f$0$2874$7b1e8fa0@news.nbl.fi... > Paul <pchristor@yahoo.co.uk> 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 as not all CPU's are the same. Can you explain how many clock cycles you think it'd take? --- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-08-15 02:15 -0700 |
| Message-ID | <8740e3fe-8a70-4d59-bead-66ac3485b009@k3g2000vbz.googlegroups.com> |
| In reply to | #8846 |
On Aug 15, 1:09 am, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Juha Nieminen" <nos...@thanks.invalid> wrote in message
>
> news:4e48109f$0$2874$7b1e8fa0@news.nbl.fi...
>
> > Paul <pchris...@yahoo.co.uk> 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"
> 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
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-15 12:18 +0100 |
| Message-ID | <j2avah$2htu$1@adenine.netfront.net> |
| In reply to | #8850 |
"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message news:8740e3fe-8a70-4d59-bead-66ac3485b009@k3g2000vbz.googlegroups.com... On Aug 15, 1:09 am, "Paul" <pchris...@yahoo.co.uk> wrote: > "Juha Nieminen" <nos...@thanks.invalid> wrote in message > > news:4e48109f$0$2874$7b1e8fa0@news.nbl.fi... > > > Paul <pchris...@yahoo.co.uk> 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". --- 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 13:22 +0100 |
| Message-ID | <KNudnS_kS6YbktTTnZ2dnUVZ8iGdnZ2d@giganews.com> |
| In reply to | #8852 |
On 15/08/2011 12:18, Paul wrote: > > "Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message > news:8740e3fe-8a70-4d59-bead-66ac3485b009@k3g2000vbz.googlegroups.com... > On Aug 15, 1:09 am, "Paul" <pchris...@yahoo.co.uk> wrote: >> "Juha Nieminen" <nos...@thanks.invalid> wrote in message >> >> news:4e48109f$0$2874$7b1e8fa0@news.nbl.fi... >> >> > Paul <pchris...@yahoo.co.uk> 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. HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-15 13:38 +0100 |
| Message-ID | <j2b41t$2o6a$1@adenine.netfront.net> |
| In reply to | #8854 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:KNudnS_kS6YbktTTnZ2dnUVZ8iGdnZ2d@giganews.com... > On 15/08/2011 12:18, Paul wrote: >> >> "Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message >> news:8740e3fe-8a70-4d59-bead-66ac3485b009@k3g2000vbz.googlegroups.com... >> On Aug 15, 1:09 am, "Paul" <pchris...@yahoo.co.uk> wrote: >>> "Juha Nieminen" <nos...@thanks.invalid> wrote in message >>> >>> news:4e48109f$0$2874$7b1e8fa0@news.nbl.fi... >>> >>> > Paul <pchris...@yahoo.co.uk> 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. --- 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 14:06 +0100 |
| Message-ID | <bKadnRAH7It7hNTTnZ2dnUVZ8mWdnZ2d@giganews.com> |
| In reply to | #8856 |
On 15/08/2011 13:38, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:KNudnS_kS6YbktTTnZ2dnUVZ8iGdnZ2d@giganews.com... >> On 15/08/2011 12:18, Paul wrote: >>> >>> "Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message >>> news:8740e3fe-8a70-4d59-bead-66ac3485b009@k3g2000vbz.googlegroups.com... >>> On Aug 15, 1:09 am, "Paul" <pchris...@yahoo.co.uk> wrote: >>>> "Juha Nieminen" <nos...@thanks.invalid> wrote in message >>>> >>>> news:4e48109f$0$2874$7b1e8fa0@news.nbl.fi... >>>> >>>> > Paul <pchris...@yahoo.co.uk> 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. Only a naive implementation would have O(n) branching instructions to jump to any case of a switch of n cases; with jump tables (learn about them) *most* switch cases can be reached with O(1) instructions making an estimate of just 6 clock cycles perfectly acceptable. 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). You really need to accept that your programming knowledge is limited to what you have currently learnt and accept that some people know more than you. HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-15 16:05 +0100 |
| Message-ID | <j2bcls$2gk$1@adenine.netfront.net> |
| In reply to | #8859 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:bKadnRAH7It7hNTTnZ2dnUVZ8mWdnZ2d@giganews.com... > On 15/08/2011 13:38, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:KNudnS_kS6YbktTTnZ2dnUVZ8iGdnZ2d@giganews.com... >>> On 15/08/2011 12:18, Paul wrote: >>>> >>>> "Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message >>>> news:8740e3fe-8a70-4d59-bead-66ac3485b009@k3g2000vbz.googlegroups.com... >>>> On Aug 15, 1:09 am, "Paul" <pchris...@yahoo.co.uk> wrote: >>>>> "Juha Nieminen" <nos...@thanks.invalid> wrote in message >>>>> >>>>> news:4e48109f$0$2874$7b1e8fa0@news.nbl.fi... >>>>> >>>>> > Paul <pchris...@yahoo.co.uk> 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. :) --- 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 16:20 +0100 |
| Message-ID | <voKdneBY59LDpNTTnZ2dnUVZ8t2dnZ2d@giganews.com> |
| In reply to | #8865 |
On 15/08/2011 16:05, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:bKadnRAH7It7hNTTnZ2dnUVZ8mWdnZ2d@giganews.com... >> On 15/08/2011 13:38, Paul wrote: >>> >>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>> news:KNudnS_kS6YbktTTnZ2dnUVZ8iGdnZ2d@giganews.com... >>>> On 15/08/2011 12:18, Paul wrote: >>>>> >>>>> "Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message >>>>> news:8740e3fe-8a70-4d59-bead-66ac3485b009@k3g2000vbz.googlegroups.com... >>>>> >>>>> On Aug 15, 1:09 am, "Paul" <pchris...@yahoo.co.uk> wrote: >>>>>> "Juha Nieminen" <nos...@thanks.invalid> wrote in message >>>>>> >>>>>> news:4e48109f$0$2874$7b1e8fa0@news.nbl.fi... >>>>>> >>>>>> > Paul <pchris...@yahoo.co.uk> 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). Your epic fails are so epic that they will probably make people laugh for many years to come. HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web