Use an array instead of a Vec

[richardpringle]

The Vec was always had the same length. There's no reason to use a Vec here, unless I'm missing something

[richardpringle]

What serializer(s) are we using here and what are the backward compatibility requirements? It's possible that we would prefer to serialize as &[F] instead of [F; 3] to maintain backward compatibility (arrays aren't generally serialized with a length). .

[dannywillems]

Yes, it would probably break compatibility on the serialization level.
However, if the performance is non-negligible, I would be in favor of doing it.

Note that other optimisations can be done at the same time (see below for the contiguous allocated memory or see discussions on Slack to move to Poseidon2 or a Poseidon instance with full/partial rounds), and there is a balance to discuss regarding how/if it would impact the Mina codebase (for instance by requiring a HF).

[richardpringle]

Are there any .sage files that need a similar update?

[dannywillems]

I like the idea.
I think the initial code was using Vec because the specification of Poseidon does not enforce the size of the state; it is only when you instantiate with specific security parameters that you end up with a fixed value - in our case three.

A further optimisation is to get a single contiguous piece of memory that contains:

• the matrix coefficients (32 * 3 * 3 bytes)
• the constant coefficients (3 * 55 * 32 bytes)
• the sponge state (3 * 32 bytes)
  When doing that in C, like here, I remember I got a ~15% perf improvements. This way, the CPU cache is used as often as possible.

[richardpringle]

@dannywillems, there are a lot of round-constants. It's generally not advisable to make stack values that large. I'm not sure I want to make that change (I just needed the inner values of mds to be arrays, I'm not sure I want to make that invasive of a change.

I like the idea. I think the initial code was using Vec because the specification of Poseidon does not enforce the size of the state; it is only when you instantiate with specific security parameters that you end up with a fixed value - in our case three.

A further optimisation is to get a single contiguous piece of memory that contains:

• the matrix coefficients (32 * 3 * 3 bytes)
• the constant coefficients (3 * 55 * 32 bytes)
• the sponge state (3 * 32 bytes)
  When doing that in C, like here, I remember I got a ~15% perf improvements. This way, the CPU cache is used as often as possible.

[richardpringle]

It would also probably make sense to lazily initialize these as constants so we can have &'static [[F; 3]] properties. But I think that'll be easier with a newer version of Rust (once those PRs land)