arrow-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Nugent <nug...@gmail.com>
Subject Re: Question the nature of the "Zero Copy" advantages of Apache Arrow
Date Tue, 26 Jan 2021 18:30:19 GMT
Right, I recongize that using mmap directly isn't necessarily the most
straightforward, which is why I suggested using a RAM disk with
uncompressed arrow files. It saves the trouble of having to deal with
passing addresses around and puts a nice file system API on top of any
dataset operations that arrow already supports that you might want to do
(you can get a reasonable approach to appends using this, for example).

But if you've already got an on-disk, uncompressed arrow buffer that's
bigger than memory, the arrow api should take care of using the mmap system
calls to load it into memory (at least I think this is currently supported
for all the arrow libraries? You may have to double check. I know it's in
C/C++/Python for sure, probably Rust and I think R?).

Then you're only dealing with virtual allocations and you can load that
larger than memory file in as many analytics packages as you like and there
will only be one copy of any portion of that file in memory at any given
time.

-Dan Nugent


On Tue, Jan 26, 2021 at 1:15 PM Thomas Browne <thomas@crvm.io> wrote:

> Yes I think the term "zero copy" was confusing to me. It doesn't quite do
> what it says on the tin since if I understand correctly the term still
> allows for an actually copy still to occur, it's just a direct binary copy
> without a [de]serialisation process.
>
> I hear you on plasma.
>
> On the issue of MAP_SHARED, got it, but that means I'm having to talk C
> from other languages.
>
> I think Jorge's answer (
> https://arrow.apache.org/docs/format/CDataInterface.html) is pretty good
> though. Good enough for me anyway. Thanks everyone.
> On 26/01/2021 18:09, Daniel Nugent wrote:
>
> I think you might be a bit confused about what zero copy means if that’s
> what you’re concerned about. If you have a bigger than memory file, then
> Plasma wasn’t going to help since its design always involved copying the
> arrow buffers to memory.
>
> If you have larger than memory arrow files in the first place, just open
> them using mmap (should be automatically done for non-compressed arrow
> files).
>
> --
> -Dan Nugent
> On Jan 26, 2021, 13:07 -0500, Thomas Browne <thomas@crvm.io>
> <thomas@crvm.io>, wrote:
>
> don't I lose the benefit of mmapping huge files with a ramdisk? Cos the
> file has to now fit on my ramdisk.
>
> Personally working with financial tick data which can be enormous.
> On 26/01/2021 18:00, Daniel Nugent wrote:
>
> Is there a problem with just using a RAM disk as the method for sharing
> the arrow buffers? It just seems easier and less finicky than a separate
> API to program against.
>
> It also makes storing the data permanently a lot  more straightforward, I
> think.
>
> --
> -Dan Nugent
> On Jan 26, 2021, 12:47 -0500, Thomas Browne <thomas@crvm.io>
> <thomas@crvm.io>, wrote:
>
> So one of the big advantages of Arrow is the common format in memory, on
> the wire, across languages.
>
> I get that this makes it very easy and fast to transfer data between
> nodes, and between languages, which will all share the in-memory format
> and therefore the (often expensive) serialisation step is removed.
>
> However, is it true that one of the core objectives of the project is
> also to allow shared memory objects across different languages on the
> same node? For example, a fast C-based ingest system constantly
> populates a pyarrow buffer, which can be read directly by any other
> application on that node, through pointer sharing?
>
> If this is a core objective, what is the canonical way for brokering the
> "pointers" to this data between languages? Is it the Plasma store? And
> if so, are there plans for Plasma to move be implemented in other client
> languages?
>
> In short. Is Plasma (or if not Plasma, the functionality it provides
> implemented some other way), a core objective of the project?
>
> Or instead is Flight supposed to be used between languages on the same
> node, and if so, does Flight provide true zero-copy (ie - the same
> buffer, not copying the buffer) if run between processes on the same node?
>
> Many thanks.
>
>

Mime
View raw message