Simplify debug naming of variables in constraints

[matthiasgoergens]

Instead of passing an FnOnce closure with no arguments, we just pass the name itself.

It looks like we copied the old convention from other R1CS proving systems like bellman. But we always execute our closure, rendering the whole exercise pointless, while they only do execute theirs in debug contexts. (Thanks to Ming for the historic context!)

(And even for bellman, it's unlikely they actually get anything out of the extra complexity: making and passing closures around is a lot of work at runtime. And an optimising compiler that can remove an unused closure can also much easier remove an unused string.)

---

I ran some benchmarks. The change ever so slightly speeds up compilation and runtime, and decreases the size of our binaries.

On master:

$ du -h target/*/libceno_zkvm.rlib
4.8M    target/debug/libceno_zkvm.rlib
4.4M    target/release/libceno_zkvm.rlib

On this branch:

$ du -h target/*/libceno_zkvm.rlib
4.7M    target/debug/libceno_zkvm.rlib
4.3M    target/release/libceno_zkvm.rlib

This benchmark is just for fun, the PR is for readability.

[hero78119]

I would say this change definitely worth to explore as we always looking for improve the readibility.

But honestly wrapping them in || <name> closure vs "pure string" looks not that different to me, but with "closure " one benefit is we keeping the door open for further experimenting skipping variable name string in release build, see bellperson

https://github.com/filecoin-project/bellperson/blob/95fd3fc10e740547b53ce8e86a04c49509af6a41/src/groth16/prover/mod.rs#L104-L115

And we can expect it might be help to make binary size smaller if we gonna distribute prover binary into IOT device.

So I would suggest before clear out the thoughts, please on hold this issue and spend effort on other more urgent milestone task. We definitely look back into this issue sometime, and prove we can achieve same effect without "closure" then it will be super nice

[matthiasgoergens]

Closures aren't free to create and pass around, even if you don't use them.

Yes, a clever optimizing compiler can perhaps remove them, but the same techniques would allow the compiler also remove the &str.

And we can expect it might be help to make binary size smaller if we gonna distribute prover binary into IOT device.

Well, the PR branch has about 3% smaller binary sizes than what's currently in master. Exactly because not handling closures is easier for the compiler, I guess.

This is PR mainly for readability, and to avoid our typical cargo culting and tendency to unnecessarily overcomplicate things.

[matthiasgoergens]

@lispc If you want to quickly get PRs into master, here's one that's been sitting for a while. It simplifies our code, without any compromise in performance.

[hero78119]

@lispc If you want to quickly get PRs into master, here's one that's been sitting for a while. It simplifies our code, without any compromise in performance.

I dont think this fit the long sitting for a while PR, especially from my comment above. The closure style didn't bring up readibility issue to me, while with that in key setup/release build, we can eliminate those debugging message. I vote +1 for current bellman style and think we should build idea based on that unless there is a more convinced method to me.

[matthiasgoergens]

Yes, you can get rid of these messages in either style. And the optimiser has a slightly easier job with the plain string than when unnecessarily wrapping it in a closure.

In the common case now we are just passing a reference to a string that's a constant in the binary. Instead of all the heavy machinery necessary to make closures work.

About readability: it's useful to use simple mechanisms when simple mechanisms are sufficient.

Amongst other benefits, this lets the presence of a complicated mechanism alert the reader that something complicated is going on.

Basically, the only reason this is still in the code is because of status quo bias. I hope no one would really suggest going from the simpler system to the overly complicated version we have right now.