-
Notifications
You must be signed in to change notification settings - Fork 21
Add 5 arg copyto!
into Vector
with matching type
#264
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
base: main
Are you sure you want to change the base?
Conversation
@@ -76,6 +89,9 @@ macro implement_array_methods(t) | |||
function Base.copyto!(dest::PermutedDimsArray{T,N}, src::$t{T,N}) where {T,N} | |||
return $_disk_copyto!(dest, src) | |||
end | |||
function Base.copyto!(dest::Vector{T}, dstart::Integer, src::$t{T, 1}, sstart::Integer, n::Integer) where {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.
Is T
always identical for scr and dest in Base copyto!
? What if you have different Real 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.
No, the copyto!
in Base uses setindex!
so will call convert
on each element.
I added a version that uses broadcasting to support that case.
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'm assuming here that readblock!
requires the element types to match, and aout
to be stored in contiguous memory.
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 also use setindex!
when writing into the chunk buffer, so it should be the same?
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.
Maybe. Looking at the docs, it just says "The results shall be written into aout
" but I'm not sure if there are implementations of readblock!
that make other assumptions about aout
's eltype, or memory layout.
src/array.jl
Outdated
throw(ArgumentError(LazyString("tried to copy n=", | ||
n," elements, but n should be non-negative"))) | ||
end | ||
view(dest, range(dstart, length=n)) .= view(src, range(dstart, length=n)) |
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.
Depending on the use case it might be better for performance to avoid the DiskArray broadcast machinery, broadcast on views should work but might be a bit slow if chunk sizes are too small. Instead we might instantiate the result and copy with coptyo!(dest,dstart,src[range(dstart, length=n)])
Can we assume that the amount of data we copy fits in memory, or is dest
mmapped in your case?
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'm not doing any mmapping in InputBuffers.jl
, though there is nothing stopping someone from passing a mmapped out
to Base.readbytes!(b::InputBuffer, out::AbstractArray{UInt8}, nb=length(out))
Also, the copyto!
in InputBuffers.jl
should end up calling _disk_copyto_same_type_vector
with the direct readblock!
call since src
and dest
both have eltype UInt8
.
copyto!
into Vector
copyto!
into Vector
with matching type
I removed the specialization that does type conversion to limit the scope of this PR. |
Fixes #263
I only implemented the one-dimensional case with matching types because it wasn't obvious to me how to handle multiple dimensions, and this is all that is required for better
InputBuffers.jl
compatibility for now.I also modified the
copyto!
function to always returndest
, which somehow fixed thecircshift
test.