Bernd Nawothnig <Bernd.Nawoth...@t-online.de> writes:
> If somebody thinks he needs a goto he should better use a language
> which already comes with that construct (like C/C++).
On Sat, Aug 11 2012, RG wrote:
> In article <46551c33-9db1-49e6-a0bc-4ab53b2fa05c@googlegroups.com>,
> Bill <schottsta...@gmail.com> wrote:
>> > C/C++ doesn t have a native computed goto.
>> gnu c does, but in my experience it is not much, if any,
>> faster than a switch statement.
> That's because a switch statement compiles to a computed goto.
Well, a switch statement needs to perform a range check first, then look
up the address in a table, then perform the computed goto. Computed
gotos should be a win if the indirection through the table can be
avoided.
>> In article <46551c33-9db1-49e6-a0bc-4ab53b2fa05c@googlegroups.com>,
>> Bill <schottsta...@gmail.com> wrote:
>>> > C/C++ doesn t have a native computed goto.
>>> gnu c does, but in my experience it is not much, if any,
>>> faster than a switch statement.
>> That's because a switch statement compiles to a computed goto.
> Well, a switch statement needs to perform a range check first, then look
> up the address in a table, then perform the computed goto.
Not necessarily. The compiler knows all case constants and if they are
close enough a table of addresses is generated and only one
range-check at the beginning is needed. And if it is a byte-variable
even that check can be omitted. As far as I know uses the Python
runtime interpreter when compiled with a newer gcc this feature for a
significant speed up when switching by the byte-opcode.
> Computed gotos should be a win if the indirection through the table
> can be avoided.
Depends on the CPU and cache size how much that indirection costs. For
modern CPUs it should be neglectable.
Bernd
-- "Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist
haben - und Geld." [Friedrich Nietzsche]
>> Depends on the CPU and cache size how much that indirection costs. For
>> modern CPUs it should be neglectable.
> A memory reference will always be slower than no memory reference
> regardless of cache sizes.
If the whole vector fits into L1 the cache - and that will be the case
if it is relatively small, e.g. 256 entries - accessing the address
will be very fast. No external bus cycles are required. So the
additional costs in such a situation will be neglectable or even zero
in some cases. Precondition for that is, of course, that the vector is
kept in the L1 cache and will stay there. But that will be
automatically the case if the corresponding switch/case is executed
often enough (like in the inner loop of the mentioned Python runtime
interpreter).
Bernd
-- "Die Antisemiten vergeben es den Juden nicht, dass die Juden Geist
haben - und Geld." [Friedrich Nietzsche]
"Pascal J. Bourguignon" <p...@informatimago.com> writes:
> That's ludicruous! In a language where the Duff device is valid,
> there's no reason to prevent jumping into or out of loops.
I know you can jump into a loop. As a matter of fact that is exactly the
situation where you need a brute-force goto, because if you adhere
strictly to the structured programming tenets you will need a lot of
awkward flags.
But the point I was replying to was another: if you can
simulate a jumping-into-a-scope goto using only an array of
pointers. And that is not possible, as far as I know (obviously that
question is little pertinent with lisp programming...)
Bernd Nawothnig <Bernd.Nawoth...@t-online.de> writes:
> You can be very sure that I would get another answer for the same
> question in the C++ group ;-)
The difference being that many people here in c.l.l. know C++ reasonably
well, whereas in the C++ group almost no one knows anything about Common
Lisp.
