I make abs() function.
It is same for original library.
But, it is slow.

int myAbs ( int number )
{
	return( number>0 ? number : -number );
}

I checked its running time, so It spend more than triple running time
of original library function.

Why is my function slow than abs-function of <math.h> ?

I tried to make INLINE-function.
But, it is no effect.

On 10=BF=F930=C0=CF, =BF=C0=C0=FC4=BD=C339=BA=D0, hm <raleigh...@gmail.com>=
 wrote:
> I make abs() function.
> It is same for original library.
> But, it is slow.
>
> int myAbs ( int number )
> {
>         return( number>0 ? number : -number );
>
> }
>
> I checked its running time, so It spend more than triple running time
> of original library function.
>
> Why is my function slow than abs-function of <math.h> ?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hm wrote:

> I tried to make INLINE-function.
> But, it is no effect.
> 
> On 10월30일, 오전4시39분, hm <raleigh...@gmail.com> wrote:
>> I make abs() function.
>> It is same for original library.
>> But, it is slow.
>>
>> int myAbs ( int number )
>> {
>>         return( number>0 ? number : -number );
>>
>> }
>>
>> I checked its running time, so It spend more than triple running time
>> of original library function.
>>
>> Why is my function slow than abs-function of <math.h> ?

Have you enabled ALL optimisations?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkrqvbAACgkQG6NzcAXitM8b2ACfTJUB4E5xaIqehA28sJOoNv+/
ALEAn2pDux8auHxrG9MwwxTNNJ7Xykgg
=+ZwA
-----END PGP SIGNATURE-----

hm wrote:
> I make abs() function.
> It is same for original library.
> But, it is slow.
> 
> int myAbs ( int number )
> {
> 	return( number>0 ? number : -number );
> }
> 
> I checked its running time, so It spend more than triple running time
> of original library function.
> 
> Why is my function slow than abs-function of <math.h> ?

Your function has an extra negation operation
when number is equal to zero.

Also because your function is written in C,
instead of in assembly language.

-- 
pete

On 30 Oct, 08:39, hm <raleigh...@gmail.com> wrote:
> I make abs() function.
....
> Why is my function slow than abs-function of <math.h> ?

I'm putting myself up to be shot down, but I would suspect that an
optimising compiler could replace a call to the abs() function with a
suitable piece of optimised assembler.

The manual page for abs() on my system says "GCC handles abs() and labs
() as builtin functions." which reinforces my suspicion.

On Oct 30, 1:39=A0am, hm <raleigh...@gmail.com> wrote:
> I make abs() function.
> It is same for original library.
> But, it is slow.
>
> int myAbs ( int number )
> {
> =A0 =A0 =A0 =A0 return( number>0 ? number : -number );
>
> }
>
> I checked its running time, so It spend more than triple running time
> of original library function.
>
> Why is my function slow than abs-function of <math.h> ?

The abs function is not in math.h.  Its prototype is there but you
have no idea where the function itself comes from.  It is entirely
possible that the compiler generates inline code for this function
without passing parameters or returning a value as your function must
do.

If you are really interested in the answer to your question, a
starting point would be to generate some code that calls both
functions and examine the resulting machine instructions.

In <Ye-dnff_IrymQHfXnZ2dnUVZ_gKdnZ2d@earthlink.com>, pete wrote:

> hm wrote:
>> I make abs() function.
>> It is same for original library.
>> But, it is slow.
>> 
>> int myAbs ( int number )
>> {
>> return( number>0 ? number : -number );
>> }
>> 
>> I checked its running time, so It spend more than triple running
>> time of original library function.
>> 
>> Why is my function slow than abs-function of <math.h> ?
> 
> Your function has an extra negation operation
> when number is equal to zero.
> 
> Also because your function is written in C,
> instead of in assembly language.

Well, glibc actually defines abs as a simple macro.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

hm <raleighnc7@gmail.com> writes:

> I make abs() function.
> It is same for original library.
> But, it is slow.
>
> int myAbs ( int number )
> {
> 	return( number>0 ? number : -number );
> }
>
> I checked its running time, so It spend more than triple running time
> of original library function.
>
> Why is my function slow than abs-function of <math.h> ?

Use a good debugger. switch it into machine code /assembler view. Step
through it. You will learn a lot.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

hm wrote:

> I make abs() function.
> It is same for original library.
> But, it is slow.
> 
> int myAbs ( int number )
> {
> return( number>0 ? number : -number );
> }
> 
> I checked its running time, so It spend more than triple running
> time of original library function.
> 
> Why is my function slow than abs-function of <math.h> ?

<math.h> declares "fabs()"; "abs()" is defined in <stdlib.h>.
You unnecessarily negate zero values; other than that, it all
depends on the optimization capabilities and how your libc is
implemented.  In GNU C, you could replace the function by:

   #define abs(iv) {(int _i = (iv); _i >= 0 ? /* empty */: -_i)}

