Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Endianness #288

Open
BeckySharp opened this issue May 14, 2021 · 1 comment
Open

Endianness #288

BeckySharp opened this issue May 14, 2021 · 1 comment
Assignees

Comments

@BeckySharp
Copy link
Contributor

PLAN:

  • save endianness of index in buildinfo or somewhere, where we can check at the beginning
  • when launching odinson, check native endianness
  • based on compatibility, when initializing the unsafe serializer, decide which version of the get/put methods to use, set
    (have 2 versions of serializer methods -- one that reverses the bytes and one that doesn't)

ALSO:

  • have "validation" program that checks things like endianness but maybe more
  • if endianness is not compatible, suggest user reindex if odinson docs/corpus available to have fastest runtime possible

OTHER:

  • can we update a field?

FYI @kwalcock thanks for the thoughts in processors land, do you have thoughts on this?

@kwalcock
Copy link
Contributor

The default should probably be whatever the Intel chips have so that there is no need to record it in the file, IMO. If a different endianness is found, the bytes can be swapped and swapped back. Those machines will just be slightly (I assume) slower. If the memory layout can vary, there are more than two possibilities, but that's going too far.

If this is the case "The Intel x86 and AMD64 / x86-64 series of processors use the little-endian format." and this is the case "Internally, Java uses Big Endian." then we should be able to look at the output and notice the contradiction---and make sure I'm not crazy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants