It appears that -jv is like a summary version of -jdump. -jdump lists, for each trace, the Lua opcodes that it reads; if the trace succeeds, it additionally shows the intermediate representation in 3AC (used in optimization) and the final machine code. The Lua opcodes are the same you get when you use -b -l; they are the disassembled version of the binary code that the interpreter uses. I don't understand the IR much (haven't bothered to try), but the final compiled code is sometimes useful (if you understand the assembly code for the target processor).nameless tee wrote: ↑Tue Jan 07, 2020 2:58 ampgimeno: After reading your post I tried to understand the output of luajit -jdump and luajit -jv but without much success.
In this case, the output of -jv is probably enough. The preprocessor of course has a lot of NYI instructions that break the traces, that's expected.
Funnily, I get a lot of different traces. It really looks as if LuaJIT introduces some kind of randomness on purpose; another hypothesis is that minor variations of the CPU timings (which are somewhat random as they are influenced by e.g. what's running in the background) make a difference. Here are two sample runs, omitting the preprocessor related lines:
Code: Select all
[TRACE 2 hateful.lua:20 loop]
[TRACE 3 (2/3) hateful.lua:19 -> 2]
[TRACE --- 0x414a3970:25 -- leaving loop in root trace at 0x414a3970:28]
[TRACE 4 0x414a3970:25 loop]
[TRACE 5 (4/3) 0x414a3970:28 -> 4]
[TRACE --- 0x414ac050:194 -- leaving loop in root trace at 0x414ac050:198]
[TRACE 6 (5/2) hateful.lua:28 -> 4]
[TRACE 7 hateful.lua:25 -> 4]
[TRACE 8 (3/1) hateful.lua:24 -> 7]
[TRACE 9 (6/5) hateful.lua:28 -> 2]
[TRACE 10 0x414ac050:194 loop]
Code: Select all
[TRACE --- hateful.lua:20 -- leaving loop in root trace at hateful.lua:19]
[TRACE 2 hateful.lua:20 loop]
[TRACE 3 (2/3) hateful.lua:19 -> 2]
[TRACE 4 0x41e2e328:25 loop]
[TRACE 5 (4/3) 0x41e2e328:28 -> 4]
[TRACE 6 (5/2) hateful.lua:28 -> 4]
[TRACE 7 hateful.lua:25 -> 4]
[TRACE --- 0x41e2e9c8:194 -- leaving loop in root trace at 0x41e2e9c8:198]
[TRACE 8 (3/1) hateful.lua:24 -> 7]
[TRACE 9 (6/5) hateful.lua:28 -> 2]
[TRACE --- 0x41e2e9c8:194 -- leaving loop in root trace at 0x41e2e9c8:198]
15022020.071668
One thing I'd advise is to use numeric indices instead of structs, e.g. v[1], v[2], v[3] (or v[0], v[1], v[2] if you don't want compatibility with tables) instead of v.x, v.y, v.z. AFAIK structs still use hashing.nameless tee wrote: ↑Tue Jan 07, 2020 2:58 am Apparently LuaJIT really hates loops longer than two that use ctypes.