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 current code+build structure generates some (object) code duplication as the same code gets compiled multiple times with different defines for different name spaces. This is not ideal for size-constrained environments (smart cards, HSMs) that have to provide all parameter options within one library. This also might be an issue for high-load servers having to serve clients with different parameter sets.
Just looking at the size of different .so libraries generated by make shared it seems there might be potential for saving ~54kB per algorithm combination in ref and ~60kB in avx2 (x64, -O3 compiled).
Looking at one library (build by cmake) containing all combinations (ref+avx2, dil2+3+4, plain+90s), the size differs (again, x64, -O3) between 714416 bytes and 347112 bytes supporting only the "dilithium3" parameter set (still including ref+avx2 & plain+90s), i.e., more than 50%.
This difference of course would change by doing even more code sharing (see also #21 ) and completely factoring out non-Dilithium core code (e.g., Keccak).
The text was updated successfully, but these errors were encountered:
The current code+build structure generates some (object) code duplication as the same code gets compiled multiple times with different defines for different name spaces. This is not ideal for size-constrained environments (smart cards, HSMs) that have to provide all parameter options within one library. This also might be an issue for high-load servers having to serve clients with different parameter sets.
Just looking at the size of different
.so
libraries generated bymake shared
it seems there might be potential for saving ~54kB per algorithm combination inref
and ~60kB inavx2
(x64, -O3 compiled).Looking at one library (build by
cmake
) containing all combinations (ref+avx2, dil2+3+4, plain+90s), the size differs (again, x64, -O3) between 714416 bytes and 347112 bytes supporting only the "dilithium3" parameter set (still including ref+avx2 & plain+90s), i.e., more than 50%.This difference of course would change by doing even more code sharing (see also #21 ) and completely factoring out non-Dilithium core code (e.g., Keccak).
The text was updated successfully, but these errors were encountered: