The importance of using a 16bit integer

Question

How seriously do developers think about using a 16bit integer when writing code? I've been using 32bit integers ever since I've been programming and I don't really think about using 16bit.

Its so easy to declare a 32bit int because its the default for most languages.

Whats the upside of using a 16bit integer apart from a little memory saved?

Answer 1

You might need to wrap at 65535. You might need to work with a message sent from a device which includes fields which are 16 bit. Using 32 bit integers in this case would cause you to be accessing bits at the wrong offset in the message. You might be working on an embedded 16 bit micro, or an embedded 8 bit micro. Hint: not all processors are x86, 32 bit.

Answer 2

In large arrays, "little memory saved" could instead be "much memory saved".

Answer 3

I think most people use the default int on their platform. However there are times when you have to communicate with older systems or libraries that are expecting 16 bit or even eight bit integers (thank god we don't have to worry about 12 bit integers any more). This is especially true for databases. Also, if you're doing bit masking or bit shifting, you might have an algorithm that specifies the length of the integer. By default, and on platforms where memory is cheap, you should probably use integers sized to your processor.

Answer 4

The use of 16 bit integers is primarily for when you need to encode things for transmission over a network, for saving on hard disk, etc. without using up any more space than necessary. It might also occasionally be useful to save memory if you have a very large array of integers, or a lot of objects that contain integers.

Use of 16 bit integers without there being a good memory saving reason is pretty pointless. And 16 bit local variables are most often silently implemented with 32 or 64 bit integers anyway.

Answer 5

you have probably been using the 16 bit datatype more often than you knew. The char datatype in both C# and Java are 16 bit. Unicode is typically stored in a 16bit datatype.

Answer 6

It's hardly a little memory saved [read: 50%] when you allocate memory for a large number of numeric values. Common uses are:

• COM and external device interop
• Reducing memory consumption for large arrays where each number will never exceed a couple thousands in magnitude
• Unique hashes for pairs of objects, where no more than ~65K objects are needed (hash values can only be 32-bit ints, but note that hash table types must transform the value for internal representations so collisions are still likely, but equality can be based on exact hash matches)
• Speed up algorithms that rely on structs (smaller sized value types translates to increased performance when they are copied around in memory)

Answer 7

Those 2 bytes add up. Your data types eventually become part of array or databases or messages, they go into data files. It adds up to a lot of wasted space and on embedded systems it can make a huge difference.

When we do peer review of our code at work, if something is sized incorrectly, it will be written as a discrepancy and must be corrected. If we find something that has a range of 1-1000 using an int32_t, it has to be corrected. The range must also be documented in a comment. Our department does not allow use of int, long, etc, we must use int32_t, int16_t, uint16_t, etc. so that the expected size is documented.

uint16_t conicAngle;   // angle in tenths of a degree (range 0..3599)

or in Ada:

type Amplitude is range 0 .. 255;   // signal amplitude from FPGA

Get in the habit of using what you need and no more and documenting what you need (if the language doesn't support it).

We are currently in the process of fixing a performance problem by resizing the data types in several messages, they have 32 bit fields that could be 8 or 16 bit. By resizing them appropriately we can reduce the message rate in half and improve our data throughput to meet the requirements.

Answer 8

This is really important in database development, because sometimes people are using a lot more space than is really needed (e.g. using int when small would have been sufficient). When you have tables with millions of rows this can be important factor in e.g. database size and queries. I would recommend people using always the appropriate datatype for columns.

I also try to use the correct datatype for other development, I know it can be a pain dealing with long and small (pretty convenient to have everyting int) but I think it pays off in the end, for example when serializing objects.

Answer 9

Once upon a time, in the land of Earth, there existed devices called computers.

In the early days following the invention of "computers," there was limited storage in memory for fancy things like numbers and strings.

Billy, a programmer, was encouraged by the evil Wizard (his boss) to use the least amount of memory that he could!

Then one day, memory sizes got large enough that everyone could use 32-bit numbers if they wanted!

I could continue on, but all the other obvious things were already covered.

Answer 10

APIs/interfaces (e.g. TCP/IP port numbers) and algorithms that require manipulation (e.g. rotation) of 16-bit values.

Answer 11

16 bits is still plenty big enough to hold pixel channel values (e.g. R, G, or B). Most pixels only use 8 bits to store a channel, but Photoshop has a 16-bit mode that professionals use.

In other words, a pixel might be defined as struct Pixel16 { short R, G, B, A; } or an image might be defined as separate channels of struct Channel16 { short channel[]; }

Answer 12

you ask: Any good reason to keep them around?

Since you say 'language-agnostic' the answer is a 'certainly yes'.

The computer CPU still works with bytes, words, full registers and whatnot, no matter how much these 'data types' are abstracted by some programming languages. There will always be situations where the code needs to 'touch the metal'.

Answer 13

when there is memory constraints short can help u lot. for e.g. while coding for embedded systems, u need to consider the memory.

Answer 14

Now that we have cars, we don't walk or ride horses as much, but we still do walk and ride horses.

There is less need to use shorts these days. In a lot of situations the cost of disk space and availability of RAM mean that we no longer need to squeeze every last bit of storage out of computers as we did 20 years ago, so we can sacrifice a bit of storage efficiency in order to save on development/maintenance costs.

However, where large amounts of data are used, or we are working with systems with small memories (e.g. embedded controllers) or when we are transmitting data over networks, using 32 or 64 bits to represent a 16-bit value is just a waste of memory/bandwidth. It doesn't matter how much memory you have, wasting half or three quarters of it would just be stupid.

Answer 15

16-bit values are still in great demand (though unsigned would do - don't really need signed). For example,

• 16 bit Unicode - UTF-16/UCS-2.
• 16 bit graphics - especially for embedded devices.
• 16 bit checksums - for UDP headers and similar.
• 16 Bit devices - e.g. many norflash devices are 16 bit.

Answer 16

The question should really be why we need a 16-bit primitive data type, and the answer would be that there is an awful lot of data out there which is naturally represented in 16 bits. One ubiquitous example is audio, e.g. CD audio is represented as streams of 16 bit signed integers.

Answer 17

I was interested in the relative performance so I wrote this small test program to perform a very simple test of the speed of allocating, using, and freeing a significant amount of data in both int and short format.

I run the tests several times in case caching and so on are affected.

#include <iostream>
#include <windows.h>

using namespace std;

const int DATASIZE = 1000000;

template <typename DataType>
long long testCount()
{
    long long t1, t2;

    QueryPerformanceCounter((LARGE_INTEGER*)&t1);

    DataType* data = new DataType[DATASIZE];
    for(int i = 0; i < DATASIZE; i++) {
        data[i] = 0;
    }

    delete[] data;

    QueryPerformanceCounter((LARGE_INTEGER*)&t2);
    return t2-t1;
}

int main()
{

    cout << "Test using short : " << testCount<short>() << " ticks.\n";
    cout << "Test using int   : " << testCount<int>() << " ticks.\n";
    cout << "Test using short : " << testCount<short>() << " ticks.\n";
    cout << "Test using int   : " << testCount<int>() << " ticks.\n";
    cout << "Test using short : " << testCount<short>() << " ticks.\n";
    cout << "Test using int   : " << testCount<int>() << " ticks.\n";
    cout << "Test using short : " << testCount<short>() << " ticks.\n";
}

and here are the results on my system (64 bit quad core system running windows7 64 bit, but the program is a 32 bit program built using VC++ express 2010 beta in release mode)

Test using short : 3672 ticks.
Test using int   : 7903 ticks.
Test using short : 4321 ticks.
Test using int   : 7936 ticks.
Test using short : 3697 ticks.
Test using int   : 7701 ticks.
Test using short : 4222 ticks.

This seems to show that there are significant performance advantages at least in some cases to using short instead of int when there is a large amount of data. I realise that this is far from being a comprehensive test, but it's some evidence that not only do they use less space but they can be faster to process too at least in some applications.