I'm looking into performance differences between integers and int32s in Koka.
// Code like this for generic integers
kk_integer_t _x776;
kk_integer_t _x777 = kk_integer_add(acc,a,kk_context()); /*int*/
// Turns into code like this
int32_t _x874;
int32_t _x875 = (int32_t)((uint32_t)acc + (uint32_t)a); /*int32*/
In kklib/include/kklib/integer.h we have the following statement about integers in Koka
Integers are either a pointer to a `kk_bigint_t` (with lowest bit == 0),
or a _small_ int (with lowest bit == 1).
The small int is restricted in size to KK_SMALLINT_BITS such that we can do
efficient arithmetic on the representation of a small int `n` directly where
`boxed(n) == 4*n + 1`. The `kk_smallint_t` size is chosen to allow efficient overflow detection.
By using `4*n + 1` we always have the lowest two bits of a pointer as `00`
while those of a kk_smallint_t are always `01`.
This way we can do more efficient basic arithmetic where we can for example directly add
and test afterwards if we actually added two small integers (and not two pointers or smallint and pointer)
and whether there was an overflow. For example,
intptr_t kk_integer_add(intptr_t x, intptr_t y) {
intptr_t z;
if (unlikely(__builtin_add_overflow(x,y,&z) || (z&2)==0)) return kk_integer_add_generic(x,y);
return (z^3); // or `z - 1`
}
This is 6 extra instructions on x86 and 4 extra on arm64.
For a quick test, using one of the tree benchmarks: (I'm testing on x86_64) I get that it is basically identical. I'll have to look into it more. Perhaps I'll use a benchmark that is more math oriented.