Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Which is more optimal for changing a variable from 1 to 0?

  1. Apr 26, 2015 #1
    I'm micro-optimizing my program written in classic C. When I use and unsigned short int for a boolean value, I need to switch between values of 0 and 1, so what I need to know is whether it's more efficient to use bitshift operators or reassignment. In other words, is

    unsigned short int i = 1;
    i >>= 1;


    or

    unsigned short int i = 1;
    i = 0;


    faster for changing i from 1 to 0?
     
  2. jcsd
  3. Apr 26, 2015 #2
    I don't know...how about you do it a million times and time it?

    By the way, how many times is this supposed to happen in your program? 'cause if it is not going to happen that many times, I doubt you will notice the difference.
     
  4. Apr 27, 2015 #3
    I think that after compiler optimization, it's the same result. You can check it by doing G++ -S to generate assembly file for the both solution and check the difference. A friend say to me (i don't know if it's true) that if you use 64 Bit variable on a 64 bit device it's faster than a 32 bit variable on a 64 bit machine, So instead of using unsigned int, use size_t which is an unsigned number of size 32 on a 32bit an 64 on a 64 bit computer.

    Don't forget -O3 compiler option !
    If you want help, post part of your code, maybe we can see another inprovement.
     
  5. Apr 27, 2015 #4
    Nevermind. I just made my function more compact, removing the need for the variable I had before.

    New function:

    Code (Text):

    unsigned short int stringCompare ( char * s1, char * s2 )
    {
        while (*s1 && (*s1++ == *s2++));
        return (*s1 == *s2);
    }
     
    Don't ask what the old function looked like. It was needlessly long.
     
  6. Apr 27, 2015 #5

    Filip Larsen

    User Avatar
    Gold Member

    I think you may want to check your stringCompare method again, especially for inputs where s2 is a prefix of s1.
     
  7. Apr 29, 2015 #6
    You are using char* as string ! Just use std::string and gain time and energy ! If you don't know std::string class, just ask me, i can help.
    Compile with g++ to have BOOLEAN OBJECT ! If you don't want to modify your code you can do that :

    #include <string>

    int stringCompare(char* s1, char* s2)
    {
    return std::string(s1).compare(std::string(s2));
    }

    or something like that !
     
  8. Apr 29, 2015 #7

    wle

    User Avatar

    Is there something wrong with strcmp?

    According to this function, "mummy" and "mommy" test as equivalent strings.

    (Incidentally, to answer the OP: I remember from learning a bit of assembly language years ago that, at least on x86 processors, the fastest way to set an integer register to zero is to xor it with itself. It's really the compiler's job to handle this sort of thing, though.)
     
  9. Apr 30, 2015 #8
    Why are you even writing this code and micro-optimising it? Just call one of the strcmp functions (or the safe versions if you deal with web etc) from the standard library. More than likely your library implements it as hand-coded, optimised assembler - because it is so commonly used.
     
    Last edited: Apr 30, 2015
  10. May 1, 2015 #9
    Dont waste your time rewriting libraries. Chances are, they do it better than you.

    As to why this doesn't work, well, your while loop is true while these conditions are true. In the case of mommy vs mummy

    the while loop gets to o vs u.. and compares them
    (then increments s1, s2)
    they dont match, so it exits the loop
    then it compares m to m, and returns true.

    Its obvious how to fix this.

    Yes, xoring a register is the fastest way to set it to 0. But most likely his variable will be stored on the stack, so the compiler will likely do something such as mov dword ptr ss: [ebp + x], 0

    Something to ponder about your above code.

    What if something happens to your unsigned integer value, and its value isnt 1 anymore? Then you'll be surprised to see that your code will evaluate to true before and after the bit shift :P
     
  11. May 1, 2015 #10
    Your friend is right, using 32 bit operations in 64 bit registers requires extra emitted stuff such as setting carry flag, overflow flag, etc

    EDIT: Sorry guys, didn't mean to double post. I was going to edit this post into my last one, but slipped up.
     
  12. May 2, 2015 #11
    thanks for the answer !
     
Know someone interested in this topic? Share this thread via Reddit, Google+, Twitter, or Facebook