-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
use fused types for parts of algos_common_helper #22452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @jreback
return indexer | ||
|
||
|
||
pad_float64 = pad["float64_t"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to explicitly use indexing here or is calling also an option? The latter may help reduce the amount of code required (maybe worth exploring in separate PR):
http://docs.cython.org/en/latest/src/userguide/fusedtypes.html#calling
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to explicitly use indexing here or is calling also an option?
I think you're right that the calling can be simplified, but this way keeps the changes self-contained.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea for sure - not saying do here but food for thought in subsequent changes or new developments.
return False, False, True | ||
|
||
if algos_t is not object: | ||
with nogil: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is just copy / paste of the below block, what do you think about creating a blank context manager that doesn't really do anything.
if algos_t is not object:
cm = nogil
else:
cm = dummy_context
And then either implementation can share the context manager:
with cm:
...
Would reduce the copy / paste and make it so we don't miss updates to say one part of the fused type in the future that makes for hard-to-find implementation differences. Could be generalizable in a few instances in Cython.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be great if it can be made to work; a lot of the tempita code takes this form.
I don't think cython treats with nogil
as an actual contextmanager. @scoder any thoughts on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, making this simpler would motivate this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, nogil
is really special in Cython and not an actual context manager. I could imagine something like with nogil.only_if(some_bool_condition)
, which would then duplicate the with-block to generate a True and False version of it and select the right one at runtime. Or even at compile time, if the condition is a compile time constant, such as a type check on fused types (release GIL for native C types, keep for object types). The latter would definitely be possible, whereas duplicating the code block could be messy and is definitely more work.
Note that nogil
is also a decorator, so nogil(something)
is already taken.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@scoder thanks for the info! What would be the next steps to get the functionality you've described? Compile-time evaluation would certainly be ideal
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Read and discuss Allow (compile-time) conditional "with nogil" blocks cython/cython#2579
- find someone to implement it
:)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this will be released in Cython 3.0 - could have a few uses in our codebase for sure. Thanks!
Codecov Report
@@ Coverage Diff @@
## master #22452 +/- ##
=======================================
Coverage 92.05% 92.05%
=======================================
Files 169 169
Lines 50733 50733
=======================================
Hits 46702 46702
Misses 4031 4031
Continue to review full report at Codecov.
|
return False, False, True | ||
|
||
if algos_t is not object: | ||
with nogil: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, making this simpler would motivate this PR
return maybe_convert_objects(result) | ||
|
||
{{endfor}} | ||
|
||
#---------------------------------------------------------------------- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's left here? possible to fully remove this file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAICT diff_2d_dtpye is not straightforward to using fused types
perf check? |
Still need to run, will update later in the day. |
With this option it would be a slam dunk. Without it I still think this is preferable, but it's a closer call. |
asvs look on the good size of noise:
|
Looks like rebasing is gonna be a hassle. Before I jump into it, is the not-yet-implemented cython feature a deal-breaker? I prefer the implementation in this PR, but I'm not clear on what the consensus is. |
I don’t consider it a deal breaker because I’d seen that same copy / paste in the templates before and may still be there in a few instances. Just my $.02 |
thanks! |
Broken off of #22432, which was a proof of concept.