Jerry Ling
Jerry Ling
I think we can make a branch where this works for you to test your application in a day or two one more question: >computes something else using the histogram...
@mtagliazucchi can you try this branch? https://github.com/Moelf/FHist.jl/tree/gpu_ext here's how to use it: ```julia-repl julia> using FHist, KernelAbstractions, CUDA julia> data = CUDA.randn(10^5); julia> FHist.gpu_bincounts(data; sync=true, binedges=-1:0.1:1) 20-element CuArray{Float32, 1, CUDA.DeviceMemory}:...
that's not a bug, the bin edges are open interval to the right, this is how CPU histogram works as well. we're currently missing `overflow=true` for GPU, which will collect...
@mtagliazucchi did that work for you use case?
right, `Tables.partitions` should just iterate clusters in RNTuple era sounds like you want 2.b, which is not a bad default recommendation, since that's basically uproot
>I assume for-loops with smart buffering will work anyway as well. the question there is: 1) if it should be thread-safe by default, that has the "lock" overhead as well...
Question for that, can you switch to 1.b easily? 1.b has thread-safety by construction, as for type stability, we can always do the TypedTable thing as an option/different API
this can be closed?
why can't we have `ProgressMeter` compat upper limit to 0.10.4?
oh I see, just wondering, nothing urgent from my end.