which should be faster than even a hand-coded assembly function.
Another option would be function inlining, but that also depends
on the C compiler you're using.


mike

In article <Yu6dncUhQoDIcnfXnZ2dnUVZ7sti4p2d@bt.com> rjh@see.sig.invalid writes:
....
 > Well, glibc actually defines abs as a simple macro.

Hrm, here it is:

extern int abs (int __x) __THROW __attribute__ ((__const__)) __wur;

I suspect some compiler magic.
-- 
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn  amsterdam, nederland; http://www.cwi.nl/~dik/

In 
<6c732d13-0b76-4a17-9881-0105307a598c@v30g2000yqm.googlegroups.com>, 
hm wrote:

> I make abs() function.
> It is same for original library.
> But, it is slow.
> 
> int myAbs ( int number )
> {
> return( number>0 ? number : -number );
> }
> 
> I checked its running time, so It spend more than triple running
> time of original library function.

In my testing, it came out at roughly twice the time.

Changing it to n < 0 ? -n : n more or less eliminated the differences.

(Data: For 10,000,000 trials, 0.23 seconds vs 0.10 seconds for the 
first version, and 0.13 seconds vs 0.11 seconds for the second.)

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

In <KsBzwC.BL5@cwi.nl>, Dik T. Winter wrote:

> In article <Yu6dncUhQoDIcnfXnZ2dnUVZ7sti4p2d@bt.com>
> rjh@see.sig.invalid writes: ...
>  > Well, glibc actually defines abs as a simple macro.
> 
> Hrm, here it is:
> 
> extern int abs (int __x) __THROW __attribute__ ((__const__)) __wur;

Oops, it seems I disremembered. Sorry.

Anyway, getting the comparison right (<0 rather than >0) is likely to 
lift a user function into the same general performance bracket as the 
libc version.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

Michael Schumacher <misc_@gmx.de> writes:
> hm wrote:
>
>> I make abs() function.
>> It is same for original library.
>> But, it is slow.
>> 
>> int myAbs ( int number )
>> {
>> return( number>0 ? number : -number );
>> }
>> 
>> I checked its running time, so It spend more than triple running
>> time of original library function.
>> 
>> Why is my function slow than abs-function of <math.h> ?
>
> <math.h> declares "fabs()"; "abs()" is defined in <stdlib.h>.
> You unnecessarily negate zero values; other than that, it all
> depends on the optimization capabilities and how your libc is
> implemented.  In GNU C, you could replace the function by:
>
>    #define abs(iv) {(int _i = (iv); _i >= 0 ? /* empty */: -_i)}

> which should be faster than even a hand-coded assembly function.

Shame it would (a) not compile, for several reasons; and (b)
give the wrong answer. But apart from that, you can't fault 
the speed - the speed's great.

Phil
-- 
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1

On 2009-10-30, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
> Michael Schumacher <misc_@gmx.de> writes:
>> In GNU C, you could replace the function by:
>>
>>    #define abs(iv) {(int _i = (iv); _i >= 0 ? /* empty */: -_i)}
>
>> which should be faster than even a hand-coded assembly function.

> Shame it would (a) not compile, for several reasons; and (b)
> give the wrong answer. But apart from that, you can't fault 
> the speed - the speed's great.

I don't know enough of the GNU extensions to comment, but it doesn't
strike me as obvious that this wouldn't compile or wouldn't work.  He
did say "in GNU C".  Although I didn't think the ?: shortcut operator
worked that way -- specifically, I think that tihs would yield 1 in the
case where "_i >= 0", because the general form of the GNU extension is
"x ?: y" which is "x, or y if x compares equal to zero".

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs <usenet-nospam@seebs.net> writes:

> On 2009-10-30, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
>> Michael Schumacher <misc_@gmx.de> writes:
>>> In GNU C, you could replace the function by:
>>>
>>>    #define abs(iv) {(int _i = (iv); _i >= 0 ? /* empty */: -_i)}
>>
>>> which should be faster than even a hand-coded assembly function.
>
>> Shame it would (a) not compile, for several reasons; and (b)
>> give the wrong answer. But apart from that, you can't fault 
>> the speed - the speed's great.
>
> I don't know enough of the GNU extensions to comment, but it doesn't
> strike me as obvious that this wouldn't compile or wouldn't work.  He
> did say "in GNU C".  Although I didn't think the ?: shortcut operator
> worked that way -- specifically, I think that tihs would yield 1 in the
> case where "_i >= 0", because the general form of the GNU extension is
> "x ?: y" which is "x, or y if x compares equal to zero".

Yes.  (This extension is usually just useful for pointers, if
then.)

Also, the syntax for statement expressions is ({...}), not {(...)}.
-- 
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.\
 \n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

