🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.c.moderated
Article #2469

Re: Efficiency Question : bits vs. bytes (or anything else, for that matter)

#2469
From: Richard A. O'Keefe
Date: Tue, 02 Apr 1996 12:38
75 lines
2883 bytes
vjarnot@mnw.net (Asmodeus) writes:
>I have set up an array in the following manner (obviously I just need
>0 or 1) :

>typedef struct my_bits {
>	unsigned the_bit : 1;
>};

I see a struct tag, but where is the identifier that typedef is supposed
to be defining?  Surely you meant

typedef struct {
    unsigned the_bit: 1;
} my_bits;


>my_bits the_array[800][800];

I don't see the point of this.
*EVERY* C object is a whole number of bytes.
Why?  Because the standard says so.

This means that each instance of your struct occupies AT LEAST one byte.
There are many C systems on which each instance of your struct will
occupy four bytes.

You can pack bit fields within a record, but array elements CANNOT be
packed tighter than bytes in C.

>	My question is this : I have read that some operations ( =,+,- are
>what I use) are slower when performed on bits as opposed to other >types.

Completely bogus.  Operations such as + and - are not performed on bits
at all.  As soon as you mention a bitfield, such as

	the_array[10][20].the_bit

the spell causes it to materialise as an 'unsigned' (if you had declared
the bit field as "signed int the_bit: 1;" it would have materialised as
a 'signed int').  + and - then operate on the unsigned value just as they
normally would.

A better way to think about it is that LOADING and STORING bit fields
may be slower than loading or storing normal arithmetic values; on the
other hand it may not be.

>My objective is to optimize the code for speed, and I figured
>using less memory would help me do so, now I'm having doubts.  So what
>is more efficient, bits or some other type???

Packing to the bit level is a good way to optimise SPACE but a truly
dreadful way to optimise TIME, particularly when you aren't even optimising
space in the first place.

A good compromise would be to use

	typedef char my_bit;

	my_bit the_array[800][800];

Be warned that some modern machines are not particularly speedy with
objects smaller than a word (think "Alpha"), so that

	#ifdef	CHAR_IS_SLOW
	typedef int my_bit;
	#else
	typedef char my_bit;
	#endif
	my_bit the_array[800][800];

might be better.

-- 
Result of state election = 50% Victorians didn't get MP of their choice.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
Technical Details
Message-ID: <4jr741$h8l@solutions.solon.com>
Path: arc1-ca.pugleaf.net!solon.com!not-for-mail
References: <4jbciv$2kk@solutions.solon.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!solon.com!not-for-mail
From: ok@cs.rmit.edu.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c.moderated
Subject: Re: Efficiency Question : bits vs. bytes (or anything else, for that matter)
Date: 2 Apr 1996 06:38:25 -0600
Organization: Comp Sci, RMIT, Melbourne, Australia
Sender: clc@solutions.solon.com
Approved: clc@solutions.solon.com
Message-ID: <4jr741$h8l@solutions.solon.com>
References: <4jbciv$2kk@solutions.solon.com>
NNTP-Posting-Host: solutions.solon.com
X-Newsreader: NN version 6.5.0 #0 (NOV)