You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
RFC: Change __cuda_stream__ from class attribute to method #348
I realized I had forgotten about this during the design stage until now. This fact has also been pointed out by @gmarkall (back in the days of designing CAI, IIRC).
I propose to change __cuda_stream__ and any future protocols to a callable class method from a class property/attribute so as to avoid side effects (thereby reducing overhead) and establish a future-proof convention, following DLPack and other protocols.
The arguments are an object and a string. The result is True if the string is the name of one of the object’s attributes, False if not. (This is implemented by calling getattr(object, name) and seeing whether it raises an AttributeError or not.)
@property decorators create descriptors, which are one of many ways to add dynamic attributes to an object. Unfortunately, the only way to resolve such dynamic attribute lookups is by actually trying to get the attribute, so we are left paying this cost when using properties.
I ran some microbenchmarks and I agree that using a method instead of a property is a good solution to increase performance, regardless of whether the user takes an EAFP (try: ... except AttributeError:) or LBYL (if hasattr(...):) approach.
Activity
bdice commentedon Jan 4, 2025
To add some context: this is the intended design of
hasattr. https://docs.python.org/3/library/functions.html#hasattr@propertydecorators create descriptors, which are one of many ways to add dynamic attributes to an object. Unfortunately, the only way to resolve such dynamic attribute lookups is by actually trying to get the attribute, so we are left paying this cost when using properties.Relevant StackOverflow post: https://stackoverflow.com/questions/30143957/why-does-hasattr-execute-the-property-decorator-code-block
I ran some microbenchmarks and I agree that using a method instead of a property is a good solution to increase performance, regardless of whether the user takes an EAFP (
try: ... except AttributeError:) or LBYL (if hasattr(...):) approach.leofang commentedon Jan 11, 2025
@NaderAlAwar, this should be a quick fix, could you help make the change and propagate it to cuda.par PR please? 🙂
shwina commentedon Jan 11, 2025
@bdice Just out of curiosity, I added a couple of more tests to your benchmark (cached properties, getattr_static):
Click to see benchmark
Method access is still fastest (although cached properties is a very close second).