Seebs <usenet-nospam@seebs.net> writes:
> On 2009-10-30, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
>> Michael Schumacher <misc_@gmx.de> writes:
>>> In GNU C, you could replace the function by:
>>>
>>>    #define abs(iv) {(int _i = (iv); _i >= 0 ? /* empty */: -_i)}
>>
>>> which should be faster than even a hand-coded assembly function.
>
>> Shame it would (a) not compile, for several reasons; and (b)
>> give the wrong answer. But apart from that, you can't fault 
>> the speed - the speed's great.
>
> I don't know enough of the GNU extensions to comment, but it doesn't
> strike me as obvious that this wouldn't compile or wouldn't work.  He
> did say "in GNU C".  Although I didn't think the ?: shortcut operator
> worked that way -- specifically, I think that tihs would yield 1 in the
> case where "_i >= 0", because the general form of the GNU extension is
> "x ?: y" which is "x, or y if x compares equal to zero".

It /has/ struck you as obvious that it wouldn't work then.

The non-compilation is due to ({}) being the idiom not {()}, and 
the statements within needing to be complete statements.

Phil
-- 
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1

On 2009-10-30, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
> It /has/ struck you as obvious that it wouldn't work then.

No.  It struck me as suspicious but not obvious, because for all I know
GNU C's idiom is now "x <op value> ?: y" for "x if operator yields non-zero,
otherwise y".  I don't really follow that.

(I sorta wish we'd picked up the "x ?: y" idiom, because it is sort of
pretty, but I don't actually care that much.)

> The non-compilation is due to ({}) being the idiom not {()}, and 
> the statements within needing to be complete statements.

Ahh.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

On Oct 30, 1:39=A0am, hm <raleigh...@gmail.com> wrote:
> I make abs() function.
> It is same for original library.
> But, it is slow.
>
> int myAbs ( int number )
> {
> =A0 =A0 =A0 =A0 return( number>0 ? number : -number );
>
> }
>
> I checked its running time, so It spend more than triple running time
> of original library function.
>
> Why is my function slow than abs-function of <math.h> ?

What inputs are you using?  Can you post the exact code you used to
test the speed?

Phil Carmody wrote:

> Michael Schumacher <misc_@gmx.de> writes:
>> hm wrote:
>>
>>> I make abs() function.
>>> It is same for original library.
>>> But, it is slow.
>>> 
>>> int myAbs ( int number )
>>> {
>>> return( number>0 ? number : -number );
>>> }
>>> 
>>> I checked its running time, so It spend more than triple running
>>> time of original library function.
>>> 
>>> Why is my function slow than abs-function of <math.h> ?
>>
>> <math.h> declares "fabs()"; "abs()" is defined in <stdlib.h>.
>> You unnecessarily negate zero values; other than that, it all
>> depends on the optimization capabilities and how your libc is
>> implemented.  In GNU C, you could replace the function by:
>>
>>    #define abs(iv) {(int _i = (iv); _i >= 0 ? /* empty */: -_i)}
> 
>> which should be faster than even a hand-coded assembly function.
> 
> Shame it would (a) not compile, for several reasons; and (b)
> give the wrong answer. But apart from that, you can't fault
> the speed - the speed's great.

*blush*  Sorry, that #define should, of course, read:

   #define abs(iv) ({int _i = (iv); _i >= 0 ? /* empty */: -_i;})

Other than that, it's valid GNU C code, and it should produce the
fastest code possible on any given architecture for which gcc is
available.


Cheers,
mike

Seebs wrote:

> On 2009-10-30, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
>> It /has/ struck you as obvious that it wouldn't work then.
> 
> No.  It struck me as suspicious but not obvious, because for all I know
> GNU C's idiom is now "x <op value> ?: y" for "x if operator yields
> non-zero,
> otherwise y".  I don't really follow that.

It still compiles with gcc 4.3.2, so I guess it's still valid.

>> The non-compilation is due to ({}) being the idiom not {()}, and
>> the statements within needing to be complete statements.
> 
> Ahh.

Yes.  Stupid me managed to confuse parens/braces and to forget the
semi-colon at the end of the "statement" -- and all of this in just
one line!  Guess I'm getting old...  ;-)


Cheers,
mike

On 2009-10-31, Michael Schumacher <misc_@gmx.de> wrote:
>    #define abs(iv) ({int _i = (iv); _i >= 0 ? /* empty */: -_i;})
>
> Other than that, it's valid GNU C code, and it should produce the
> fastest code possible on any given architecture for which gcc is
> available.

Won't the ?: produce 1 if i >= 0, rather than i?

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

Seebs wrote:

> On 2009-10-31, Michael Schumacher <misc_@gmx.de> wrote:
>>    #define abs(iv) ({int _i = (iv); _i >= 0 ? /* empty */: -_i;})
>>
>> Other than that, it's valid GNU C code, and it should produce the
>> fastest code possible on any given architecture for which gcc is
>> available.
> 
> Won't the ?: produce 1 if i >= 0, rather than i?

If so, just replace "/* empty */" with "_i" (t'was hackish, anyway).


mike