about speed:
i've seen compression formats fine tuned for a particular generation of
a particular architecture, so benchmark claims on a single cpu may not
be relevant to everybody.
another common failure i've seen is lack of documentation about worst
case resource usage (e.g. zlib was designed so decompress works with
very small memory footprint). this is probably not the job of ELF to
fix, but eventually users will want to know if there is a dos attack
surface.
>
>
> I wish that we can reserve a generic ABI value for it. Otherwise, I will
> seek for a GNU ABI value in the range ELFCOMPRESS_LOOS - ELFCOMPRESS_HIOS.
> The value will be used by Linux and likely Fuchsia. I'll need to notify
> FreeBSD/NetBSD/OpenBSD/etc folks.
>
> --
> You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/generic-abi/64bec546-9acd-40b0-a48f-29cd656a235bn%40googlegroups.com.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/generic-abi/YrmqiEcRYlZPFyAy%40arm.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/generic-abi/YrmqiEcRYlZPFyAy%40arm.com.
There was a question in this mailing regarding Zstandard stability, and I guess it’s worthwhile clarifying that point.
Zstandard format is completely stable since v1.0 which was published in 2016, 6 years ago.
It means it’s both forward and backward compatible :
any payload produced by an old version >= 1.0 can be decoded by current version,
and same thing in the other direction, payloads produced by newer versions are compatible with older decoders.
The format is completely defined into an IETF RFC document :
https://datatracker.ietf.org/doc/html/rfc8878 ,
so there is no room to “go fancy” and introduce breaking changes.
This is essentially the same status as deflate and follows the same established model.
Based on this RFC, new implementations of Zstandard are also available, beyond the reference one we provide.
For example, there is an excellent Go re-implementation by Klaus Post, at https://github.com/klauspost/compress/tree/master/zstd#zstd,
another one in Java by Martin Traverso, a Rust decoder by Moritz Borcherding,
or a pure Javascipt decoder by Arjun Barrett ( https://www.npmjs.com/package/fzstd ).
Hardware accelerators are starting to appear.
All this to say, the format itself is here to stay, there’s an ecosystem around it.
There was another question around memory usage,
and while the Zstandard format allows high memory usage for specific scenarios,
let it be clear that it doesn’t have to, and by default it doesn’t.
There are also advanced options to control or even restrict memory usage to even lower levels whenever needed, notably for embedded scenarios, on both compression and decompression sides.
And there are also build options to address the binary size if that’s a concern.
For continued discussions on these advanced topics, I’m CCing my colleague Felix Handte, who can be helpful since he has a good grasp and experience on these topics.
Best Regards
Yann Collet
(Adding a new format also introduces complexity on their
build system side. They need to teach DWARF consumers they use. It's not
a small undertaking.)
--
You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/generic-abi/CAJimCsE2ODPaEcZcnvd5gaAXgADt8hZznAD7hu5%2BAFpnoS-jkw%40mail.gmail.com.