[issue37774] Micro-optimize vectorcall using PY_LIKELY

Jeroen Demeyer added the comment: > My question is if it is safe to let developers "abuse" it. If these macros > are misused, they can lead to a performance regression. I expect people using these macros and PR reviewers to use good judgement when to use these macros. There are many cases

[issue37774] Micro-optimize vectorcall using PY_LIKELY

STINNER Victor added the comment: Few more links about likely/__builtin_expect: * GCC documentation says: "In general, you should prefer to use actual profile feedback for this (-fprofile-arcs), as programmers are notoriously bad at predicting how their programs actually perform."

[issue37774] Micro-optimize vectorcall using PY_LIKELY

STINNER Victor added the comment: > We're not talking about prefetching here. The Py_LIKELY/Py_UNLIKELY macros > only affect which of the two code paths in a branch is the "default" one, > i.e. the one not involving a jmp. I know. My point about prefetching is that if we provide a way to

[issue37774] Micro-optimize vectorcall using PY_LIKELY

Jeroen Demeyer added the comment: I claim that adding Py_LIKELY/Py_UNLIKELY will reduce the performance randomness of non-PGO builds. So it would be strange to use that randomness as an argument *against* this patch. -- ___ Python tracker

[issue37774] Micro-optimize vectorcall using PY_LIKELY

Jeroen Demeyer added the comment: We're not talking about prefetching here. The Py_LIKELY/Py_UNLIKELY macros only affect which of the two code paths in a branch is the "default" one, i.e. the one not involving a jmp. -- ___ Python tracker

[issue37774] Micro-optimize vectorcall using PY_LIKELY

STINNER Victor added the comment: Another example to explain my concern. In the Linux kernel, list macros used to prefetch next items: “(...) So the conclusion is: prefetches are absolutely toxic, even if the NULL ones are excluded.” https://lwn.net/Articles/444336/ The lesson is that we

[issue37774] Micro-optimize vectorcall using PY_LIKELY

STINNER Victor added the comment: > I would expect that Py_LIKELY/Py_UNLIKELY helps with this. Well, PGO is made of many optimizations, not only help branch prediction. For example, it detects hot code and tries to put functions which call them each other close in memory to enhance the CPU

[issue37774] Micro-optimize vectorcall using PY_LIKELY

Jeroen Demeyer added the comment: > If it's an optimization, can you show a benchmark to validate that it's > really faster as expected? Yes, I did test it. I didn't save the results, but I can redo them if you want. If you plan to reject the issue anyway, there is no point. > not building

[issue37774] Micro-optimize vectorcall using PY_LIKELY

STINNER Victor added the comment: > That's certainly true. The question is whether we want to optimize also > non-PGO builds. If it's an optimization, can you show a benchmark to validate that it's really faster as expected? I tried for 6 months to run benchmarks without PGO and it was a

[issue37774] Micro-optimize vectorcall using PY_LIKELY

Jeroen Demeyer added the comment: > IHMO PGO compilation already defeats the purpose of these macros. That's certainly true. The question is whether we want to optimize also non-PGO builds. -- ___ Python tracker

[issue37774] Micro-optimize vectorcall using PY_LIKELY

STINNER Victor added the comment: My previous attempt: bpo-29461. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue37774] Micro-optimize vectorcall using PY_LIKELY

STINNER Victor added the comment: I dislike adding these macros: # define Py_UNLIKELY(value) __builtin_expect(!!(value), 0) # define Py_LIKELY(value) __builtin_expect(!!(value), 1) It's too easy to introduce a performance regression by mistake. IHMO PGO compilation already defeats the

[issue37774] Micro-optimize vectorcall using PY_LIKELY

Ma Lin added the comment: How about write a suggestion on when to use them in the comment? For example: > You should use it only in cases when the likeliest branch is > very very very likely, or when the unlikeliest branch is very > very very unlikely. from

[issue37774] Micro-optimize vectorcall using PY_LIKELY

Inada Naoki added the comment: I'm conservative about adding public APIs. But in this case, LIKELY/UNLIKELY macros are battle-tested in the world already. So I think it's safe to make it public. But I'll wait to merge for a week for other core dev's comments. --

[issue37774] Micro-optimize vectorcall using PY_LIKELY

Josh Rosenberg added the comment: Is the intent to make these macros public? If not, shouldn't they be prefixed with an underscore, like _Py_SIZE_ROUND_DOWN/_Py_SIZE_ROUND_UP in the same header? -- ___ Python tracker

[issue37774] Micro-optimize vectorcall using PY_LIKELY

Change by Josh Rosenberg : -- nosy: +josh.r ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37774] Micro-optimize vectorcall using PY_LIKELY

Change by Jeroen Demeyer : -- keywords: +patch pull_requests: +14881 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15144 ___ Python tracker ___

[issue37774] Micro-optimize vectorcall using PY_LIKELY

Change by Serhiy Storchaka : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37774] Micro-optimize vectorcall using PY_LIKELY

New submission from Jeroen Demeyer : Take the LIKELY/UNLIKELY macros out of Objects/obmalloc.c (renaming them of course). Use them in a few places to micro-optimize vectorcall. -- components: Interpreter Core messages: 349108 nosy: Mark.Shannon, inada.naoki, jdemeyer priority: normal