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
I noticed from the documentation that cmux cost + comparison operator cost was lesser than TFHE.max and TFHE.min which does not make sense.
I have just confirmed with a simple experiment on Remix using this contract :
contractCmuxComp {
uint32public maximum;
constructor() {}
function cmuxcomp(uint32x, uint32y) external {
euint32 xx = TFHE.asEuint32(x);
euint32 yy = TFHE.asEuint32(y);
ebool comp = TFHE.gt(xx,yy);
euint32 maxx = TFHE.cmux(comp,xx,yy);
maximum = TFHE.decrypt(maxx);
}
function max(uint32x, uint32y) external {
euint32 xx = TFHE.asEuint32(x);
euint32 yy = TFHE.asEuint32(y);
euint32 maxx = TFHE.max(xx,yy);
maximum = TFHE.decrypt(maxx);
}
}
Calling max here costs me almost 25% more than calling cmuxcomp which shows that we have either :
1/ Misspriced the fhevm operators in gas .
2/ Found a bug or an inefficiency in tfhe-rs library
The text was updated successfully, but these errors were encountered:
I noticed from the documentation that cmux cost + comparison operator cost was lesser than TFHE.max and TFHE.min which does not make sense.
I have just confirmed with a simple experiment on Remix using this contract :
Calling max here costs me almost 25% more than calling cmuxcomp which shows that we have either :
1/ Misspriced the fhevm operators in gas .
2/ Found a bug or an inefficiency in tfhe-rs library
The text was updated successfully, but these errors were encountered: