Like Tree2Likes

Get absolute value efficiently

This is a discussion on Get absolute value efficiently within the C Programming forums, part of the General Programming Boards category; Originally Posted by Subsonics It's not necessarily an assumption, if the target cpu is known. All you have done is ...

  1. #16
    Registered User
    Join Date
    Jun 2005
    Posts
    6,266
    Quote Originally Posted by Subsonics View Post
    It's not necessarily an assumption, if the target cpu is known.
    All you have done is re-express the assumption. It is now an assumption that host CPU is the same (or compatible with) the specified target CPU.
    Right 98% of the time, and don't care about the other 3%.

  2. #17
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    I'm not sure what you mean exactly, it's pretty common with conditional directives like: #ifdef __i386__ for example.

  3. #18
    Registered User
    Join Date
    Jun 2005
    Posts
    6,266


    The reason a conditional like #ifdef __i386__ is needed is because the code that will be substituted assumes a particular architecture.
    Right 98% of the time, and don't care about the other 3%.

  4. #19
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    Yes, but if __i386__ is defined then it's not an assumption, is it?

  5. #20
    Registered User
    Join Date
    Jun 2005
    Posts
    6,266
    Apparently you assume so. You assume incorrectly.
    Right 98% of the time, and don't care about the other 3%.

  6. #21
    Registered User ledow's Avatar
    Join Date
    Dec 2011
    Posts
    435
    I still say, given that glibc has some HORRENDOUS hacks elsewhere in the library for performance reasons, the fact that they just use an if speaks volumes. You need to benchmark your code against an if. I don't see how your code will be any faster. This is what's known as premature optimisation. You're employing bit-twiddling techniques that run afoul on other architectures to the point you need to #ifdef.

    Seriously. Benchmark it. In my test, a naive version that just copies the glibc branch code but with long long's instead is twice as fast, even in a tight loop of 100,000,000 executions of the functions and with all compiler optimisations turned off (with optimisations on, it's still the same because there's nothing to optimise here). Which is what someone else showed you too.

    - Compiler warnings are like "Bridge Out Ahead" warnings. DON'T just ignore them.
    - A compiler error is something SO stupid that the compiler genuinely can't carry on with its job. A compiler warning is the compiler saying "Well, that's bloody stupid but if you WANT to ignore me..." and carrying on.
    - The best debugging tool in the world is a bunch of printf()'s for everything important around the bits you think might be wrong.

  7. #22
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    Quote Originally Posted by ledow View Post
    I still say, given that glibc has some HORRENDOUS hacks elsewhere in the library for performance reasons, the fact that they just use an if speaks volumes. You need to benchmark your code against an if. I don't see how your code will be any faster. This is what's known as premature optimisation. You're employing bit-twiddling techniques that run afoul on other architectures to the point you need to #ifdef.

    Seriously. Benchmark it. In my test, a naive version that just copies the glibc branch code but with long long's instead is twice as fast, even in a tight loop of 100,000,000 executions of the functions and with all compiler optimisations turned off (with optimisations on, it's still the same because there's nothing to optimise here). Which is what someone else showed you too.
    Eh, I'm not the OP. I only forwarded a code snippet from the book Hackers Delight, if it has been established that optimization is needed. I'm not advocating the use of it if it's not warranted, nor that it should not be tested. For what it's worth, I inlined it in the test program in post #8 and it ran about 40% faster than libc, and the relation was identical with the original program intact i.e libc was faster.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Efficiently adding to the end of a linked ist
    By nkbxwb in forum C Programming
    Replies: 1
    Last Post: 10-29-2011, 04:41 PM
  2. Drawing bitmaps efficiently
    By scwizzo in forum Windows Programming
    Replies: 28
    Last Post: 06-30-2009, 08:25 PM
  3. Help on making program run more efficiently
    By peeweearies in forum C Programming
    Replies: 2
    Last Post: 03-23-2009, 02:01 AM
  4. solve efficiently
    By jack_carver in forum C Programming
    Replies: 4
    Last Post: 02-20-2009, 06:56 AM
  5. solving efficiently
    By jack_carver in forum C++ Programming
    Replies: 1
    Last Post: 02-20-2009, 06:54 AM

Tags for this Thread


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21