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

API design: user wants low-level control for block-based compression #41

Open
amallia opened this issue Aug 11, 2018 · 3 comments
Open

Comments

@amallia
Copy link
Contributor

amallia commented Aug 11, 2018

Hi, one thing that I miss from this library is the ability to integrate into a bigger project where I handle the block encoding manually.
To be more specific, it would be grate to have encodeArray and encodeBlock, so the user can decide what to use.

If i want to encode blocks of 128 elements, I don't want to use encodeArray because it will store the length of the block which is redundant.

@lemire lemire changed the title API design API design: user wants low-level control for block-based compression Aug 12, 2018
@lemire
Copy link
Owner

lemire commented Aug 12, 2018

For an immediate solution, please consider these lower-level libraries...

The simdcomp library was designed specifically for such low-level work.

Otherwise, it is certainly possible to add what you seek to FastPFor, pull requests are invited.

@amallia
Copy link
Contributor Author

amallia commented Aug 12, 2018

I managed to encode blocks of 128 elements using SImple8b, for example, by specifying MarkLength to false. Then it wont write the length for every block and the final result of using encodeArray for small blocks is probably the same of calling it on the entire list.

My main issue is with SIMDBP128. First, do you think it make sense to encode blocks of 128 elements using SIMDBP128? I have the impression the minimal length it makes sense is 16*128.

@lemire
Copy link
Owner

lemire commented Aug 12, 2018

If you want to design your own data layout, then the simdcomp library is probably a much better choice. It also comes with extra functions... see this paper: https://arxiv.org/abs/1611.05428

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

No branches or pull requests

2 participants