Concrete v2.7: GPU Wheel, Extended Function Composition and Other Improvements

July 5, 2024

Quentin Bourgerie

We’re excited to announce that Concrete v2.7 introduces the first wheel that can accelerate computations on GPUs! In this new release, we also extend the support for function composition, and add several new features in the Python frontend for the user.

GPU acceleration

For those who have been following our GitHub repository, you know that accelerating Fully Homomorphic Encryption (FHE) on GPUs has been a challenging task. After months of dedicated effort and significant progress, we are thrilled to announce that GPU acceleration for FHE is now officially available to end-users.

Concrete aims to make FHE easy to use, so the developer can leverage its power without an extensive knowledge of FHE or of GPU acceleration. To use GPU acceleration, simply install the Concrete wheel that supports the GPU acceleration and to add the [.c-inline-code]use_gpu[.c-inline-code] option when compiling. You can find the GPU in our Zama public PyPI. There are two repositories: one for the CPU wheels (including nightlies) and one for the GPU wheels. To install the GPU wheel, you just need to specify our GPU repository in the installation command.

pip install concrete-python --index-url https://pypi.zama.ai/gpu

Once the GPU wheel is installed, you need to set the [.c-inline-code]use_gpu[.c-inline-code] option of the compile function to [.c-inline-code]True[.c-inline-code], and the Concrete compiler/runtime will do the rest under the hood to exploit all the available CPUs and GPUs of the host.

from concrete import fhe


@fhe.compiler({"x": "encrypted"})
def myfunction(x):
   ...


myfhefunction = myfunction.compile(inputset, use_gpu=True)

It’s important to note that hosts with GPUs are not always faster than machines with only CPUs. The performance gain depends both on the hardware and the workloads. One key factor is the amount of parallelizable work and its granularity, so workloads heavy on linear algebra, for example, tend to benefit from GPUs.

We have benchmarked this feature running CIFAR-10 on three different systems:

AWS hpc7a.96xlarge with 192 CPU hardware threads
Hyperstack n3-H100x4 with 124 hardware threads and 4 GPU H100
Hyperstack n3-H100x8 with 252 hardware threads and 8 GPU H100

The execution times for this benchmark, in both exact or approximate PBS modes, are as follows:

As we can see, the GPU wheel can be up to 2.5 times faster than the CPU wheel in this use case.

Enhanced function composition

In our previous release, Concrete v2.7, has introduced modules which allow for the composition of multiple functions. However, the support was quite limited as it relied on the simplest algorithm available to select the cryptographic parameters, meaning that the same set of parameters was used for the whole module. Depending on your module, this approach could significantly impact the performance.

Concrete v2.7 improves the modules optimization by using a partition-based approach. This approach allows different crypto-parameters to be used for different parts of the module. By partitioning the graph based on the precision requirements of the subpart, you can optimize independently the different partitions and yield tighter crypto-parameters.

As always, this complexity is completely handled by Concrete. If you already use modules, simply update Concrete and you will benefit from the performance boost.

If you want to have even tighter crypto-parameters, Concrete v2.7 now allows you to specify the actual dependencies between the functions in your modules. This enables the compiler to apply an even more aggressive partitioning, leading to faster execution.

Below is a code snippet showing how to specify dependencies between inputs and outputs. You can find more information on the wiring API here.

from concrete import fhe
from fhe import Wired, Wire, Output, Input


@fhe.module()
class Collatz:


   @fhe.function({"x": "encrypted"})
   def collatz(x):
       y = x // 2
       z = 3 * x + 1
       is_x_odd = fhe.bits(x)[0]
       ans = fhe.multivariate(lambda b, x: b * x)(is_x_odd, z - y) + y
       is_one = ans == 1
       return ans, is_one


   composition = Wired(
       [
           Wire(Output(collatz, 0), Input(collatz, 0)
       ]
   )

Other improvements

Finally, Concrete v2.7 includes several additional minor improvements that you can find on GitHub or in the release note. These improvements don’t require any change in the API, so we encourage you to test our latest releases and enjoy the benefits of these improvements without any additional effort.

Thank you for your continued support and feedback as we strive to make FHE more accessible and efficient for everyone.

Additional links

Star the Concrete Github repository to endorse our work.
Review the Concrete documentation.
Get support on our community channels.
Participate in the Zama Bounty Program to get rewards in cash!

Privacy is necessary for an open society in the electronic age. Privacy is not secrecy. A private matter is something one doesn't want the whole world to know, but a secret matter is something one doesn't want anybody to know. Privacy is the power to selectively reveal oneself to the world.If two parties have some sort of dealings, then each has a memory of their interaction. Each party can speak about their own memory of this; how could anyone prevent it? One could pass laws against it, but the freedom of speech, even more than privacy, is fundamental to an open society; we seek not to restrict any speech at all. If many parties speak together in the same forum, each can speak to all the others and aggregate together knowledge about individuals and other parties. The power of electronic communications has enabled such group speech, and it will not go away merely because we might want it to.Since we desire privacy, we must ensure that each party to a transaction have knowledge only of that which is directly necessary for that transaction. Since any information can be spoken of, we must ensure that we reveal as little as possible. In most cases personal identity is not salient. When I purchase a magazine at a store and hand cash to the clerk, there is no need to know who I am. When I ask my electronic mail provider to send and receive messages, my provider need not know to whom I am speaking or what I am saying or what others are saying to me; my provider only need know how to get the message there and how much I owe them in fees. When my identity is revealed by the underlying mechanism of the transaction, I have no privacy. I cannot here selectively reveal myself; I must always reveal myself.Therefore, privacy in an open society requires anonymous transaction systems. Until now, cash has been the primary such system. An anonymous transaction system is not a secret transaction system. An anonymous system empowers individuals to reveal their identity when desired and only when desired; this is the essence of privacy.Privacy in an open society also requires cryptography. If I say something, I want it heard only by those for whom I intend it. If the content of my speech is available to the world, I have no privacy. To encrypt is to indicate the desire for privacy, and to encrypt with weak cryptography is to indicate not too much desire for privacy. Furthermore, to reveal one's identity with assurance when the default is anonymity requires the cryptographic signature.We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence. It is to their advantage to speak of us, and we should expect that they will speak. To try to prevent their speech is to fight against the realities of information. Information does not just want to be free, it longs to be free. Information expands to fill the available storage space. Information is Rumor's younger, stronger cousin; Information is fleeter of foot, has more eyes, knows more, and understands less than Rumor.We must defend our own privacy if we expect to have any. We must come together and create systems which allow anonymous transactions to take place. People have been defending their own privacy for centuries with whispers, darkness, envelopes, closed doors, secret handshakes, and couriers. The technologies of the past did not allow for strong privacy, but electronic technologies do.We the Cypherpunks are dedicated to building anonymous systems. We are defending our privacy with cryptography, with anonymous mail forwarding systems, with digital signatures, and with electronic money.Cypherpunks write code. We know that someone has to write software to defend privacy, and since we can't get privacy unless we all do, we're going to write it. We publish our code so that our fellow Cypherpunks may practice and play with it. Our code is free for all to use, worldwide. We don't much care if you don't approve of the software we write. We know that software can't be destroyed and that a widely dispersed system can't be shut down.Cypherpunks deplore regulations on cryptography, for encryption is fundamentally a private act. The act of encryption, in fact, removes information from the public realm. Even laws against cryptography reach only so far as a nation's border and the arm of its violence. Cryptography will ineluctably spread over the whole globe, and with it the anonymous transactions systems that it makes possible.For privacy to be widespread it must be part of a social contract. People must come and together deploy these systems for the common good. Privacy only extends so far as the cooperation of one's fellows in society. We the Cypherpunks seek your questions and your concerns and hope we may engage you so that we do not deceive ourselves. We will not, however, be moved out of our course because some may disagree with our goals.The Cypherpunks are actively engaged in making the networks safer for privacy. Let us proceed together apace.Onward. By Eric Hughes. 9 March 1993.