On Tue, Dec 7, 2010 at 1:19 PM, Brad King <brad.king@kitware.com> wrote:

Actually there are more reasons to use uint64_t rather than size_t.
Some APIs may support loading a small part of a gigantic image.
In that case the underlying indexing and file offsets must be 64-bit
even though pointers might be only 32-bit.  Types like size_t are
good for dealing with in-memory buffers (and thus standard library
APIs) but not for indexing something that might be mostly out-of-core.

BTW, a patch like that attached will be helpful for dealing with 64-bit
integer types.  This adds "long long" overloads for vnl_math functions
that are supposed to be available for all fundamental integer types.



Please forgive me for being the pain.  I am not against what you proposed.  Just want to raise a couple points for discussion:

First, I have not heard of any images as gigantic as having one of the dimensional index goes beyond 2^32.  Hypothetically, if such an image exists and it is close to a square, it takes roughly 2^64 bytes to store a grayscale byte image, which seems unrealistically large and will break 64-bit pointers anyway.  Therefore, we do not gain any real benefits from  uint64_t index type unless  1) image is not square but a narrow strip or 2) image is sparse, similar to the idea of a sparse matrix. This second idea is beyond my knowledge.

Second, using uint64_t index type on 32-bit systems will likely result in performance loss when applied to vil_image_view<T>.  To access a pixel, which usually occurs in a double loop, arithmetic operations performed on 64-bit indices take more than twice the number of CPU instructions than on 32-bit indices.   At the end, the pointer still needs to be truncated to 32 bits in order to access the memory.   Maybe we shall apply uint64_t to only a selected subset of APIs or employ overloading functions? 

Please feel free to correct me if I am wrong or partial. 

Best regards,
Gehua Yang