By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,778 Members | 1,947 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,778 IT Pros & Developers. It's quick & easy.

which code runs faster?

P: n/a
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&0x7f);
}

or

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

?

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

Dec 12 '05 #1
Share this Question
Share on Google+
16 Replies


P: n/a

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)

Dec 12 '05 #2

P: n/a
"nelu" <ta********@gmail.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&0x7f);
}

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_
Dec 12 '05 #3

P: n/a

Ben Pfaff wrote:
return b & 0xff;


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

Dec 12 '05 #4

P: n/a
"nelu" <ta********@gmail.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
Dec 12 '05 #5

P: n/a
"nelu" <ta********@gmail.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_Keith) 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.
Dec 12 '05 #6

P: n/a
In article <87************@benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.edu> wrote:
"nelu" <ta********@gmail.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&0x7f);
} 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.
Dec 12 '05 #7

P: n/a
On 12 Dec 2005 13:35:09 -0800, in comp.lang.c , "nelu"
<ta********@gmail.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 =----
Dec 12 '05 #8

P: n/a
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?

Dec 12 '05 #9

P: n/a
In article <11**********************@z14g2000cwz.googlegroups .com>,
nelu <ta********@gmail.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
Dec 13 '05 #10

P: n/a
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
In article <11**********************@z14g2000cwz.googlegroups .com>,
nelu <ta********@gmail.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.


No, they're not synonyms, but a "byte" is by definition the size of
type "char" in C. (Of course the terms are used differently outside
the context of C.)

--
Keith Thompson (The_Other_Keith) 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.
Dec 13 '05 #11

P: n/a
nelu wrote:
Keith Thompson wrote:
No, they're not synonyms, but a "byte" is by definition the size of
type "char" in C. (Of course the terms are used differently outside
the context of C.)
In Java byte (8 bits) is the equivalent of signed char.


No. In C, signed char needn't be two's complement. You should be trying
to
use int8_t, rather than signed char.
char in java has 2 bytes.

I have never used a machine that has more or less than 8 bits in 1 byte
(not even on Sinclair Spectrum).
Some of the older PDP implementations had non-8-bit byte sizes.
Can you tell me how they work?
Like any other implementation, just with wider than usual bytes.
Is it possible for them to comunicate with 8 bits bytes machines and if yes,
how?


The same way that 8-bit byte machines communicate through 7-pin din
connectors.
Any number of ways. But none of them are necessarily topical in
comp.lang.c.

--
Peter

Dec 13 '05 #12

P: n/a

Peter Nilsson wrote:
No. In C, signed char needn't be two's complement. You should be trying
to
use int8_t, rather than signed char.


True, I was thinking about char the way I used it on my machine :-).

Dec 13 '05 #13

P: n/a

Keith Thompson wrote:

No, they're not synonyms, but a "byte" is by definition the size of
type "char" in C. (Of course the terms are used differently outside
the context of C.)


In Java byte (8 bits) is the equivalent of signed char. char in java
has 2 bytes.
I have never used a machine that has more or less than 8 bits in 1 byte
(not even on Sinclair Spectrum). Can you tell me how they work? Is it
possible for them to comunicate with 8 bits bytes machines and if yes,
how?

Thanks

Dec 13 '05 #14

P: n/a
On 12 Dec 2005 15:09:08 -0800, in comp.lang.c , "nelu"
<ta********@gmail.com> wrote:
I was wondering which is the best way to get the value of a byte
between 0 and 255.


In C, a byte is the same size as a char. You get its value by
examining it. No casts are needed.

----== 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 =----
Dec 13 '05 #15

P: n/a
Mark McIntyre <ma**********@spamcop.net> writes:
On 12 Dec 2005 15:09:08 -0800, in comp.lang.c , "nelu"
<ta********@gmail.com> wrote:
I was wondering which is the best way to get the value of a byte
between 0 and 255.


In C, a byte is the same size as a char. You get its value by
examining it. No casts are needed.


Unless it's a signed char (or a plain char and plain char happens to
be signed); then you can cast it to unsigned char.

--
Keith Thompson (The_Other_Keith) 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.
Dec 14 '05 #16

P: n/a
On 12 Dec 2005 20:22:02 -0800, "Peter Nilsson" <ai***@acay.com.au>
wrote:
nelu wrote:

<snip>
I have never used a machine that has more or less than 8 bits in 1 byte
(not even on Sinclair Spectrum).


Some of the older PDP implementations had non-8-bit byte sizes.

Terminology: this sounds like you mean different C implementations on
one "PDP" machine, or several "PDP" machines that implement a common
architecture. In fact Programmed Data Processor was the name used for
a series of machines by DEC (Digital Equipment Corporation) that were
mostly quite different, some with multiple implementations. There were
four models of PDP-10 namely KA-10, KI-10, KL-10, KS-10 which
implemented the same architecture, which was nearly the same as PDP-6.
There were several models of PDP-8 of which I recall 8/s, 8/i, 8/e,
8/m and 8/a, which implemented one architecture, nearly the same as
PDP-5 and similar to PDP-12 aka LINC-12, but very different from -6
and -10. PDP-7 and -9 were similar, and I believe also similar to -4
and -1, but different from -6/10 and -5/8/12. There were many
(numbered) models of PDP-11 like 11/20, 11/40, 11/45, 11/34, 11/70
etc. all implementing basically the same architecture, different from
all other PDP series machines.

There were also quite a few non-DEC machines with non-8-bit bytes.
Can you tell me how they work?


Like any other implementation, just with wider than usual bytes.
Is it possible for them to comunicate with 8 bits bytes machines and if yes,
how?


The same way that 8-bit byte machines communicate through 7-pin din
connectors.
Any number of ways. But none of them are necessarily topical in
comp.lang.c.


In the early days of the Internet and before that ARPANET, this was a
significant issue and there are a number of features (still) specified
especially in FTP to deal with data exchange with systems having a
byte other than 8 bits, no longer used today except perhaps
occasionally by mistake.

- David.Thompson1 at worldnet.att.net
Dec 19 '05 #17

This discussion thread is closed

Replies have been disabled for this discussion.