-
Notifications
You must be signed in to change notification settings - Fork 189
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
PyArray conversion speedups and PyArrayFromBuffer #487
Conversation
Thanks for working on this! My hope for a long time (see #70) has been to ditch |
That is, |
Yeah I think you can remove all the stuff related to Python Array -> PyArray conversion. But this doesn't do anything for julia array -> python array |
as in everything related to |
Right.... for that we'd need to create an object that implements the buffer API. One concern is that I don't know how well this would work with Python functions expecting a NumPy array. Okay, it makes sense to replace the Python -> Julia array code ( |
The other issue with replacing |
I'm guessing that this never happens in practice. My preference would be to remove |
Ok, let's not support it then unless someone tells us it does 😄 |
What's the issue with having numpy as a test dependency? Seems that using numpy will allow us to cover more cases, more easily. I thought I might be able to get by with python's array module, but then I did a little digging and found out that it doesn't support the buffer interface on Python 2.7 🤦. You can get typed byte data with struct.pack, but you can't reshape a memoryview using It could be done, but would take effort, esp. for more exotic arrays (e.g. non-native endian and f_contiguous), and since I'm guessing the majority of the arrays these functions will see in the wild will be coming from numpy anyway (?), could be good to test with it. |
NumPy as a test dependency is fine; we should definitely test with NumPy arrays and operations anyway. |
* PyArray_Info parameterised T,N and immutable * PyArray_Info size and stride changed to Tuples (from Vectors) * PyArray_Info data changed from Ptr{Cvoid} to Ptr{T} * `PyArrayInfoFromBuffer(o::PyObject)` faster way to get PyArray_Info from numpy than numpy's __array_interface__ * `PyArrayFromBuffer(o::PyObject)` 4x faster PyArray conversion * ArrayFromBuffer no copy conversion to Julia Array * moved PyBuffer tests to separate file
rename ArrayFromBuffer to NoCopyArray, and make indexing of NoCopyArray match py indexing for row major arrays too
Bump. |
Assuming the tests pass I think this is pretty good to go. (they pass for me on mac with py 2/3 julia 0.6.3/0.7-dev-xxx) There are things in pep-3118 that it doesn't handle, but I think it handles all the cases of arrays (strides and types) that current master does. Oh the one thing I wanted to ask about is there's a deprecation warning about |
Umm nightly failures seem unrelated :/ |
Nightly failures on |
and change pass a PyPtr_NULL instead of a C_NULL for Py_buffer.obj when creating a new PyBuffer
Codecov Report
@@ Coverage Diff @@
## master #487 +/- ##
==========================================
- Coverage 53.11% 53.03% -0.09%
==========================================
Files 19 20 +1
Lines 1525 1567 +42
==========================================
+ Hits 810 831 +21
- Misses 715 736 +21
Continue to review full report at Codecov.
|
indexing into a PyArray was throwing a ambiguous method error for similar(::PyArray, T, dims::Dims)
pyarr = convert(PyArray, ao1) | ||
ao2 = arrpyo(11.0:20.0, "d") | ||
setdata!(pyarr, ao2) | ||
@test all(pyarr[1:10] .== 11.0:20.0) |
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.
using PyCall
np = pyimport("numpy")
pyarr = pycall(np["array"], PyArray, [1:10;])
pyarr[1:2]
The above is an error on current master on Julia 1.0.1 🙀
Bumpity bump? @stevengj |
Hello? |
Thanks for keeping at this! |
🎉 🎉 🎉 |
There are failures in Julia 0.7 after this is merged: https://travis-ci.org/JuliaPy/PyCall.jl/builds/454473965 (One failure is from nightly but it's terminated due to "No output has been received in the last 10m0s" during installation. So it probably is irrelevant.) The build before merge was all green: https://travis-ci.org/JuliaPy/PyCall.jl/builds/450430878 Also, Travis reports "Job errored" What is happening? |
I think it could be related to 48d730f |
N.b. I didn't merge that commit into the branch of this PR |
Simple fix in #615 |
Apologies, I haven't followed the discussion above, but I did bisect a failure of my code when upgrading to PyCall#master down to this commit. It seems that before this commit,
but after
Was this intended or not? In either case, is there a workaround to force conversion to a Julia |
Probably not intended. Have you tried |
Thanks. Neither of these two attempts on current master seem to work:
But |
This is the last one for now 😄
Speedups for PyArray conversion using Python's Buffer interface.
PyArrayFromBuffer
could become the default constructor for PyArray, if this looks good.PyArray(o::PyObject)
PyArrayFromBuffer(o::PyObject)
further 4x faster PyArray creation (~60x faster than master)setdata!
for fast reassignment of data ptr in PyArray when you know the array is the right shape (~500x faster than creating a new PyArray on master - not an apples to apples comparison, but still good to have)PyArrayInfoFromBuffer(o::PyObject)
- a faster way to get PyArray_Info from numpy than extracting values from the__array_interface__
In no major rush for review, so please don't feel pressured.
master results:
This branch results:
Benchmark code for master.