tags:

views:

743

answers:

8

In Java or C++:

Which is better? To use short or int for numbers that go to the short Max value, from 0 to 65535 in the case of unsigned short in C++.

I heard something about using int is better by the processor registers...

+19  A: 

You've mostly answered your own question. If you are concerned about space, use short. If you are concerned about time, use int. Except that cache turbulence may also be a factor. If all your shorts fit into cache, but expanding to ints results in cache misses, you'll be slower with ints.

In, ahem, short, you need to measure your actual situation.

bmargulies
plus one for the pun
Russell
+1 for the pun and *not* saying no pun intended.
Mk12
+2  A: 

Using numbers that correspond to the processor's word size is usually a little faster than the alternatives.

Whereas a short takes up less memory on most architectures.

Anon.
+9  A: 

In C (and C++), "int" is defined as the natural word size for the processor. In many processors, there are significant gains to be had by using that natural word size, which is why C promotes most integer operations to "int" even if you're, say, adding two shorts. You should only use short if storage space is a premium.

There was a time when Unix C compilers on many of the popular chips of the day, including the 386 used by a Sun 396i, used 32 bits for both longs and ints and 16 bits for shorts, while Windows on that same 386 used 32 bits for longs, but 16 bits for ints and shorts. I'm not sure what the justification for 16 bit ints on Windows was, but I assume the 32 bit ints on Sun OS on 386 was to be the same as on the other platforms running Sun OS (MC68020 and SPARC).

In Java, because it's using a JVM and because they define the size of short and int to some extent, the considerations may be slightly different, but I'd still use int unless you have a need to use short.

Paul Tomblin
I would guess that Sun used 32 bits on the 386 because it's a 32-bit CPU, and Microsoft used 16 bits for compatibility, since Windows was born on (and still ran on) 16-bit processors.
Ken
+1  A: 

int is shorter to type than short. Code for clarity for the vast majority of code. When speed/size is important (e.g. in a rasterization function), benchmark it!

When designing structs (that includes classes, of course), space considerations are far more important than in the automatic scope (within a function), as structures make up the obvious majority of memory usage in a program. In that case, it is often better to use shorts or chars instead of ints whenever possible, as memory usage is usually more important than speed.

Although int is, by definition, the natural word size, some architectures can probably do some nifty things with shorts like pack two into one register. I know that the Motorola 68000 works with shorts faster than ints despite having 32-bit registers.

Also, don't worry about optimization in Java. It's gonna be bloated anyway :P

Joey Adams
typedef short s; // yeeaaaah!
Ken
If you're using the CCAN module short_types, you can say s16 :-) http://ccan.ozlabs.org/browse.cgi/ccan/short_types/short_types.h
Joey Adams
@Joey - yuck! <stdint.h> for me, all the way.
Tom
Here's one for you: the ARM7 and ARM9 processors can operate in either 8/32 bit mode or 16-bit mode (thumb) mode. This mode can be switched on the fly. Also, packing memory by using 16-bit integers on a 32-bit system may slow down the program because the processor has fetch some 16-bit integers that are not on a 32-bit boundary.
Thomas Matthews
+2  A: 

well - what about boolean? is it really just one bit? should we use int instead?

choose the correct type based on program requirement first. If it has only two values, use boolean, and trust JVM in handling it efficiently.

irreputable
A: 

Basically ditto bmargulies. Let me just add that space is only a serious consideration if you have LOTS of numbers to store, like a large array or collection of some sort. If you've talking about the ordinary handful of individual variables you have ina typical program -- what, maybe a dozen or so? -- the few bytes saved is not going to matter. I don't worry about the space saving until I start pondering something like "int[10000]" versus "short[10000]".

Java routinely converts shorts to ints to do arithmetic. I'd have to check the bytecode, but I suspect there would have to be some extra operations to do the conversion, which will take a few bytes to express, so you may paradoxically actually take more space to use a short!

Jay
A: 

The following assumes a compiler with cstdint.

For from 0 to 65535 I'd use uint16_fast_t if you are concerned about speed and uint16_t if you are concerned about space.

KitsuneYMG
A: 

In Java, the only case where you would consider using short rather than int for space efficiency reasons is where you have large arrays of numbers. A Java short[] will occupy less memory than a int[] with the same number of elements. In other cases (local variables, parameters, object attributes, statics, ...) a JVM will use the reserve the same amount of memory for a boolean, byte, short, char and int.

It is possible that short versus int might make a difference for computations, but it it will be platform and version specific, and probably will not be significant to the overall performance of your program. In other words, don't bother worrying about it unless extensive profiling indicates that you need to micro-optimize your code.

Stephen C