Read-only tables performance

[lukego]

I am very interested in the read-only tables feature. I have seen promising results in a microbenchmark (https://github.com/LuaJIT/LuaJIT/issues/248#issuecomment-269988067) and now I am testing with a real application (Snabb).

Initial scores are low on my simplest Snabb benchmark. Baseline score is 27, merging the readonlytables branch (commit 68515a2ea3cc4a2b0570a02679413a47d7512fa5) this drops to 7, and adding a couple of calls to table.setreadonly() that I expected to be beneficial dropped the score to 0.1. So the opening position is a 270x slowdown and I am keen to improve on this :-)

Just quick questions if I may:

• Is readonlytables the right branch? I also see readonly_tables.
• Any loose ends in the implementation that I should be aware of?
• Any immediate idea on what could cause a performance drop even when not calling table.setreadonly()?

Cheers!

[lukego]

Step to reproduce JFYI:

$ git clone -b jit-readonly https://github.com/lukego/snabb
$ make -C snabb -j
$ sudo snabb/src/snabb snsh -jv -p snabbmark basic1 10e6
Processed 10.0 million packets in 68.06 seconds (rate: 0.1 Mpps).

[fsfod]

Is readonlytables the right branch? I also see readonly_tables.

I thought I hadn't pushed it from a separate repo before.

Any loose ends in the implementation that I should be aware of?

It was more proof of concept I only tested simple examples work.

Any immediate idea on what could cause a performance drop even when not calling table.setreadonly()?

The most likely answer is my changes might be causing a bad guard to be emitted that always fails or I might be causing traces to be always aborted for some reason. You can try just the first commit on its own since it only touch the interpreter which in theory should 0 to almost no slowdown. The collocated table size field for marking a table readonly could be getting some weird collision i didn't correctly check for