You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The file "/native/src/seal/serializable.h" used to say this:
/**
Class to represent a serializable object. Some functions return serializable
objects rather than normal objects. For example, Encryptor can be used in
symmetric-key mode to create symmetric-key ciphertexts, where half of the
ciphertext data is pseudo-random and can be generated from a seed, reducing
the size of the newly created ciphertext object by nearly 50%. However, the
compression only has an effect when the object is serialized with compression
mode compr_mode_type::deflate due to an implementation detail. This makes
sense when, e.g., the ciphertexts need to be communicated from a client to
a server for encrypted computation.
Serializable objects also expose the save_size function that behaves just
as the save_size functions of other objects in Microsoft SEAL: it returns
an upper bound on the size of a buffer needed to hold the serialized data.
The following illustrates the use of serializable objects:
+--------------------------+
| Serializable<GaloisKeys> | Size 2 MB (example)
+------------+-------------+
|
| Serializable<GaloisKeys>::save
| with compr_mode_type::deflate
v
+---------------+
| Stream/Buffer | Size ~1 MB (example)
+-------+-------+
|
|
v
+---------+
| Network | Minimized communication
+----+----+
|
| GaloisKeys::load
v
+------------+
| GaloisKeys | Size 2 MB (example)
+------------+
*/
So, deflate gave a lot of compression, The file "/native/src/seal/serialization.h" says:
/**
A type to describe the compression algorithm applied to serialized data.
Ciphertext and key data consist of a large number of 64-bit words storing
integers modulo prime numbers much smaller than the word size, resulting in
a large number of zero bytes in the output. Any compression algorithm should
be able to clean up these zero bytes and hence compress both ciphertext and
key data.
*/
enum class compr_mode_type : std::uint8_t
{
// No compression is used.
none = 0,
#ifdef SEAL_USE_ZLIB
// Use ZLIB compression
zlib = 1,
#endif
#ifdef SEAL_USE_ZSTD
// Use Zstandard compression
zstd = 2,
#endif
};
So, compr_mode_type::deflate isn't even defined. And, the compiler wastes no time in telling me that indeed, deflate is not defined.
So, can I please have my deflate back? I am running out of space rather quickly using this new version of SEAl(v3.6.3). By the way, I have used the compression modes, both, and they seem to do little, or nothing at all.
The text was updated successfully, but these errors were encountered:
compr_mode_type::deflate was renamed to compr_mode_type::zlib in 3.6.0. The comments in serializable.h are old and apparently have not been updated; this is a mistake. The statement that the ~50% size decrease only works when compression is used is also old and incorrect: it works automatically even if no compression is used.
For BFV the benefit of compression tends to be minor because the coeff_modulus primes are often advantageous to take to be rather large (close to 64 bits) so when encrypted data is serialized in 64-bit words there isn't much to compress. For CKKS some of the coeff_modulus primes tend to be much smaller, e.g. ~30 bits, in which case compression can yield a huge benefit.
In general it's highly recommended to use compr_mode_type::zstd than compr_mode_type::zlib for performance reasons.
The file "/native/src/seal/serializable.h" used to say this:
So, deflate gave a lot of compression, The file "/native/src/seal/serialization.h" says:
So,
compr_mode_type::deflate
isn't even defined. And, the compiler wastes no time in telling me that indeed, deflate is not defined.So, can I please have my deflate back? I am running out of space rather quickly using this new version of SEAl(v3.6.3). By the way, I have used the compression modes, both, and they seem to do little, or nothing at all.
The text was updated successfully, but these errors were encountered: