Merge pull request #1167 from openfheorg/dev

Updates to v1.5.1

Author: dsuponitskiy

CMakeLists.txt

@@ -29,7 +29,7 @@ project (OpenFHE C CXX)
 
 set(OPENFHE_VERSION_MAJOR 1)
 set(OPENFHE_VERSION_MINOR 5)
-set(OPENFHE_VERSION_PATCH 0)
+set(OPENFHE_VERSION_PATCH 1)
 set(OPENFHE_VERSION ${OPENFHE_VERSION_MAJOR}.${OPENFHE_VERSION_MINOR}.${OPENFHE_VERSION_PATCH})
 
 set(CMAKE_CXX_STANDARD 17)

benchmark/src/ckks-bootstrapping.cpp

@@ -73,6 +73,8 @@ struct boot_config {
     { 1 << 17,  1 << 5,       59,       60,         0,        10,     1, {1, 1},  SPARSE_ENCAPSULATED,         FLEXIBLEAUTO},
     { 1 << 17, 1 << 16,       59,       60,         0,        10,     2, {4, 4},  SPARSE_ENCAPSULATED,         FLEXIBLEAUTO},
     { 1 << 17,  1 << 5,       59,       60,         0,        10,     2, {1, 1},  SPARSE_ENCAPSULATED,         FLEXIBLEAUTO},
+    { 1 << 16, 1 << 15,       55,       60,         3,          1,    1, {3, 3},      UNIFORM_TERNARY,         FLEXIBLEAUTO},  // GPU0
+    { 1 << 16, 1 << 14,       50,       53,         7,         10,    1, {3, 3},       SPARSE_TERNARY,         FLEXIBLEAUTO},  // GPU1
     // TODO: enable following once STC Composite Scaling operational
     // { 1 << 17, 1 << 16,       78,       96,         0,        10,     2, {4, 4},       SPARSE_TERNARY, COMPOSITESCALINGAUTO},
 };

docs/sphinx_rsts/modules/core/math/sampling.rst

@@ -200,7 +200,7 @@ Generic Sampler
    }
 
    /*Create the sampler object*/
-   int base = std::log(CENTER_COUNT)/std::log(2);
+   int base = std::log2(CENTER_COUNT);
    DiscreteGaussianGeneratorGeneric dggGeneric(peikert_samplers,stdBase,base,SMOOTHING_PARAMETER);
 
    /*Generate Integer */

docs/static_docs/Best_Performance.md

@@ -1,13 +1,13 @@
 # Building OpenFHE for Best Performance
 
 The default build configuration of OpenFHE focuses on portability and ease of installation.
-As a result, the runtime performace for the default configuration is often significantly worse than for the optimal configuration.
+As a result, runtime performace for the default configuration is often significantly worse than for the optimal configuration.
 
-There are three important CMake flags that affect the runtime performance:
+There are three important CMake flags that affect runtime performance:
 * `WITH_NATIVEOPT` allows the user to turn on/off machine-specific optimizations. By default, it is set to OFF for maximum portability of generated binaries.
 * `NATIVE_SIZE` specifies the word size used internally for "small" integers. By default, it is set to 64. However, when used moduli are 28 bits or below,
 it is more efficient to set it to 32.
-* `WITH_OPENMP` allows the user to turn on multithreading using OpenMP. By default, it is set to ON, and all threads are available for OpenMP multithreading. The OMP_NUM_THREADS environment variable can be used to set the number of threads available in parallel regions.
+* `WITH_OPENMP` allows the user to turn on/off multithreading using OpenMP. By default, it is set to ON, and all threads are available for OpenMP multithreading. The `OMP_NUM_THREADS` environment variable can be used to limit the number of threads available in parallel regions.
 
 The compiler used is also important. We recommend using more recent compiler versions to achieve the best runtime performance.
 
@@ -33,16 +33,15 @@ Typically, the default configuration for schemes in the `pke` module is only to
 
 # Multithreading Configuration using OpenMP
 
-OpenFHE uses loop parallelization via OpenMP to speed up some lower-level (mostly polynomial) operations. This loop parallelization gives the biggest improvement in the `pke` module and only provides modest speed-up in the `binfhe` module.
-
-From a bird's eye view, the built-in OpenFHE loop parallelization is applied at the following levels:
+OpenFHE uses loop parallelization via OpenMP to speed up some lower-level (mostly polynomial) operations. From a bird's eye view, built-in OpenFHE loop parallelization is applied at the following levels:
 * For many Double-CRT operations (used for BGV, BFV, and CKKS implemented using RNS in OpenFHE), loop parallelization over the number of RNS limbs is automatically applied. The biggest benefit is seen when the multiplicative depth is not small (in deeper computations). For BGV and CKKS, the number of RNS limbs is roughly the same as the multiplicative depth set by the user (it is 1 or 2 larger). In BFV, it gets more complicated, but the number of RNS limbs is still proportional to the multiplicative depth.
 * A higher-level loop parallelization is employed for CKKS bootstrapping and scheme switching between CKKS and FHEW/TFHE.
-* Loop parallelization is also used for all schemes during key generation (but this does not have effect on the online operations).
+* Loop parallelization is also used for all schemes during key generation (but this does not have effect on online operations).
 
-When developing C++ applications based on OpenFHE, it is advised to use OpenMP parallelization at the application level, e.g., when independent operations on multiple ciphertexts are performed, application-level OpenMP loop parallelization can be turned on. The scaling of performance with the number of cores in this setup can approach the "ideal" linear scaling if the dimension of the loop is comparable to the number of cores. Note that turning on OpenMP parallelization at the application level typically turns off the lower-level OpenMP loop parallelization (i.e., we do not use nested loop parallelization in OpenMP), so application-level loop parallelization should be used only when you know that the application loop dimension is higher than what is expected for built-in OpenFHE OpenMP loop parallization.
+When developing C++ applications based on OpenFHE, it is advised to use OpenMP parallelization at the application level, e.g., when independent operations on multiple ciphertexts are performed, application-level OpenMP loop parallelization can be turned on.
+The scaling of performance with the number of cores in this setup can approach the "ideal" linear scaling if the dimension of the loop is comparable to the number of cores. Note that turning on OpenMP parallelization at the application level typically turns off the lower-level OpenMP loop parallelization (i.e., we do not use nested loop parallelization in OpenMP), so application-level loop parallelization should be used only when you know that the application loop dimension is higher than what is expected for built-in OpenFHE OpenMP loop parallization.
 
-Within OpenFHE, the use of hyperthreading can lead to decreased performance so the `OMP_NUM_THREADS` environment variable should not be set higher than the number of physical cores.
+Within OpenFHE, the use of hyperthreading can lead to decreased performance so the `OMP_NUM_THREADS` environment variable should be set no higher than the number of physical cores (usually half the number of logical cores). Performance also depends heavily on the execution environment. While a dedicated server allows OpenFHE to utilize all physical cores in isolation, running on a personal laptop often introduces contention with background processes and OS tasks. In such contentious environments, using every available thread can lead to frequent context switching and cache thrashing, ultimately degrading performance. To mitigate this on a general-purpose machine, it may be beneficial to further limit `OMP_NUM_THREADS` to a number slightly less than the number of physical cores, leaving sufficient headroom for the rest of the system. Benchmarking with a varying number of threads should be performed to determine the optimal `OMP_NUM_THREADS` value for your given system and workload.
 
 If an alternative parallelization mechanism is used, e.g., pthreads, C++11 threads, or multiprocessing, OpenMP should be turned off by setting the `WITH_OPENMP` CMake flag to OFF.
 

docs/static_docs/Release_Notes.md

