-
Notifications
You must be signed in to change notification settings - Fork 1.3k
HeapTypeExt and Protocol Methods Pointer #3819
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
@youknowone can you run the performance check? I think we may use week order read after replace AtomicCell to AtomicPtr |
I am running tests. I used benchmark tests from https://github.com/python/pyperformance/tree/main/pyperformance/data-files/benchmarks running command was:
comparing command was:
|
vm/src/builtins/float.rs
Outdated
Self::number_general_op(number, other, inner_div, vm) | ||
}), | ||
..PyNumberMethods::NOT_IMPLEMENTED | ||
macro_rules! atomic_func { |
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.
putting in type/slots.rs
will be better to share the macro over all protocol implementations
const AS_NUMBER: PyNumberMethods; | ||
|
||
#[inline] | ||
#[pyslot] | ||
fn as_number(_zelf: &PyObject, _vm: &VirtualMachine) -> &'static PyNumberMethods { | ||
&Self::AS_NUMBER | ||
} |
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.
is this need to be changed?
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.
we need static variable, const variable is not globally static, it creates instance wherever is used.
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.
return static reference from a const variable gives me a warning with compiler.
vm/src/builtins/float.rs
Outdated
} | ||
} | ||
|
||
static AS_NUMBER: PyNumberMethods = PyNumberMethods { |
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.
even if we make this out of trait, it still can be defined in fn as_number()
method unless we need it as a pub
vm/src/builtins/type.rs
Outdated
}; | ||
use crate::{ |
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.
}; | |
use crate::{ |
vm/src/protocol/number.rs
Outdated
@@ -1,189 +1,155 @@ | |||
use crossbeam_utils::atomic::AtomicCell; | |||
use once_cell::sync::OnceCell; | |||
|
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.
pub number_methods: PyNumberMethods, | ||
} | ||
|
||
pub struct PointerSlot<T>(NonNull<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.
What's the benefit of this type comparing to &'static
?
They seem to guarantee same things.
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.
It just hint the reference should either be static or from type, I don't know is it neccesary.
impl<'a> From<&'a PyObject> for PyNumber<'a> { | ||
fn from(obj: &'a PyObject) -> Self { |
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.
This change means having a PyNumber
object doesn't guarantee it is an actual number object.
Do you intend to change it?
In that case, we'd better to carefully comment about it because it is counter-intutitive to rust sense.
I still think OnceCell
for methods
is an overkill because it can be safely managed only with properly designed types.
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 think PyNumber shouldn't garrentee anything as it could be int, float, subclass, complex or class with _int_, _float_ etc, so what the caller expect is depend on what method been called.
The reason I use OnceCell is because we always use the type id first to avoid method call and I think that is more common case like get int from PyInt
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.
We will obtain an PyNumber
object only when we need PyNumber
operations, isn't it? The method can be obtained when we create PyNumber
, not when retrieving methods from it. PyNumber
itself is a Once
. OnceCell
in PyNumber
is duplicated encoding of data.
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.
so maybe a function that will create PyNumber only if it is not exact type could be better?
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 am sorry. I didn't understand well what you meant by "create PyNumber only if it is not exact type". could you help me to understand it?
I think we need to create a PyNumber
type object only when we need to call methods()
of it. In that case, we don't need OnceCell
for PyNumber - because we will create a PyNumber
object always with methods. If we don't need method, we can handle PyObjectRef
instead of PyNumber
.
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.
because recent patches are adding number protocol implementations, quickly merging this one will be less painful in future.
I want to know how do you think about this OnceCell problem for now. You know about it the best.
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.
@qingshi163 do you mind if I try to edit this PR to work this way? I want to listen your decision because you are the best professional for PyNumber.
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 am thinking we should remove OnceCell from PyNumber but keep From<&PyObject> trait.
Than we modify or create function under VirtualMachine(to_int, to_index, to_float, etc) for all the function that could short cut with type id and do the check there. so we will always call number methods if we created PyNumber.
We should always use functions under VirtualMachine instead PyNumber if we do not sure the type.
I'd like to keep From<&PyObject> is because PyNumber is not garuentee anything about the type. we should not check the type when creating 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.
Sure you can modify the pr, I am quite busy and I want to fix the sre-engine first.
oh, I learned about those performance tools from @corona10, thank you! |
3884481
to
e8fe8ea
Compare
d345c31
to
09c4fa3
Compare
|
@qingshi163 could you review changes? |
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.
Great!
No description provided.