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
The linear mapping tables for squaring/squarerooting/solving x^2+x+a/converting between field representations are currently all encoded very compactly in the C++ code, and get expanded at compile time (through constexpr) into full lookup tables.
Given that the compact encoding (mapping of every power-of-two) is already generated using Sage code, and we have little hope of avoiding that, I wonder if we shouldn't drop the whole constexpr construction, and instead generate the full expanded tables directly in Sage. That would massively increase the source code size, but probably cut down compilation times too (and perhaps enable a few small optimizations too).
One reason to not do this is if we'd want to make the layout of the tables dynamic (for example, we realize that on certain hardware constructing the table using 6-bit lookups is sufficiently suboptimal that we want to use a different layout there). If the tables are stored in expanded form, that would require duplicating the tables.
The text was updated successfully, but these errors were encountered:
The linear mapping tables for squaring/squarerooting/solving x^2+x+a/converting between field representations are currently all encoded very compactly in the C++ code, and get expanded at compile time (through
constexpr
) into full lookup tables.Given that the compact encoding (mapping of every power-of-two) is already generated using Sage code, and we have little hope of avoiding that, I wonder if we shouldn't drop the whole constexpr construction, and instead generate the full expanded tables directly in Sage. That would massively increase the source code size, but probably cut down compilation times too (and perhaps enable a few small optimizations too).
One reason to not do this is if we'd want to make the layout of the tables dynamic (for example, we realize that on certain hardware constructing the table using 6-bit lookups is sufficiently suboptimal that we want to use a different layout there). If the tables are stored in expanded form, that would require duplicating the tables.
The text was updated successfully, but these errors were encountered: