Skip to content

Use floating-point literals in TrackUtils.h - #15689

Merged
davidrohr merged 2 commits into
devfrom
f3sch-patch-2
Aug 19, 2026
Merged

Use floating-point literals in TrackUtils.h#15689
davidrohr merged 2 commits into
devfrom
f3sch-patch-2

Conversation

@f3sch

@f3sch f3sch commented Aug 18, 2026

Copy link
Copy Markdown
Collaborator

This shows up during profiling ITS GPU kernels.
The division on line 176 is forced to be calculated in double. This costed 23% of stalls in some kernels.
I am not sure if the precision is required here?
At least in local tests it did not affect the ITS tracking output (<0.1%).

This shows up during profiling ITS GPU kernels.
The division on line 176 is forced to be calculated in double.
This costed 23% of stalls in some kernels.
I am not sure if the precision is required here?
At least in local tests it did not affect the ITS tracking output (<0.1%).
@f3sch
f3sch requested a review from shahor02 as a code owner August 18, 2026 13:08
Comment thread DataFormats/Reconstruction/include/ReconstructionDataFormats/TrackUtils.h Outdated
@davidrohr

Copy link
Copy Markdown
Collaborator

That was definitely a bug, and is a common case which can force GPUs to do double arithmetics instead of single.
Though, I am wondering do we need to cast everything to value_t? In my opinion, it makes the code a bit more complicated. Changing 1. to 1.f should be enough?
All the constants are anyhow only float precision, so no reason to cast to double in case value_t is double.

Obviously this is a matter of taste, but in my code I prefer to use use float constants.
Of course, in case we want to support value_t = half or so, the version of this PR is better.

@f3sch

f3sch commented Aug 19, 2026

Copy link
Copy Markdown
Collaborator Author

Hi David, that's how I found it. I profiled ITS kernels which were forced to do double here. I first did I like you suggested 1.f and Sandro suggested to use value_T. I honestly do not have a preference here.

@davidrohr

Copy link
Copy Markdown
Collaborator

If that was intentional, one should put a comment, looks like an oversight.

OK, I don't care too much for the style if it is outside my code :).

@davidrohr
davidrohr merged commit 0f02172 into dev Aug 19, 2026
12 checks passed
@davidrohr
davidrohr deleted the f3sch-patch-2 branch August 19, 2026 12:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants