TFHE-rs v0.2.5 vs v0.3.1 release question

Zama TFHE-rs
1

Hi.

I saw that the new version TFHE-rs 0.3.1 is released. I updated the lib in my current repo from v0.2.5. However, when running a piece of TFHE code in v0.3.1 I noticed that the performance of the new version is 30% slower than the same code in the v0.2.5 version. I am wondering a lot what causes this performance drop. I have tested different hardware, it seems to be the case more or less independent of hardware.

I also saw that the integer implementation has changed, and that you now just specify integers and not the integer type in the config. Before the integer type had to be manually specified, is this the reason maybe?

2

Hello!

Are you using the boolean module? If so, it will indeed be slower, as we updated the parameters and they are slower than the older ones. We had to do this for security reasons, so you should migrate to the latest version and not use the older one anymore. FYI, using 1-bit shortins will be equivalent in terms of features and performance as using booleans, but will be compatible with other shortints. As such, you should almost never need to use the boolean module itself, and do everything with shortints and ints!

3

Thank you for your fast response! I am using the integer module (now I am a little confused since all modules seem to be loaded into the toml file)

That you have updated the parameters makes sense that this is the reason for the performance drop, thanks a lot again for the fast response.

NB: The integers that I want to operate on are large, so I wondered if this also may have some effect on the performance?

4

What hardware did you try ? Specifically how many cores/threads do they have ?

Integers (tfhe::RadixCiphertext / tfhe::FheUint) have been reworked to make heavy use of parallelism, and if your hardware does not have enough threads you will not get the best performances

5

It was run on a standard intel laptop with 8 cores. I noted btw that on the 0.2.4 version the fheuint size had to be specified i.e .enable_default_uint64() , while on the 0.3.1 it was changed to .enable_default_integers()…

6

The new way (enable_default_integers) was made to allow casting between between integer types (e.g. cast a FheUint32 to as FheUint64)

As for a 64 bits integers, 8 cores is not enough to get the true performances of the implementations of all operations.

Which one are you using ?

7

Right, that is what I thought. Enabling such casting makes sense.
I enabled the fheuint64 in both 0.2.5 and 0.3.1.

8

If you dont use booleans, there shouldnt be a slowdown, as the parameters for shortints didnt change. So the issue is probably somewhere else! Can you share the code you’re running?

9

We will re-introduce some checks that, for some operations (-, + mainly) will prefer implementations that are slower than the fully parallelized implementations but friendlier for CPU’s that do not have enough threads to fully/actually benefit from them

1 Like