search

eyalroz / cuda-kat

CUDA kernel author's tools
BSD 3-Clause "New" or "Revised" License
104 stars 8 forks source link

Shoud we adhere to CUDA's confusing use of "index" and "id"? #50

Open eyalroz opened 4 years ago

eyalroz commented 4 years ago

An index is either a "list of items" arranged in order, or "a number... used as an indicator or measure", or "a number ... associated with another to indicate... position in an arrangement".

An id is an identification, or " a document bearing identifying information".

So, if we have an item in a 3D block, the triplet of coordinates in each axes is - literally - that item's 'id' not its 'index'. If anything, it is its position in a linearization of that grid that could be considered its 'index'.

... Unfortunately, CUDA defines this exactly backwards: The 'index' in CUDA is the 3-dimensional entity, and the 'id' is the number.

Currently, in my code, I'm making a bit of a mess of these two conceptions. I'm going to sort that out, but the question is how?

  1. Keep CUDA's terminology, use _index() functions in grid_info to return uint3's and dimensions_t's.
  2. Switch CUDA's terminology as described above, advise users to do the same.
  3. Use only neutral terms, e.g. 'position' and 'linearized_id'.
  4. Mix of the above.

What do you think?

eyalroz commented 4 years ago

@codecircuit : Question for you as well.

eyalroz commented 4 years ago

Sticking to #1 for now - which means a bunch of changes to our current code.

codecircuit commented 4 years ago

Personally I stick to 2. I think it is not intuitive to call a multi dimensional object an "index". With indices I associate something linear. But sometimes I name index variables ..._id because they represent something, which is only aligned in one dimension at all.

eyalroz commented 4 years ago

@codecircuit : Other people I asked have mostly told me the detriment of 2 would exceed the benefit - unless I expect people to only use my grid_info code, not read about indices and id's in the CUDA documentations and be generally isolated from the switched semantics. ... which is not what's going to happen.

codecircuit commented 4 years ago

I agree with you. Point 1. makes more sense here.