which code runs faster?

[nelu]

I know I can use unsinged byte, but I need it for java, which code runs
faster in C?

int f1(char b) {
return (b&0x80)|(b&0x7 f);
}

or

int f2(char b) {
return b>0?b:256+bl
}

?

In my tests f2 performs better. I need a better opinion. :-)
Thanks.

[nelu]

nelu wrote:

In my tests f2 performs better. I need a better opinion. :-)

Ooops, my java tests... f1 performs better in C, it seems. (gcc -O3)

[Ben Pfaff]

"nelu" <ta********@gma il.com> writes:

I know I can use unsinged byte, but I need it for java, which code runs
faster in C?

int f1(char b) {
return (b&0x80)|(b&0x7 f);
}

or

int f2(char b) {
return b>0?b:256+bl
}

return b & 0xff;
--
"...what folly I commit, I dedicate to you."
--William Shakespeare, _Troilus and Cressida_

[nelu]

Ben Pfaff wrote:

return b & 0xff;

Right, still, which of the ones I wrote should be faster?

[Ben Pfaff]

"nelu" <ta********@gma il.com> writes:

Ben Pfaff wrote:

return b & 0xff;

Right, still, which of the ones I wrote should be faster?

There's no way to say. It will vary from one machine to another
and one compiler to another. If you want an answer for your
implementation, try them both.
--
"C has its problems, but a language designed from scratch would have some too,
and we know C's problems."
--Bjarne Stroustrup

[Keith Thompson]

"nelu" <ta********@gma il.com> writes:

Ben Pfaff wrote:

return b & 0xff;

Right, still, which of the ones I wrote should be faster?

The only way to know is to measure it. The answer is likely to vary
depending on the compiler, the system you're using, and any
optimization options used.

Unless the code is critical (meaning that you've measured it and found
that its performance has a *significant* impact on the performance of
your program), you should probably just write the clearest code
possible and let the compiler worry about it.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Walter Roberson]

In article <87************ @benpfaff.org>,
Ben Pfaff <bl*@cs.stanfor d.edu> wrote:

"nelu" <ta********@gma il.com> writes:

I know I can use unsinged byte, but I need it for java, which code runs
faster in C? int f1(char b) {
return (b&0x80)|(b&0x7 f);
} int f2(char b) {
return b>0?b:256+bl
}

return b & 0xff;

Or, if it is known that CHAR_BIT is 8, then

return (int)(unsigned char)b;

This has the advantage that on compilers where char is already unsigned
and 2s complement, this will become just return b .

If the environment might not be 2s complement, then f1() and f2()
are not equivilent. On a signed-magnitude machine, (b&0x80) might
be equivilent to b&0x00. On SM, -1 might be 1|0000001
and f2() would produce 255 but f1() would probably produce 0x01.
b & 0xff has the same difficulty. (int)(unsigned char)b would
produce the same result as f2() on such a machine.

Thus, the designer must decide whether the intent is to get at the
native bit pattern, or to get at the value "as if" it were 2s complement.
--
Programming is what happens while you're busy making other plans.

[Mark McIntyre]

On 12 Dec 2005 13:35:09 -0800, in comp.lang.c , "nelu"
<ta********@gma il.com> wrote:

I know I can use unsinged byte, but I need it for java, which code runs
faster in C?

neither.
both.
There's no way to say, its implementation specific and might even
depend on what else the computer was doing, etc etc. Why does it
matter? Do you know that you have a performance bottleneck here?

There are three rules about optimisation.
1) don't do it
2) don't do it YET
3) you can guess what this one is.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[nelu]

Walter Roberson wrote:

Or, if it is known that CHAR_BIT is 8, then

return (int)(unsigned char)b;

This has the advantage that on compilers where char is already unsigned
and 2s complement, this will become just return b .

If the environment might not be 2s complement, then f1() and f2()
are not equivilent. On a signed-magnitude machine, (b&0x80) might
be equivilent to b&0x00. On SM, -1 might be 1|0000001
and f2() would produce 255 but f1() would probably produce 0x01.
b & 0xff has the same difficulty. (int)(unsigned char)b would
produce the same result as f2() on such a machine.

Thus, the designer must decide whether the intent is to get at the
native bit pattern, or to get at the value "as if" it were 2s complement.
--
Programming is what happens while you're busy making other plans.

I was wondering which is the best way to get the value of a byte
between 0 and 255. The difference between the two functions in C is big
compared to the same functions written in JAVA. The bit operations are
a lot faster than the if function on my machine (AMD64) when compiled
with -O3. I thought there would've been an easy answer since both codes
look really simple.
I guess the safest way is to use the if function for what I need since
bit operations can have different results in that form from machine to
machine, right?

[Walter Roberson]

In article <11************ **********@z14g 2000cwz.googleg roups.com>,
nelu <ta********@gma il.com> wrote:

Walter Roberson wrote:

Or, if it is known that CHAR_BIT is 8, then return (int)(unsigned char)b; Thus, the designer must decide whether the intent is to get at the
native bit pattern, or to get at the value "as if" it were 2s complement.

I was wondering which is the best way to get the value of a byte
between 0 and 255. I guess the safest way is to use the if function for what I need since
bit operations can have different results in that form from machine to
machine, right?

Suppose, though, that CHAR_BIT is not 8. Imagine, for example, that
the "Windows" key operated by setting the 9th bit. How is your function
defined in such a case?

"byte" is a general concept, but the size of a "byte" varies
with different architectures. Same with "char". "byte" and "char"
are not exactly synonyms either.
If I understand correctly something I have read in passing, in Java
the size of characters is fixed, defined as being the same on
every implementation. This might perhaps affect your choice of
semantics you define.
--
Prototypes are supertypes of their clones. -- maplesoft