Skip to content

[hist] Annotate RHist with R__CLING_PTRCHECK(off).#22219

Closed
hageboeck wants to merge 1 commit into
root-project:masterfrom
hageboeck:RHist_PtrCheck
Closed

[hist] Annotate RHist with R__CLING_PTRCHECK(off).#22219
hageboeck wants to merge 1 commit into
root-project:masterfrom
hageboeck:RHist_PtrCheck

Conversation

@hageboeck
Copy link
Copy Markdown
Member

In JITted RDF nodes, cling added an unnecessary pointer check, which significantly slows down execution.

@hageboeck hageboeck self-assigned this May 11, 2026
@hageboeck hageboeck requested a review from hahnjo as a code owner May 11, 2026 09:32
@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 11, 2026

Test Results

    22 files      22 suites   3d 14h 32m 32s ⏱️
 3 852 tests  3 852 ✅ 0 💤 0 ❌
76 977 runs  76 977 ✅ 0 💤 0 ❌

Results for commit 7d64f80.

♻️ This comment has been updated with latest results.

In JITted RDF nodes, cling added an unnecessary pointer check, which
significantly slows down execution.
To allow for compiling the package standalone, the macro is defined in
RHistUtils instead of including ROOT's RTypes.h
@dpiparo dpiparo added this to the 6.40.00 milestone May 13, 2026
Copy link
Copy Markdown
Member

@hahnjo hahnjo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still trying to figure out why we only need to annotate the two classes. I would expect to also need it in RHistEngine, RHistStats, RHist


#ifdef __CLING__
// This attribute can significantly speed up JIT-compiled code in CLING
// It is also defined in ROOT, so keep the definitions the same.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering if we should give it a different name...

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found it in the C standard, and it's covering the exact case where two (sometimes related, sometimes unrelated) include paths lead to the macro being redefined.

6.10.3 p2:

An identifier currently defined as an object-like macro shall not be redefined by another
#define preprocessing directive unless the second definition is an object-like macro
definition and the two replacement lists are identical. Likewise, an identifier currently
defined as a function-like macro shall not be redefined by another #define
preprocessing directive unless the second definition is a function-like macro definition
that has the same number and spelling of parameters, and the two replacement lists are
identical.

By the above, we are doing it standard-compliant as it's now.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But indeed, we could define also an RHist-specific macro that expands to the same attribute. I don't see a downside of that, so I guess that should be the way forward.

@hageboeck
Copy link
Copy Markdown
Member Author

Still trying to figure out why we only need to annotate the two classes. I would expect to also need it in RHistEngine, RHistStats, RHist

In general, that might be correct, but the code path in RDF is such that it doesn't trigger the pointer check.

@dpiparo
Copy link
Copy Markdown
Member

dpiparo commented May 14, 2026

Is this superseded by #22288 ?

@hageboeck
Copy link
Copy Markdown
Member Author

Is this superseded by #22288 ?

Indeed, this will achieve the same speedup, and cover even more cases.

@hageboeck hageboeck closed this May 15, 2026
@hageboeck hageboeck deleted the RHist_PtrCheck branch May 15, 2026 07:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants