Re: [LI] Sizeof structure

[Babu Kalakrishnan <kalakrishnan@xxxxxxxx>]

Raj,

Moving this thread to the [LIP]..

On Thu, Feb 17, 2000 at 06:56:27PM +0530, Raj Mathur typed:
> >>>>> "Babu" == Babu Kalakrishnan <kalakrishnan@xxxxxxxx> writes:
>     Babu> [snip]
>     Babu> Why would I do that ? I think you can always code your
>     Babu> structure read/write functions in such a way that it is
>     Babu> readable across platforms with reasonably standard
>     Babu> architectures (by say casting to (char *) etc.  as you
>     Babu> suggested). I think it's not that tought to tackle the
>     Babu> endian-ness issue as well..

> Sure, but you're forgetting that programmer time is much more
> expensive than disk space.  

I wasn't really referring to disk space when I said 500MBs of text data.
(though that's also a saving)..I was referring to the performance issue -
the time taken in reading the bigger input file and parsing it into binary
form would be a major bottleneck.. After all I/O speeds haven't really
kept pace with with the increase in CPU power in recent years.

When a programmer writes inefficient code that causes a program to take
even 1 minute extra to execute, Imagine the number of man-hours that are
lost when that program is used by thousands of users day-in and day-out !
If the company that executed the job had insisted on an efficient program
in the first place, the overall saving (Man-hours saved by users minus the
extra effort put in by the programmer) would always be positive for
non-trivial programs. Imagine the savings if WIN NT would boot up in 5
seconds !! (or 15 seconds for that matter)..

> Given enough time, you can code extremely
> efficient and small programs in assembler, but how many people do it
> today?  

The problem with writing in assembly is not really the extra effort
required, but the high possibility of undetected bugs creeping in when the
program is big. (I'm not saying that C is much better.. With it's cryptic
syntax, C code is equally bug prone..You'd be better off coding in Pascal,
Java or Ada)

>The same logic applies to data: if it's going to take a
> programmer 2 days to figure out the structure and another 2 days to
> decode it on a foreign architecture, it's probably worth it to push
> the data into ASCII in the first place and buy another 5 Rs. 1000
> DAT's to store it on.

Please read the first para quoted above carefully. I was talking about
coding the structure read/write functions in such a way that it can be
"reasonably" portable. For instance, see the following code :

/* Say my intrinsic need is for 16 bit integers only - should be portable
   across 16, 32, 64 bit architectures and little/big-endian systems */
typedef struct {
	int myint1;	
	char mychar1;
	int myint2;	 
	} MYSTRUC;	

#define BASIC_INT_SIZE 4  
 	/* Make this 8 for 64 bit systems, 2 for Turbo C - Real mode */
/*#define BIG_ENDIAN */ 
	/* Uncomment this for BIG-ENDIAN architectures */
int read_myint16(FILE *fd) 
{
	int x=0;
	char *c;

#ifdef BIG_ENDIAN
	c = (char *) (&x);
	fread(&c[BASIC_INT_SIZE-1],1,1,fd);
	fread(&c[BASIC_INT_SIZE-2],1,1,fd);
#else
	fread(&x,2,1,fd);
#endif	
	return x;
}

/* Similar code for write_myint16 */

void read_mystruc(FILE *fd,MYSTRUC *m)
{
	m->myint1 = read_myint16(fd);
	fread(&m->mychar,1,1,fd);
	m->myint2 = read_myint16(fd);
}

/* Similar code for write structure also */

I suppose the above example shows what I was trying to imply. So a
programmer need not take 2 days to figure out the structure as long as one
is running on architectures on which the code was intended to be
portable across. Once you're on totally alien architectures, ASCII data
can have the same amount of portability issues as binary data.

> IMHO portability is much more critical than efficiency, especially
> when the efficiency in question refers to usage of non-human
> resources.  It would have been easier for everyone to use 4 bytes for
> storing the year instead of trying to save 2 bytes per record, but how
> many people did it?  And we are all familiar with the cost of fixing
> that small ``efficiency gain''?

Look at it from another perspective. In case the year field was coded in
binary, we could have had a range of 65536 years with just 2 bytes !! ;-)
My code (written in 1983 for a Z80 processor) with 1 byte for the year
field still works and will continue to work till the year 2225 ! It all
depends on how much resources are available and how one utilizes it
efficiently. (1 byte was quite a lot of memory  in 1976 !!)


>     Babu> P.S. I strongly believe that 100% portability is a
>     Babu> myth.. Look at the 100% pure (supposed to be 100% portable)
>     Babu> java programs that behave differently even on different
>     Babu> versions of the same Sun JDK !!
> 
> Java sucks.  I wish someone would come out with a better, GPL'd
> embeddable language.  No, not me.  I don't know anything about CS
> theory :-)
> 

<ENABLE ASBESTOS UNDERWEAR>

If you ask my opinion, as a high level language I'd rate Java to be a
much better one than C. (with no intentions of starting a language
war). It's the virtual machine concept which sucks.. Wish we had high
performance native compilers for Java in Linux.. (Anybody know of any ? -
Visual Age for Java has one for Windows, but not for Linux AFAIK) 

<DISABLE ASBESTOS UNDERWEAR>

Kala