-
Notifications
You must be signed in to change notification settings - Fork 6.8k
[MXNET-1185] [WIP] Support large array in several operators #13191
Conversation
python/mxnet/base.py
Outdated
@@ -215,6 +215,7 @@ def _load_lib(): | |||
# type definitions | |||
mx_uint = ctypes.c_uint | |||
mx_float = ctypes.c_float | |||
mx_long = ctypes.c_longlong |
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.
should this be longlong or just long?
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 should be longlong. c_long is the same as c_int in python ctypes.
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.
LGTM
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.
LGTM. One question: what performance implication do we have to change the data type here? memory usage?
@mxnet-label-bot add [pr-awaiting-review] |
@yuxihu That's a good question. We have not yet run a full performance test. @wkcn did some initial test and did not see much performance variation between int32_t and int64_t: https://github.com/wkcn/c_performance |
@apeforest Could you please add the test? #13070 |
Added: test_ndarray_empty() |
@apeforest Regarding what you have changed the JNI on Scala, I suggest to apply some changes to the following line as well:
@andrewfayres WDYT? |
@lanking520 @andrewfayres After offline discussions, I have updated the PR by limiting the changes in scala package to its JNI interface and leave a TODO item to systematically update Scala code to support large array. Please help to review the code again since there are still a few scala-unit test failure. Thanks! |
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.
dim_t, size_t, index_t are used in different places within the change. It is unclear to me when to use each one. It is going to be very difficult for others to follow on future changes. I think we need detailed documentation on how to choose data type for operators in order to support large array. It should be also mentioned the in PR description.
In addition, only a few operators are changed to support large array. This make our code base a mix of int/index_t for operators. This can be confusing. Please document and we may need a more systematic way of handling large array instead of hot fixes to a few operators.
@@ -354,8 +354,8 @@ inline std::vector<std::string> SafeGetListNames(const Rcpp::List& src) { | |||
* \param rshape The dimension in R | |||
* \return A internal vector representation of shapes in mxnet. | |||
*/ | |||
inline std::vector<mx_uint> Dim2InternalShape(const Rcpp::Dimension &rshape) { | |||
std::vector<mx_uint> shape(rshape.size()); | |||
inline std::vector<dim_t> Dim2InternalShape(const Rcpp::Dimension &rshape) { |
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.
QQ: what is the type of mx_uint and dim_t?
static_cast<size_t>(N), static_cast<size_t>(omp_threads))) { | ||
for (int i = 0; i < N; ++i) { | ||
N, static_cast<size_t>(omp_threads))) { | ||
for (size_t i = 0; i < N; ++i) { |
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.
why size_t here and index_t on L549?
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 omp parallel block requires index to be signed integer, while size_t is unsigned.
Change this PR to [WIP] because we want to merge a smaller part first (#13418) |
@mxnet-label-bot update [pr-work-in-progress] |
@apeforest do you plan to still use this PR for part 2? If not maybe close it first. |
@roywei We can close this PR for now. I will reopen it when it comes to all the language binding support. Thanks! |
Description
This PR fixed the large array issue (#13036, #13070) in the following operators:
ndarray.ones
ndarray.zeros
ndarray.sum
ndarray.arange
ndarray.slice
ndarray.random.uniform
ndarray.empty
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.
Changes
Comments