Mailing-List: contact dev-help@arrow.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@arrow.apache.org
MIME-Version: 1.0
Reply-To: emkornfield@gmail.com
In-Reply-To: <CAJPUwMB1SzaJir8HmiLZzzUzGR1nX-XawzFtMXSO7WcU-zoupA@mail.gmail.com>
References: <BLU181-W60CF6C658EFC9B3A213EF7A7040@phx.gbl> <CAAOiHjFN8d_1i_CE+U=Fu6+BcAKG_7jmKKAYmTyD-qGp71DLuw@mail.gmail.com>
 <CAAOiHjEfVywsLa9pkqrztdT0fQpSXSWrupYoPbOJ_=kQKmRrPQ@mail.gmail.com> <CAJPUwMB1SzaJir8HmiLZzzUzGR1nX-XawzFtMXSO7WcU-zoupA@mail.gmail.com>
From: Micah Kornfield <emkornfield@gmail.com>
Date: Mon, 1 Aug 2016 11:02:38 -0700
Message-ID: <CAK7Z5T8BmyzjM+dR4Q8tQM5Ls=oA+FTcputSLa=4ucexp9i07g@mail.gmail.com>
Subject: Re: Is there plan to support BigEndian Systems like SUN SPARC
 Hardware ?
To: dev@arrow.apache.org
Content-Type: multipart/alternative; boundary=94eb2c09411ee4c3290539066759
archived-at: Mon, 01 Aug 2016 18:02:50 -0000

--94eb2c09411ee4c3290539066759
Content-Type: text/plain; charset=UTF-8

Hi Wes,
The point I was trying to argue from an earlier thread is that the most
common cases for relocation are:
1.  Little endian machine to little endian machine (most likely same
machine)
2.  big endian machine to big endian machine (most likely same machine)
3.  big endian machine to little endian machine or vice versa

The purpose of the metadata would be to make use-cases 1 and 2 possible
without byte-swapping.  Use case 3 would obviously require byte swapping
but for an initial implementation the code could simply indicate that it is
not supported.

This seems less complex to me than actually implementing any sort of
byte-swapping logic while still supporting the widest variety of hardware
with the same code for the most common use-cases.

Thanks,
Micah

P.S. If anybody can provide pointers I'd be interested to understand which
pieces of the java code make assumptions about little-endianness.

--94eb2c09411ee4c3290539066759--