@@ -1,3 +1,14 @@
+04/10/2026: OpenFHE 1.5.1 (stable) is released
+
+* Fixes the compilation error when OpenMP is disabled using the CMake flag (#1131)
+* Fixes BGV/BFV ring dimension underestimation for certain multiparty scenarios (#1157)
+* Fixes a BFV decryption error for HPS* variants in the multiparty setting (#1139)
+* Improves (slightly, i.e., by ~1 bit) the precision of Chebyshev series coefficients for CKKS functional bootstrapping (#1156)
+* Makes the unit test battery run faster on desktop machines (#1138)
+* Code cleanup and minor bug fixes
+
+The detailed list of changes is available at https://github.com/openfheorg/openfhe-development/issues?q=is%3Aissue+milestone%3A%22Release+1.5.1%22
+
 02/26/2026: OpenFHE 1.5.0 (development) is released
 
 * Optimizes CKKS bootstrapping and polynomial evaluation for multithreaded scenarios (#908)

src/binfhe/examples/boolean-serial-binary-dynamic-large-precision.cpp

@@ -50,7 +50,7 @@ int main() {
     uint32_t Q = 1 << logQ;
 
     int q      = 4096;                                                // q
-    int factor = 1 << int(logQ - log2(q));                            // Q/q
+    int factor = 1 << int(logQ - std::log2(q));                       // Q/q
     int p      = cc1.GetMaxPlaintextSpace().ConvertToInt() * factor;  // Obtain the maximum plaintext space
 
     std::cout << "Generating keys." << std::endl;

src/binfhe/examples/boolean-serial-json-dynamic-large-precision.cpp

@@ -50,7 +50,7 @@ int main() {
     uint32_t Q = 1 << logQ;
 
     int q      = 4096;                                                // q
-    int factor = 1 << int(logQ - log2(q));                            // Q/q
+    int factor = 1 << int(logQ - std::log2(q));                       // Q/q
     int p      = cc1.GetMaxPlaintextSpace().ConvertToInt() * factor;  // Obtain the maximum plaintext space
 
     std::cout << "Generating keys." << std::endl;

src/binfhe/examples/eval-decomp.cpp

@@ -55,7 +55,7 @@ int main() {
     uint32_t Q = 1 << logQ;
 
     int q      = 4096;                                               // q
-    int factor = 1 << int(logQ - log2(q));                           // Q/q
+    int factor = 1 << int(logQ - std::log2(q));                      // Q/q
     uint64_t P = cc.GetMaxPlaintextSpace().ConvertToInt() * factor;  // Obtain the maximum plaintext space
 
     // Sample Program: Step 2: Key Generation

src/binfhe/examples/eval-sign.cpp

@@ -55,7 +55,7 @@ int main() {
     uint32_t Q = 1 << logQ;
 
     int q      = 4096;                                               // q
-    int factor = 1 << int(logQ - log2(q));                           // Q/q
+    int factor = 1 << int(logQ - std::log2(q));                      // Q/q
     int p      = cc.GetMaxPlaintextSpace().ConvertToInt() * factor;  // Obtain the maximum plaintext space
 
     // Sample Program: Step 2: Key Generation

src/binfhe/include/binfhe-constants.h

@@ -69,10 +69,10 @@ enum BINFHE_PARAMSET {
     STD256Q,              // more than 256 bits of security for quantum attacks              : 2^(-70)
     STD256Q_3,            // STD256Q for 3 binary inputs                                     : 2^(-65)
     STD256Q_4,            // STD256Q for 4 binary inputs                                     : 2^(-50)
-    STD128_LMKCDEY,       // STD128 optimized for LMKCDEY (using Gaussian secrets)           : 2^(-60)
+    STD128_LMKCDEY,       // STD128 optimized for LMKCDEY                                    : 2^(-60)
     STD128_3_LMKCDEY,     // STD128_LMKCDEY for 3 binary inputs                              : 2^(-90)
     STD128_4_LMKCDEY,     // STD128_LMKCDEY for 4 binary inputs                              : 2^(-60)
-    STD128Q_LMKCDEY,      // STD128Q optimized for LMKCDEY (using Gaussian secrets)          : 2^(-60)
+    STD128Q_LMKCDEY,      // STD128Q optimized for LMKCDEY                                   : 2^(-60)
     STD128Q_3_LMKCDEY,    // STD128Q_LMKCDEY for 3 binary inputs                             : 2^(-95)
     STD128Q_4_LMKCDEY,    // STD128Q_LMKCDEY for 4 binary inputs                             : 2^(-55)
     STD192_LMKCDEY,       // STD192 optimized for LMKCDEY (using Gaussian secrets)           : 2^(-65)
@@ -81,10 +81,10 @@ enum BINFHE_PARAMSET {
     STD192Q_LMKCDEY,      // STD192Q optimized for LMKCDEY (using Gaussian secrets)          : 2^(-65)
     STD192Q_3_LMKCDEY,    // STD192Q_LMKCDEY for 3 binary inputs                             : 2^(-65)
     STD192Q_4_LMKCDEY,    // STD192Q_LMKCDEY for 4 binary inputs                             : 2^(-105)
-    STD256_LMKCDEY,       // STD256 optimized for LMKCDEY (using Gaussian secrets)           : 2^(-60)
+    STD256_LMKCDEY,       // STD256 optimized for LMKCDEY                                    : 2^(-60)
     STD256_3_LMKCDEY,     // STD256_LMKCDEY for 3 binary inputs                              : 2^(-80)
     STD256_4_LMKCDEY,     // STD256_LMKCDEY for 4 binary inputs                              : 2^(-70)
-    STD256Q_LMKCDEY,      // STD256Q optimized for LMKCDEY (using Gaussian secrets)          : 2^(-80)
+    STD256Q_LMKCDEY,      // STD256Q optimized for LMKCDEY                                   : 2^(-80)
     STD256Q_3_LMKCDEY,    // STD256Q_LMKCDEY for 3 binary inputs                             : 2^(-70)
     STD256Q_4_LMKCDEY,    // STD256Q_LMKCDEY for 4 binary inputs                             : 2^(-50)
     LPF_STD128,           // STD128 configured with lower probability of failures            : 2^(-135)