Extract instr_info & var_info to standard OCaml int

[vbgl]

This seems to be good for performances (of the compiler).

The following table reports compilation times (in seconds) for .jazz files in libjade and the corresponding (base-2) speed-up.

Thanks Tiago for the jtiming script in libjade!

path                               before   after    change
────────────────────────────────────────────────────────────
onetimeauth/poly1305/ref             0.08     0.08     0.0
hash/sha3-224/avx2                   0.94     0.93     0.02
hash/sha3-256/avx2                   0.94     0.93     0.02
hash/sha3-384/avx2                   0.94     0.93     0.02
hash/sha3-512/avx2                   0.94     0.93     0.02
stream/chacha/chacha12/avx           5.82     5.65     0.04
stream/chacha/chacha12/avx2          5.74     5.59     0.04
stream/chacha/chacha20-ietf/avx      5.79     5.63     0.04
stream/chacha/chacha20-ietf/avx2     5.72     5.57     0.04
xof/shake128/avx2                    1.11     1.08     0.04
xof/shake256/avx2                    1.11     1.08     0.04
stream/chacha/chacha20/avx           5.83     5.64     0.05
stream/chacha/chacha20/avx2          5.74     5.55     0.05
xof/shake256/ref1                    0.15     0.14     0.1
xof/shake256/spec                    0.3      0.28     0.1
kem/kyber/kyber512/avx2              8.71     7.99     0.12
stream/xsalsa20/avx2                 2.19     2.01     0.12
scalarmult/curve25519/ref4           1.25     1.14     0.13
secretbox/xsalsa20poly1305/avx2      4.04     3.7      0.13
stream/salsa20/salsa20/avx2          1.5      1.37     0.13
stream/xsalsa20/avx                  1.9      1.74     0.13
kem/kyber/kyber768/avx2             11.75    10.63     0.14
secretbox/xsalsa20poly1305/avx       3.77     3.42     0.14
stream/salsa20/salsa2012/avx         1.26     1.14     0.14
stream/salsa20/salsa2012/avx2        1.5      1.36     0.14
hash/sha3-224/ref                    0.6      0.54     0.15
hash/sha3-384/ref                    0.6      0.54     0.15
stream/salsa20/salsa20/avx           1.26     1.13     0.16
xof/shake256/ref                     1.24     1.11     0.16
xof/shake128/ref                     1.25     1.11     0.17
hash/sha3-256/ref                    0.61     0.54     0.18
hash/sha3-512/ref                    0.61     0.54     0.18
stream/salsa20/salsa2012/ref         0.45     0.39     0.21
onetimeauth/poly1305/avx             0.57     0.49     0.22
secretbox/xsalsa20poly1305/ref       1.5      1.29     0.22
scalarmult/curve25519/ref5           1.23     1.05     0.23
stream/chacha/chacha20/ref           0.27     0.23     0.23
stream/salsa20/salsa20/ref           0.46     0.39     0.24
stream/xsalsa20/ref                  0.77     0.65     0.24
onetimeauth/poly1305/avx2            0.51     0.43     0.25
scalarmult/curve25519/mulx           2.09     1.73     0.27
stream/chacha/chacha20-ietf/ref      0.28     0.23     0.28
stream/chacha/chacha12/ref           0.28     0.22     0.35
hash/sha256/ref                      0.68     0.48     0.5

[tfaoliveira]

This seems to be good for performances (of the compiler).

The following table reports compilation times (in seconds) for .jazz files in libjade and the corresponding (base-2) speed-up.

Thanks Tiago for the jtiming script in libjade!

Anytime! I have a question about the 'change' column. How it is being computed? We could try to include that computation on some script under libjade/scripts/ci to produce this kind of report systematically.

[vbgl]

I’ve run jtiming twice, writing two CSV files (before.csv and after.csv), then the following Julia program produced that table:

using CSV, DataFrames

function main()

  before = DataFrame(CSV.File("before.csv", header=[:path, :before]))
  after = DataFrame(CSV.File("after.csv", header=[:path, :after]))

  both = innerjoin(before, after, on=:path)

  return sort(select(both, :, [:before, :after] => ByRow((x, y) -> round(log(x/y)/log(2); digits=2)) => :change), order(:change))
end

@show main()

[bgregoir]

Hi Vincent,
I think this commit goes into the good direction.
I have a small question: why do you extract var_info to "int" instead of the ocaml var_info ?
I think this will allows to remove the conversion in Conv.ml.

[vbgl]

Thanks for the suggestion. Last commit does remove the vari table in Conv.

[eponier]

Thanks for the suggestion. Last commit does remove the vari table in Conv.

Out of curiosity, why did you do this move for var_info and not instr_info? Performance-wise, it's pretty clear that it was more worth to do it for var_info, but for consistency reasons, it seems to me that it would have been good to do it too for instr_info.

[vbgl]

Yes, this deserves a sequel.

[bgregoir]

Agree, with you. Maybe we should ask Frederic I think he uses the fact that instr_info are positive and uses them as "instruction label"