in reply to Re: Re: Re: Re: Re: Perl Idioms Explained: && and || "Short Circuit" operators
in thread Perl Idioms Explained - && and || "Short Circuit" operators

So would I be correct in understanding that 

switch (ulong_val) {
  case 0       : handle_case0; break;
  case ULONGMAX: handle_caseMAX; break;
  default      : handle_default; break;
}

[download]

Generates a _huge_ dispatch table? Can that be correct? I found your dissambly to be very interesting, but I personaly would have like to have seen what happens when the input is discontiguous and operated on a variable and not a constant. Any chance of an update BrowserUk?


---
demerphq

    First they ignore you, then they laugh at you, then they fight you, then you win.
    -- Gandhi

Replies are listed 'Best First'.
Re+ :Perl Idioms Explained: && and || "Short Circuit" operators
by BrowserUk (Patriarch) on Oct 23, 2003 at 00:49 UTC

    Modern C compilers have the smarts built in to make intelligent decisions on what code to emit. In the case of your example of 2 widely spaced cases, it produces this

    Read more... (2 kB)

    Which as you can see, gets translated into a test and jump for the extreme case, another test and jump for the default case and a fall through for the 1 case.

    If you combine a contiguous range and an extreme case, you get.

    Read more... (5 kB)
[reply]
[d/l]
[select]

      So the rub of this is that switch() is not O(1). But that as often as possible the optimizer will do its best to convert it to be so. Which if you think about it means that from a programmers perspective its merely syntactic sugar for a chain of ifs. I say this becuase its just as reasonable to assume that the optimizer could figure out that a chain of ifs can be represented by a jump table and do the same optimization there.

      Also in your private message to me you mentioned that on occassion the compiler constructs a multi gigabyte executable to try to provide this "optimization". Which I would have thought _totally_ defeats the purpose given that the swap/thrash times involved to implement it would _far_ outweigh the execution times of a chained if.

      Anyway, many thanks to you and the other respondants about this. I have certainly learned something.


      ---
      demerphq

        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi

[reply]
[d/l]
        I say this becuase its just as reasonable to assume that the optimizer could figure out that a chain of ifs can be represented by a jump table and do the same optimization there.

        Indeed, Perl4 did precisely that. We kept threatening to do it in Perl5, but nobody ever got around to doing it. Perl6 will need to do it--the switch statement was designed with the assumption that it would be optimized in the simple cases.

[reply]

In Section Meditations