which code runs faster?

N

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&0x7f);
}

or

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

?

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

Ben Pfaff

nelu said:
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;
 
B

Ben Pfaff

nelu said:
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.
 
K

Keith Thompson

nelu said:
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.
 
W

Walter Roberson

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.
 
M

Mark McIntyre

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.
 
N

nelu

Walter said:
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.

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?
 
W

Walter Roberson

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.
 
K

Keith Thompson

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.)
 
N

nelu

Keith said:
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
 
P

Peter Nilsson

nelu said:
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.
 
N

nelu

Peter said:
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 :).
 
M

Mark McIntyre

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.
 
K

Keith Thompson

Mark McIntyre said:
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.
 
D

Dave Thompson

nelu wrote:

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.
Like any other implementation, just with wider than usual bytes.


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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top