[jira] [Created] (ARROW-9046) [C++][R] Put more things in type_fwds

Neal Richardson created ARROW-9046: -- Summary: [C++][R] Put more things in type_fwds Key: ARROW-9046 URL: https://issues.apache.org/jira/browse/ARROW-9046 Project: Apache Arrow Issue Type:

[jira] [Created] (ARROW-9045) [C++] Improve and expand Take/Filter benchmarks

Wes McKinney created ARROW-9045: --- Summary: [C++] Improve and expand Take/Filter benchmarks Key: ARROW-9045 URL: https://issues.apache.org/jira/browse/ARROW-9045 Project: Apache Arrow Issue

[jira] [Created] (ARROW-9044) [Go][Packaging] Revisit the license file attachment to the go packages

Krisztian Szucs created ARROW-9044: -- Summary: [Go][Packaging] Revisit the license file attachment to the go packages Key: ARROW-9044 URL: https://issues.apache.org/jira/browse/ARROW-9044 Project:

Re: [DISCUSS] [C++] custom allocator for large objects

Le 05/06/2020 à 17:09, Rémi Dettai a écrit : > I looked into the details of why the decoder could not estimate the target > Arrow array size for my Parquet column. It's because I am decoding from > Parquet-Dictionary to Arrow-Plain (which is the default when loading > Parquet). In this case the

Re: [DISCUSS] [C++] custom allocator for large objects

Le 05/06/2020 à 16:25, Uwe L. Korn a écrit : > > On Fri, Jun 5, 2020, at 3:13 PM, Rémi Dettai wrote: >> Hi Antoine ! >>> I would indeed have expected jemalloc to do that (remap the pages) >> I have no idea about the performance gain this would provide (if any). >> Could be interesting to

Re: [DISCUSS] [C++] custom allocator for large objects

I looked into the details of why the decoder could not estimate the target Arrow array size for my Parquet column. It's because I am decoding from Parquet-Dictionary to Arrow-Plain (which is the default when loading Parquet). In this case the size prediction is impossible :-( > This would

Re: [DISCUSS] [C++] custom allocator for large objects

On Fri, Jun 5, 2020, at 3:13 PM, Rémi Dettai wrote: > Hi Antoine ! > > I would indeed have expected jemalloc to do that (remap the pages) > I have no idea about the performance gain this would provide (if any). > Could be interesting to explore. This would actually be the most interesting

[jira] [Created] (ARROW-9043) [Go] Temporarily copy LICENSE.txt to go/

Wes McKinney created ARROW-9043: --- Summary: [Go] Temporarily copy LICENSE.txt to go/ Key: ARROW-9043 URL: https://issues.apache.org/jira/browse/ARROW-9043 Project: Apache Arrow Issue Type:

Re: [DISCUSS] [C++] custom allocator for large objects

Hi Antoine ! > I would indeed have expected jemalloc to do that (remap the pages) I have no idea about the performance gain this would provide (if any). Could be interesting to explore. > do you know that Arrow also supports integration with another allocator, mimalloc I only tried Jemalloc and

[jira] [Created] (ARROW-9042) [C++] Add Subtract and Multiply arithmetic kernels with wrap-around behavior

Krisztian Szucs created ARROW-9042: -- Summary: [C++] Add Subtract and Multiply arithmetic kernels with wrap-around behavior Key: ARROW-9042 URL: https://issues.apache.org/jira/browse/ARROW-9042

Re: [DISCUSS] [C++] custom allocator for large objects

Le 05/06/2020 à 14:25, Rémi Dettai a écrit : > Hi Uwe! > >> As your suggestions don't seem to be specific to Arrow, why not > contribute them directly to jemalloc? They are much better in reviewing > allocator code than we are. > I mentioned this idea in the jemalloc gitter. The first response

Re: [DISCUSS] [C++] custom allocator for large objects

Hi Uwe! > As your suggestions don't seem to be specific to Arrow, why not contribute them directly to jemalloc? They are much better in reviewing allocator code than we are. I mentioned this idea in the jemalloc gitter. The first response was that it should work but workloads with realloc aren't

Re: [DISCUSS] [C++] custom allocator for large objects

Hello Rémi, under the hood jemalloc does quite similar things to what you describe. I'm not sure what the offset is in the current version but in earlier releases, it used a different allocation strategy for objects above 4MB. For the initial large allocation, you will see quite some copies as

[NIGHTLY] Arrow Build Report for Job nightly-2020-06-05-0

Arrow Build Report for Job nightly-2020-06-05-0 All tasks: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-06-05-0 Failed Tasks: - conda-win-vs2015-py36: URL: https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-06-05-0-azure-conda-win-vs2015-py36 -

Re: [jira] [Created] (ARROW-9037) [C++/C-ABI] unable to import array with null count == -1 (which could be exported)

Apologies. This was sent by mistake. On 5 Jun 2020, at 15:17, Saurabh Kumar wrote: Zhuo Peng created ARROW-9037: Summary: [C++/C-ABI] unable to import array with null count == -1 (which could be exported) Key: ARROW-9037

[jira] [Created] (ARROW-9037) [C++/C-ABI] unable to import array with null count == -1 (which could be exported)

Zhuo Peng created ARROW-9037: Summary: [C++/C-ABI] unable to import array with null count == -1 (which could be exported) Key: ARROW-9037 URL: https://issues.apache.org/jira/browse/ARROW-9037 Project:

[jira] [Created] (ARROW-9037) [C++/C-ABI] unable to import array with null count == -1 (which could be exported)

Zhuo Peng created ARROW-9037: Summary: [C++/C-ABI] unable to import array with null count == -1 (which could be exported) Key: ARROW-9037 URL: https://issues.apache.org/jira/browse/ARROW-9037 Project:

[jira] [Created] (ARROW-9041) overloaded virtual function "arrow::io::Writable::Write" is only partially overridden in class

Karthikeyan Natarajan created ARROW-9041: Summary: overloaded virtual function "arrow::io::Writable::Write" is only partially overridden in class Key: ARROW-9041 URL: