UCI integer types?

[lucasart]

The UCI protocol does not specify a minimum (or maximum) range for integers. Most C/C++ programmers probably assume int, and possibly int64_t for node counts (?)

However, in a portable world we know only sizeof(int) >= 2, which is certainly not enough. For node counts, we need 64-bit integers, to avoid overflow in long searches. For all other ints, 32-bit should be enough.

Using int64_t for UCI I/O generic code therefore seems a good idea. Problem is, manipulating 64-bit integers on 32-bit platforms can be quite slow. None of that should be on the hot path, except for node counts...

So I would like an integer type that is the largest possible that translates into efficient code. Should be at least 32-bit on 32-bit platforms, and 64-bit on 64-bit platforms. Can I assume long for that? Is there any C implementation that does not respect that? (i know the C standard does not guarantee it)

[BB+]

Maybe I am answering a slightly different question, but:
"The C99 standard includes definitions of several new integer types to enhance the portability of programs." http://en.wikipedia.org/wiki/C_data_types
Fixed-width integer types:
Fastest integer types which are guaranteed to be the fastest integer type available in the implementation, that has at least specified number N of bits. Guaranteed to be specified for at least N=8,16,32,64.

Code: Select all

Fastest 	int_fastN_t 	INT_FASTN_MIN 	INT_FASTN_MAX 	uint_fastN_t 	0 	UINT_FASTN_MAX

OTOH, as to your specific question, I would guess that the number of compilers which lack this C99 feature could well be greater than those which don't have long be 32 for 32-bit and 64 for 64-bit. Also, I am not sure that int_fast32_t is going to end up being 64 bits on all 64 bit platforms (the idea of "fastest" is unclear to me). It seems that the specs are more for the case where you want it to be as small as possible w/o losing speed (due to unioning), while you want it to be as big as possible.

[BB+]

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

In 64-bit Windows, ... an abstract data model called LLP64 (or P64). In the LLP64 data model, only pointers expand to 64 bits; all other basic data types (integer and long) remain 32 bits in length.

[lucasart]

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

In 64-bit Windows, ... an abstract data model called LLP64 (or P64). In the LLP64 data model, only pointers expand to 64 bits; all other basic data types (integer and long) remain 32 bits in length.

Thank you. So sizeof(long) can even be different on the same architecture (x64-64) for different OS. Perhaps even on x64-64 with Windows it still depends on the compiler (4 for MSVC and 8 for MinGW?). I only use Linux on my x86-64 machine with GCC or Clang, so I wasn't aware of that annoying fact of life…

I will therefore use int64_t, and possibly an #ifdef logic if there is a measurable perf hit on 32-bit with 64-bit node counts.

[H.G.Muller]

XBoard processes all node counts as uint64.

If you really worry about the cost of incrementin an int64 on i386, you can increment only the low 32-bit counter, and have some code that is called only occasionally (like the code that prints output) check if there is an overflow compared to the previous value it has seen (of which it keeps a copy), and if so, increment the high 256-bit part.