Use size_t for byte count in device attributes

[davebayer]

No description provided.

[fbusato]

I'm not against it, but I would like to understand the motivation behind using size_t. The shared memory space is 32-bit; I'm not sure it's worth moving the attributes to 64-bit. I'm thinking of use cases where users experience worse performance (on the device) due to implicit promotion.

[github-actions]

🥳 CI Workflow Results

🟩 Finished in 4h 31m: Pass: 100%/239 | Total: 8d 07h | Max: 4h 30m | Hits: 80%/302280

See results here.

[davebayer]

I'm not against it, but I would like to understand the motivation behind using size_t. The shared memory space is 32-bit; I'm not sure it's worth moving the attributes to 64-bit. I'm thinking of use cases where users experience worse performance (on the device) due to implicit promotion.

Whenever you have number of bytes in C++, it's data type is size_t, the type returned by sizeof operator. I believe we should be consistent with what's commonly used.

I understand the point about performance, but I don't believe anyone would use any of these parameters in performance critical path, but tell me if I'm wrong :)

And the returned values are known at compile time so I don't believe there will be any overhead in the end

[fbusato]

the fact that they are compile-time values mitigates the issue. In the worst case, the user can do int{attribute}.

[github-actions]

Backport failed for branch/3.1.x, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin branch/3.1.x
git worktree add -d .worktree/backport-6151-to-branch/3.1.x origin/branch/3.1.x
cd .worktree/backport-6151-to-branch/3.1.x
git switch --create backport-6151-to-branch/3.1.x
git cherry-pick -x 050b57c3199088674e0d7ddabdcdd32001a4c032