zeekay 787284d140 mpcvm/fhe: one device round trip, three kernels ...

BatchNTTForward, BatchNTTInverse and BatchPolyMul were three copies of one
loop — snapshot the session, allocate operand tensors, run a kernel, sync, read
back, copy out, and on any failure at any step close what is open and do the
operation on the CPU instead. ~45 statements each, differing in how many
polynomials an element reads, which kernel runs, and what the CPU does instead.
Three copies of a resource lifecycle are three places to forget a Close, and a
fourth kernel would have been a fourth copy.

Now one offload plus one element, and three wrappers that name their three
differences. 101 lines go, no behaviour with them.

The floors are deliberately NOT unified: forward NTT reaches the device at 64
polynomials and ring degree 8192, the other two at 4 and any degree, and the
reasoning written on the forward path applies to all three. That reads as
drift, but changing a performance threshold needs a device to measure on and
this host has none, so the numbers are carried through as parameters and the
disagreement is stated where the next reader will see it.

Also drops the count == 0 guard, which count < minBatch already subsumes for
every floor; reverting it changed no test result, which is what redundant
means.

2026-08-28 15:02:56 -07:00

..

main_test.go

mpcvm/fhe: one device round trip, three kernels

2026-08-28 15:02:56 -07:00

main.go

mpcvm: M-Chain to 98.6%

2026-08-28 13:25:30 -07:00