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
I got interested in the performance of zarr and did a comparison with npy, pickle, hdf5 etc. See https://stackoverflow.com/a/58942584/353337. To my surprise, I found zarr reads large arrays slower than npy. This is for random float data as well as more structured mesh data. I had expected zarr to take the cake using multiple cores. Perhaps this isn't a good test for zarr to show its strength either.
Thanks for posting, interesting. Couple of factors may be at work here.
In the read test you use zarr in a zip file. IIUC reading from zip adds
some overhead because the CRCs are checked. I'd suggest comparing with zarr
stored as files in a directory (as you do for the write test).
Also when comparing zarr versus h5, if you wanted to be totally fair you'd
need to use the same chunk sizes and the same compressor. In your benchmark
you don't explicitly set the chunk size, so zarr and h5py will guess a
chunk size from the data size, and both use the same algorithm for guessing
chunk size but zarr is tuned to guess larger chunks. This may not make a
difference in your benchmark but thought I'd mention. Also you don't
explicitly set the compressor, and h5py and zarr have different defaults.
Again may not make a difference here, but worth noting.
I am doing a similar testing and I was trying to understand whether in zarr it is possible to read partially the file to get only some slices of the array. If I compare performance on partial retrieval with hdf5 files, where I know this is possible, I get a much longer time to read small chunks of the data (smaller than the zarr chunk size), and this seem to come from the fact that zarr reads the entire chunk to return part of it. Is there any way to get a partial file reading in zarr?
Afaik, zarr uses blosc compression by default. h5py does not compress by default.
Also, h5py does not chunk the data if you don't specify chunks=True (or enable compression).
Numpy and pickle neither compress nor chunk, I don't know about pytables.
So the comparison is not very fair.
FWIW when I benchmarked z5, which implements the zarr spec bin C++, I found the performance
on par with hdf5 in single-threaded performance and better mult-threaded. Unfortunately I don't have the results right now, the code is here.
Chunks needs to be a tuple with the chunk size you want. Compressor can either be None (= no compression) or one of the compressors from numcodecs.
Can I enable multithreading in Python?
As far as I am aware there is no convenience function to read/write multi-threaded in zarr-python and you will need to implement this yourself. (I might be wrong about this though, zarr-python has grown quite a bit since I looked at it in detail for the last time ....)
On Nov 23, 2019, at 10:05 AM, Constantin Pape ***@***.***> wrote:
Can I adjust chunking and compression in zarr.save?
You will need to use zarr.save_array instead and call it like this:
zarr.save_array('out.zr', data, chunks=chunks, compressor=compressor)
Chunks needs to be a tuple with the chunk size you want. Compressor can either be None (= no compression) or one of the compressors from numcodecs.
Can I enable multithreading in Python?
As far as I am aware there is no convenience function to read/write multi-threaded in zarr-python and you will need to implement this yourself. (I might be wrong about this though, zarr-python has grown quite a bit since I looked at it in detail for the last time ....)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
I see. I suppose you're using dask arrays then, which is perhaps easy to do since they support memory segmentation with their blocked arrays.
In my opinion, it's still worthwhile exploring the possibility of using multithreaded reads into numpy arrays. Those are the de-facto standard, every Python programmer knows them and lots of code is optimized for it. It should be possible, too: You know in advance how large the block in memory will be, and where each chunk will go.
If you don’t mind the dask dependency, it would be simple to just use dask for the reading step. If you call dask.array.from_zarr and then coerce immediately to a numpy array, you will effectively get what you’re looking for.
On Nov 24, 2019, at 1:29 PM, Nico Schlömer ***@***.***> wrote:
use zarr together with dask
I see. I suppose you're using dask arrays then, which is perhaps easy to do since they support memory segmentation with their blocked arrays.
In my opinion, it's still worthwhile exploring the possibility of using multithreaded reads into numpy arrays. Those are the de-facto standard, every Python programmer knows them and lots of code is optimized for it. It should be possible, too: You know in advance how large the block in memory will be, and where each chunk will go.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Would add I’m not aware of NumPy or pickle doing multithreaded reads or writes. Though am not sure if we are still discussing benchmarking.
They don't and yes. I want to see zarr benchmarks which show file sizes smaller than pickle/npy (they already are) and (almost) equally fast reads (not possible without multithreading it seems).
Well they are also writing a single file. I suppose one could have a Zarr file with a single chunk.
Anyways I think before we jump to conclusions we need a good benchmark. The first pass gave us a starting point albeit there are issues with it as pointed out. Can we do a second pass that integrates this feedback?
Okay, well compression does make a difference after all, at least with file sizes. In particular with structured data, zarr is way ahead of the competition. The compression also explains the slower read times.
In particular with structured data, zarr is way ahead of the competition.
@vedal: wow. Yes. This is mature for closing, indeed! Nevertheless, for multithreading, etc. zarr-python ❤️ dask.
Great @joshmoore! Do you happen to know of a piece of modern example code or other source for how to combine them efficiently? I saw that xarray and dask seem to work well together, but I suppose by zarr-python you mean instead of xarray. I couldnt find much about Dask in zarr-pythons official docs
I noticed there is an open issue on zarr+dask as well, so it made me unsure of the maturity of the duo: #962
I couldnt find much about Dask in zarr-pythons official docs
This is a good point. At the moment, Zarr is "low-level" and so doesn't try to explain how to use the other tools with it. But links from the documentation would definitely be useful. Sorry about that! We'll look into it.
@joshmoore thanks alot for these clarifications and for being concrete! I'm surprised that zarr+dask would be alot better since xarray also seems to use dask.DataArray under-the-hood.
I will look into this further. Have a very nice day :)
Activity
alimanfoo commentedon Nov 19, 2019
nschloe commentedon Nov 19, 2019
I've updated the original post to include zipped zarr vs directory zarr; same results.
I suppose it must be the default for the compressor then.
vigji commentedon Nov 22, 2019
I am doing a similar testing and I was trying to understand whether in zarr it is possible to read partially the file to get only some slices of the array. If I compare performance on partial retrieval with hdf5 files, where I know this is possible, I get a much longer time to read small chunks of the data (smaller than the zarr chunk size), and this seem to come from the fact that zarr reads the entire chunk to return part of it. Is there any way to get a partial file reading in zarr?
jakirkham commentedon Nov 22, 2019
@nschloe, are these using the same compressor and chunk size? It seems like they may not be, which could cause huge variability.
nschloe commentedon Nov 22, 2019
@jakirkham I don't know; I just used the default values. See the code for how to reproduce the plot.
constantinpape commentedon Nov 22, 2019
Afaik, zarr uses blosc compression by default. h5py does not compress by default.
Also, h5py does not chunk the data if you don't specify
chunks=True(or enable compression).Numpy and pickle neither compress nor chunk, I don't know about pytables.
So the comparison is not very fair.
FWIW when I benchmarked z5, which implements the zarr spec bin C++, I found the performance
on par with hdf5 in single-threaded performance and better mult-threaded. Unfortunately I don't have the results right now, the code is here.
nschloe commentedon Nov 23, 2019
Can I adjust chunking and compression in
zarr.save? Can I enable multithreading in Python?constantinpape commentedon Nov 23, 2019
You will need to use
zarr.save_arrayinstead and call it like this:Chunks needs to be a tuple with the chunk size you want. Compressor can either be
None(= no compression) or one of the compressors fromnumcodecs.As far as I am aware there is no convenience function to read/write multi-threaded in
zarr-pythonand you will need to implement this yourself. (I might be wrong about this though,zarr-pythonhas grown quite a bit since I looked at it in detail for the last time ....)rabernat commentedon Nov 23, 2019
nschloe commentedon Nov 24, 2019
I see. I suppose you're using dask arrays then, which is perhaps easy to do since they support memory segmentation with their blocked arrays.
In my opinion, it's still worthwhile exploring the possibility of using multithreaded reads into numpy arrays. Those are the de-facto standard, every Python programmer knows them and lots of code is optimized for it. It should be possible, too: You know in advance how large the block in memory will be, and where each chunk will go.
rabernat commentedon Nov 24, 2019
jakirkham commentedon Nov 24, 2019
Would add I’m not aware of NumPy or pickle doing multithreaded reads or writes. Though am not sure if we are still discussing benchmarking.
nschloe commentedon Nov 24, 2019
They don't and yes. I want to see zarr benchmarks which show file sizes smaller than pickle/npy (they already are) and (almost) equally fast reads (not possible without multithreading it seems).
jakirkham commentedon Nov 24, 2019
Well they are also writing a single file. I suppose one could have a Zarr file with a single chunk.
Anyways I think before we jump to conclusions we need a good benchmark. The first pass gave us a starting point albeit there are issues with it as pointed out. Can we do a second pass that integrates this feedback?
nschloe commentedon Dec 5, 2019
Okay, well compression does make a difference after all, at least with file sizes. In particular with structured data, zarr is way ahead of the competition. The compression also explains the slower read times.
In particular with structured data, zarr is way ahead of the competition.
nschloe commentedon Dec 5, 2019
Well, how do I set the compressor? This
gives the cryptic
jakirkham commentedon Dec 5, 2019
What is
data?nschloe commentedon Dec 5, 2019
A numpy array. (Edited the above code.)
vedal commentedon Nov 14, 2022
@rabernat
Is this still the recommendation? Maybe this issue is mature for closing? @joshmoore
joshmoore commentedon Nov 14, 2022
@vedal: wow. Yes. This is mature for closing, indeed! Nevertheless, for multithreading, etc. zarr-python ❤️ dask.
vedal commentedon Nov 14, 2022
Great @joshmoore! Do you happen to know of a piece of modern example code or other source for how to combine them efficiently? I saw that xarray and dask seem to work well together, but I suppose by zarr-python you mean instead of xarray. I couldnt find much about Dask in zarr-pythons official docs
I noticed there is an open issue on zarr+dask as well, so it made me unsure of the maturity of the duo: #962
joshmoore commentedon Nov 15, 2022
Yes, exactly.
The dask.array.from_zarr and dask.array.to_zarr methods are likely what you are looking for.
This is a good point. At the moment, Zarr is "low-level" and so doesn't try to explain how to use the other tools with it. But links from the documentation would definitely be useful. Sorry about that! We'll look into it.
vedal commentedon Nov 15, 2022
@joshmoore thanks alot for these clarifications and for being concrete! I'm surprised that zarr+dask would be alot better since xarray also seems to use dask.DataArray under-the-hood.
I will look into this further. Have a very nice day :)
joshmoore commentedon Nov 15, 2022
I'll update the description of this issue. Here the problem is that someone tried to wrap a dask in a zarr, but you should put a zarr in your dask. 😄