4 ms·

I see two good reasons: (1) DX: typing "int" feels more natural and less clunky than choosing some arbitrary size. (2) Perf: if you don't care about the size,

by jraph 2y ago

I see two good reasons: (1) DX: typing "int" feels more natural and less clunky than choosing some arbitrary size. (2) Perf: if you don't care about the size, you might as well use the native size, which is supposed to be faster. In Java, people do use the hardware-independent 4 byte ints and 8 byte longs. I guess (1) matters more, or that people think that the JVM will figure out the perf issue and that it'll be possible to micro-optimize if a profile pointed out an issue.

epcoa 2y ago
> Perf: if you don't care about the size, you might as well use the native size, which is supposed to be faster. You always care about the size (or should), especially if you're writing C or C++. Though it is often reasonable that 32767 is a sufficient limit and you're guaranteed at least that with int.
- jraph 2y ago
  What I meant is that if you don't specifically need a small int size (because for instance you are going to serialize it into a format that mandates it), and you will not deal with even moderately large ints, you will probably use int even if you could use a smaller type. I've not seen many codebases doing something else. Of course you need to think about it. In C, but also in many languages (not python though, which magically switch to bigint when needed). In Java, the wrong int type won't cause UB, but it will throw (unchecked) exceptions.
Tuna-Fish 2y ago
> which is supposed to be faster. If you care about this, you figure out exactly how much you need and always use the smallest type that meets this criteria. There have been architectures in the past where the "native" size was in practice faster than the smaller types, but those architectures are now long dead. On all modern architectures, none of the instructions for smaller data types are ever slower than the native size, and while using them doesn't directly win you cycles of execution time in the cpu (because they are no faster either), it wins you better cache utilization. As a rule, the fastest data type is a byte. There is no reason to ever use "int", other than inertia.
- jraph 2y ago
  I was under the impression that native into size was still faster on current architectures, I guess I have stuff to read! Thanks for telling me. > There is no reason to ever use "int", other than inertia. ...and DX, as I said.

by jraph 2y ago

epcoa 2y ago

> Perf: if you don't care about the size, you might as well use the native size, which is supposed to be faster. You always care about the size (or should), especially if you're writing C or C++. Though it is often reasonable that 32767 is a sufficient limit and you're guaranteed at least that with int.

jraph 2y ago
What I meant is that if you don't specifically need a small int size (because for instance you are going to serialize it into a format that mandates it), and you will not deal with even moderately large ints, you will probably use int even if you could use a smaller type. I've not seen many codebases doing something else. Of course you need to think about it. In C, but also in many languages (not python though, which magically switch to bigint when needed). In Java, the wrong int type won't cause UB, but it will throw (unchecked) exceptions.

Tuna-Fish 2y ago

> which is supposed to be faster. If you care about this, you figure out exactly how much you need and always use the smallest type that meets this criteria. There have been architectures in the past where the "native" size was in practice faster than the smaller types, but those architectures are now long dead. On all modern architectures, none of the instructions for smaller data types are ever slower than the native size, and while using them doesn't directly win you cycles of execution time in the cpu (because they are no faster either), it wins you better cache utilization. As a rule, the fastest data type is a byte. There is no reason to ever use "int", other than inertia.

jraph 2y ago
I was under the impression that native into size was still faster on current architectures, I guess I have stuff to read! Thanks for telling me. > There is no reason to ever use "int", other than inertia. ...and DX, as I said.