Skip to content

Conversation

@corona10
Copy link
Member

@corona10corona10 commented Nov 9, 2024

  • None / bool / int / str are immutable types, so they is thread-safe.
  • list is mutable, but by using PyList_GET_SIZE we can make it as thread-safe.

* None / bool / int / str are immutable types, so they is thread-safe. * list is mutable, but by using ``PyList_GET_SIZE`` we can make it as thread-safe.
@corona10corona10 marked this pull request as draft November 9, 2024 09:44
@corona10corona10 marked this pull request as ready for review November 9, 2024 10:33
@corona10corona10 changed the title gh-115999: Add free-threaded specialization for TO_BOOL[WIP] gh-115999: Add free-threaded specialization for TO_BOOLNov 9, 2024
@corona10corona10 changed the title [WIP] gh-115999: Add free-threaded specialization for TO_BOOLgh-115999: Add free-threaded specialization for TO_BOOLNov 9, 2024
if (PyAnySet_CheckExact(value)){
returnSPEC_FAIL_TO_BOOL_SET;
}
if (PyTuple_CheckExact(value)){
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe not for this PR to address, but why is the tuple type handled here? I see no specialization for tuple (or did I miss something?). Tuple is immutable, so it should be relatively easy to add

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

IIRC, we added specializaiton based on metric that is measured at https://github.com/faster-cpython/benchmarking-public.
I am not sure how many tuple cases are actually existed.

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

I agree that tuple case is easy to add but that would be based on how many boolean operations are existed for the tuple at the real world workload.

Copy link
Contributor

@mpagempage left a comment

Choose a reason for hiding this comment

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

Thanks for doing this! Looks good overall. In addition to the comment inline, we're also going to need to update _GUARD_TYPE_VERSION to load tp->tp_version tag using an FT_ATOMIC_LOAD_UINT32_RELAXED.

My review raced with your updates, I hope the comments still make sense.

@bedevere-app
Copy link

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

@corona10corona10 requested a review from mpageNovember 10, 2024 08:26
Hustlersambitionz

This comment was marked as spam.

@corona10
Copy link
MemberAuthor

I have made the requested changes; please review again

@bedevere-app
Copy link

Thanks for making the requested changes!

@markshannon, @mpage: please review the changes made to this pull request.

@bedevere-appbedevere-appbot requested a review from mpageNovember 16, 2024 02:34
@corona10
Copy link
MemberAuthor

corona10 commented Nov 16, 2024

Mark,
I have addressed your code review especially for #126616 (comment)

I am okay with surrounding #ifdef Py_STATS but it will need extra PR for specialize and unspecialize function, so I prefer to handle it separately, and I believe that @mpage will handle this. (or I will submit the patch for this)

Please take a look :)

Copy link
Contributor

@mpagempage left a comment

Choose a reason for hiding this comment

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

I still don't understand the rationale for keeping the gotos, but I care more about seeing this PR move forward. Accepting to unblock.

@corona10
Copy link
MemberAuthor

@mpage I 've followed the changes from #127030, Would you like to take a look again?

Copy link
Contributor

@mpagempage left a comment

Choose a reason for hiding this comment

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

LGTM!

@bedevere-app
Copy link

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

@corona10
Copy link
MemberAuthor

I am merging this PR, @markshannon. Please let me know if we have to handle more things in the future PRs. Matt and I will try to adjust what you concerns :) cc @mpage

@corona10corona10 merged commit 78a530a into python:mainNov 21, 2024
@corona10corona10 deleted the gh-115999-bool branch November 21, 2024 22:52
ebonnal pushed a commit to ebonnal/cpython that referenced this pull request Jan 12, 2025
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants

@corona10@mpage@eendebakpt@markshannon@Hustlersambitionz