Why are you wearing shorts?

Question

The guy short corresponds to a 16-bit integer - it is literally syntactic sugar for type Int16.

The current processors are all 64 bits, even on the most machines low-end. Some older machines still have processors with 32-bit architectures.

As far as I understand (and correct me if I’m wrong), it’s faster to work with an entire processor architecture size in most cases due to CPU optimizations. I.e.: if I am adding up 16-bit integers, the CPU records receive and treat 32-bit or 64-bit blocks anyway, and then there is still the work of zeroing out all bits beyond the sixteenth in the result (assuming there is no overflow treatment).

So, in what situations should I use the type short, and why?

Answer 1

In general there is no reason to use a short in applications, especially on . NET.

A case to use is if you have a volume much large numerical data within the range that fits into a short (-32768 to 32767). At a very large volume, decreasing from 4 to 2 bytes can give some advantage. But note that this volume really needs to be very large indeed. It is very rare to be necessary. And even if the volume is large also need to have the need (not having enough memory to use a int). Otherwise, it is micro-optimization that is not worth the effort.

Another point is that this memory usage optimization is valid when virtually only using data short in its structured data. If the information is in more complex structures, where the field of type short is only a part of the memory consumption, mainly if the structure is of a reference type (objects allocated in the heap), gain certainly won’t help much in memory consumption.

Depending on of the platform and the implementation of the Jitter may even have a worsening performance using short. There is usually a gain when the size of the data equals the word size of the processor. But don’t try to use information about implementation, it can change without warning. If it has a very large volume of data that needs to be manipulated intensely the most common is that it has some gain mainly by the ability to store more (double) cached elements using a short than a int.

You may have losses, in some cases, also by having to make unnecessary conversions. Much of . NET is better prepared to work with int. But the opposite can make the short more interesting. If you know you will use many methods that primarily work with short its use can prevent conversions, but are rare methods.

A typical case to avoid conversions is when working with interoperability with external code waiting for a short, mainly with C/C++ code, managed or not. Interoperability is the main case for which the short was created on . NET.

Documentation.

Answer 2

To maniero’s response already gives an excellent overview, I would just like to complement the following part:

The most common if you have a very large volume of data that needs to be manipulated intensively is that you have some gain by the ability to cache more elements using a short than a int.

Generally speaking, the influence of a good cache on a system’s performance is something not to be underestimated. Often a lot of attention is paid to local performance (cast) and the overall performance is forgotten (in a miss cache, several cycles are wasted - more than the overhead an extra instruction or two, depending on the case).

None of this contradicts the answer mentioned: only if the volume of data is large is there an advantage (although perhaps I disagree on what would be "very" large). Also, it is quite different for you to have, for example, an array of objects:

class MeuObjeto {
    Foo foo;
    Bar bar;
    Baz baz;
    short s;
}
MeuObjeto[] array = new MeuObjeto[10000];

Or an array of shorts:

short[] array = new short[10000];

In the first case, the space saving is minimal - even if the objects are in contiguous memory positions (depending on the case, they may not be) - and that is if the memory alignment does not eliminate this space difference. The use of short instead of int will not have a significant impact on Misses cache, so that the overhead of the cast operations shall not receive any positive consideration.

In the second case, the story is different: it will take twice as long for you to have one miss cache if you are accessing these elements sequentially, compared to an array of int. Even for random hits, the chance of the data you want to already be in the cache is twice as high. So, even though each individual operation is a little less efficient, the cycles you "save" by avoiding the Misses can compensate - making complete operation faster.

(In any case, it remains worth the advice to avoid premature optimizations / micro optimizations)

Answer 3

Not that it gets slower, because the CPU even being 64 bits, still has instructions to deal with numerical types smaller than the native.

The char of . Net for example, has 16 bits, which is equivalent to a short/ushort.

The real advantage I see in using the smaller integer types, would be to save memory in case of the need for an array with millions of items in memory... or even billions.

Other than that, it’s more practical to use the type int even.

Answer 4

The short type guarantees at the very least 16 bits -- is not a synonym for int16_t.

I only see use for it when you need to interact with a value or structure that is also short, like some hardware table, device driver or low-level API. For example, on a TCP/IP connection the port is unsigned short (http://www.gta.ufrj.br/ensino/eel878/sockets/sockaddr_inman.html)

It also happens a lot when dealing with data coming from the network, usually in conjunction with htons(). When dealing with network, it is best to use the guaranteed size types, like int16_t or uint16_t, which ensure the exact bit size.

Answer 5

As far as I understand (and correct me if I’m wrong), it’s faster to work with an entire processor architecture size in most cases due to CPU optimizations.

Actually, defining variables of the short or char type is kind of a waste, since these variables will live in a register where more bits fit. In general, one uses short or char for data stored in memory, where the size of the logger does not matter. The time it takes to transfer a short from memory to a register is the same time it takes to read an int, but the shorts vector will spend half the space that the int vector.