[Zlib-devel] crc32 big/little endian

[John Bowler]

From: Mark Adler
>On the other hand, it may be faster for the machine to access
>the native word size in the array when 64 bits.

I wouldn't expect this simply because there really is no such thing as native word size on higher end CPUs; they have multiple buses what vary in width.  A typical 32 bit processor may load data from DRAM using a 128 bit bus and after that it doesn't matter how it is accessed.  On the other hand an ARM on a washing machine might actually do 16 bit access throughout, even though it's a 32 bit processor...

>On the other hand, the table would take less cache space if it
>were half the size.  Any opinions on that?  

Less size is always better (well, you asked for an opinion ;-)

What would be nice is a --small option to configure to force all of the FAT_CODE options off in zconf.h, or just a list somewhere of what to set, or a #ifndef Z_SMALL to protect the setting of every such option.  (I didn't know about NOBYFOUR until you mentioned it.)

>On the vast majority of platforms with memory measured in gigabytes (a difference
>of six orders of magnitude!) there is no suffering.

The vast majority of platforms have only a few MByte of memory, if that; and I really am talking about *platforms*.  The vast number of *machines* have even less memory (Poisson distribution of number of machines by platform RAM, I'm guessing).

>Only in embedded applications with limited memory could that cause any suffering.  Those >applications can customize the code.

My own opinion is that the default build should be small and that it should be the relatively smaller number of high-end platform builders (who have more time and more money) who should be turning on options.  But then the high end platform builders tend to be a lot louder too, so it may be less suffering for *you* just to put all the fat code in by default.

It would be nice to know, reliably, at every release, how to get rid of it ;-)

John Bowler <jbowler at acm.org>